« ソフトウェア開発の諸問題はソフトウェアで解決する | トップページ | 要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス »

2009/09/25

チケット駆動開発の運用例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とバージョン管理ツールがあれば、誰でもチケット駆動開発を実践できるはずだ。


|

« ソフトウェア開発の諸問題はソフトウェアで解決する | トップページ | 要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス »

Agile」カテゴリの記事

Redmine」カテゴリの記事

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

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

コメント

以前チケット駆動開発してました。
本質的にはエクセルでのタスク管理と変わらないと思いました。
結局管理者がチケットを使う運用を定着させる活動を継続していないとあまり意味がないなあと。逆にその活動で運用が定着するならエクセルでも問題ないかなあと。
最終的にはツールは問題ではなく、管理者の能力に依存していると思いました。

投稿: とおりすがり | 2009/09/27 11:44

コメントを書く



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


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



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/46309800

この記事へのトラックバック一覧です: チケット駆動開発の運用例part3:

« ソフトウェア開発の諸問題はソフトウェアで解決する | トップページ | 要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス »