スクラムは、要件が変更されないプロジェクトに追加のオーバーヘッドを作成しますか？
私は Scrum-Gunther Verheyenによるポケットガイド を読んでいます、そしてそれは言う：
Standish Groupによる2011年のカオスレポートは、ターニングポイントを示します。従来のプロジェクトとアジャイル手法を使用したプロジェクトを比較するために、広範な調査が行われました。このレポートは、ソフトウェア開発へのアジャイルアプローチにより、ソフトウェアを時間どおりに、予算どおりに、約束されたすべての範囲で提供しなければならないという以前の期待に反して、はるかに高い歩留まりをもたらすことを示しています。 このレポートは、アジャイルプロジェクトが3倍成功し、失敗したアジャイルプロジェクトが従来のプロジェクトと比較して3倍少ないことを示しています。
ですから、同僚の1人との議論があります。たとえば、一部のプロジェクト（医学/軍事など、要件が変更されない）では、アジャイル（特にスクラム）はすべての会議のオーバーヘッドであり、より論理的です。たとえば、滝を使用します。
私の見解では、スクラムはプロセスをより透明にし、チームの生産性を向上させるため、そのようなプロジェクトで採用されるべきであると考えています。また、1か月のスプリントのためにスプリント計画に8時間丸ごと座る必要がないため、スクラムイベントが必要なければ、それほど時間はかからないと思います。全員が同じページにいることを確認し、作業を開始するためだけに、5分の余裕があります。
それでは、スクラムは、要件が変更されないプロジェクトに追加のオーバーヘッドを作成しますか？
要件が変わらないプロジェクトがあると言うのは間違った仮定だと思います。防衛産業と製薬産業の両方でソフトウェアを作成してきた経験から、ソフトウェアが主題の専門家（内部または外部のいずれか）の手に渡ると、フィードバックがあることがわかります。このフィードバックは、要件が満たされている方法に関する場合もあれば、要件自体が間違っているか不完全である場合もあります。
敏捷性とは、フィードバックサイクルを減らし、作業中のソフトウェアをより迅速に手に入れ、フィードバックを得て、顧客がソフトウェアを受け入れることを決定したときに提供されるものが付加価値を確実にするための次のステップを決定することです。カスタムハードウェアを備えた組み込みシステム（航空宇宙、自動車、医療機器などのドメインで見つかるような）の分野でも、機能の薄いスライスを迅速に提供して統合し、プロトタイプを作成すると、ソフトウェアとハードウェアシステムが確実に機能するようになります。意図したとおりに、エンドユーザーを支援する方法で機能します。
フィードバックサイクルの長さの短縮は、リスク軽減の大きな要因です。プロジェクト管理の観点から見ると、プロジェクトに2〜4週間資金を投入し、定期的に進捗状況を確認できれば、順調に進んでいることが保証されます。機能の薄いスライスを提供できるようにすることで、目標の状態に向けて段階的に取り組み、そこに到達する時期を予測し始めることができます。時間が制約になる場合は、最初に実行される作業が高値関数または高値関数のイネーブラーであるため、低値関数をデスコープできます。いつでも、努力に資金を提供し続ける価値があるか、別の方向に進んで手遅れになる前にプロジェクトを停止する価値があるかどうかを決定できます。
非常に短い答えは、はい、スクラムは設計により高価なアプローチですが、それをプロジェクトと呼んでいる場合、それはほぼ間違いなく重要であり、最終的には常により良いROIをもたらすでしょう。
より完全な答えはこれです：
一般的に、プロセス制御には3つの形式があります。定義済みプロセス制御、統計的プロセス制御、および経験的プロセス制御です。定義されたプロセス制御は、最も安価です。これは、頻繁に繰り返される作業で可能になり、作業を行う「最良の」方法を見つけるために時間をかけて改良されました。ソフトウェア開発におけるCI/CDはこのカテゴリに分類されます。ビルドプロセスに変化をつけたくないので、プロセスを標準化し、満足するまで調整してから、自動化します。この自動化されたプロセスは、デプロイを手動で行うよりも、実行するコストがはるかに安価です。
統計的プロセス制御は次に安価ですが、既知のプロセスの変動を考慮に入れています。計画通りに進む医療処置はこのカテゴリーに分類されます。毎回バイパス手術をやり直したくありません。基本的なプロセスに従って、バリエーションに合わせて調整します。これは、認知負荷が比較的低く、成功率がかなり高いです。
次は経験的プロセス制御です。これは、進行中にプロセスを発見する必要があるため、はるかに高価です。学習は非常に高いですが、生産性と効率を犠牲にしています。ただし、これまでに行われたプロジェクトはほとんどないため、ほぼすべてのプロジェクト作業でこれが必要です。もちろん例外もあります。大規模なActive Directory環境のセットアップは、状況に応じて少し逸脱するいくつかの実証済みの指示から作業するため、より統計的です。しかし、プロジェクトがこれまでに行われた正確な作業を行うことでない限り、ほぼ確実にEmperical Process Controlが必要です。
スクラムをスクラムに戻すために、スクラムはEmperical Process Controlの問題を解決するように設計されています。そのため、はい、他のアプローチよりもオーバーヘッドが大きくなります。ただし、ほとんどのプロジェクトではこのアプローチが必要であるため、議論の余地があります。
医学と軍事プロジェクトについて対比するには、それは欠陥のある論理のように聞こえます。 500機の注文を履行している場合、はい、正確に何かを再作成しているため、スクラムはおそらく有益ではありません。あなたが新しい飛行機を構築していて、あなたの要件が決して変わらないなら、私はその飛行機を飛ばしません。
確かに、前もって非常に明確な要件があるプロジェクトがある場合、それらを開発者の前にウォーターフォールにダンプし、2年後に夢のソフトウェアに会うことができます。
しかし、ソフトウェアプロジェクトの大部分はこのようなものではありません。
通常、顧客は必要なものを知りません。彼らは完全で特定の要件を提供することができません。反復的なアプローチがここで役立ちます。小さなものを構築し、顧客にフィードバックを求めます。はい、これはデモに時間を「浪費」し、次の反復を計画します。しかし、1つのスプリントに対して間違ったものを構築し、要件をすばやく修正する方が、プロジェクト全体に対して間違ったものを構築するよりもはるかに優れています。つまり事前の要件により、より多くの効率的な開発が可能になる場合がありますが、反復的なアプローチの方がより多くの効果的なになります。
開発者は、有用なソフトウェアを構築する場合、要件を正しく理解する必要があります。手遅れになる前に誤解を発見する良い方法は何ですか？繰り返しになりますが、反復的なアプローチが役立ちます。ただし、要件ドキュメントの作成者を通じてフィルタリングされた情報を取得するだけでなく、開発者自身が顧客と協力することも重要です。
最後に、プロジェクトの間、世界は止まりません。外部システムの変化、優先順位の変化、人々の変化。短いプロジェクトを除いて、ソフトウェアプロジェクトの要件が変更されないふりをするのは悪い考えです。
これらのプロセスレベルのメリットはすべて、アジャイルアプローチの日常的な大きなメリットを逃しています。アジャイルが正しく行われれば、everyoneはより幸せになります。これらの最大の1つは、アジャイル技術が短期間に実際の価値を提供することに焦点を当てていることです。これは、開発プロセスを可視化し、利害関係者にプロジェクトに対する合理的なレベルの制御を提供し、遠い目標に向けて取り組むよりもはるかに動機付けになります。これに関連するのは、アジャイルチームは主に自己組織化するという考えです。日々の仕事を管理していると感じると、人々は価値を感じるようになり、そのために最善を尽くす可能性が高くなります。
あなたの同僚は、ウォーターフォールスタイルのプロジェクトが自分たちの立場を持つことができるのは間違いありません。そして、アジャイルっぽい慣習が時間を浪費する儀式になることは間違いありません。しかし、アジャイルで反復的なアプローチの利点、特により良いリスク管理と個人の尊重を無視することは完全に愚かです。これらは、すべてのプロジェクトで必要なものです。必要に応じて、チームはこれらの一部を内部で実装することを試みることができますが、プロセスは誰もが参加しているときにうまく機能します。
これは@Cort Ammonが言っていることを言い換えているかもしれませんが、これが私の見解です：
外部要件（「成果物」を説明する）は、プロジェクトの唯一の要件ではありません。外部の要件が変更されなくても、作業中に「内部」の要件が変更されるか、変更が許可される必要があります。開発者はアプローチによって障害や問題を発見し、これはチーム内の他の人々の作業に影響を与えます。毎日のスタンドアップは、これらの内部変更で全員を最新に保ちます。
それを考慮してください：
機能要件が固定されていても、それらを技術要件に変換する必要があります。そして、これは反復によってよりよく行われるかもしれません。プロジェクトの途中で問題を解決するより良い方法を発見するかもしれません。
「使いやすい」、「安全である」など、一部の要件は一般的すぎたりあいまいであったりします。システムのセキュリティや使いやすさを分析するのは、システムが完成していないと難しいです。一部には隠された影響があるか、よく理解されていない場合があります。
一部の要件は改善される可能性があります。 200msでの応答は良いかもしれませんが、100の方が良いかもしれません。可能な限り最良の結果を目標にしても、プロジェクト中に必要に応じてそれを犠牲にすることができます。
契約には書かれていないが、プロジェクトを失敗から成功に変える可能性のある隠れた要求を発見するかもしれません。プロジェクトを提供しても、クライアントは満足できない場合があります。初期段階で安価にプロジェクトで設計できる新しい機能を追加（および課金）するために、契約を変更する必要さえあるかもしれません。
所定の時間内に要件を満たせない場合があります。ソフトウェアプロジェクトが遅れることはありません。したがって、最高の価値を提供することで、削除する機能を再度関連付けることができます。
より早く何かを提供することは統合に役立ち、このプロジェクトが結果を提供できることを示します。
すべての要件が完璧にレイアウトされている場合、それらの要件を可能な限り迅速に達成するトップダウンアプローチが存在するという主張をすることができます。ただし、これらが適切な要件である場合は、作成方法ではなく、作成方法が示されます。彼らがそれを作る方法をあなたに言うなら、私はそれを「要件」ではなく「作業指示書」と呼ぶことを選択し、私たちは別の種類の問題について議論します。
したがって、要件を実装する会社またはチームの内部にある「方法」を開発するプロセスは常に存在します。経験的に言えば、設計者のチームがこれらの要件を満たすように高レベルシステムを設計し、その高レベルシステムの詳細を使用して詳細を具体化する小規模チームに「要件」を提供する階層的アプローチに強く依存しています。
ウォーターフォールプロセスでは、これは設計と実装の間の一方向の矢印で確認できます。ただし、これらの要件は、顧客提供の要件とは異なり、明確なものではありません。これらは内部で定義されており、反復プロセスの余地があります。実際には、設計者はこの反復の欠如を説明するためにプロセスにかなりのマージンを設けるか、反復プロセスを模索していることがわかります。
SCRUMと他の多くの関連するアジャイルメソッドは、この反復プロセスを実行するための厳密なフレームワークを提供します。アジャイルアプローチのトレードマークは、この反復パターンをプロセスのコアとなるように最適化することを、ハード要件の外側の層に焦点を合わせるのではなく、検討することです。他の人が述べたように、actual固定要件はまれですが、SCRUMが存在する場合でも、SCRUMは方法論として反復アプローチを使用して、内部に適合する契約アプローチを制御します。
これが成功するかどうかは、オープンな議論の問題です。他には、この目的のために多くのメトリックを提供しています。それらの下で発生する反復が上記の契約システムに正しく適合していることを確認するのは、リーダーシップの強さ次第であることを単に指摘しておきます。これは、開発へのあらゆるアプローチに当てはまりますが、よりトップダウンのアプローチが「通常」であり、そのように訓練されたリーダーであると想定するように提起されているため、アジャイルアプローチでより目に付きます。