アジャイルサムライで一番難しくて面白い概念～Velocity

先週、アジャイルサムライ読書会に行ってきた。
スタッフ並びに勉強会の皆様、ありがとうございました。
考えたことをメモ書き。

【元ネタ】
アジャイルサムライ読書会(湯島道場) 第三回 火の巻に参加してきた #agilesamurai #湯島道場 - Shinya’s Dairy Report

ReadingAgileSamuraiInYushima - GitHub

Twitter / @ryuzee: 道場破り？の@akipiiさんがいますけどねｗ RT @haradakiro: 道場破りとかこないとヒマなのですね。RT @ryuzee: 用心棒だから黙ってるよ！ #agilesamurai #湯島道場

Twitter / @kakutani: 読書会が盛り上っているなあという感じがよく伝わる / アジャイルサムライ読書会(湯島道場) 第三回 火の巻に参加してきた #agilesamurai #湯島道場 - Shinya’s Dairy Report http://htn.to/xXn8Nh

Velocity駆動のイテレーション計画の作り方とは: プログラマの思索

イテレーションの考え方は締め処理と同じ: プログラマの思索

TiDD初心者が陥りやすい罠～バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

TiDDを実践して気づいたことpart9～Scrumのベロシティ #tidd: プログラマの思索

【1】VelocityはScrumが発見したもっとも重要な概念であり、Agile開発で一番難しくて一番面白い概念だと思う。

一番難しいとは、Velocityは実際のプロジェクトで簡単には計測しづらいメトリクスだから。
一番面白いとは、従来のソフトウェア工学にはなかった新たな概念であり、ソフトウェア開発の本質に迫る概念だと直感しているから。
とはいえ、PMBOKのEVMに出てくるCPI(コストパフォーマンス)、バーンダウンチャートで出てくる右肩下がりの残作業量の降下速度、でも表現できるだろうと思う。

今の僕は、RedmineやTracでVelocityを計測できないか、色々試行錯誤している。
Velocityらしきものとしては、2種類のメトリクスを計測している。

【2】一つは、EVMのCPI。
アイデアは下記に書いた。

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

実際の計測方法としては、各イテレーション実施中のチケットに対して、PV＝全チケットの予定工数、AC＝全チケットの実績工数、EV＝完了チケットの予定工数の総和、を1週間単位に計測し、CPI＝EV/ACの変化をみている。

CPIは定義からして、顧客へ納品できた作業の出来高工数/実作業のコストだから、開発チームのコストパフォーマンスを表している。

例えば、「ソフトウェア見積り―人月の暗黙知を解き明かす」の188ページにある例がCPIの良い例だと思う。

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

(引用開始)
例えば、6ヶ月のスケジュールがあったとしよう。あなたは、最初のマイルストーンを4週間で達成する計画を立てた。しかし、実際には6週間かかってしまった。この場合、あなたなら次のうちどれを選ぶだろうか。
(1)失った2週間は、スケジュールの後の方で埋め合わせられると考える。
(2)スケジュールの合計の2週間を追加する。
(3)誤差の大きさ(この場合は50%)をスケジュール全体に掛け合わせる。
もっともありがちなのは、1番目の選択肢だろう。通常は次のような論法になる。「要求にかける時間が予定より少し長かった。だが、もう要求は固まった。残りの時間を切り詰めよう。コーディングとテストの間で不足分を埋め合わせられるはずだ」。しかし、1991年に300以上のプロジェクトについて調査した結果によると、プロジェクトが一度失った時間を埋め合わせることは、まず不可能であることが分かっている。それどころか、遅れはさらに広がる傾向にある。したがって、この選択肢がベストチョイスなることは、ほとんどないと思ってよい。
(中略)
よほどの例外を除いて、実際の結果が見積もり通りにならない場合の正しい選択肢は、3番目ということになる。
(引用終了)

3番目の選択は、CPI＝4週間/6週間＝0.67という意味になり、顧客の要望から発生する作業の予定工数に対し、1.5倍の工数がかかって開発チームは作業していることを意味している。

