4

イテレーションの計画中に、私たちはこの男と同じ立場にいることがよくあります -経験がない場合にプログラミングタスクを見積もる方法

合理的な見積もりを出す前にプロトタイピングを行うことに私は間違いなく同意します。しかし、少しのアーキテクチャと設計が必要な場合にも同じことが当てはまりますが、スプリントの範囲外でこれらすべてを行うのはあまり快適ではありません。

基本的な考え方は、自信を持ってできる限り多くのタスクを特定し、それらを通常と推定することです。不明な領域については、調査と実装という 2 つの「タイプ」のタスクが特定されている必要があります。

調査タスクは、「Control X をデータにバインドする方法を調査する」など、不明な作業の簡単な説明です。これらについては、概算が提示されます。

実装タスクは、おそらく割り当てられたストーリー ポイントに基づいて、機能を実装するのにかかると思われる時間を大まかに推測したものです。

スプリント中に調査タスクが完了すると、開発者は何が起こっているのかをよりよく理解できる段階にあるはずです。その後、「適切な」タスクを識別できます。これは、実装プレースホルダーの代わりになります。さらに、この段階でさらなる調査タスクが特定される可能性があり、サイクルは継続します。

上記の例では、7 時間の調査タスクと推定 14 時間の実装タスクから開始します。最初の調査が完了すると、タスク 1、2、および 3 が特定され、ある程度確実に推定されます。ここで、タスク 3タスク 4 と 5 は後の段階で識別される別の調査タスクです。ご覧のとおり、最初の実装見積もりでは 14 時間以内に機能が配信されましたが、実際には少なくとも 4 + 7 + 3 + 4 + 2 = 20 かかりました。最初の見積もりよりも 3 分の 1 長くなりました。

代替テキスト http://www.duncangunn.me.uk/myweb/images/estimate.png

すべての考えを歓迎します - 私の本能はこれが飛ぶということです - 私は正しいですか、それとも私は間違った兄弟ですか?

乾杯！

4

3 に答える 3

3

私達がすること。

一部の機能には、新しいテクノロジーが含まれます。それらを正確に見積もることはできません。限目。

私たちは数を作ります。いくつかのことに基づいています。それはどのくらい「難しい」と感じますか？ある種の「部分的」または「十分な」実装でうまくいくでしょうか?

  • 大変といえば大変です。高価になります。

  • 多くのパーツがあり、優れたカーネルといくつかのボーナスが重ねられている場合、カーネルだけをリリースに入れ、他のものは後で取っておく可能性があります。部分的なリリースが不可能な「オール オア ナッシング」となるものはほとんどありません。その場合、「すべて」に十分な時間を提供する必要があり、費用がかかります。

私たちの標準的なアプローチは、機能するものを取得し、予想外の複雑さのために時間がなくなった場合は、後のスプリントに延期することです。

あなたが「調査」と呼んでいるもの、私たちはテクニカル スパイク スプリントと呼んでいます。新しいものについては、物事を過剰に計画する必要があると感じているマネージャーをなだめるために、推定数を作成します。次に、テクノロジーをスパイクします。スパイクが発生したら、現在わかっていることに基づいて見積もりを修正できます。

于 2009-01-09T11:58:04.600 に答える
2

実際、機能の実装には 27 時間かかりました。最初の 7 時間の調査を忘れていたので、実際の実装には見積もりの​​ほぼ 2 倍の時間がかかりました。

これには 2 つの方法があります。

  1. できる限り見積もりを行うだけで、スプリントが破綻し、プロジェクトの速度が低下する可能性があります (これは、機能が緊急かつ重要である場合にのみ行う必要があります)。また
  2. このスプリントの調査をスケジュールし、実装を別のスプリントに任せる - タスクにかかる時間がわからない場合、プロダクト オーナーは、どのスプリントでスケジュールするか、またはそれを行うかどうかを決定するのに十分な情報を持っていません。まったく。見積もり済みのタスクのみをスプリントに含める必要があります。

最初の選択肢は、スプリントとプロジェクトの見積もりがいくらか恣意的であることを意味します。2 番目の選択肢は、スプリントの予測可能性を大幅に高めます。

あなたの例では、最初の調査がスプリント 1 にスケジュールされている可能性がありますが、タスクにかかる時間を知らなければ、プロダクト オーナーはそれをスケジュールする方法を決定できません。あなたが 200 時間の見積もりで戻ってきた場合、製品所有者はその機能をまったく実行しないか、製品のリリース 2 まで延期することを決定する可能性があります。見積もりが届き、プロダクト オーナーはタスク 1、タスク 2、およびスプリント 2 のタスク 3 の調査をスケジュールします。タスク 3 の見積もり後、タスク 4 と 5 はスプリント 3 以降でスケジュールできます。

于 2009-01-08T23:45:43.510 に答える
0

通常、機能の推定は複雑な作業です。しばらくすると、見積もりが改善されます。しかし、良いアプローチは、ストーリー ポイントを使用して機能を見積もることです。ストーリーポイントとは、問題の複雑さを表す抽象的な値（チーム内で合意した意味）です。同じ複雑さ (同じ数のストーリー ポイント) を同じ複雑さの機能に割り当てる必要があります。その後、より小さな機能セットのみを見積もる (または履歴データを調べる) だけで十分であり、必要な時間を見積もることができるはずです。

同様の複雑さを持つ機能は、実装に必要な時間も同様です。

于 2009-01-08T23:44:30.627 に答える