プログラマの思索

Redmineを運用して気づいたことを書いてみる。

【元ネタ】
ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回　運用の開始｜gihyo.jp … 技術評論社

ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回　BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社

[redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06)

【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる

Redmineによるチケット管理で重要な概念はトラッカー。
Redmineのトラッカーは、チケットの種類を意味する。
デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。
バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分ければよいだろう。

Redmineでは、管理画面にあるワークフロー画面で、先行ステータスと後行ステータスのマトリクスでチケットの状態遷移を定義できる。
このチケットの状態遷移は、トラッカー単位、更にユーザーのロール単位で切り替えることができる。

Tracのワークフローよりも勝るRedmineの利点だと思う。

このワークフロー画面がプロジェクトリーダーにとって、自身のチームのSW開発フローを定める重要な機能になる。
プロジェクトリーダーは、何種類の運用フローを意識して管理しているか、が、この画面で一目で分かる。
レベルの低いプロジェクトリーダーは、ウォーターフォール型開発の1種類の運用フローしか持っていないから、結合テスト以降で苦労するだろう。

普通のSW開発では、障害修正と仕様変更の運用フローは異なる。
障害修正は、一つのバグ報告票に対して、PGとテスターが交互に修正＆検証し合う。

仕様変更は、設計者・PG・テスターの3人が必要なため、バグ修正よりもはるかに複雑になる。
設計者が仕様の方針決定の後に、PGのソース修正が始まるから、障害修正よりもフローが長くなる。
この運用フローを意識して使いこなせれば、Redmineの強力な変更管理機能のおかげで、作業状態を追跡するのが簡単で、運用後に履歴として簡単に検索できる。

更に、新規開発の場合も上記と異なるだろう。
新規開発は何も無い所から実装するため、要件定義や設計がより重視される。
だから、その工程のためのステータスが必要になるだろう。

僕は、TestLinkで判明したバグ修正フローをRedmineにのせた場合、運用フローを変えた。
普通は、新たなステータスが発生するタイミングは、担当者が増えた場合だ。
１ステータス＝１担当者として管理した方が楽だから。

【2】フィードバック、却下になったチケットは要注意

プロジェクト管理をチケット管理に置き換えて運用して、色々面白い現象に気付く。

PGがバグ修正したものの、テスターが検証するとNGになる場合がある。
その時に、フィードバック(差し戻し)というステータスが発生する。

僕が運用してみて気付いたことは、フィードバックになったチケットは、フィードバックを2回以上繰り返す確率が高くなる。
つまり、何度修正しても、テスト漏れや仕様漏れが発覚して、なかなか終了しない時がある。
殆どの原因は仕様漏れ、設計漏れが多いため、PGのミスとは言い難い。
だから、フィードバックのチケットは、根本原因を探るために細心の注意を払う必要がある。

あるいは、テスターがバグとして起票したチケットが、実は仕様通りと判明する場合がある。
その時に、却下というステータスが発生する。

却下の場合は、根本原因を探るのが重要。
チケット発行者が仕様を理解していない場合なら、技術力が低いか、設計者が仕様をきちんと説明していなかったのが根本原因だろう。
テストケースや設計書そのものが間違っていたのが原因ならば、設計工程の成果物の品質が低い可能性が高い。

いずれにしても、上流工程や運用フローに問題があるため、根本的な問題に対処しないと同じ過ちを繰り返す可能性が高い。

【3】複数のチケットを関連させる

バグが他のバグと関連しているため、チケット同士にリンクさせたい時がある。
Redmineのチケット欄には、追加というリンクがあり、ここにチケットIDを入力すればリンクできる。

Redmineの関連チケットの種類は下記4種類がある。

4-1.単なる関連 (related up) : 単に関係していることだけを表す
4-2.重複 (duplicates) : 同期してクローズされる
4-3.ブロック (blocks) : ブロックしている問題がクローズされないとブロックされた問題はクローズできない
4-4.先行 (precedes) : スケジュール的な前後関係を表す

よく使われるのは「単なる関連」。

二つのチケットの原因と修正方針が全く同じならば、「重複」を使う。
このケースは、一つのチケットの修正で他チケットのバグも直る場合に使う時が多いだろう。
「重複」されたチケットは、元チケットが終了ステータスになったタイミングで、終了になるので便利。

「ブロック」を使うケースは、別チケットの修正が終わらないと修正できない状況。
例えば、Amazonのように、カート画面で重大なバグが発生した場合、注文フローのテストやバグ修正は行っても、再検証の必要があるから、ブロックにして保留にしておく。
つまり、ブロックしている問題が終了してから、ブロックされた問題を終了できる。
「先行」も同様に使えるだろう。

ブロックの使い道は、変更要求の親チケットと複数タスクの子チケットの関連に使えるかもしれない。

チケット管理を上手に運用できないと、すぐにチケットは乱発されて放置されて、泥沼に陥りやすい。

10人以上のチームや複数チームで運用している場合は、Redmineのチケットを管理するだけの専門担当者をアサインする必要があるだろう。
更には、一つのチケットの修正方針を、管理者だけで判断できない状況が増えたら、ITILの言うCAB（Change Advisory Board：変更諮問委員会）」を開催して、複数の関係者と相談して決めざるを得ないだろう。

チケット管理こそがチケット駆動開発の肝。