チケット駆動開発の流れ。

tracでのチケットを利用した開発の流れを見ていきます。

全体像として下図のチケットフローを想定します。

プロジェクト参加者は、管理者(PM)、リーダー(SE)、実装者(PG)です。
1.登録されたチケットを担当者に割当て
new → assigned
2.登録時点で担当者が割当てられていたチケットを担当者が着手する
new → accepted
3.登録されたチケットが既に対応済、不正な内容、対応しない、重複して登録されている、再現しない等対応しない場合
new → resolved
4.割当てられたチケットを担当者が着手する
assigned → accepted
5.担当者に割当てたチケットが既に対応済、不正な内容等対応しない場合
assigned → resolved
6.着手したチケットの対応が完了した場合
accepted → resolved
7.対応されたチケットの内容が正しく確認できた場合、または、対応しない内容が確認できた場合
resolved → closed
8.対応されたチケットの内容が確認できなかった場合
resolved → reopened
9.担当者が差し戻されたチケットを再度着手
reopened → accepted
10.差し戻されたチケットを担当者に割当てる
reopened → assigned
11.差し戻されたチケットが既に対応済、不正な内容等対応しない場合
reopened → resolved
初期のTracには、ステータス「解決:resolved」がワークフローにありません。
「解決:resolved」を追加します。




追加した解決をワークフローに乗せます。下図を参考にしてください。
変更ボタンでそれぞれのステータスの内容が変更できます。


修正が終わったら、最後に「変更を適用」します。


秋元さんログイン後の画面。
チケットを登録します。


ステータスは「登録:new」です。


秋元さんは問題(バグ含む)を管理する立場なので、どのプログラムを修正するかは担当SEに任せます。
ここでは、担当SEの高橋さんに担当者を変更します。


担当者が高橋さん、ステータスが「担当者割当:assigned」になりました。


高橋さんログイン後の画面。
自分の担当しているチケットが表示されています。


実装者である前田さんに担当を変えます。


修正に関連するプログラムを記入しました。関係者に自分を含めておきます。


ステータスは「担当者割当:assigned」のままです。


前田さんログイン後の画面。
自分の担当しているチケットが表示されています。


実装者は、実際にプログラムを修正するタイミングでスタータスを「着手:accespted」に変えます。


ここから先は実際のプログラム修正作業⇒単体テストになります。
SubVersionを利用しますが、ここではワークフローのみの説明にします。


修正が終わったので、ステータスを「解決:resolved」にしました。


高橋さんログイン後の画面。
前田さんが修正したプログラムの受け入れを行います。


受け入れた結果が思わしくないので、差し戻しました。「reopend」


前田さんログイン後の画面。
再び、プログラムを修正して「解決:resolved」に。


今度は問題なかったので、チケットを「完了:closed」にします。


関係者を秋元さんにしました。


カスタムクエリを利用すれば、いろいろな検索条件で参照できます。


以上で終了です。

(記事を書いた日:2014/05/14)