時間の見積もりはスクラムでの約束と同じですか？

見積もりが約束ではない場合、製品所有者として、どのくらい時間がかかるかわからないままプロジェクトを提供するにはどうすればよいですか？

時間の見積もりを約束として扱うと、スクラムチームはより効率的に機能しますか？

ストーリーの調査（準備、問題を理解するための努力）はどれだけ適切な見積もりを出すのに十分ですか？

作業を見積もった後に発生する予期しない技術的な問題（最初の見積もりを実際に混乱させる可能性がある問題）はどうですか？

見積もりは石に刻まれた約束ではありません。彼らは、チームがタスク/ストーリーを完了するために必要な努力について行うことができる最も良い推測です。

「私はリファレンスとして、時間外で自分のプロジェクトを提供することができますどのように製品の所有者？として」あなたの質問への答えでは、答えはあなたがいることであるとすべきであることができ、参照（つまりは、あなたのように時間を持っています、特定の日付にリリース）。あなたが持っていないものは、配信される正確な範囲です。

私が言ったことは、開発を推進するために使用するすべての方法論に当てはまることに注意してください。スクラムと他の方法（ウォーターフォールなど）の違いは、スクラムではこの事実が認められ、説明されていることです。POとして行うことは、スコープに優先順位を付け、常にチームが次の状態になるようにすることです。

1. 配信されていない最も重要な（重要な）機能（タスク、要件、ユーザーストーリー）に取り組む
2. 現在取り組んでいる機能よりも重要なすべての機能を正常に完了しました（これは、完了の定義を意味します：完了したすべてのストーリーがテストされ、受け入れられ、バグがなく、機能が完全です）。

そうすることで、いつでも最新のビルドが出荷できる最高の製品であることを知っているので、すぐに出荷または配送できます。つまり、最初のリリース契約の日付に、可能な限り最高の製品を提供することになります。

もちろん、これはチームが開発するように要求したすべてのストーリーで構成されるとは限りませんが、残りの不完全なストーリーはもちろん、後で簡単に配信できる最も重要でないストーリーであることを知っています。

また、チームによる見積もりはますます改善されるため、リリースの最後にどのようなスコープになるかを早期に確固たるアイデアを持つことができます。数週間後、重要性の低い機能が追加された優れた固体製品を予定どおりに出荷できます（もちろん、いつになるかを見積もることができます）。

必要な研究の量に関しては、ここでは利益を減少させる法則が作用しています。ストーリーを十分に小さく壊した場合、少しの調査で十分に近い見積もりが得られるはずです。それらを間違えた場合は、次のスプリントで修正し、推定値が改善されます。3〜4回のスプリントでは、平均して、期限までに配信できるスコープの量（またはスコープの完了までにかかる時間）を把握する必要があります。

スクラムでストーリーポイントを見積もるときは、実際に機能の記述を開始できるように十分な知識が必要です。見積もりは完全に正確であるとは限りません。アジャイル開発方法論の要点は、開発にかかる時間を正確に予測できないことを認識していることです。

提供することを約束する段階は、製品バックログからのストーリーをスプリントに受け入れるときです。あなたは、それらのストーリーをスプリント内で提供することを約束しています。

あなたがこの約束をするなら、あなたがあなたの約束を果たそうとしていないように見えるなら、これはあなたがいくつかの追加の時間を喜んですることを意味します。実際には、一部のストーリーは思ったよりも時間がかかり、他のストーリーは思ったよりも時間がかかります。

チームが十分な見積もりを行うと、それが上手になります。

あなたはまた見たいかもしれません...

Clean Coder（本） -この本には「コミットメントの言語」というタイトルの章と、推定に関する章があり、これは本当に目を見張るものです。

かんばん -かんばんは、プル型の開発を実行するものです。両方のアイデアから生まれた「Scrumban」と呼ばれるスクラムとかんばんの組み合わせもあります。

番号。

スプリントで完了した各タスクのすべての推定値の合計は、速度と呼ばれます。速度は「スプリントごとの完了したポイントの数」として定義されます。「ポイント」はチームが推定する単位です。

したがって、速度は、チームが同じ方法を使用して推定し、チームが安定しているなどの前提で、チームが次のスプリントでどれだけ生産できるかを知ることができます。

これにより、ランダムな約束をしなくても、チームが何を提供できるかを確実に確認できます。

努力の見積もりは、予測のためのツールです。予測は約束でも保証でもありません。予測は新しい知識を考慮して継続的に再評価され、楽観的および悲観的変動などの可能な代替案を含める必要があります。

アジャイルを楽しみにしています。コミットメントは、予測よりも組織計画に価値をもたらしません。

