アジャイルな見積もり手法

Abstract

アジャイルプロジェクトにおける作業工数の見積もりは、従来の見積もり方法とは根本的に異なります。 従来の方法は、「ボトムアップ」手法で見積もることです。すべての要件を詳細に記述し、それらの要件を満たすための各作業を時間/日単位で見積もり、このデータを使用してプロジェクトのスケジュールを作成します。 これに対し、アジャイルプロジェクトでは、機能セットに対してグロスレベルの見積もり手法を用い、その後、漸進的な詳細化とローリングウェーブプランニング手法を採用して、ジャストインタイムベースでタスクレベルまで掘り下げ、レベルを下げるごとに詳細化を繰り返しながら、「トップダウン」手法を使用するのである。 この論文では、アジャイル推定のための 2 つの一般的なテクニック (プランニング ポーカーと親和性グループ化) について詳しく説明し、これらの演習の結果がスケジュールと予算の予測にどのように反映されるのかについて触れます。 すべての既知の要件を引き出し、文書化すると、要件を満たすために必要なすべてのタスクと各タスクの見積もりを示すガント チャートを作成することができます。 そして、リソースはタスクに割り当てられ、ローディングやレベリングなどのアクションにより、最終的な納期と予算が決定されます。 このプロセスはボトムアップ方式と呼ばれ、プロジェクトのスケジュールとコストを見積もる前に製品に関するすべての詳細を定義する必要があるからです。 変化のスピードとは、新しい開発ツールや新しい知識へのアクセスのスピードが非常に速いため、納品が遅れると、競合他社に先を越され、時代遅れの製品を提供する危険性があるということです (Sliger, 2010)。トップダウン方式は、現在利用できる情報を使用して、総量の見積もりを行うことにより、この重要な問題に対応します。 その後、ローリングウェーブプランニングを使用して、判明した新しい情報を取り入れ、さらに見積もりを精緻化し、プロジェクトの進行に合わせてより詳細に反復的に練り上げる。

Estimation Techniques

Gross-level estimation techniqueは、スクラムやエクストリームプログラミングのようなアジャイル手法を使用するチームで使用されており、本論文では最も人気のあるテクニックの2つを取り上げます。 プランニングポーカーとアフィニティグルーピングです。 2900>

Planning Poker

グロスレベルの見積もりで最も人気のある手法は、プランニングポーカー、またはフィボナッチ数列を使用して機能またはアイテムにポイント値を割り当てるものである (Grenning, 2002)。 フィボナッチ数列は13世紀に導入された数学的な数列で、木の枝分かれなど、自然のある種の造形的な側面を説明するために用いられた。 この数列は、前の2つの数字を足し合わせて次の値を得ることで生成される。 0, 1, 1, 2, 3, 5, 8, 13, 21,……………………………..。 アジャイルな見積もりのために、いくつかの数値は変更され、次のような系列になる。 1, 2, 3, 5, 8, 13, 20, 40, 100.

