チケット駆動開発がWF型開発と異なる点

チケット駆動開発について、良い記事があったのでリンクしておく。
Redmine上で実装されたチケット駆動開発について、よく理解されていると思う。

【1】技術士とアジャイル開発について（DAD） - A-JUNのブログ - Yahoo!ブログ

(引用開始)
こうした"計画外に発生したもの"はチケット/BTSでの管理が非常に向いている。なので「計画できることはWBSで。計画できないことはチケットで」というのが私の主張だ。
(引用終了)

WF型開発をベースタにした開発において、「計画できるものはWBSで、計画外のことはチケットで」という発想のチケット駆動開発は、アダプタブルWFと呼ばれる。
WBSによるプロジェクト管理が基本にありながら、そこから漏れた活動はチケット管理する発想。
アジャイル開発を取り入れにくい現場で適用する時が多い。

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン: プログラマの思索

【公開】第10回 RxTstudy／第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索

【2】技術士とアジャイル開発について（チケット駆動） - A-JUNのブログ - Yahoo!ブログ

【2－1】(引用開始)
　バーンダウンチャート（バックログをグラフで表し、マイルストーンまでの残りの作業量の推移を、理想線、予定線、実績線、3つの右下がりの折れ線グラフで表示）とEVMの違いは、出来高という概念を残工数でみるか、完成した出来高の累積値として捉えるか、の違いだ。つまり、バーンダウンチャートは、イテレーション単位にEVMのグラフからPV-EVの数値だけを時系列に抜き出したものと見なすことができる。

　(WF型開発のEVMとアジャイル開発のバーンダウンチャートの)この観点の違いは重要だ。バーンダウンチャートでは、PVは変動する値と見なすのに対し、WF型開発のEVMではPVは固定値と見なす。そして、EVの考え方も、WF型開発では進捗率で測定するのに対し、アジャイル開発では未完了か完了のどちらかで測定する。

　したがって、アジャイル開発の方がEVの定義が厳しいために、担当する作業の粒度を小さくしてどんどん完了していくペースでなければ、プロジェクトの進捗は遅延しているように見えるだろう。つまり、アジャイル開発では、イテレーションというタイムボックスで管理したり、作業の粒度を小さくするなどの工夫をしなければ、EVMで測定しても変化がほとんどないから意味がない。

　EVMをアジャイル開発に適用できると、EVMの公式を使って、プロジェクトの進捗やコストを予測したり評価する手法を使える。AgileEVM: 製品ライフサイクル全体で費用対効果を計測するでは、SPIを使って進捗度合いをグラフ化して見える化している。CPIを測定すれば、開発チームの開発ペースが分かるから、総コストも予測できるだろう。
(引用終了)

EVMとバーンダウンチャートの見た目の違いは、進捗度合いを、出来高を累積して見るのか、残工数(残作業量)として見るのか、にある。
しかし、根本的な考え方は全く違う。

EVMでは、PVという計画された作業量は事前に決められており、変更することはできない。
予定された作業対し、どれだけ実績の差分が発生するか、という観点で進捗管理を行う。
この方法の弱点は、ソフトウェア開発のように、事前に要件を固めることが難しく、頻繁に要件の変更が発生する場合に使いにくい。

逆に、バーンダウンチャートでは、要件は変化するという前提で、スプリント単位に残工数を測定する。
計画時点の作業が変更されることを考慮するだけでなく、計画時の予定作業の「変動量」に注目し、その変動の揺れ幅を一定範囲内に収めることに注力する。

この方法の利点は、チームの開発能力が安定していて、計画時の作業の分量も大きな揺れ幅にならない前提があれば、変化を許容しながら開発できることだ。

EVMとバーンダウンチャートは本質的に違う: プログラマの思索

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2～RedmineでEVMを実現 Lychee EVM: プログラマの思索

【2－2】(引用開始)
Redmineのロードマップ画面では、該当バージョンの進捗バーは濃緑色の部分が多く、もう少しでリリースできる状況だろう。即ち、チケットをこなす速度も予定よりも早く進み、そのおかげで納期も短くなったことになる。このパターンは、プロジェクトの理想的な展開だといえるだろう。

　実際は、アジャイル開発で小規模リリースを実施すると、初期のイテレーションは非常に苦労するが、後期のイテレーションではこのパターンに当てはまる。最初は、要件や仕様の理解に苦しんだり、新しい技術の習得に時間がかかったり、メンバーの役割分担が不十分だったりして、何とかイテレーションをこなすのが精一杯となるのが通常だ。

