固定範囲+固定期限+固定価格契約を「アジャイル」で機能させることはできますか？
回答:
私は反疑問を提起したい：
これまでの作品に行われる範囲+固定期限+固定価格契約に固定することができます期間は？
「良い/速い/安い-2つ選んでください」という言葉は、単なる馬鹿げたエンジニアリングの冗談ではありません。彼の塩の価値があるすべてのプロジェクトマネージャーは、プロジェクト管理トライアングルについて知っています。
コスト、範囲、およびスケジュールはすべて固定されていると言っています。そのため、操縦性やエラーの余地はありません。 なし。「品質」を属性として表示することもできますが、これは「実際の」属性ではなく、他の属性（コスト/スコープ/スケジュール）から派生したメタ属性のようなものです。
問題は、プロジェクトが人間によって計画および実行されている限り、これが現実には決して起こらないということです。
要件と仕様は、有資格の建築家と設計者によって非常に詳細に作成されていない限り、すべてのエッジケースをカバーすることはありません。その場合、プロジェクトはすでに半分完了しています。そしてその後も、まだエラーの可能性があります。
予想外のコストが発生し、予算超過につながります。サブスクリプションの有効期限が切れました。製造元は、使用している製品のサポートを終了しました。新しい製品を見つける必要があります。1時間ごとの請負業者が出発の脅威の下で料金を引き上げました。チーム全体がストライキを行ったところ、10％の昇給と1週間の休暇が必要になりました。
スケジュールがずれます。予期しない問題が発生します。5年連続で使用してきたチャート作成コンポーネントは、クライアントがまだ使用しているWindows 95と互換性がありません。64ビットWindowsの不明瞭なバグは深刻なUIの不具合を引き起こし、1週間近くかけてそれを追跡し、回避策を開発します（実際に私に起こりました）。あなたのシニア開発者がバスに襲われたので、新しい開発者を募集して訓練する必要があります。配達予定日は常に間違っています。常に。
ホフスタッターの法則を参照してください。
Hofstadterの法則：Hofstadterの法則を考慮した場合でも、予想よりも常に時間がかかります。
アジャイル手法はすべて、コスト、スケジュール、範囲を調整することです。ほとんどの場合、彼らは特にスコープと時々スケジュールをジャグリングすることについてです。だからこそ、完全版ではなく曖昧なユーザーストーリーから始めて改訂を計画するのです。異なる方法論では異なる用語が使用されますが、基本的な前提はすべて同じです。頻繁なリリースと、各リリースでのスケジュールと範囲の再調整です。
これは、固定スコープまたは固定スケジュールのいずれかである（またはそうであると主張する）プロジェクトでは意味がありません。
場合は1つのプロジェクトの属性（コスト/スコープ/スケジュール）を固定し、私はそれはあなたのことを言うだろう可能性があるアジャイル方法論のために良いフィットではありません。
場合は2つのプロジェクト属性が固定され、その後、あなたのプロジェクトがある間違いなくアジャイル方法論に適していません。
場合はすべての3つの属性が固定され、その後、あなたのプロジェクトは、おそらく失敗する予定です。実際に出荷された場合、元のスケジュールが大幅に変更されたか、クライアントが約束されたものを実際に納品したと考えるようになりました。
この契約がまだ表に残っている場合は、拒否することをお勧めします。そして、あなたがすでにそれを受け入れているなら、神があなたの魂に慈悲をお持ちになるように。
もちろん、品質バーが著しく低く保たれている限り。私は、「配達時間/品質/価格」という古い鉄の三角形を信じています。そこでは、2つを選択できますが、もう1つは浮いています。納期と価格（および機能）を修正したように思えるので、本当にできるのは品質だけです。
ただし、バーンダウンチャートを使用しており、優先度の最も高いアイテムを最初に実行している場合、指定された金額で指定された時間枠に最も重要なアイテムをいくつか実行しても問題ありません。少なくともクライアントは、各イテレーションの終わりに成果物を使用してプロセスをある程度制御していることを確認し、最も重要なことを言うことができます。
そうでなければ、固定された時間、機能セット、価格にコミットするのは無謀であり、結果として品質が低下し、コードの保守性が低下するという英雄的な努力につながると思います。アジャイルは魔法の妖精の塵ではありません。
固定価格/固定期限/固定範囲は、少なくともウォーターフォールの場合と同様に機敏に実行できます。
ウォーターフォールでは、時間の推定が不正確であり、詳細は元の仕様とは異なる方法で実装されます。つまり、期限/スコープを正確に事前に知ることはできません。
アジャイルでは、スプリントゼロを実行してユーザーストーリーのバックログを生成し、推定を行うことができます。次に、固定の期限までに、固定価格でバリューストーリーを満たすことに同意します。スコープは、実現する価値のあるストーリーの観点からは固定されており、ユーザーストーリーについては約束されていません。
言い換えれば、あなたは重要なものを提供することを約束し、収益/貯蓄/その他とは関係のない特定の設計決定について約束することを避けます。プロジェクトが提供することになっていること。
ブルースにはある程度同意します。私は滝やRUPにあまり詳しくないので、それについてコメントすることはできません。
私が最近読んだ、そして私は本当によく言われたと思ったのは、アジャイルでも計画を無視しているということでした。反復が完了したら、徹底的な計画セッションが必要です-いいえ、それは必須ではありませんが、反復を通して計画することも重要です。
私は、物事が常に変化しているエンターテイメント業界で働いています。チームにはある程度の寛容性と柔軟性が必要です。これにより、スプリントの途中でストーリーを「再計画」して、新しい目標や修正された目標に合わせることができます。
開発者は、スプリントの途中でストーリーに取り組んでいるときにプロダクトオーナーに立ち去るように指示することが多いため、継続的な計画のアイデアが気に入っています。これは、チームがまだ有効なストーリーに取り組んでおり、製品の所有者が迷惑をかけている場合に優れています。しかし、場合によっては、スプリント中にストーリーが冗長になり、製品所有者がこれを見つけ、チームが変更された目標/ストーリーに再調整することが不可欠です-それはアジャイルとは何ですか？