23

固定価格のソフトウェア開発プロジェクトに取り組んでいると、価格が設定されてから作業を開始するまで (または開発の非常に早い段階) に、プロジェクトにかかる合計時間を見積もらなければならないことがよくあります。残念ながら、これらのタイプのプロジェクトは、反復的/アジャイルな方法を使用して開発するのが最適です。つまり、完全な事前設計を行うことはできません (実際にはできません)。

典型的なシナリオでは、X の機能と Y ドルの契約があります。契約後、エンジニアリング部門は、X 機能を完了するのに必要な時間を見積もる必要があります。この情報を前もって必要とするいくつかの理由が考えられます。

• Y ドルは利用可能な Z 時間に変換されるため、おそらく X の範囲を縮小して、time(X)<=Z であることを確認する必要があります。

• 配達日が設定されているため、その日に間に合うように適切なリソースを割り当てる必要があります。

Kelly Waters は、ここでアジャイルの見積もりについて興味深い見解を持っています: http://www.agile-software-development.com/2009/04/agile-estimating.html時間に換算します。

次の 2 つのいずれかを実行できるようにする必要があるように思えます。

• アジャイルな開発プロセスに対応するために、非常に柔軟性のある契約を取得します。

• まだ設計されていない機能について、合理的に正確な事前見積もりを提供する方法を考え出す。

もちろん、ほとんどの場合、最初のオプションはオプションではありません。アジャイル開発シナリオで事前見積もりを生成する方法について、誰かアドバイス/ガイダンスはありますか?

あるいは、他のプロセス変更を通じて問題を解決するための別のオプションを誰かが考えていますか?

4

6 に答える 6

11

すべてのクライアントは、特定の数の機能の実装にかかる費用を少なくとも見積もりたいと考えていると思います。アジャイルを使用している場合、これを行うことはできないと言う人には同意しません。アジャイルは、クライアントがプロジェクトに費やす金額を知りたい、または少なくとも大まかなアイデアを知りたいという現実の世界に適応できます。

したがって、これを行う方法が少なくとも 2 つ文書化されており、その両方については、Mike Cohn 著の「Agile Estimating and Planning」という本に記載されています。この本を読むことを強くお勧めします。

  • プロジェクトを開始する前に、ストーリーをタスクに分解し、各家を数時間で見積もる練習をしてください。それらの見積もりで予算計算を行います。これらの見積もりは、見積もり時間/予算に到達するためにのみ使用されることに注意してください。プロジェクトが開始されると、チームは通常どおりタスクの見積もりと作成を担当する必要があります。

  • 履歴データを使用します。同じチームが以前に同様のテクノロジーを使用したプロジェクトに取り組んだことがある場合は、過去のチームのベロシティを使用してプロジェクトのコストを見積もることができます。

繰り返しますが、これを行う方法の詳細については、参照されている本を読んでください。

于 2009-11-24T09:28:07.920 に答える
9

Big Upfront Estimation は、$$$ が添付された Big Upfront Design です。

そうしないと、アジャイルのパラダイム全体に完全に反することになります。

アジャイルは固定費に関係している可能性があります

あなたができることは、日付を設定し、イテレーション/スプリントでそれに向けて取り組み、プロダクト所有者にその日付までに何が重要であるかを決定させることです. このように、1 週間または 2 週間のスプリントは、ビッグ アップ フロント デザインと同じように固定費であり、固定費が小さいだけです。

アジャイル方法論の背後にある全体的な前提は、恣意的な締め切りと、契約と締め切りで変更が考慮されていないために生じる死の行進を排除することです。SCRUMは機能し、方法論を構築し、それについて読んで、少なくとも出発点としてそれが言うことを行うための優れた出発点です.

顧客からのフィードバックと承認を得た短いスプリント

将来の見積もりを改善するための出発点を提供し、製品所有者と顧客から非常に迅速に信頼を得るのに役立ちます.

于 2009-11-23T22:09:54.233 に答える
5

アジャイルの固定価格は、特定のチーム サイズに対して実行できる反復回数を示します。アジャイルのポイントは、これらの反復中に得られる価値を最大化することです。アジャイルとはスコープ管理に関するものです。

