« Strutsの終焉 | トップページ | アジャイル開発とソフトウェアプロダクトラインの関係 »

2010/11/20

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上でリアルタイムに最新化されて、全てのメンバーが共有されるべきものだと思う。

|

« Strutsの終焉 | トップページ | アジャイル開発とソフトウェアプロダクトラインの関係 »

プロジェクトマネジメント」カテゴリの記事

Redmine」カテゴリの記事

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: Redmineのトラッカーやステータスの付け方:

« Strutsの終焉 | トップページ | アジャイル開発とソフトウェアプロダクトラインの関係 »