チケット駆動開発におけるソフトウェア見積り

細谷さんの下記のつぶやきでいくつか考えたことをメモ。

【元ネタ】
Twitter / @yasuohosotani: @akipiiさんがbit.ly/9LRcnhで触れているようにXDDPとチケット駆動はとても相性がいいです。たぶん、USDM作成時に各階層の粒度がある程度そろった結果、1つの変更設計に対する作業量や深さも揃うからだと思っています。

ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（1） - アークウェブシステム開発SandBox

ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（2） - アークウェブシステム開発SandBox

ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（3） - アークウェブシステム開発SandBox

ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（4） - アークウェブシステム開発SandBox

www.sakuttoly.com - 読書記録#9 スティーブ・マコネル『ソフトウェア見積り 人月の暗黙知を解き明かす』

SEの読書回顧録 ソフトウェア見積り―人月の暗黙知を解き明かす

ソフトウェア見積りを読了

【1】RedmineのチケットをXPのタスクカードのように運用した場合、僕の経験上、チケットの平均工数は1.5人日程度になる。
最初は2～5人日程度の大きなチケットも作りがちだが、作業後に気付いたタスクや突然発生したバグ、突発的な仕様変更などが入り交じって、最終的には1人日以下のチケットが多くなる。
リリース後にチケットを集計してみると、計画当初に登録したチケット数とイテレーション実施中に登録したチケット数はほぼ同じぐらいの割合になる。

逆に言えば、実際のソフトウェア開発では、計画外の作業がかなり多く、計画当初の想定よりも2倍くらいの作業になることを意味している。
WF型開発でうまくいかない理由は多分この現象にあるのだろうと思う。
計画外の作業がとにかく多すぎて、計画当初の作業は追跡できても、計画外の作業をリリースまで追跡していくのはとても煩雑で難しい。
そこから作業漏れが発生し、リリース後に膨大な仕様変更と障害報告がチームに押し寄せる。

ソフトウェア開発では、要求は変更されやすいから、スコープ管理がとても重要。
コストと納期は固定なのだから、顧客のビジネス要件と開発チームの生産能力の観点で、スコープを削って定期的に安定してリリースさせるのが本来のSW開発のマネジメント。

そして、変更要求をきちんと管理して追跡していく仕組みがソフトウェア開発ではとても重要。
管理されない変更要求は、必ず作業漏れが発生し、仕様漏れという名前の大きなバグとしてリリース後に判明する。
駄目なマネージャは、変更要求を認識せず、顧客の言いなりになってどんどん開発作業を膨らませて、最後にプロジェクトを破綻させてしまう。

チケット駆動開発では、ロードマップ機能でリリース計画を担当するので、各イテレーションの計画時に必ずスコープをチェックする仕掛けがある。
直近のバージョンにリリースする機能はどれか、いつどの機能を順にリリースしていくか、というマネジメントを常に意識せざるを得ないからだ。

更に、突発的に発生した仕様変更やバグは、即座にチケットに登録すればいい。
登録されたチケットを吟味して、更に追加のタスクが発生すれば、子チケットで作ったり、関連するチケットを作ればいい。
あるいは、登録されたチケットのワークフローが現状に合わないのなら、トラッカーを変えて、本来のあるべきトラッカーへ修正すればいい。
あるいは、直近のイテレーションで実施しなくていいチケットならば、チケットの属性にある対象バージョンを変更して、イテレーション間を移動すればいい。
つまり、計画外の作業は即座にチケットに登録しておき、そのチケットを精査して詳細化する過程でチケットの属性を変更してFixすればいい。

【2】見積りという技術が計画プロセスで大きな重要性を占めることは下記で書いた。

ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索

チケット駆動開発でも、リリース計画づくりで見積り技術は必須だろうと思う。
とはいえ、実際のチケット駆動開発では、チケットの粒度が小さいため、予定工数まで書かない運用は多い。

チケット駆動開発の特徴の一つは、チケットをタスクカードとして扱うため、既に見積りは終わっているという過程から始まる点がある。
実際、チケットの粒度は1人日以下が多いから、チケットの中身はかなり詳細化されているため、チケットの優先度や作業順序を決めやすい。
メンバーはチケットに書かれたタスクを順番にこなしていくだけでいい。

細谷さんが言う通り、清水吉男さんが提唱するXDDP(派生開発の開発プロセス)では、USDMという手法によって要件をかなり細かい部分まで仕様化していく。
だから、タスクの粒度も小さいレベルまで落とすことができて、その分、見積もりの精度も正確になるのだろう。

【3】チケットの属性には実績工数があるので、チケット完了後に実績工数を入力する運用があれば、リリース後に実績工数を簡単に集計できる。
僕は、毎週、登録・終了チケットの枚数と実績工数を必ずカウントして、Excel上で時系列に並べて分析している。
その目的は、バグ収束曲線とEVMを見たいから。
その時に気付いたことは下記に書いた。

アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索

安定したプロジェクトならば、未完了チケット数が一定になるようにプロジェクトがコントロールされているだろう。
つまり、登録チケット数－完了チケット数が一定なので、メンバーは忙しくもなく暇でもないように、常にタスクがある状況になっているだろう。

また、初期のイテレーションでは、Velocityが安定しないので、CPI(コストパフォーマンス)はあまり良くないが、イテレーションをこなしていくうちにVelocityのばらつきも減り、CPIも1.0へ近づいてくる。
これは、予定工数と実績工数の差が小さくなっていくこと、つまり、見積もりの精度が上がっていくことを意味している。

PMBOKのEVMの概念は、Agileのバーンダウンチャートとほぼ同じ概念だ。
EVMがPV・EVの右肩上がりのグラフなら、バーンダウンチャートは残PV・残EVの右肩下がりのグラフに過ぎない。
EVMの優れている点は、CPIを計測することで、リリース時のコスト(工数)を予測しやすくなること。
チケット駆動開発を通じて、この辺りの概念の特徴を理解しやすくなった。

【4】チケット駆動開発に弱点があるとすれば、規模見積りを含めた計画づくりをサポート出来ていない点だろう。
実案件の要件をチケットのレベルまで詳細化できれば、チケットの粒度は所詮1人日程度なのでかなり正確に見積もれる。
WBSを詳細化していく過程で、どんな作業が必要なのか、を考えるから、作業漏れがかなり減るはず。

しかし、肝心の要件そのものが漏れていたら意味がないし、スコープコントロールも作業レベルだ。
かなり大きめの仕様変更が来た場合、イテレーションに組み入れるのは難しいから、複数のイテレーションに分けるリリース計画を作る必要があり、そこには見積り技術が必要。
特に初期の概要見積りは、開発規模を見極めるのが重要で、顧客のビジネスの目的やコスト、納期を考慮して、どの機能が必要だから残し、どの機能が優先度が低いので削る、という判断がいる。
その部分はチケット駆動開発の範囲外。

チケットの親子関係によって、ストーリーカードとタスクカードを実現する手法もあり、多分ScrumのストーリーポイントやVelocityの概念をうまく使えばカバーできるだろうと思うが、まだよく分からない。

チケット駆動開発は実作業の管理にすごく向いているが、要件レベルの管理はまだ力不足かなと思っている。
見積りによって計画の精度を上げる、ないし、スコープを制御して計画をコントロールする手法はまだまだ研究の余地があるように思っている。