マイク・コーンのアジャイル見積もりと計画を強くお勧めします

見積もりが約束ではない場合、製品所有者として、どのくらい時間がかかるかわからないままプロジェクトを提供するにはどうすればよいですか？

1つの大きな見積もりではなく、ストーリーレベルの多数の小さな見積もりで作業します。ストーリーレベルの推定エラーの多くは平均化されています。内容と日付の両方を約束することはできません。ただし、バックログの最上部がリリースされることをかなり確信で​​きます（または、バックログ全体を配信できる日付はかなり正確ですが、固定されていません）。

時間の見積もりを約束として扱うと、スクラムチームはより効率的に機能しますか？

いいえ。それはサンドバギングの見積もりにつながり、速度/バーンダウンチャートを役に立たないデータに変換します-これはチームの改善を妨げます。

ストーリーの調査（準備、問題を理解するための努力）はどれだけ適切な見積もりを出すのに十分ですか？

精度をどの程度重視するかによって異なります。すべての見積もりを慎重に準備するために何週間も費やすか、迅速な誠意のある見積もりを出し、エラーが平均化することを期待できます。最初の方法は、失敗に備えてセットアップすることです。これまでに行ったことがないことを見積もることは非常に困難であり、ソフトウェアエンジニアリングは、以前に行ったことがないことがすべてです。

個人的には、非常に正確な見積もりを取得しようとするメリットはあまりないと思います。私がやろうとしていることは、見積もりが十分に正確であることを確認することです。つまり、ストーリーが見積もりから1桁ずれる原因となる可能性があるものを見逃していないことです。（次のポイントを参照）。

作業を見積もった後に発生する予期しない技術的な問題（最初の見積もりを実際に混乱させる可能性がある問題）はどうですか？

小さな反復。注文バックログ。小さな物語。危険なものは、あなたが知らない、知らないものです。問題に関する専門知識の欠如は、不十分な見積もりにつながりますが、専門知識を取得する（詳細な）か、「十分に良い」見積もりで調整することができます。それはすべてリスク管理に関するものです。

見積もりが約束ではない場合、製品所有者として、どのくらい時間がかかるかわからないままプロジェクトを提供するにはどうすればよいですか？

これは、スクラムに関する最大の誤解の1つです。「プロジェクトにはどれくらい時間がかかりますか？」という質問 では、ある時点で、プロジェクトを完了するために必要なことを正確に定義できると想定しています。しかし、スクラムについての全体的な考えは、プロジェクトに取り組むにつれて、プロジェクトについて学ぶことがプロジェクトの定義を変えることになることを認めているということです。

プロジェクトを定義する最も一般的な方法は、プロジェクトが持つ機能をリストすることです。通常、プロジェクトはすべての機能が実装されたときに完了します。しかし、プロジェクトに取り組んでいるときに、最初に特定された5つの機能は必要ないことに気づいたとしても、最初の6か月で本当に含めるべき7つの機能があるとしたらどうでしょう。それはどれくらいの時間がかかるのかという質問に対してそれは何をしますか？

もう1つの要因は、学ぶことによって特定の機能の実装方法に対する理解が変わり、各機能の実装に近づくにつれて、見積もりが変化することです。個人的には、実装の地平線に近づかないものに数値の見積もりを付けることに抵抗します。「小さな」、「小さな」、「中」、「大きな」、「巨大な」または「壮大な」などの説明的な見積もりを使用する可能性があります。そうすれば、推定できるよりも高い精度を意味するわけではありません。

正直なところ、「どれくらい時間がかかりますか？」、「それが完了するとどうなるでしょうか？」以上の答えはありません。会計士や従来のビジネスの人々はこれを嫌っています。そのため、一部の組織ではウォーターフォールから離れることが非常に困難です。

また、速度とメトリクスについて多くの話をする必要があるのもこのためです。ソフトウェアプロジェクトには、一種のハイゼンベルクの不確実性原理が組み込まれているため、測定の微調整に時間をかけすぎると、非常に正確なナンセンスになってしまいます。

したがって、見積もりは約束ではありません。見積もりです。「約束」とは、特定のスプリントで特定の数の機能またはストーリーを完成させるためのチームの取り組みです。

見積もりは、チームがスプリントにぴったり合うことができる機能（またはストーリー）の数をチームが識別できるほど正確である必要があります。見積もりの​​正確さよりもさらに重要なのは一貫性です。これは、実際の作業が通常見積もりの​​2倍であることが判明した場合でも、チームはスプリントに組み込むことができる見積もりの​​作業量を学習するためです。それが一貫してオフである限り、彼らは計画を立てることができます。