Redmineのトラッカーやステータスの付け方
Redmineのトラッカーやステータスの付け方の記事があったのでメモ。
【元ネタ】
Redmine チケットのトラッカーとステータス項目の意味と設定 - developer
(引用)
* トラッカー
o ドキュメント
+ ドキュメント書き。
o 調査・検証
+ 調査、検証、研究など。
o 機能
+ 機能の追加や変更など。
o 不具合/バグ
+ バグや不具合登録する。
o 要望
+ ユーザーからの要望。
+ 後で「機能」や「バグ」に変化する可能性がある。
o サポート
+ ユーザーからの問い合わせは、とりあえず登録。
+ 後で「要望」や「バグ」に変化する可能性がある。
o 障害
+ なんらかの障害が発生したら、とりあえず登録。
+ このチケットに関連した「不具合/バグ」のチケットが後から追加される可能性あり。
o 環境
+ 環境構築・環境整備や設定変更など。
o アイデア
+ アイデアを登録。
o タスク
+ 上記以外は全てタスクにする。
+ タスクのトラッカーが多い場合は、トラッカーの項目を見直す必要あり。
* ステータス
o 未着手
+ 新規登録したチケットのデフォルトステータス。
o 作業に着手
+ 担当者が作業を行っている状態。
o 対応待ち
+ なんらかの対応を待ってからではないと進められない保留状態。
o 保留
+ 対応待ち以外の保留状態。
+ 保留状態が長く続くようであればチケットを見直す事も必要。
o 作業終了(review待ち)
+ 担当者が作業を終了した状態
+ 担当変更(作業者⇒レビューを行う人)
o フィードバック(差戻し)
+ 差し戻す場合に。
+ 担当変更(差し戻し先に)
o 終了
+ チケットを完全にクローズ。
o 却下(終了)
+ 作業を行わずに終了。
+ チケットの目的を果たす必要が無くなったもの。
+ チケットを誤って登録した場合など。
MyNETS - Ticket - Usagi Project Redmine
(引用)
o 「バグ」チケット
バグと認められたものを登録する。公式ドキュメントの誤りも「バグ」とする(ドキュメントの作成・更新作業は「ドキュメント」チケットを登録する)。
チケットをみるだけで、バグの修正ができるように、バグの詳細について再現手順を記載する。
o 「機能」チケット
実装することが決まったものを登録する。仕様を記載する。チケットを見て、その機能がどういうものかわからない場合は、説明を追加するように担当者に依頼する。仕様不明でテスターがテストできない場合も同様。
o 「ドキュメント」チケット
公式ドキュメント作成・更新に関するチケットを登録する。
o 「要望」チケット
要望を忘れないようにするために登録する。一般に記載できる掲示板(例:サポート掲示板等)・開発SNS日記・今後作られる掲示板等で開発SNSメンバーがこれは面白いと思う要望の内、日記などで寸評交え叩いてみて反響があった等の提案について、チケットを発行する。
o 「タスク」チケット
プロジェクト管理に必要なタスクを把握・管理するために登録する。
「Redmineによるタスクマネジメント実践技法」にはトラッカーやステータスの重要性について色々書きましたが、トラッカーやステータスのテンプレートは提起していません。
その部分は、自分たちが話しあったり、試行錯誤しながら作った方がフィットすると思うからです。
トラッカーはワークフロー管理そのもの。
開発プロセスの観点では、トラッカーが非常に重要。
現場リーダーがトラッカーのバリエーションをどれだけ保持して効果的に運用出来ているか、を見れば、そのプロジェクトの状態やシステムの品質も推測しやすいだろうと思う。
トラッカーは多すぎればメンバーに浸透しにくいし、トラッカーを複雑にすると、実際の運用がうまくいかない。
そのバランス加減を実際のたくさんの現場で見てみたいところでもある。
ステータスはワークフローの状態を指す。
ステータスは普通は作業者が切り替わるタイミングで発生する。
例えば、テスターがバグを起票して、開発者がソースを修正してコミットして、テスターが再検証する。
開発者が実装済みなら、設計者がレビューする。
開発者が仕様の不明点を起票して設計者が回答して送り返す。
その作業フローを「Redmineによるタスクマネジメント実践技法」では「ペア作業」と呼んでいる。
実際、場所も時間も離れていても、一つの成果物を二人以上の目を通すことで品質をチェックする利点がある。
従来はExcelで、開発中・検証中・レビュー中・リリース完了などのステータスを管理台帳で管理していたから、共有しにくいし、最新化しづらい。
このステータスを管理して最新化するために、現場リーダーの仕事の大半は割かれていると言っても過言ではない。
その作業はRedmineやTracのようなITS上でリアルタイムに最新化されて、全てのメンバーが共有されるべきものだと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント