TiDDを実践して気づいたことpart9～Scrumのベロシティ #tidd

Scrumが従来のAgile開発に比べて優れている点は、プロダクトオーナー、バックログ、ベロシティという概念を明確に定義した点にあると思う。
チケット駆動開発をいくつかのプロジェクトで実践してみて、ベロシティという概念が一番難しく、そして奥が深いという経験を少しだけした。

考えたことをラフなメモ書き。
僕はScrumを勉強中なので、間違っていたら後で直す。

【元ネタ】
Twitter / @Kakutani Shintaro: ベロシティを「安定させるもの」「だいたい予想できるようにすること」と捉えているのが素晴しい / Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - daipresents!! http://htn.to/odgTtR

Twitter / @江端 一将 （えばた かずまさ）: スクラムのベロシティに似ていると思う。ベロシティを高く表現するのは簡単でしょw でも、本当の能力は、ある１つの測定項目では把握しえないみたいなww RT @kanu_ CMMIのレベルで計れないとすれば、何で計れば良いの？ #aj11 #aj11cmmi

[Agile]ベロシティを他のチームと比較してはいけない | Ryuzee.com

[Agile]新規チームではベロシティの測定期間が必要だ | Ryuzee.com

[Agile]目標ベロシティとベロシティのインフレ | Ryuzee.com

fortunecodec ? 塹壕よりScrumとXP（日本語訳）

(引用開始)
Actual Velocity
実際速度
スプリントの終了時に確定する、各ストーリーの実装に実際に掛かった作業量。
Estimated Velocity
見積速度
スプリントの開始時にチームが見積もった、各ストーリーの実装に掛かるであろう作業量。
(引用終了)

Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - @daipresents

(引用開始)
アジャイルで登場するのがVelocity（速度）です。ベロシティは、チームがコミットしたイテレーション期間内のストーリーポイント合計を指します。
(引用終了)

【1】XPが「最適なペースの仕事」「週40時間労働」「適切なペース」「プロジェクト速度」という言葉で暗示している概念は、Scrumのベロシティのことだと思っている。

XPが当初注目された時に最も目立ち、賛同と批判の両方が入り交じったものが「週40時間労働」だった。
IT業界はサービス残業が当たり前で定時退社はありえない現状があるからこそ、週40時間労働が暗示している「適切なペースの仕事」というアイデアは誰も具体的に認識していなかったと思う。

駄目なプロジェクトは、前日の残業疲れがあるので、皆いろんな理由で遅刻して出勤するので朝会も開けない。
おもむろに仕事を始めて、だいたい午後4時ぐらいから開発速度が上がってくる。
そして、終電間際までバタバタ仕事をして終わる。
金曜にバグを発生させるコミットが多い: プログラマの思索でも書いたけれど、定時後の作業や休日出勤が当たり前になってくるために、18時以降や週末にコミット回数やバグ消化数が増える。
学生症候群で仕事をするのが当たり前なのだ。

何故なら、最後の1回の本番リリース直前まで本当に動くかどうか分からないので、動作確認できる期間が短く、バグ取りがリリース直前に集中してしまうからだ。
だから、本番リリース直前が最も忙しいし、リリース後も大量の問合せや障害報告という名の改善要望で溢れかえって、更に忙しくなる。
イテレーションという開発リズムがないために、開発チームが生産できるシステム規模が最後まで分からず、契約という名でメンバーに能力以上の作業負荷を強いる。

【2】XPでは、ケント・ベックがソフトウェア開発を車の運転にたとえて「ドライブ」という概念を多用する。
イテレーションの目的はストーリーの完成であり、ドライブはストーリーを実現させるマネジメントのこと。
「イテレーションを運転する」「リリースを運転する」とXPでは呼んでいる。

そのためにストーリーを完成させるまでのタスクをトラッキングする必要があり、その責任を負う人をトラッカとXPは呼んで、マネージャやメンバーと区別していた。
僕のイメージでは、XPのトラッカはScrumマスターの役割に似ている。