したがって、実際には事前の見積もりを行うべきではありません。これは、アジャイルや反アジャイルとは正反対の固定範囲を意味します。

別の回答で指摘されているように、アジャイルはこのようには機能しません。新しい種類の契約が必要です。たとえば、10 Agile Contractsおよび/またはgoogleを参照してください。

于 2009-11-23T22:26:37.780 に答える
4

「プロジェクト全体」の契約を目指すのではなく、1〜2か月間だけ実行される契約を作成する必要があります。

いくつかの非常に低い目標を設定します。おそらく2つまたは3つの機能だけです。

これはプロジェクトの発見段階であることをクライアントに説明します。このフェーズがないと、スコープ全体の見積もりを出すことはできません。彼らに不正確な見積もりを与えることは誰の利益にもなりません。

クライアントには、次のようなメリットがあります。

  • 前払い費用を削減します（合計価格のほんの一部）。物事が悪化した場合、彼らの経済的エクスポージャーには限界があります（ほとんどのソフトウェアプロジェクトが失敗することを考えると賢明です）。
  • 問題のいくつかをすぐに解決する可能性のあるソフトウェアを数か月以内に使用できるようにする
  • 要件についての考え/会話を誘発するための実用的なソフトウェアを持っている
  • クライアントは彼らが実際に欲しいものについてもっと知るでしょう
  • クライアントはあなたがどれだけうまく働いているかを見ることができます。彼らがそれを気に入らなければ、彼らは他の場所を見ることができます。
于 2009-12-11T02:25:43.637 に答える
3

「そうしないと、アジャイルのパラダイム全体に完全に反することになります」: これはかなり間違っていると思います。アジャイルは常識に基づいており、おおまかなコストがどれくらいかかるかわからなければ、誰もプロジェクトに投資しません。締め切りに間に合わせるためにスコープを縮小したり、予算を増やしたり、スコープ全体を提供するために締め切りを延長したりする必要があるかもしれないことを理解しています。私の会社のプロジェクトでは、プロジェクトのサイズを比較して見積もっています。また、ポーカー プランニングを使用してエピックを見積もっています。不確実性の円錐を使用し、品質をトレードオフすることなく、最初のスプリントを開始する前に、現実と比較して見積もりを最大で約 50% オフにします。そして、アジャイルの専門知識 (精度と最初の見積もりを得るまでの時間) を構築するにつれて改善します。あなたはできる'

于 2011-07-30T21:01:34.603 に答える
1

ストーリー ポイント (リンク先の Kelly Waters の記事で説明されています) でバックログ項目を見積もる場合、問題は、チームがスプリントで提供すると予想されるストーリー ポイントの数になります。チームが以前に共同作業を行ったことがある場合は、これを推測できるはずです (おそらく、信頼範囲を示す上限と下限を使用して)。

チームが以前に一緒に仕事をしたことがない場合は、いくつかのよく理解されたストーリーを取り上げて、それらを詳細なタスクに分解できます。これにより、工数が得られ、これをストーリー ポイントの見積もりと比較して、速度を試して予測することができます。繰り返しますが、上限値と下限値の信頼範囲はおそらく適切です。

ユーザー ストーリーの合計が 150 ポイントになり、チームが 1 か月あたり 15 ～ 20 ストーリー ポイントを提供できると予測すると、作業には 7.5 ～ 10 か月かかります (単純な分割による)。

このアプローチの利点は、チームの実際のベロシティを測定し、それを計画と比較できることです。タイムラインの再見積もりも非常に簡単です。たとえば、チームの速度が実際には 1 か月あたりわずか 10 ストーリー ポイントであることが数回のスプリントの後でわかった場合、修正されたタイムラインがどうなるかを簡単に予測できます。

チームの速度はさまざまな理由で変動することに注意してください。チームがまだ形成されているプロジェクトの開始時は通常、これよりも低くなります。また、この時点では、チームは機能を提供することよりもインフラストラクチャの問題に集中している可能性が高い.

于 2009-12-03T01:16:31.840 に答える