« 30分でだいたいわかるアジャイル開発 | トップページ | てつ。さんのAgile Tour Osaka 2010の予習ガイド #agileto2010 »

2010/10/23

Mantisのチケット集計機能にある最大放置日数と平均完了日数

Mantisには要約(summary_page.php)というWebページがチケット集計機能に相当する。
そこに表示されている「最大放置日数」「平均完了日数」についてメモ。

【元ネタ】
MantisBT Git - mantisbt.git/blob - lang/strings_japanese.txt

Mantisの日本語化の文言

脱サラ大学生のプログラム日記~Mantisカテゴリ

アジャイル開発と品質管理の関係: プログラマの思索

Mantisの要約ページは、Redmineのサマリ画面のように、優先度・開発者・起票者などの観点でチケット数を集計表示してくれる。
その中で興味を引いたメトリクスは、「最大放置日数」「平均完了日数」。

【1】最大放置日数は、チケットが起票されてから未完了のまま放置されている期間を表示している。
RedmineやTracでチケット駆動開発を実践してみると、チケットが放置される時は多い。

例えば、チケットに起票された課題を解決するには、顧客や上司の同意が必要だったり、回答を得て課題が解決したと思っても見直してみたら、実は別の不明点が出てきたりする時がある。
あるいは、結合テスト工程でバグがたくさん出て、チケットが乱発されてしまい、チケットの棚卸しが出来ていない時もあるだろう。
ダメなプロジェクトリーダーほど、チケットの棚卸し、つまりチケットの優先順位付けを判断出来ていない。

最大放置日数が長いチケットがたくさんあるほど、チケット管理がうまく機能されていない状況を意味する。
せっかくプロジェクト管理をチケット管理に置き換えたとしても、次々に起票されるチケットが解決されなければ、プロジェクトは停滞していることと同じ。

チケット駆動開発では、チケットは単なるタスクや障害だけでなく、設計上の課題や実装リスクも起票されるので、それらのチケットを管理することはリスク管理につながる。
次々に起票されるチケットはプロジェクトのリスクとして見える化されたわけだから、プロジェクトリーダーはそれらチケットに対して、あらゆる手を使って解決しなければならない責任を負っている。

特にバグが発見されて、そのチケットの難易度がたとえ簡単であったとしても、放置されている期間が長いほど、残存バグの解決コストは大きくなる。
残存バグの解決コストは、難易度×最大放置日数だからだ。
たとえ簡単なバグであっても、発見されずに放置されれば、リリース後の改修コストは非常に高くつく。

【2】平均完了日数は、チケットが起票されてから完了するまでの平均日数を表示している。
例えば、バグが発見されてから、開発者が修正して、テスターが検証して解決するまでの期間に相当する。

平均完了日数はまさに、ソフトウェアのMTTR(平均修復時間)を表している。

平均修復時間 - Wikipedia

チケット駆動開発の場合、イテレーション単位にAgileに開発していくから、平均完了日数がイテレーション期間よりも短くなるように調整しなければ、そもそもリリースできないだろう。
Scrumなら4週間、XPなら2~4週間のサイクルで小刻みにリリースする開発スタイルを実践したいならば、平均完了日数はその期間以下に抑える必要がある。

普通のチケットは1人日以下で終わる時が多いだろうが、テストやレビューで検証NGとなって差し戻しになったり、設計上の課題を質問して回答を得ても精査したら整合性があっていなかったので再質問する時もあるだろう。
又、プロジェクトの運営上、放置すると意思決定したチケットもあるだろう。
そうすれば、結局、平均完了日数は、例えば5日とか10日などのように長くなる。

逆に言えば、チケットの平均完了日数よりも短いイテレーションでAgileに開発することは不可能。
つまり、開発チームが実現できるイテレーションの長さには平均完了日数という制約がある。

リーンソフトウェア開発を運用したいなら、毎日リリースするわけだから、平均完了日数が1日以下にならなければ、そもそも実現できないだろう。

ここで、アジャイル開発と品質管理の関係: プログラマの思索にも書いたように、「アジャイル開発はMTTRを重視している」意見もあるらしい。
リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性という品質を高めてソースを修正しやすくすることを目指している。つまり、バグ修正工数と言うMTTRを短くすることにも注力していることにつながる。

平均完了日数が長いシステムは、経験的に品質が悪いように思う。
簡単に直せるバグに必要以上に時間をかけてしまうわけだから、作業効率が悪くなっているのだろう。
例えば、たくさんのバグが発見されてチケットが乱発されてしまって、チームが混乱してしまい、作業効率が悪くなっている状況があげられるだろう。

個人的には、Redmineでも「最大放置日数」「平均完了日数」をプロジェクト単位、イテレーション単位に集計表示してくれると面白いだろうと思う。
チケットの「最大放置日数」「平均完了日数」はシステムの品質とプロジェクトの生産性を映し出す鏡だからだ。

|

« 30分でだいたいわかるアジャイル開発 | トップページ | てつ。さんのAgile Tour Osaka 2010の予習ガイド #agileto2010 »

ソフトウェア工学」カテゴリの記事

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

Agile」カテゴリの記事

コメント

コメントを書く



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


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



トラックバック


この記事へのトラックバック一覧です: Mantisのチケット集計機能にある最大放置日数と平均完了日数:

« 30分でだいたいわかるアジャイル開発 | トップページ | てつ。さんのAgile Tour Osaka 2010の予習ガイド #agileto2010 »