　しかし、イテレーションと言うリズムに慣れると、イテレーションに収まりきらないチケットは後回しにしたり、優先順位を付けてチケットを入れ替えるなどのマネジメントがスムーズになるので、結果的にバグが生じにくくなり、手戻り作業も減る。

　システム開発では、学習速度と言う概念が重要だと思う。3ヶ月経てば、新人であろうとも、仕様も技術も慣れてくる。その分、タスクをこなす速度は上がってくる。つまり、開発チームのベロシティ(進捗速度)はほぼ一定になるので、見積もりの精度が高くなり、手戻り作業などのリスク管理も上手に制御できるようになるだろう。
(引用終了)

Redmineのロードマップによる小規模リリースの戦略のお話。
Redmineのバージョンがイテレーションに相当し、イテレーション完了の条件がRedmineのバージョンが進捗率100％で完了する状態と一致するのが、運用のコツ。

チケット駆動開発の戦略: プログラマの思索

【3】技術士が考える見積もり方法について - A-JUNのブログ - Yahoo!ブログ

(引用開始)
　アジャイル開発の利点は機能単位の小刻みな小規模リリースだけではなく、チームの現在の能力に見合った見積りを提示できる点にもある。顧客に、現在のチームの能力ではこれぐらいの期間でこれぐらいの機能(規模)を提供できます、とイテレーションのたびに説明できるのは、ウォーターフォール型開発よりもとても有利だ。

　アジャイル開発の見積りで面白いのは、実績工数よりもVelocityを追跡することに注力することだ。予定していたVelocityと実績のVelocityを各イテレーションで計測しながら、次のイテレーションの見積りに使う。実績工数にこだわると、いかに時間をかけずに仕事するか、に開発者の意識が寄ってしまって、手抜き作業が起きる可能性もあるからだろう。これは、非常に重要な考えだ。

　また、実績工数は規模や難易度によって大きく変わるから、あまり当てにならない。Velocityの計測を追跡することによって、チームの能力をいつも気にかけるようになり、XPの言う「持続可能な開発ペース」を保持するのにも役立つだろう。

　ストーリーポイントやVelocityはアジャイル開発特有の概念であり、その概念の意味はとても奥深い。Redmineによるチケット駆動開発を通じて、WF型開発でよく使われるFP法やEVMとは全く違うことも理解することが必要だ。こういうメトリクスを計測できる環境をチケット駆動開発は提供してくれるからこそ、色々思索することもできる。
(引用終了)

メトリクス採取の観点は、従来のWF型開発とアジャイル開発では全く違うと思う。
WF型開発では、メトリクスを計画と実績の差異比較に使う。
しかし、ソフトウェア開発は案件の独自性が大きいために、計画時にメトリクスの値を想定するのはとても難しい。
実際に設定したとしても、開発チームの生産性、納期と工数のバランス、新技術の実現可能性、メンバーの学習能力などを考慮すると、大きくブレがちだ。

一方、アジャイル開発では、メトリクスを実績ベースの値から採取する。
例えば、Velocityやサイクルタイムなどが相当するだろう。
すると、イテレーションごとに開発チームの実績を定期的に計測することで、その値を直近のイテレーションへの見積りに利用できる。
実際の案件で採取した実績値を元に見積りを行うから、その精度は高いはず。

また、WF型開発のメトリクスの弱点は、採取したメトリクスを開発チームにフィードバックしづらいことだ。
工程単位にメトリクスを採取したとしても、次工程に進んでしまったら、前工程のメトリクスを利用する意味が半減する。
次工程では、前工程のメトリクスはそもそも使えない可能性が高い。
しかも、工程終了・開始前後は大変忙しいから、採取したメトリクスをフィードバックするタイミングも取りにくい。
最悪な場合は、工程単位に多重請負構造になっている時だ。
前工程の下請け・元請の負債を引きずるメトリクスをもらったとしても、正直嬉しくない。

一方、アジャイル開発では、イテレーション単位に取得したメトリクスは、イテレーション終了直後に「ふりかえり」で開発チームにフィードバックするタイミングがある。
開発チームは、そのメトリクスから得られたノウハウを、次のイテレーションに生かすことができる。
この点が最大の違いだと思う。

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

チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索

Velocity計測の注意: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3～サイクルタイムとリトルの法則の関係: プログラマの思索

【公開】第10回 RxTstudy／第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索