3

2 つの Web アプリケーション (DAL/DAO/BO アセンブリといくつかの OSS ライブラリを共有する) を含むプロジェクトがあるとします。

  • 認証に Windows Live ID を使用し、さまざまな通知サービス (電子メール、SMS、Twitter など) と通信することもできる半複雑な管理アプリケーション。対象となる通知機能は機能の約 10% です。
  • 機能は少ないが堅牢性が高く、認証に Windows Live ID も使用する、単純からやや複雑なユーザー アプリケーション

中程度の見積もり能力を持つ私たちのうちの 2 人がいて、たとえ私たちが望んでも、またはしなければならないとしても、2 日でそれを行うことはできません。少なくとも、それはかなりかけ離れた見積もりになるでしょう。

質問

  1. 信頼できる/価値のある見積もりを行うには、通常どのくらいの時間がかかりますか?
  2. 精度を犠牲にすることなく推定を高速化するために何を提案しますか?
  3. 推定速度に応じて、どのくらいのスラック(コスト/時間の観点から)を追加しますか(あなたが言う場合:まだかなりずれていると思うので、もう少し推定できます
4

5 に答える 5

4

私たちはアジャイル手法 (具体的にはスクラム) を使用しているため、ユーザーが優先順位を付けるのにかかる時間よりも約 1 時間長くかかります。

時間をかけても精度が向上するわけではありません。

難しいのは、ユーザーに優先順位をつけさせることです。「すべてが時間通りに完了しなければ、すべての価値がない」という議論を常に耳にします。「何らかの値を持つXYZZYコンポーネントを除いて。」この議論は、XYZZY が最初であるべきだという結論が出るまで、何時間も続く可能性があります。

通常、4 週間のスプリントを作成しようとします。最初のいくつかは複雑です。なぜなら、常に何か新しいものがあるからです。最初の 2 つ (または 3 つ) の後は、安定したペースを設定しているようです。

各ユースケースには、それを完了するのにどのくらいの労力がかかるかについて、比較的単純で主観的な評価があります。1 つの完全なスプリントの期間を超えるものはすべて分解する必要があります。ほとんどの場合、いくつかのユース ケースが 1 つのスプリントにまとめられます。

これは、コストとスケジュールの問題をより適切に処理するために、各ユース ケースをスコアリングする正式な方法です。余分な労力は役に立たないので、私たちはそれらを使用しません。

最初の2回のスプリントの後、

  1. 新しくて異なる機能があり、

  2. 優先順位がすべて変わり、

  3. 各ユースケースの詳細が大幅に改訂されました。

推定しようとしているものが各スプリントの終わりに変化する場合、「精度」とはどういう意味ですか?


1 つの教訓が得られました。私の会社の一部は、提供されるものを正確に完全に定義し、それから彼らが望むものを正確に提供しているかどうかを測定するのに長い時間を費やしています.

顧客はこれに気づき、「契約の内容を提供するために多くの時間を費やしていますが、それは私たちが必要としていたものではありません」と言われました.

確固たる事前見積もりの​​問題は、それらが独自の人生を歩むことです。見積もりに「投資」すればするほど、見積もりは有用な成果物であると思われます。それらは一般的に完全に間違っているため、役に立ちません。それらは完全に間違っている事前の仮定に基づいています。

見積もりに多くの時間費やすのは悪い方針です。「正確な」回答はそれほど正確ではありませんが、管理のすべての階層でより大切にされています。あなたと顧客が学習するにつれて、多くの仮定が無効になり、常に再見積もりする必要があります。

前もってやらないでください。契約で前もって行う必要がある場合は、変更管理規定があることを確認し、今後は絶対に変更することを顧客に伝えます。あなたと顧客の両方が学習するにつれて、あなたも変更を加える必要があります。

于 2009-09-01T21:58:40.423 に答える
2

興味深い質問です。答えは「本当に依存する!」だと思います。私はそれがひどく役に立たないことを知っています(それは本当ですが)ので、ここにいくつかの要因があります:

1)要件とその仕様の品質と完全性。これは、私にとって、ほとんどの場合、プロジェクトの見積もりキラーです。品質要件がない場合、見積もりの​​合理的な根拠はありません。ここでは「RUP-lite」スタイルの製品開発を使用しているため、エンジニアリングマネージャーとして、「精緻化」フェーズが完了し、製品管理から承認を得るまで、最も大まかな見積もり以外は何も提供しません。製品機能のコア80%は、実際には正確にカバーされています。

