見積もりの目的

アジャイルソフトウェア開発を最初に経験したのは、エクストリームプログラミングの黎明期に、Kent Beckと一緒に作業したときでした。そのプロジェクトで感銘を受けたことの1つが、計画を立てる方法でした。これには、これまで目にしてきたよりも軽量でありながらより効果的な推定を行うアプローチが含まれていました。それから10年以上が経過し、経験豊富なアジャイリストの間には、推定はまったく行う価値があるのか、それとも実際には有害なのかという議論があります。[1]この質問に答えるには、推定がどのような目的に使用されるのかを調べる必要があると思います。

よくあるシナリオは次のとおりです。

• 開発者は今後の作業の見積もりを要求されます (または提供されます)。

人間は楽観的なので、これらの見積もりは低くなりすぎてしまう傾向があります。低く見積もるようプレッシャーをかけられることもありません (通常はある程度の暗黙のプレッシャーはあります)。

• これらのタスクと見積もりはリリース計画に変換され、バーンダウンチャートで追跡されます。
• 時間と労力がこれらの計画に対する進捗の監視に費やされます。実際の進捗が計画を超えると、誰もが動揺します。見積もりを追いつかせるために、開発者は品質を犠牲にするように言われます。そうなると事態はさらに悪化します。

この場合、見積もりに費やした労力は、せいぜい無駄です。「見積もりはきれいにして着た推測」[2]だからです。通常、見積もりはFeatureDevotionを促進するため、有害なものになってしまいます。FeatureDevotionとは、人々がプロジェクトの実際の成果を追跡することよりも、機能を完了することに価値を見出すようになる厄介な状態です。[3]

見積もりは期待値を設定しますが、見積もりは通常低くなりすぎるため、非現実的な期待値を設定します。[4]そのため、時間や機能の拡大が損失と見なされるようになります。損失回避により、これらの損失は増幅効果をもたらします。[5]

このような状況に直面すると、人々が推定に対して怒りを向けるのは理解できます。その結果、推定に携わる人は皆、真のアジャイリストではないという考えが広まっています。アジャイルの批評家は、これはアジャイル開発は開発者が漠然としたことをやって、いつ終わるか、気に入ってもらえるかが決まれば終わりだと約束することだと述べています。

私は、推定は本質的に悪であるという見解には賛同しません。推定が良くないことかどうかを尋ねられた場合、一般的なコンサルタントの答えとして「状況による」と答えます。誰かが「状況による」と答えると、常に「何の状況によるのか」という追及を受けます。それに答えるには、なぜ推定を行っているのかを問う必要があります。私は「うまくやる価値があるなら、そもそもなぜやっているのかを問う価値がある」と言っています。

私にとって、推定は重要な意思決定を行う際に役立つ場合に価値があります。

見積もり情報に基づく意思決定の最初の例は、リソースの割り当てです。通常、企業には限られた金額と人員があり、通常、実施に値するプロジェクトは多すぎます。そのため、人々は判断を迫られます: A を実施するか、B を実施するか?このような判断に直面した場合は、それぞれのプロジェクトにどれだけの労力（とコスト）がかかるかを知ることが役立ちます。何をすべきかについて賢明な意思決定を行うには、コストとメリットの両方について理解する必要があります。

別の例は、調整に役立てることです。ブルーチームは Web サイトに新機能をリリースしたいと考えていますが、グリーンチームが重要なデータを提供する新しいサービスを構築するまではリリースできません。グリーンチームが 2 か月で完了すると見積もり、ブルーチームが機能の構築に 1 か月かかると見積もった場合、ブルーチームは今日始める価値がないことを理解します。ブルーチームは少なくとも 1 か月はリリースが早い他の機能に取り組むことができます。

したがって、見積もりの依頼を検討する場合は、その見積もりがどの意思決定を知らせるのかを常に明確にする必要があります。見つからない場合、または決定があまり重要ではない場合は、それは見積もりは無駄であるというシグナルです。意思決定が見つかった場合は、意思決定がコンテキストを提供するため、見積もりに焦点を当てます。また、必要な精度も明確にする必要があります。

意思決定を理解すると、見積もりを伴わない代替策を思いつく可能性もあります。おそらくタスク A が B よりもはるかに重要であるため、すべてを利用可能なエネルギーを最初に投入するために見積もりは必要ありません。ブルーチームのメンバーが、グリーンチームと協力してサービスをより迅速に構築する方法があるかもしれません。

同様に、計画に対する追跡は、それがどのように意思決定の情報を提供するかによっても推進されるべきです。ここで私がいつもコメントするのは、計画は変更を評価するための基準となるというものです。新しい機能を追加する場合は、FivePoundBagにどのように収めますか?見積もりは、これらのトレードオフを理解し、変更に対応する方法を決定するのに役立ちます。大規模では、リリース全体の再見積もりは、プロジェクト全体が依然としてエネルギーを最も有効に活用する方法であるかどうかを理解するのに役立ちます。数年前、私たちは、数か月後に再見積もりを行った後、1 年間のプロジェクトをキャンセルしました。私たちはそれを成功と見なしました。なぜなら再見積もりは、プロジェクトの完了に当初の予想よりはるかに時間がかかると示唆したからです。早期キャンセルにより、顧客はリソースをより適切なターゲットに移すことができました。

ただし、計画に対する追跡を伴う見積もりには有効期限があることに留意してください。私はかつて、計画と見積もりはレタスのようなもので、数日間は新鮮ですが、1 週間後にはしおれてしまい、数か月後には認識できなくなると、気の利いたプロジェクトマネージャーが言っていたのを覚えています。

多くのチームは、見積もりによってチームメンバー同士が会話するのに役立つ強制機能が提供されると感じています。見積もり会議は、今後のストーリーの実装、将来のアーキテクチャの方向性、コードベース内の設計上の問題をより深く理解するのに役立ちます。場合によっては、出力の見積もり数値は重要ではありません。このような会話はさまざまな方法で行うことができますが、このような会話が行われていない場合に、見積もり議論を導入できます。[6]逆に、見積もりを中止することを考えている場合は、見積もり中の有益な会話を他の場所でも継続させる必要があります。

アジャイル的な精神のカンファレンスに行くと、見積もりなしで効果的に働いているチームに関する講演を耳にするでしょう。多くの場合、これらのチームとその顧客は、見積もりをしても重要な意思決定に影響を与えないことを理解しているため、この方法が機能しています。その一例は、ビジネスと密接に連携する小規模なチームです。より大きなビジネスがそのビジネスユニットに人員を割り当てて満足している場合、仕事は優先順位に従って実行できます。多くの場合、チームが作業を十分に小さな単位に分割することで、これが助けられます。 [7] ここでの役割は、 アジャイルの流暢性モデルでのチームレベル によって大きく異なります。チームが成長すると、最初に推定に苦労し、その後はかなり得意になりますが、最終的には必要なくなる時点に達します。 [8]

推定は善でも悪でもありません。推定なしで効果的に作業できる場合は、そのままにしておきます。何らかの推定が必要だと思う場合は、意思決定における役割を理解していることを確認してください。重要な意思決定に影響を与える場合は、最高の推定を行います。何よりも、推定が常に必要である、または必要でないと言う人に注意してください。推定の使用に関する議論は常に、特定のコンテキストに適したテクニックを決定すべきというアジャイル原則に委ねられます。