これらの数字をトランプのセットで表現する(図表1)。 チームメンバーは「プランニング・ポーカー」(別紙2)を行い、各項目の見積りを点数で提示する。

  • 各チームメンバーはトランプを手に入れる。
  • ビジネスオーナー(見積もりをしない人)は見積もりをする項目を提示する。
  • その項目について議論する。
  • 各チームメンバーは自分の見積もりを表すカードを個人的に選択する。
  • 全員の準備ができたら、選んだカードを同時に公開する。
  • チームメンバー全員が同じカードを選んだ場合、その点数が見積もりとなる。
  • カードが同じでない場合、チームは見積もりについて、外れた値に重点を置きながら議論する。
    • 最も低い値を選んだメンバーがその値を選んだ理由を説明する。
    • 最も高い値を選んだメンバーがその値を選んだ理由を説明する。
  • 推定値が収束するまで再度選択する。
  • 長時間の会話や「雑草の中」の会話が発生した場合、チームメンバーは2分間タイマーを使って議論をタイムボックス化し、タイマーが切れるたびに、収束するまで再度選択することができる。 企画ポーカーカード

    展示物2. プランニング・ポーカーをする様子 (Photo courtesy of Museums and the Web. All Rights Reserved)

    フィボナッチ数が使われる理由、そしてこのような形式で使われるのにはいくつかの理由がある。 まず、チームが見積もり基準として時間を排除すれば、より詳細な見積もりを要求したり、見積もりを水増ししたりする可能性は低くなるという考え方がある。 これらの数字は、時間ではなく、相対的な大きさを表しています。 その結果,見積もりは非常に短時間で終了する. チームは通常、各アイテムにおよそ2分費やし、30アイテムのバックログを1時間で見積もることができます。 チームが 9 つの選択肢 (すなわち、ポイント値またはカード) のみに制限されていることも、プロセスのスピードアップに貢献しています。

    また、この順序は、小規模でよく理解されている機能に対しては適切な詳細レベルを提供し、より高い見積もりに対しては誤った正確さの感覚を避けることができます。 たとえば、高い見積もり (20 以上) を持つ項目は、その項目が大きく、まだよく理解されていないことを意味します。 その項目が20なのか19なのか22なのかを議論することは、単に利用可能なデータが十分でないため、時間の無駄である。 その項目が作業される反復に近づけば、より小さな断片に分解され、より細かい数値(1~13)で見積もることができるようになる。 ポイントの見積もりが 1 ~ 13 の項目は、一般に 1 回のイテレーション (1 ~ 4 週間) で完了します。

    ポイントはチーム間で同じ意味を持たないことに注意することが重要です。たとえば、あるチームの “5” が別のチームの “5” と同じではありません。 したがって、ポイントから得られるチームベロシティは、チーム間の生産性の比較に使用すべきではありません。

    Affinity Grouping

    見積もりをさらに速くする方法、および見積もる項目の数が多い場合に使用する方法は、親和性のあるグループ化です。 チームメンバーは、同じ大きさのものをグループ化するだけで、図表3のような構成になる。

    • 最初の項目がチームメンバーに読まれ、壁に置かれる。
    • 2番目の項目が読まれ、それが最初の項目より小さいか大きいかをチームに尋ね、壁への配置はチームの反応に対応する(大きい方が右、小さい方が左である)。
    • 3番目の項目が読まれ、チームはそれが最初と/または2番目の項目より小さいか大きいかどうか尋ねられます;項目はそれに応じて壁に配置されます。 しかし、より迅速な方法は、各チームメンバーにアイテムを選択させ、各自の最善の理解に基づいてそれを配置させることである。 これは、すべての項目が評価され、壁に配置されるまで、すべてのチームメンバーが並行して作業します。 比較的短時間で数百のアイテムを見積もることができる。 すべての項目が壁に貼られたら、チームはグループ分けを見直す。 チームメンバーが間違ったグループに入っていると考える項目は議論され、適切であれば移動される。

      親和性のグループ化が完了すると、ポイントなどの見積もり単位値を割り当てることができる。

      親和性のあるグループ化が完了すると、ポイントなどの推定単位の値を割り当てることができます。図表3では、左端の最初のセットは1ポイント、2番目のセットは2ポイント、3番目のセットは3ポイント、4番目のセットは5ポイント、最後のセットは8ポイントとラベル付けされます。

      Exhibit 4は、ポイントの代わりにTシャツのサイズでラベル付けされた親和性グループ化アイテムの例です。 親和性のあるグループ化例

      Exhibit 4. T シャツのサイズを使用した親和性のあるグループ化 (グラフィック提供: Chris Sterling。All Rights Reserved.)

      Estimation Units

      T シャツのサイズの使用 (Extra Small , Small , Medium , Large , Extra Large) は、機能の相対的なサイズを考えるもう 1 つの方法です。 これは数値システムからさらに大きく逸脱しており、すべての優れたグロスレベルの見積もり単位と同様に、特定の時間の長さと決して関連付けることはできません。 チームは独自の見積もり単位を作成することができ、おわかりのように、しばしばそうすることでちょっとした楽しみがあります。

      この文書では、理想的な開発日や時間といった時間ベースの単位の使用はカバーしていません。 これらはすでに一般的でよく理解されているため、その説明は含まれていません。 しかし、総量レベルの見積もりは、時間の概念から切り離されたときに、より成功する可能性があることは注目に値します。 時間の見積もりは、経営陣やビジネスによってコミットメントされることが多いため、チームメンバーはできるだけ正確でなければならないというプレッシャーを感じるようになります。 その結果、見積もり対象について、より詳細な情報を要求するようになります。

      Forecasting Schedule and Budget

      グロスレベルの見積もりとチームの速度が決定されると、スケジュールと予算を予測することができるようになる。 チームは、反復で完了したすべてのアイテムの合計ポイント数を合計することによって、自分のベロシティを決定します。 例えば、あるチームは5つのアイテムを選択し、合計ポイント値が23ポイントだったとします(図表5参照)。 2週間のイテレーションの終わりに、チームは5つの項目のうち4つしか完成させることができませんでした。 彼らのベロシティは、1~4のポイントの合計である15である。 チームは項目の一部を完了しても「部分単位」を得られないので、たとえ項目5に着手していたとしても、完了していないのでカウントされない。

      Exhibit 5. チームベロシティの決定

      スケジュールの決定

      長期スケジュールの予測には、チームの平均ベロシティが使用される。 平均ベロシティは、チームの過去3回の反復からベロシティ測定値を合計し、その合計を3で割ることによって計算されます。 つまり、あるチームが最初の反復で15点、その後の2回の反復でそれぞれ20点を達成した場合、そのチームの平均速度は18(15+20+20 / 3)です。 もし、あるチームが1回のイテレーションで平均18ポイントを達成し、プロジェクトで完了すべき作業が144ポイント分あるとすると、その作業を完了するのに8回のイテレーションが必要です(144 / 18)。 1回の反復が2週間だとすると、完成予測は16週間となる。 この方法によって、「この作業はいつ終わるのか」という質問に答えることができる。

      チームにベロシティ データの実績があれば、最も楽観的な完了日、最も悲観的な完了日、そして最も可能性が高い日を決定することが可能である。 チームの平均ベロシティ数値は最も可能性の高いシナリオを計算するために使用され、チームの最も成績の悪い反復のベロシティ数値は最も悲観的な予測完了日を計算するために使用されます。

      また、これらの数字を使用して、「この日までに何かを提供しなければならないが、その日までにいくつの機能を完成させるのか」という質問に答えることもできます。 完了する可能性が最も高い予測量、悲観的予測、楽観的予測の例については、図表6を参照されたい。 この例は、平均速度が20で、最悪速度が12、最高速度が25のチームの場合である。 この状態で6週間(3イテレーション)しかない場合、どの程度完成させることができるのでしょうか? 悲観的な予測では,6週間で完了するのは項目1~8だけである. 楽観的な予測では、1~18の項目が完了すると思われる。 そして、チームの平均速度20に基づく最も可能性の高い予測は、項目1~13が6週間で完了することです。

      チームがTシャツのサイズなど数値以外の推定単位を使用していた場合、予測のためのアルゴリズムはより複雑になるでしょう。 より簡単に類似のデータを生成するために、サイズを数値システムに変換することが推奨されます。 例えば、SmallはNUTの3、MediumはNUTの5、といった具合に変換することが可能である。 これらはまた、時間範囲に変換されるかもしれません(例えば、小は1-3日かもしれません)が、これは見積もり単位のセクションですでに引用した問題のために、本質的に危険です。 項目完了の予測例

      Determining Budget

      このセクションでは、「資金はこれだけしかないが、いつまで持つのか、使い切るまでにどれだけできるのか」に対する答えを見ていきます。

      Σ (期間 n のロードされたチーム給与) / 期間 n で完了したポイント

      ある期間、たとえば 2 週間の反復を 3 回行った場合のチームの給与の合計 (ロード) を取り、同じ期間にチームが完了したポイントの数で割ります。 つまり、6週間で給与の合計が24万ドルで、その3回の反復作業で60ポイントの作業を完了したチームは、1ポイントあたりのコストが4,000ドルとなるわけです。 ここで、次の式を使用して予算を決定する:

      (ポイントあたりのコスト×完了する項目の合計ポイント値)+その他の費用=予測予算

      プロジェクトの開始時に製品のすべての機能が定義されていないことがかなりあるが、これはアジャイルプロジェクトでは予想されることである。 そのため、予算の見積もりは、現在わかっていることに加えて、過去のデータや専門家の指導に基づく予測アルゴリズムに基づいて行われる。 例えば、今のところ20の機能しかリストアップされていないが、最初のリリースが顧客にどのように受け取られるかを見るまでは、ビジネスでは追加の機能要求や改良を提供することはできないとする。 3回のリリースを予定しているプロジェクトの予算は、最初のリリースのみの予測データで、プロジェクト全体ではありません。 チームは上記のアルゴリズムを使用して最初のリリースの予算を予測し、次に過去の経験に基づいて、2番目のリリースにさらに20%、最後のリリースにさらに5%を仮定することができます。

      ベロシティと同様に、予算予測とスケジュール予測は反復ごとに改訂されます。 これは、アジャイル プロジェクトが準拠しているローリングウェーブ プランニング プロセスの一部です。

      Final Words

      この論文で特に取り上げられていないのは、カンバンなどのリーン方式で使用される構造化した見積もり技法の欠如です。 アイテムの見積もりに時間をかける (無駄にする) 代わりに、平均サイクル タイムとリード タイムは、チームの実際のスループット レートに基づいて計算されます。 かんばんは、数学的な定理であるリトルの法則を計算式の基礎として使用しています。 累積フロー図からリードタイムを計算することで、見積もり作成に時間をかけることなく、プロジェクトのスケジュールを予測することができます。 読者はこのトピックについて独自の研究を行うことが推奨され、それ自体が別の論文になる可能性があります。

      Agile プロジェクトは、顧客フィードバックやその他の学習を次のリリースに組み込むために、製品または製品増分を早期に、頻繁に提供することを目的としています。 実験、実行、および学習に多くの時間を費やし、推測にかける時間を減らすことで、納品のサイクルタイムが短縮されます。 アジャイルチームは、市場での競争力を高め、増え続ける変化のスピードに対応することができます

コメントを残す

メールアドレスが公開されることはありません。