目次:
ソフトウェアプロジェクトの見積もり
前書き
見積もりは難しいです。残念ながら、それも非常に必要です。企業は見積もりを使用して、リリーススケジュールを予測し、顧客にコミットし、提案された機能を実装する価値があるかどうかを判断し、チームの速度を追跡し、作業に効果的に優先順位を付けます。経営幹部は、機能や成果物がいつ生産できるようになるかを知りたがる場合がよくあります。結局のところ、ソフトウェア開発は簡単な投資ではありません。見積もりがない場合、プロジェクトマネージャーはどのように評価を行いますか？人間が未来を正確に予測できれば、2％の確率で競馬に勝つことはできません。見積もりは大きな難問です。企業が人々に不可能なことをするように頼むことは不可欠であり、必要です。未来を予測することです。
最初に、いくつかの一般的な推定方法を確認しましょう（興奮の一部を逃した場合に備えて）。次に、これが私たちと私たちのプロジェクトにとって何を意味するのかを見ることができます。
占い師モデル
このモデルは、見積もりを作成するためにほとんど労力を必要としません。見積もり担当者は、機能を実装してテストするために何をする必要があるかについて少し考えてから、数値を捨てます。 「…（長い休止）…うーん… 6週間」のように聞こえます。それからみんながうなずいて、次に進みます。彼らはフロントエンドでかなりの時間を費やして、要件について知っていることを話し合うことができました（これはおそらく全体像ではありません）。この注意深い分析により、彼らの見積もりはより信頼できるものになります。プロジェクトの終わりには、見積もりが現実からかけ離れていた理由について、常に受け入れられている論理的根拠があります。スケープゴートとして役立つことができる予期しない状況が常にあります。モデルに重大な欠陥があることは、誰にも起こりません。
では、どうすればこのプロセスを改善できるでしょうか。知っている！分解手法（分割統治）を使用できます。このアプローチは、フロントエンドの機能またはプロジェクトの完全な範囲を知っていることを前提としています。すべての機能は一口サイズのチャンクに分割されます。各チャンクは推定され（占い師スタイル）、それらを合計して全体的な機能/プロジェクトの推定値を取得します。これは確かにより複雑なアプローチですが、2つの理由からより良いようです。
- 作業のチャンクが小さいほど、確実に見積もることが容易になる傾向があります。
- エラー（+/-ある程度）の可能性はまだありますが、すべてを合計するとエラーが互いに相殺され、より信頼性の高い全体的な見積もりが得られると想定されています。
このアプローチの根本的な欠陥は、個々の貢献者（実際に仕事をしている人々）が普遍的に過小評価していることです。それらはまだそれらの上や周りのものよりもかなり優れていますが、それは高い基準ではありません。開発者が予定より早く何かを成し遂げることで自分自身を驚かせたケースを私たち全員が見たので、これはそうではないようです。ただし、これは単一のデータポイントであり、傾向ではありません。人々は実際にカジノで時折勝ちます。カジノで1年間毎日お金を使うと、最初よりもお金が少なくなります。 1、2年の見積もりと実績を追跡すると、見積もりが現実に達していないことがわかります。多くのビジネスマンは、開発者が見積もりを怠惰に埋めて、余分な時間を「金メッキ」または在庫の確認に使用していることを絶対に確信していますが、データはそうではないことを示しています。 「キャンセル」戦略は機能しません。
んで、どうする？占い師モデルを捨てて、サイズベースのアプローチに切り替えましょう。人間は完了時間を見積もるのはかなりひどいですが、実際には何かがどれほど大きいかを言うのはかなり得意です。私たちは特に比較サイジングが得意です（「それよりも大きいが、あそこよりも小さい」）。時間ではなくサイズや複雑さの観点から考えると、私たちの脳はそれをより確実に処理します。次に、サイズの値を取得し、気の利いた魔法の公式に基づいてプロジェクトの実際の時間数を計算できます。そして、人気のファンクションポイントモデルが登場したときです（左のステージ）。
ファンクションポイント分析（FPA）
ファンクションポイント分析では、アプリケーションで5つのタイプのものを識別する必要があります。外部入力、外部出力、外部クエリ、外部インターフェイスファイル、および内部論理ファイルです（定義についてはあまり気にしないでください。後で調べることができます）。 。それらの各例（関数）には、それに関連する複雑さ（低、平均、または高）があります。以下の表を使用して、各機能に割り当てられるポイント数を計算します。
ここで、すべての関数のポイントを合計すると、プロジェクトの457ファンクションポイントのような数が得られる可能性があります。次に、時間数を計算する式が必要です…前回のプロジェクトに基づくと、「配信率」は1人あたり月額15ファンクションポイントでした。これは約30人月分の作業であり、12人の私のチームでは2か月半強かかるはずです。
これは確かに以前のモデルよりも複雑です。実際、認識すべき複雑さの4つの重要な領域があります。
- 5つのコンポーネントタイプは必ずしも直感的ではなく、リストに何かを入れたり、間違ったバケットに割り当てたりするのを忘れがちです。
- 実際にファンクションポイントを生成するために使用されるテーブルには、検証に多くの労力を必要とするマジックナンバーが含まれています。これらの数値は、チームの信頼できる見積もりを生成するために適切に調整されていますか？
- 配信率（パズルの重要な部分）は、チームの生産性に基づいて計算されます。新しい数値を計算する必要がある頻度はどれくらいですか？実際、これに関するガイダンスはほとんどありません。
- 低、平均、または高の複雑さを構成するものは何ですか？誰もがそれを理解できるように、それをどのように定義しますか？私たちの計算の正確さにとって、それを正しくすることは重要ではありませんか？
この非常に単純な例にはいくつかの可動部分があり、より複雑な複雑さのモデルや、関係する可能性のあるその他のデータ（コスト率、サポート率、欠陥密度など）についても説明していません。可動部品が多いほど、エラーが発生する可能性が高くなります。今、見積もりを複雑にしすぎていませんか？見積もりに多くの時間を費やすために開発者にお金を払っていません。見積もりを顧客に販売することはできません。動作するソフトウェアが必要です。他に何かありますか？
アジャイルになる
次に、アジャイルスクラムを簡単に見てみましょう（比較を行うのに十分です）。先に述べたように、人間は時間を見積もるのがひどく、比較サイジングがかなり得意です。理解すべきいくつかの用語は次のとおりです。
- スプリント-タイムボックス化された期間（通常は2週間）。
- ユーザーストーリー-個別の作品。できれば、スプリントで1人で行うのに十分小さい作品。これは私たちが推定していることです。
最も一般的な戦略は、推定にフィボナッチ数列（0、1、2、3、5、8、13）を使用することです。線形ではありません。スケールを大きくすると、ギャップのサイズが大きくなります。重要なのは、わずかな違いについて議論する理由がないように、ギャップを十分に広くする必要があるということです。3を超えると、4と5または7と8の違いはごくわずかであるため、どちらであるかをハッシュするのに時間を費やしても意味がありません。基数2のシーケンスも機能します（0、1、2、4、8、16など）。
「しかし、待ってください、これは単なる数字です。どういう意味ですか？ポイントは何時間ですか？」ポイントは、時間と直接相関することを意図していません。なぜなら、そうすると、チームは時間単位での見積もりに戻り、それを何らかの方法でポイントに変換したくなるからです。前に説明したように、見積もりの精度は、サイズの比較から得られ、何かにかかる時間数を見積もることはありません。チームに時間の観点から考える能力を与えると、正確に見積もる能力が損なわれます。
キャリブレーションの演習から始めたとしましょう。チームを部屋に引き込み、10〜12のユーザーストーリーのリストをチームに説明します。小さいが最小ではないものを選び、最初にそれを行います。それを確認して、このストーリーが「3」であることを発表します。あなたは求めていません。あなたが言っている。次に、次のストーリーに進みます。 「それが3だったら、これは何ですか？」現在、チームは他のストーリーと比較してストーリーのサイズを決定しています。最終的に、彼らは「1」、「2」などを構成するものについてかなり良い考えを持っているでしょう。彼らは推定していません。時間は関係ありません。彼らはすでに数を持っている他の物語と比較して、物語のサイズを決めています。次に、定規と呼ばれるドキュメントに、シーケンス内の各番号のサンプルストーリーを配置できます。 「5」が何であるかわからない場合は、それを参照として使用できます。
これが鍵です。この作業を可能にする魔法のソースは「速度」です（3〜4回のスプリントで平均したスプリントでチームが完了することができるポイントの数）。スプリントが2週間で、8人のチームの平均速度が35ポイントだとします。 640時間の作業（8 x 80時間）で35ポイントを獲得できます。機能の開始から終了までに約100ポイント相当の作業が必要であることがわかった場合、それは約6週間の作業と約1900時間であることがわかります。チームは一貫してストーリーのサイズを決定するのが得意であり、それを活用してプロジェクトの計画を立てます。期間がスプリントからスプリントまで一貫しているため、この計算は機能します。
長期的な高レベルの計画を立てるには、リードに高レベルの機能を暫定的なワンライナーストーリーに分解してポイント値を付けるように依頼できます。ある程度の精度は失われますが、あなたは彼らがすでに理解しているモデルを活用しています。より正確なパスは、機能レベルでの相対的なサイズ設定です。「この機能は、その40ポイントの機能よりも大きく、あそこの120ポイントの機能よりも小さく、先ほど行った65ポイントの機能よりもわずかに大きいです。」ストーリーは「エピック」に分類されます。各機能が叙事詩である場合、最後に、その機能を完了するのに何ポイントかかったかがわかります。その履歴を保持しておくと、リリース計画に使用できます。
結論
今日使用されている方法論はたくさんあります。それぞれに長所と短所があります。どういうわけか、適切な決定を下せるように、見積もりの精度を最大化する方法を理解する必要があります。それは私たちの見積もりが正確でなければならないという意味ではありません。それらは、有用であるために十分に正確である必要があります。見積もりがわからない場合は、チームがうまくいかなかったため、見積もりが正確でなかったと思われるかもしれません。彼らは正しく見積もりをしなかったか、プロジェクトを正しく実行しませんでした。見積もりが改善されるまで、殴打は続きます。ただし、見積もりをコミットメントとして使用しないでください。今日の限られた情報に基づくのが最善の推測です。新しい情報が表示された場合は、見積もりを再検討できるようにする必要があります。他の何かは不可能を期待しています。それは（チームではなく）リーダーシップの問題です。
スクラムのアプローチは、ファンクションポイント分析で見られるものよりもはるかに単純です。そして、マジックナンバーのあるマジックテーブルよりもはるかに信頼できると思います。それは大金のために最大の価値を得る（適度に高い精度で最小限の努力）。努力の観点からは、チームが理解して使用するための重いプロセスを作成することはありません。アジャイルの見積もりは、見積もり対象の作業の詳細を全員が理解すると、実際には非常に迅速に発生する可能性があります。薄い空気から数字を引き出すよりは確かに良いです。速度を活用することは非常に重要なことをします：それは計算に履歴データをもたらします。スプリントごとに、速度を再計算します。時間の経過とともにスループットが変化するため、これは重要です。 FPAを使用するチームは、以前のプロジェクトから配信率を導き出す可能性があります。場合によっては数ヶ月前のことです。それ以来、おそらく多くの変化がありました。私の提案は、アジャイルを探求し、ストーリーのポイントと速度を理解することに真剣に取り組むことです。それがあなたが理解していることであるという理由だけで、時間単位での見積もりに頼らないでください。後で感謝すると思います。