TiDDはレコーディングダイエット

下記の意図についてラフなメモ書き。

【元ネタ】
PSPはレコーディングダイエット: ソフトウェアさかば

PSPは、CMMI提唱者ハンフリーが編み出した開発者個人用のソフトウェアプロセス。
自分で工数見積やバグ集計、メトリクス集計して、自分でプロセス改善していくから、規律が厳しいプロセスという印象がある。
でも、PDCAを回すという発想は、どの開発プロセスでも同じ。
特に、Checkプロセスで使うメトリクスを収集する理由は、「測定できなければ制御できない」から。

レコーディングダイエットも似た発想。
記録していくうちに、反省点が出てきて、色々試しながら、自己改善していく。

チケット駆動開発も同じだ。
チケットをタスクカードのように扱い、そのチケットをBTSというDBに格納しておけば、色んな観点でいくらでも集計できる。
開発チームがその集計結果を使って、リリース後にKPTでふりかえりを行えば、バグの傾向や開発速度(ベロシティ)が分かるだろう。
それによって、開発チームの特性に見合った改善ができる。

SW工学やSWテスト、品質管理、PMBOK、ITILを今まで色々勉強してきて、確かに知識は溜まったけれど、実際の開発現場では使えなかった。
その理由は、それらの知識で分析するための元ネタであるメトリクスが無かったから。

バグ収束曲線の見方、テストの傾向分析、リスク管理、コスト管理、クリティカルパスなどの知識は、チケット集計結果という元ネタがあって初めて分析できるのだ。

従来は、開発者にExcelで進捗報告を提出させて、プロマネが自分でExcelマクロを作って集計するしかなかった。
しかも、その精度も低いし、手間もかかった。
PMBOKを自分のものとしているリーダーは、果たしてその知識をどうやって活用していたのだろうか？と思う。
ExcelやMSProjectでは、もはや昨今のスピードの速いプロジェクトに追いつけないはずだ。

僕が今後やりたいのは、チケット駆動開発をプロジェクト管理のインフラとして扱いたいことだ。
EVM、リスク分析、要件管理、構成管理など色んな各種技法は、チケット駆動開発上で全て制御できるはず。

今は単に、RedmineサマリやTracレポートぐらいでしか集計できないが、もっと高度な統計処理ができる可能性はある。
最終的には、チケット駆動開発のインフラの上で、プロジェクトの進捗をシミュレーションしたいのだ。

開発案件を請け負った時、きちんとWBSさえ作れれば、Redmineに放り込むと、すぐにガントチャートが生成できるし、色んな観点で集計できる。
WBSを元ネタとしてシミュレーションすれば、請け負った段階でもはや工数(コスト)がオーバーしていたり、納期がオーバーしていたりする場合もあるだろう。
その場合、スコープで調整するしかないということを、シミュレーション結果を使って利害関係者に説明することもできるだろう。

つまり、XPの計画ゲーム、Scrumのスプリント計画を、プロジェクトのシミュレーション作業まで昇華できるはずだ。
今は想像に過ぎないけれど、チケット駆動開発にはかなりのポテンシャルがあると思う。