Redmineを使って気付いたことpart6～チケットの発生源

Redmineでチケット駆動開発を始めて、チケットの発生源について考えてみた。
以下ラフなメモ書き。

【1】チケット駆動開発では、タスクをチケットに起票してから作業を始める。
イテレーションに含まれるチケットは限界があるから、１イテレーションで実現できる機能は限定される。

しかし、１イテレーションに入り切らないぐらい膨大なタスクが発生する時がある。
そうなってしまうと、もはやチケット駆動開発だろうがアジャイル開発だろうが、タスクは発散しがちでプロジェクトは壊れた飛行機のようにふらついているだろう。

そうならないために、プロジェクトリーダーは、チケットの発生源をいつも気にする必要がある。
チケットの発生源はタスクの発生源であるから、タスクを増やさないためには何を処方したらよいか、というリスク管理につながる。

【2】チケットの発生源は、SW開発の工程によって異なる。

例えば、動くプログラムも無い状況で開発し始めた場合、殆どのチケットは要件定義書に基づいた機能の新規実装であり、おそらくスケジュールに引かれたWBSから作られるだろう。
この場合のチケットのトラッカー(種類)は、新規実装とか、エンハンスメントとか呼ばれるものに相当するだろう。
発生源は、要件。
つまり、ウォーターフォール型の開発に似ている。

あるいは、動くプログラムが殆ど出来上がり、結合テストからシステムテストに至るまでの工程では、TestLinkによるNGのテストケースがRedmineチケットの発生源になる。
つまり、テストしたらNGでバグが出たら、チケットをバグ報告票として起票して管理する。
この場合は、まさにバグ管理システムとしてRedmineを使っているだろう。
発生源は、テストケース。

更に、1次開発のリリース後、システムが本番運用されると、パスワードを忘れた、とか、あの業務をこの画面でやると動作がおかしい、などの問合せが顧客から来る。
すると、それぞれの問合せに対して、チケットへ起票して、一時的な対策を施したり、根本原因を調査して是正対策を行うなどの処置が必要になってくる。
発生源は、インシデント。

現在の自分の環境では、TestLinkからRedmineへの連携はスムーズのため、バグチケットの発生源がTestLinkのどのテストケースなのか、は追跡できる仕掛けになっている。

これによって、「ソース→SVNリビジョン→Redmineチケット→TestLinkテストケース」まで追跡できるから、その発生源の付近に他にどれだけのチケットがあるか、とか、発生源を解決する別の対処方法を更にチケットへ起票する、などの対策を取れる。

【3】チケットの発生源とトラッカー(チケットの種類)は密接に関係する。
要件、テストケース、インシデントの発生源に対し、それぞれのトラッカーがマッピングされて、それぞれのチケットは特有のステータスの遷移で制御される。

おそらく、発生源がテストケースの場合は追跡のインフラを作るのは簡単。
何故なら、テストNGによるバグ解決フローは、バグ管理システムの基本フローそのものだから。
むしろ難しいのは、要件管理とインシデント管理。

XPのタスクカードがチケットであるならば、要件管理は結局、XPのストーリーカードは構成管理インフラのどの機能へ配置されるべきか、という問題に辿り着く。

TestLinkの要件管理機能が使えるならば、「ソース→SVNリビジョン→Redmineチケット→TestLinkテストケース→TestLink要件」まで追跡可能で、要件カバレッジという新しい観点でシステムの品質をチェック可能になる。

インシデント管理は、チケットの状態遷移が異なるため、どのようなワークフローで制御すべきか、という問題に辿り着く。
更に、インシデントから抜本的対策が必要だと意思決定した場合、新たな変更要求が生まれ、そこから2次開発につながっていくだろう。

つまり、インシデント→変更要求→新規実装のような流れ。
従って、親チケットはインシデント又は変更要求、子チケットは複数の新規実装、のようなチケットの親子関係が発生する。
子チケットにある全ての新規実装のチケットが完了して初めて、親チケットの変更要求は終了になるなどの制約条件が更に発生する。

上記の例のように、チケットの発生源は多岐に渡る。

チケットからその発生源へ追跡できる環境があれば、チケットに書かれた作業の根本的な対策は何か？を担当者自身が考えるきっかけになりうる。