実際にCPIを計測してみると、イテレーションの最初の1～2週間のCPIはとても低く、4週間目になると、ほぼCPIは1.0に近づくみたい。
つまり、最初はなかなかアウトプットを出せずコストオーバーになるが、慣れてくると予定通りのアウトプットを出せるようになってくることを意味している。

@ryuzeeさんの解説「直近2～3スプリントが、現時点での能力でありVelocity」「ベロシティは成長するものである。一定のままなのであれば逆に問題。」がとても分かりやすかった。

【3】もう一つは、未完了チケット数の推移。
運用保守のプロジェクトでは、単なる開発・修正だけでなく、顧客からの問合せ調査や本番障害など計画外のタスクが多い。
普通は、調査や本番障害のタスクはチケット化されてバックログに入れられて、優先度の高いチケットから順に直近のイテレーションへ混ぜ込んでいく。
当然、直近のイテレーションではなく、次回や次々回のイテレーションへ入れられるチケットもあるから、即座に対応しないチケットもある。

そこでバグ収束曲線のアイデアを活かして、チケットの累積登録数とチケットの累積完了数を時系列にグラフ化してみた。
すると、チケットは日々登録されるからチケットの累積登録数は右肩上がりに増える。
チケットもできるものからCloseさせていくから、チケットの累積完了数も累積登録数から若干遅れる形で右肩上がりに増えていく。
この時、未完了チケットの総数＝チケットの累積登録数－チケットの累積完了数を時系列に見ると、最低値と最高値が平均値の２倍にならない範囲で収まるように計測できた。

未完了チケットの総数がほぼ一定の数値で前後しているという意味は、運用保守のプロジェクトで、仕掛り中のチケットがほぼ一定であることを意味していて、メンバーの作業負荷が高すぎることもなく、かと言って手持ち無沙汰で暇でもない実情を表していると思う。
つまり、仕事量が開発チームにとって溢れる程でもなく暇でもない状態であり、開発チームがプロジェクトをコントロールできているのを意味していると思っている。

@ryuzeeさんの指摘では「チケットの追加量、消化量が一定だから」とのことだが、確かに言われるとおりだと思う。
つまり、顧客の要望から発生した新規チケットがバックログへ貯められていく速度と、開発チームがバックログにあるチケットを消化していく速度がほぼ比例しているので、残作業量が一定になるのだろうと理解している。

【4】Velocityを計測したい理由は、Velocityを使ってリリース計画の精度を高めたいからだ。
普通のプロジェクトでは、納期と開発チームのVelocityを考慮すると、それ以上に顧客の要望がたまる場合が多く、うまくプロジェクトコントロールしないとすぐにデスマーチに陥る。
だから、「アジャイルな見積りと計画づくり」や「アジャイルサムライ−達人開発者への道−」で出てくるVelocity駆動で計画して、開発チームは顧客に対して、要望の制限をかけたい。
無制限な要望を全て実現するのは不可能だからだ。

特に、新しい技術を使った新規プロジェクトでは、次から次へと技術上の課題が噴出して、Velocityを計測したとしてもあまり有効でない可能性もある。
「ソフトウェア見積り―人月の暗黙知を解き明かす」の47ページでは、要求が常に不安定の場合は、プロジェクトコントロールによる対象の方が見積による対処よりも強力に働くとあり、例として、ScrumやXP、タイムボックス開発などの手法があげられている。
これは、要求の変更が多くて不安定な場合、Velocity駆動よりもコミットメント駆動で計画した方がプロジェクトを制御しやすい、という主張だと理解している。

現場リーダーしてチケット駆動開発を実践してみると、プロジェクト管理をチケット管理に置き換えることによって、チケットの取捨選択とリリース計画のブラッシュアップという計画プロセスがとても面白い。
PMBOK、Scrum、XPが主張したいことはこういうことだったのかな、という納得感が非常に多いからだ。

Velocityはチケット駆動開発でも自然に現れた概念。
Velocityが意味することは、ソフトウェア開発において生産性の向上を開発チームに強いるよりも、開発チームが適切なペースで作業できる方が安定して開発できる経験則を示唆しているのだろうと思っている。

色々試してみる。