トラッカの仕事は、タスクの進捗具合をメンバーに確認して、見積を上回るタスクを特定して、早めに対策を打つチャンスをチームにフィードバックすること。
普通は、朝会(XPならスタンドアップミーティング、Scrumならデイリースクラム)でタスクの進捗に触れる機会があるだろう。
基本は、イテレーションを開始する前に決めたイテレーション計画の内容と実績に相違がないか、いつも追跡(トラッキング)する作業を担う。

トラッキングした結果、タスクにトラブルが発生していれば、メンバー個人の問題ではなく、チーム全体でカバーすることになる。
1人日遅れたタスクは二度と元のペースに戻ることはない、という事実は、僕自身も経験してきたし、その場合はチーム全体で計画をやり直してリソースを投入するしか解決策はないと思う。

トラッキングしてみると、開発チームが1イテレーションで実装できるストーリーの量、タスクの量は実は安定している。
XPではそれをプロジェクト速度を呼んでいた。
多分、それはScrumのベロシティに対応していると思う。

【3】XPの弱点の一つは、計画ゲームと呼ばれるプラクティスが曖昧なこと。
見積もりやマネジメントはどうやって行うのか、が明示されていないので、XPの中で最も難しいプラクティスの一つだった。
計画ゲームから出てくるプロジェクト速度の概念は、僕はずっと分からなくて、生産性のことだと漠然と思っていた。

そして、チケット駆動開発を実践したプロジェクトで、ベロシティらしき数値に気付いた時がある。
その時は、WF型開発＋補間チケット方式でTracでチケット駆動開発を実践していて、チケットはWBSであらかじめ決めて、故意にイテレーションを1ヶ月に区切って開発していた。
当然、朝会はTracのチケット一覧を見ながら進捗と課題を確認し、1ヶ月終わる度にKPTでふりかえりミーティングをやった。

毎回のふりかえりで、僕はTracのレポート機能を使ってチケットを集計してメンバーに見せるのだが、毎月の終了チケットがほぼ40～50枚で安定していた。
更に興味深かったのは、最後の1ヶ月はどうしてもリソースが足りないと前持って判断していたので、メンバーを1人追加投入したにも関わらず、その月のイテレーションの終了チケット数は今までのチケット数とほぼ変わらなかったことだった。

チケットに掲載されたタスクはWBSから起こしたものが殆どだったので、チケットの粒度は安定していたから、1イテレーションでこなせるタスク量はほぼシステム規模と近似しており、安定していたのだろうと推測している。
また、人を増やしてもイテレーションごとの終了チケット数が変化しなかったという事実は、生産性が最後のイテレーションは低かったのではなく、開発チームのベロシティが安定していたことを示しているのではないか、と直感している。

但し、その時の事例はチケットの粒度が安定していたからベロシティが分かりやすく出現したわけであって、普通のチケット駆動開発では、チケットがタスクだけでなく、バグ修正やQA、課題なども入り乱れるので、チケットの粒度の幅が大きくなりやすい。
だから、チケット駆動開発上でベロシティを計測するには、チケットの属性にストーリーポイントを必ず入れるしかないだろうと思う。

【4】XPのプロジェクト速度ないしScrumのベロシティは上昇させるものではなく、安定させるべきものという主張は、XPの「適切なペースの仕事」が暗示していることと同一だと思う。
プログラマにとって人生で一番悲しい言葉、そしてプログラマの権利: プログラマの思索で書いたけれど、プログラマにプレッシャーを与えて仕事をさせたとしても、生産性は上がらない。
開発チームが安定してアウトプットを出せる環境を作り、維持していくのが大事。

イテレーションのリズム、適切な仕事のペース、Scrumのベロシティが主張していることは、潮の満ち引きのように、ソフトウェア開発には安定したリズムが必要であることを意味していると思う。

Scrumは、本来の意図がどうであったか分からないが、XPの弱点を補強する形で、アジャイル開発のマネジメントの概念を明確に定義してくれていると思う。