2)製品の範囲と性質。より大きく/より高価/より複雑=見積もりにかなり長い。私は、通常の堅牢なキャリア要件を備えた通信事業者の土地提供ソリューションで何年も働いてきました(SLAで必要とされる「59」の稼働時間は、ソリューションの設計と障害回復の良い仕事を本当にしなければならないことを意味します!)。ビジネスの機能領域全体にすべての可動部分があるこの種の環境では、作業の見積もりは全体像を把握することにかかっています...特に、部門間の依存関係と外部の依存関係は、ここでは本当にキラーになる可能性があります。そうは言っても、私はシュリンクラップされたエンタープライズソフトウェアもたくさん構築しました。これらの環境では、スコープが通常は大幅に小さいため、見積もりがはるかに簡単になります。

3)このプロジェクトはどのくらい「新しい」ですか?この製品またはテクノロジーセットのチームはどの程度「新しい」のでしょうか。製品またはチームが新しいほど、より長く、より多くのバッファーを割り当てる必要があります。

4)どの程度具体的にする必要がありますか?これが「大まかな推測」である場合は、控えめな見積もりを提供するためにエンジニアリングリードに頼り、それを埋めます。「実際の」見積もりが必要な場合(たとえば、上司が使用し、打撃を担当する見積もり)、さまざまなマネージャーやチームメンバーからの入力が必要になります。要件を分析し、それらの間で協議します。

それは数日または数週間かかることがあります..それはすべてサイズによって異なります。「2、3日」は、率直に言って、最も些細なプロジェクト以外のサイズを決定するのに十分な長さではありません。

見積もりの​​品質を改善して要件の品質を改善し、隠れた依存関係を特定することに冷酷になるためにできる最善のこと。

最後に、FWIW、私は81年からこれを行っており、プロジェクトの期間/コストを正確に見積もることは、エンジニアリング管理の最も困難で危険な部分であると考えています。

于 2009-09-01T21:59:00.393 に答える
0

信頼できる見積もりを行うには、実行するタスクのリストを作成する必要があります。それをストーリー/タスクに分割し(アジャイルを使用しない場合でも)、それらを評価します。これにはすでに多くの時間がかかる可能性があります-特に研究の量(コストを削減するためにこの通知機能を実行するライブラリを探すため)。私は少なくとも3日かかりますが、1〜2週間は私にとってより合理的に聞こえます。これは小さなプロジェクトではないようです。

ある程度合理的な結果が得られたくないのであれば、私はあえて見積もりプロセスをスピードアップするつもりはありません。見積もりは決して正確ではなく、事態を悪化させるだけです。

オプションは、数時間以内に完全に大まかな推測を行い、それからすでに(1週間ほど)作業を開始することです。週末には、現在の進捗状況に基づいて、より適切な見積もりを出すことができる場合があります。ただし、優れたプロトタイプを作成することが重要です(これはがらくたのように見えますが、すべての領域に少しコードがあります)。

于 2009-09-01T22:01:53.383 に答える
0

よくある見積もりは、「価格は当初の見積もりの​​50%から400%の間になる」というものです。この引用が大きくなった理由は、それが真実だからです。推定精度は、ドメイン知識に大きく依存します。これがあなたが見積もりについてかなり確信しているよりもあなたが与えられたタイプのブログエンジンを売った100回目であるならば。ただし、多くの場合、ドメインに関する深い知識はありません(アプリがすでに存在する場合は、なぜ新しいアプリを作成するのですか?)。

アジャイル開発は、従来の「ウォーターフォール」タイプの考え方がほとんどの実際のプロジェクトでは機能しないことを人々が広く認識しているため、人気が高まっています。同じ考え方を見積もりに適用する必要があります。明らかに、ある種のセールスポイントが必要ですが、この情報は非常に曖昧であることを顧客に必ず伝えてください(そして、競合他社が何を言おうとも、彼らの見積もりも曖昧です)。

イテレーションを販売する必要があるため、イテレーションも見積もります。どんな会社のマーケティング担当者も、事務処理や法的な処理の仕方を知っていると思いますので、それほど大したことではないはずです。

5回の反復プロジェクトについて考えてみます。

  • マイルストーンを立てることから始めます。これらは変更される可能性がありますが、最終製品の最初の見積もりを提供します。
  • 反復#1を計画します。
  • 反復#1を見積もり、それに応じて合計見積もりを調整します。
  • 反復#1を実行します
  • すすぎ/反復#5まで繰り返す
  • 完了です:)
  • プロジェクトを振り返ります。あなたの見積もりはどのように進化しましたか?理由は?行うことによって学びます :)

ほとんどの顧客は、一部のスーツが販売した非現実的な目標よりも、部分的な見積もりと部分的な配信を望んでいます:)

于 2009-09-01T22:05:38.147 に答える
0

元の質問から少し外れていますが、過去に作成した見積もりから、見積もりを行うのに実際にかかった時間に関する情報を保持することによって学ぶことも重要です。

これらのページの作成には5日と見積もられましたが、実際には10日かかりました。

長期的には、このような情報により、(うまくいけば!)より正確な見積もりを作成できるようになります。

于 2009-09-02T10:13:39.923 に答える