Mantisのチケット集計機能にある最大放置日数と平均完了日数
Mantisには要約(summary_page.php)というWebページがチケット集計機能に相当する。
そこに表示されている「最大放置日数」「平均完了日数」についてメモ。
【元ネタ】
MantisBT Git - mantisbt.git/blob - lang/strings_japanese.txt
Mantisの要約ページは、Redmineのサマリ画面のように、優先度・開発者・起票者などの観点でチケット数を集計表示してくれる。
その中で興味を引いたメトリクスは、「最大放置日数」「平均完了日数」。
【1】最大放置日数は、チケットが起票されてから未完了のまま放置されている期間を表示している。
RedmineやTracでチケット駆動開発を実践してみると、チケットが放置される時は多い。
例えば、チケットに起票された課題を解決するには、顧客や上司の同意が必要だったり、回答を得て課題が解決したと思っても見直してみたら、実は別の不明点が出てきたりする時がある。
あるいは、結合テスト工程でバグがたくさん出て、チケットが乱発されてしまい、チケットの棚卸しが出来ていない時もあるだろう。
ダメなプロジェクトリーダーほど、チケットの棚卸し、つまりチケットの優先順位付けを判断出来ていない。
最大放置日数が長いチケットがたくさんあるほど、チケット管理がうまく機能されていない状況を意味する。
せっかくプロジェクト管理をチケット管理に置き換えたとしても、次々に起票されるチケットが解決されなければ、プロジェクトは停滞していることと同じ。
チケット駆動開発では、チケットは単なるタスクや障害だけでなく、設計上の課題や実装リスクも起票されるので、それらのチケットを管理することはリスク管理につながる。
次々に起票されるチケットはプロジェクトのリスクとして見える化されたわけだから、プロジェクトリーダーはそれらチケットに対して、あらゆる手を使って解決しなければならない責任を負っている。
特にバグが発見されて、そのチケットの難易度がたとえ簡単であったとしても、放置されている期間が長いほど、残存バグの解決コストは大きくなる。
残存バグの解決コストは、難易度×最大放置日数だからだ。
たとえ簡単なバグであっても、発見されずに放置されれば、リリース後の改修コストは非常に高くつく。
【2】平均完了日数は、チケットが起票されてから完了するまでの平均日数を表示している。
例えば、バグが発見されてから、開発者が修正して、テスターが検証して解決するまでの期間に相当する。
平均完了日数はまさに、ソフトウェアのMTTR(平均修復時間)を表している。
チケット駆動開発の場合、イテレーション単位にAgileに開発していくから、平均完了日数がイテレーション期間よりも短くなるように調整しなければ、そもそもリリースできないだろう。
Scrumなら4週間、XPなら2~4週間のサイクルで小刻みにリリースする開発スタイルを実践したいならば、平均完了日数はその期間以下に抑える必要がある。
普通のチケットは1人日以下で終わる時が多いだろうが、テストやレビューで検証NGとなって差し戻しになったり、設計上の課題を質問して回答を得ても精査したら整合性があっていなかったので再質問する時もあるだろう。
又、プロジェクトの運営上、放置すると意思決定したチケットもあるだろう。
そうすれば、結局、平均完了日数は、例えば5日とか10日などのように長くなる。
逆に言えば、チケットの平均完了日数よりも短いイテレーションでAgileに開発することは不可能。
つまり、開発チームが実現できるイテレーションの長さには平均完了日数という制約がある。
リーンソフトウェア開発を運用したいなら、毎日リリースするわけだから、平均完了日数が1日以下にならなければ、そもそも実現できないだろう。
ここで、アジャイル開発と品質管理の関係: プログラマの思索にも書いたように、「アジャイル開発はMTTRを重視している」意見もあるらしい。
リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性という品質を高めてソースを修正しやすくすることを目指している。つまり、バグ修正工数と言うMTTRを短くすることにも注力していることにつながる。
平均完了日数が長いシステムは、経験的に品質が悪いように思う。
簡単に直せるバグに必要以上に時間をかけてしまうわけだから、作業効率が悪くなっているのだろう。
例えば、たくさんのバグが発見されてチケットが乱発されてしまって、チームが混乱してしまい、作業効率が悪くなっている状況があげられるだろう。
個人的には、Redmineでも「最大放置日数」「平均完了日数」をプロジェクト単位、イテレーション単位に集計表示してくれると面白いだろうと思う。
チケットの「最大放置日数」「平均完了日数」はシステムの品質とプロジェクトの生産性を映し出す鏡だからだ。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
コメント