私がもはやベロシティについてほとんど話さない理由

ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。

残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。

もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書いたコードを簡単に変更できない理由の一つとして、人々が慌てて「プロジェクト」を完了させようとしたことが挙げられます。具体的には、たいした自動テストも作成せず、コードを常にリファクタリングできる状態にもせず、ペアプログラミングやモブプログラミングもせず、従来のコードレビューすら行わなかったということです。

大規模な組織では、経験主義に基づくプロセス制御に必要な透明性の確保にとりわけ苦労します。統合され、適切にテストされ、出荷可能な状態でなければ、プロダクトを顧客のニーズに合わせて検査、適応できないのです。1つのプロダクトに複数のチームが関与している場合、数週間ごとに　完成 のインクリメントを作成できる状態になるまで、何年もかかることがあります。このような組織は、ベロシティに焦点をあてると誤った方向に進んでしまいます。

ときどきFBI Sentinelはアジャイルの成功例として挙げられますが、誤った方向へ進んでいました。 Twice The Hype の本では語られていませんが、10回のスプリントが終わったころにやっと、顧客がプロダクトに触れられるようになったのです。そして、それは失敗に終わりました。スプリントが10回終わって初めて、彼らの 完成 の定義が、テストに関して弱いことが分かったからです。もうおわかりですよね、完全なテストについてもっと早い段階から、たくさんの対話をする必要があります。ベロシティの向上を求め、ベロシティの話ばかりすると、このような結果になるのです。

質問：

企業が、「リリース日を求める」体質から「リリース日を検討する必要はない」体質に変わるのに、どのような支援をしてきましたか？

MJ:

一般に、業界のトレンドは、より頻繁にリリースすることになっています。製品を常に　出荷可能な状態 にしておくことは、そのための条件となります。ですから、当たり前の品質を担保する技術的な手法が正しく実施されていれば、途中で提供する価値の優先順位をガラガラ変えても、リリース日があることはそれほど怖いものではなくなります。

予測に価値が全くないとは言いませんが、実務ではそれ以上に解決すべき大きな問題があるのです。あなたのリリース計画が最後に正確だったのはいつですか？

質問：

こんにちは、MJさん、教えてください。ベロシティを使わない場合、半年や9ヶ月の納期をどのように計画すればいいのでしょうか？完了した項目と未完了の項目の数を使って計画を立てるのでしょうか？この場合、2つのことが必要になります：①この期間に開発されるすべてのストーリーを知ること ②開発の全期間を通じて、同じような粒度のプロダクトバックログアイテムを持つこと => この2つは現実的ではありません。

MJ:

理論的には、ベロシティは助けになるはずですが、私が見たところ、実際には、このような大きなバッチリリース(半年や９ヶ月の納期)に取り組んでいるところは、プロダクト全体を毎スプリント完全にテストし統合することで、よりリスクを減らすことができるはずです。このような大規模なバッチリリースは、通常、数え切れないほどのバグに悩まされ、リリース日に向けて統合の悪夢が繰り広げられます。

このような痛みを伴うリリースサイクルや、それに続く緊急のホットフィックスやプロダクションサポートの緊急事態の後、私は誰かが「すべての機能をプロジェクト開始前に完璧に定義しておかなかったのが原因だ！」と言ったのを聞いたことがありません。最大の問題は、組織の、コーディング、テスト、マネジメントの習慣（指示命令型）に伴う低品質なコードの蓄積なのです。ベロシティを重視することは、それをさらに 悪化 させるだけです。

私はヨギ・ベラの次の一節が好きです。「理論的には、理論と実践の間には何の違いもない。実践では、この2つは異なる。」

質問：

「スプリント毎」は、ほとんど本当に小さなウォータフォールのようなものです。

コミットを受け入れるごとに、いくつ出荷可能ですか？

MJ:

さらに良い方法があります！サンディエゴのチームのように、一日に何度もライブ機能をリリースし、通常はバグなしにリリースできるように努力することです。

コメント (Adam Gauvinより):

開発者、プロジェクトリーダー、そして時にはスクラムマスターとして、「ベロシティ」と「バーンダウン」は、不要なキーワードです。これらが提供される価値と一致することは極めて稀です。

真面目な話、誤った方向へ進むリーダーシップとプロダクトビジョンの欠如よりは、何であってもマシです。上層部に実際に測定できない付加価値を提示するという前提で、無知と無能を隠蔽するアジャイルとみなされるプロセスは、 ペストのように根絶される必要があります。 私は言いすぎています。ごめんなさい

もし、あなたの会社に、何が必要かを知っている現場の開発者がいるのに、必要なことを疎外するようなマネージャーがいたら、会社や組織は、より誤った方向へ進んでしまうでしょう。

A) 他の会社でより多くの報酬を得ることができる優秀な人材を会社は失います。

B) 顧客に価値を提供できません。

C) [説明できない理由]のために過剰なエンジニアリングを開発者に行わせています。

D) 解決する必要のない問題の解決に終始します。

E) メトリクス収集の名の下に、多くの時間とリソースを浪費します。

F) 実際に役立つはずの優秀な開発者をより多く雇うよりも、PMOやポートフォリオ管理のために（ベロシティやバーンダウンの計測、チームの報告のために…）多くの無駄なリソースを消費したことに気がつきます。

この記事を翻訳するにあたり、清水 弘毅様よりご協力をいただきました。