遅れはアジャイル方法論に意味がありますか？

これは、別の質問（これ）に対するいくつかの回答とコメントから生じました。

私は主にウォーターフォールプロジェクトを扱い、アジャイルな振る舞いを取り、アジャイルについてかなり読んだアドホックプロジェクトに取り組んできましたが、「適切な」アジャイルプロジェクトに取り組んだことは一度もありません。 。

私の質問は、「後期」の概念がアジャイルで何らかの意味を持っているということです。

私の推論では、アジャイルには事前の計画はなく、最初は詳細な要件もありません。あなたは高いレベルの目標とそれに付随する想定上の日付を念頭に置いているかもしれませんが、両方が（潜在的に大規模に）変わる可能性があり、どちらも確実ではありません。

つまり、配信してユーザーが受け入れるまで、基本的に何を配信するかが正確にわからない場合、次のスプリント以降のスケジュールがない場合、どのようにして遅れることができるでしょうか。実際に意味がありますか？

（明らかに、スプリントがオーバーランする可能性があることは理解していますが、それを超えて話しています。）

明確にするために、私がそれらを見てそれらに関与したという事実に基づいて、時間どおりにウォーターフォールプロジェクト（比較的大きなプロジェクトでも）が可能であるという仮定に（個人的に）満足しています-それらは簡単でも一般的でもありませんしかし、それらは可能です。

これはアジャイルをノックすることではなく、私が理解することです。アジャイルのメリットは、期限や予算とは関係なく（または間接的にのみ）、常にスコープと関係があると見なしてきました。アジャイルは、プロジェクトチームが重要であると考える前に、実際に重要であると考えるよりも、実際に重要なことに近づきます。何でも見ました。

アジャイルプロジェクトに事前計画がないことに同意しません。

私の経験では、ビジネスアナリストは、顧客や開発者との設計会議にかなりの時間を費やして、ユーザーストーリーとして提示される達成可能な要件の詳細なリストを作成してきました。これらは、経験豊富な開発者が適切な見積もりを付けて、タスクに分解されます。

スプリント/反復の開始時に最も重要なタスクが特定されると、コーディングを開始できます。この選択プロセスにより、プロジェクト全体の反復の意味が決まります（「ログインプロセスを構築しています」）。チームのさまざまなメンバーが、そのユーザーストーリーを実現するために必要なさまざまなタスクを実行します。

イテレーションの最後に、そのイテレーションのすべてのユーザーストーリーが完了するか、遅れます。同様に、開発は各イテレーションとリリースされた製品の終わりで停止できるはずです。すべてのユーザーストーリーが完全であるとは限りませんが、反復で要求されたそれらのユーザーストーリーは完全であり、製品はそれらの限界まで動作できます。

アジャイル方法論で「遅い」とは、ウォーターフォール方法論で意味するのと同じことを意味します。見積もりが間違っていた、スコープが割り当てられた時間に対して大きすぎた、予期しない問題が発生した、顧客の反応が不十分だった、プログラマーが怠惰になった、マシンがクラッシュした、犬が私のバイトコードを食べた、など。

あなたはそれから学び、次の反復のために調整します

違いは、これは2〜4週間ごとに発生する可能性があるため、レッスンを学び、プロセスを迅速に調整することです。

はい。ただし、9か月ではなく9か月のmythical-final-project-due-dateに達しないことを知るのに1か月しかかかりません。

あなたの推論は、大規模なプロジェクトのための事前の計画と詳細な要件が可能であるという仮定に基づいています。それを裏付ける証拠がたくさんあるかどうかはわかりません。恐らくすべてのホラーストーリーは単なる逸話なのでしょうか？どの開発者も、クライアントが完全に同意して理解する完全で変更のない仕様で作業することを望みます。

あなたが何らかの約束をするときはいつでも、あなたは遅れる危険を冒します。これはアジャイルにも当てはまります。

しかし、お客様が将来を予測することはできません。また、お客様が常に考えを変えることは承知しており、それが良いことであることに同意します。：私たちはそれを受け入れた場合、我々はまた、順番に、答えるのは簡単遅れについての質問を行っている、すべての約束はかなり常に間違っていることを受け入れなければならない我々は常に間違っている（初期または後期にします）。どれほど洗練されていても、それはすべて推測の問題です。コインを投げます。

これは、開発者として私たちが受け入れなければならないものであり、その観点から、別の作業方法、遅延の問題の重要性を低くする方法を見つけようとします。視点の変化。その方法は、顧客の満足が得られたときに終了するオプションを使用して、できるだけ早く機能するソフトウェアを提供することに焦点を当てていると思います。

それがアジャイルのすべてです。遅刻は事実であり、私たちはできる限り最善を尽くして対処する必要があるというこの不快な概念を管理する賢い方法です。

たとえば、現在のイテレーションの最初に行ったコミットメントを実行できなかった場合、遅れます。これは予想されることであり、これから学び、プロセスを調整して、次の反復で失敗する可能性を低くする必要があります。これを処理する最良の方法は、反復をできるだけ小さくすることです。

マルチイテレーション計画、つまりリリース計画では、完了したイテレーションから計算された速度を使用してデータを推定し、将来のリリース日を予測します。これについての詳細は、James Shoresの記事または自分の（短い）記事をお勧めします。ただし、これは確固たる約束ではないことに注意してください。「その日までに次の機能を完了することは80％確実です」。これは（ある程度）遅れる可能性がありますが、約束は確率であり、事実ではありません。

これで、機能するソフトウェアを完全にリリースするかどうかに関係なく、常に稼働中のソフトウェアをリリースする準備ができているというアジャイルの基本的な約束と同等になります。これにより、顧客は、システムが十分に良いと思ったときに開発を停止する自由を与えられます。これは、予想よりもはるかに早く発生する可能性があります。また、最新のイテレーションからの実際のフィードバックに基づいて、プロジェクトを新しい方向に進めることも奨励しています。

上記のポイントは、すべての顧客が開発を完全に制御するのに十分以上のものである必要があり、それがアジャイル手法の遅れに関する質問に答えることを願っています。

アジャイルSCRUMには2種類の「後期」があります>

1. キャリーオーバー-スプリントの最後にストーリーが「完了」せず、開発者がPBIを実行することを「コミット」するため、実行されない場合はキャリーと見なされます。

2. ロードマップ-組織にロードマップがあり、日付があると想定し、それらの日付の主要な成果物が欠落している場合、「遅い」と見なすことができます。