Remine規約.txt

【最初に】
Redmineは、使いこなせれば有用なプロジェクト管理ツールですが
全員がきっちり入力を行ってこそ力が発揮されます。ご協力よろしくお願いします。

【Redmine閲覧】
・メール通知は「ウォッチもしくは関係している事柄」以上のレベルで常時確認すること
・できれば「参加しているプロジェクトの全ての通知」を選択推奨

【チケット登録】
・依頼は、「すぐにチケット化する」こと
・チケット化する人は、担当外の人でも構いません
・チケットのタイトルは、開発案件の場合は、その作業が完了することで、ユーザーが何ができるようになるのかわかるようなタイトルにしましょう。
・説明は、「入力必須」です。要望だけでなく、どうして、なんのためにやるのかの記載も必要です。なぜな、それは、本当に必要なことなのか自問自答する機会でもあり、担当者には、動機とクリエイティビティの幅を与えるからと思います。
・チケットのウォッチャーで、関連するメンバーにチェックを入れておくこと
・担当者はチケットが割り振られたら、細目とゴール（クローズの条件）を埋めて作業にとりかかること
・ゴールは、漠然としたものになりやすい。管理者と担当者は、どこまでやればゴールなのか、ゴールの位置が不明にならないように話し合って決めてください。
・ちなみに、作業すれば、ソースであったり、設計書であったり、そういったものを作らない系だったら、作業ログでもよい、そういった成果物の作成をもってゴールとすると、終わったことがわかりやすい、作業自身も管理側も終了判断しやすいです。
・タスクチケットの大きさは「３日以内」になるよう分割してください
・対象バージョンで1～2weaks（締切り）のまとまった期間をスプリントとして設けること
・チケット単位で、期日を管理せず、スプリント内のタスクの量を調整すること
・チケットのテンプレートを用意して、記入事項を明確にするとよいでしょう。

【作業進捗報告】
・優先度の高いチケットからとりかかること
・作業は基本的に「二人組」で取り掛かり、担当者とウォッチャーで情報共有すること
・作業ログ（進捗）、告知案内など毎日欠かさず入力すること
・作業時間を記録は、今のところしない方向で。（PMから要望がなければ。）
・進捗率の入力は、今の所しない方向で。（進捗率は、作業担当者の感覚的なものであり数量的に導き出せるものではない。例えば、90%でも、すぐ終わらずに、そこから進まなくなるケース多く、曖昧で信憑性にかける情報である。それよりタスクを細かく分けるようにした方がよい。PMから要望がない限り入力しない。）
・作業が終了したらステータスを「レビュー中」に、担当を「管理者」にします。管理者は、作業を確認したら、完了、フィードバック、破棄するかの終了判断を行ってください。（チケットのワークフロー図解）
（そうすると、完了したチケットは皆、担当が管理者になり、誰が担当だったのかわかりにくくなるのが悩ましい）
・管理者による作業の受け入れ検証は必ずおこなってください。忙しいなら自分の他の負担を減らすように上長に相談してください。
・確認事項や進捗を止めるような課題が発生した場合は、新たに課題チケット（障害チケット）を作成してください。
・クローズしたチケットがフィードバックに戻っていたら、指摘事項に対応してください。
・一人の担当者の進行中のチケットは一つになっていることが理想です。今、誰が何をしているのか明瞭になります。
・会議、口頭、Slack等のチャットは、情報が流れてしまうので、それらの中で決まったことはチケットに記載するようにしましょう。

【作業確認】
・週次のミーティングで報告することは、全てredmineにも記述すること
・チケットの棚卸しを週次で行い、クローズ漏れがないか確認すること
・なかなかクローズされないチケットがあったら、仕事量が、みあってない可能性があるので、子チケットに分割してください
・期日の調整も行ってください。作業し始めたら、おもったよりたいへんだったというケースはよくあります。
・担当カテゴリ、ステータス、優先度から自分がやるべき仕事を定期的に見直すこと
・進捗に遅れがあるチケット、放置されているチケットには、何かしら問題が起こっています。絶対、見逃してはいけない要注意チケットです。作業者自身に何らかのフォローを差し伸べる必要があります。

【最後に】
・これをよりSCRUM的、かつ、軽量に、すすめたい場合は、Redmine Backlogプラグインを導入することをお勧めします。
・チケットの単位で、PDCAサイクルを回すつもりですすめてください。（Action＝改善ついては、週次の方がよい）