チケット駆動開発の運用例part3

チケット駆動開発の運用例を見つけたのでメモ。

【元ネタ1】
[tech]チケット駆動開発 - Kazumi007の日記

特徴は下記の通り。

・開発環境は、CVS＋Jira。
・タスクはチケットを切り、CVSコミット時は必ずチケットNoを入力する。
・Jiraの柔軟なワークフロー管理機能を使って、SW開発全体のタスクを管理する。
・Jiraのチケットのサブタスク機能(1レベル下のサブタスクを登録可能)を使い、親チケットはストーリーカード、子チケットはタスクカードのように運用する。

TiDDで良かった点で、「情報がJIRAに集まるため、ますますJIRAに情報が集まるようになった。」という感想が素晴らしい。
インターネットでは、情報をたくさん出すページに情報がどんどん集まる。
JiraがSW開発の情報収集・出力のハブになっている良い運用例。

「ゴールの見えないチケット」「有効期限切れのチケット」という言葉も素晴らしい。
当初はタスクをチケット登録しても、放置されるチケットも多々ある。
それらのチケットは随時メンテナンスして、クローズするか却下していく。
いわゆるチケット保守という作業は、現場リーダーが担当すべきなのだ。

厳密なワークフローの罠も、なるほどと思わせる。
現場に密着しない上級管理職が定義した厳密なワークフローは、現場では運用しづらい。
すると、誰もチケットを登録したり更新しないようになり、せっかくのチケット駆動開発も生きなくなる。
僕は、リリース後のふりかえりミーティングで、ワークフローの感想をKPTの観点で開発者から聞くのが一番良いと思う。

【元ネタ2】
概要設計工程でRedmine導入してみた事例 - T/O

面白いのは、見積工数と実績工数の入力ルール。

* チケットの進捗率は 0% or 100% で管理。つまり、完了するまではどんだけ時間掛けても0%。
* 少なくとも完了した時点で、経過時間を大雑把に入れるルールとした。
* 全体の進捗率は見積もり時間基準で。「全体の見積もり時間 / 完了分の見積もり時間」
* 経過時間は社内向けの進捗報告に使った。チケットのCSV出力機能で、経過時間を出力するようプチ改造。

チケットの粒度がバラバラなので、チケット数による進捗は無意味。
見積もり時間をベースに、完了チケットの見積工数/全体の見積工数で進捗率を出し、バーンダウンチャートで表示する。
「見積もり「時間」を見積もり「ポイント」に読み替えた」点は面白い。
これなら、進捗の精度は確かに上がる。

「対外的な品質管理報告用として、チケットの属性に「レビュー指摘件数」を追加し、レビューコメントのうち明確な指摘事項のみ件数を数え、記録した」運用もなるほどと思う。
結果は実態と合っていない結論だったようだが、このようなメトリクスも取得できるのは興味深い。
データさえあれば、後でいくらでも分析できるから。

高機能なBTSとバージョン管理ツールがあれば、誰でもチケット駆動開発を実践できるはずだ。