スクラムは、要件が変わらないプロジェクトに追加のオーバーヘッドを作成しますか？

Gunther Verheyenのスクラム-ポケットガイドを読んでいます。

Standish Groupによる2011年のChaosレポートは転換点を示しています。従来のプロジェクトとアジャイル手法を使用したプロジェクトを比較するために、広範な研究が行われました。このレポートは、ソフトウェアを期限内に、予算内で、すべての約束された範囲で提供しなければならないという古い期待に反して、ソフトウェア開発へのアジャイルアプローチがはるかに高い歩留まりをもたらすことを示しています。このレポートは、アジャイルプロジェクトが3倍成功し、従来のプロジェクトと比較して失敗したアジャイルプロジェクトが3倍少ないことを示しています。

ですから、一部のプロジェクト（要件が変わらない医療/軍事など）では、アジャイル（および特にスクラム）がすべての会議などでオーバーヘッドであり、より論理的であると言う同僚との議論がありますたとえば、ウォーターフォールを使用します。

私の見方では、このようなプロジェクトにスクラムを採用する必要があります。これにより、プロセスがより透明になり、チームの生産性が向上するからです。また、1か月間のスプリントのために8時間をスプリントプランニングに費やす必要がないため、スクラムイベントが必要なければ、それほど時間はかからないと思います。全員が同じページにいることを確認して作業を開始するためだけに、5分間を節約できます。

では、スクラムは、要件が変わらないプロジェクトに追加のオーバーヘッドを作成しますか？

要件が変わらないプロジェクトがあると言うのは間違った仮定だと思います。防衛産業と製薬産業の両方でソフトウェアを作成してきましたが、ソフトウェアが主題の専門家（内部または外部）の手に渡ると、フィードバックがあると言えます。時々、このフィードバックは要件が満たされた方法に関するものであり、他の場合では実際には要件自体が間違っているか不完全であることにあります。

敏ility性とは、そのフィードバックサイクルを短縮し、動作中のソフトウェアを誰かの手にすばやく届け、そのフィードバックを取得し、顧客がソフトウェアを受け入れることを決定したときに提供されるものが価値を高めるようにする次のステップを決定することです。航空宇宙、自動車、医療機器などのドメインで見られるようなカスタムハードウェアを備えた組み込みシステムのような領域においても、統合してプロトタイプを作成するための機能の薄いスライスを迅速に提供することで、ソフトウェアとハ​​ードウェアシステムが確実に機能するようになります意図したとおりに動作し、エンドユーザーを支援する方法で動作します。

フィードバックサイクルの長さの短縮は、リスク削減の大きな要因です。プロジェクト管理の観点から見ると、プロジェクトに2〜4週間資金を提供し、進捗状況を定期的に把握できれば、順調に進んでいることが保証されます。機能の薄いスライスを提供できることにより、目標の状態に向かって段階的に作業し、そこに到達する時期を予測し始めることができます。時間が制約になる場合、最初に行われる作業は高価値関数または高価値関数のイネーブラーである必要があるため、低価値関数のスコープを解除できます。いつでも、努力に資金を提供する価値があるか、別の方向に進んで手遅れになる前にプロジェクトを停止する価値があるかを決めることができます。

非常に短い答えは、はい、スクラムは設計上、より高価なアプローチですが、プロジェクトと呼んでいる場合、それはほとんど間違いなく重要ではなく、最終的には常により良いROIをもたらすでしょう。

より完全な答えはこれです：

一般的に、プロセス制御には、定義済みプロセス制御、統計的プロセス制御、およびエンペリアルプロセス制御の3つの形式があります。定義済みプロセス制御は、はるかに安価です。これは、頻繁に繰り返される作業が時間をかけて洗練され、作業を行うための「最良の」方法を見つけることで可能になります。ソフトウェア開発におけるCI / CDはこのカテゴリーに分類されます。ビルドプロセスを変更したくないので、プロセスを標準化し、満足するまで調整してから自動化します。その自動化されたプロセスは、デプロイを介して手動で戦うよりも、実行する方が明らかにはるかに安価です。

統計的プロセス制御は次に安価ですが、既知のプロセスのばらつきを考慮しています。計画通りに進む医療処置は、このカテゴリに分類されます。毎回バイパス手術をやり直したくありません。基本的なプロセスに従い、バリエーションに合わせて調整します。これは認知負荷が比較的低く、成功率がかなり高いです。

次に、経験的プロセス制御があります。これは、進行中にプロセスを発見する必要があるため、圧倒的に最も高価です。学習は非常に高いですが、生産性と効率の代価です。ただし、これまでに行われたプロジェクトはほとんどないため、ほぼすべてのプロジェクト作業でこれが必要です。もちろん例外もあります。大規模なActive Directory環境の設定は、状況に応じてわずかに逸脱する実証済みの手順で作業するため、より統計的です。ただし、以前に行った正確な作業を行うことをプロジェクトとしない限り、ほぼ確実にEmperical Process Controlが必要です。

Scrumに戻すために、ScrumはEmperical Processコントロールの問題を解決するように設計されています。そのため、はい、他のアプローチよりもオーバーヘッドが大きくなります。ただし、ほとんどのプロジェクトではこのアプローチが必要であるため、議論の余地はありません。

医学と軍事プロジェクトについての対比には、欠陥のある論理のように聞こえます。500機の注文を処理する場合、はい、正確に何かを再作成しているため、スクラムはおそらく有益ではありません。あなたが新しい飛行機を建設していて、あなたの要求が決して変わらないなら、私はその飛行機を飛ばしません。

確かに、明確な要件を前もって持っているプロジェクトがある場合は、開発者の前に滝のようにそれらを捨てて、2年後に戻って夢のソフトウェアを満たすことができます。

しかし、ソフトウェアプロジェクトの大部分はこのようなものではありません。

通常、顧客は必要なものを知りません。彼らは完全かつ特定の要件を提供することはできません。反復的なアプローチがここで役立ちます。小さなものを作成してから、顧客にフィードバックを求めます。はい、これはデモと次の反復の計画に時間を「浪費」します。しかし、1つのスプリントに対して間違ったものを作成してから要件をすばやく修正する方が、プロジェクト全体に対して間違ったものを作成するよりもはるかに優れています。すなわち、前もって要件があればより効率的な開発が可能になりますが、反復的なアプローチがより効果的になります。

開発者は、有用なソフトウェアを構築する場合、要件を正しく理解する必要があります。手遅れになる前に誤解を発見する良い方法は何ですか？繰り返しますが、反復アプローチが役立ちます。ただし、要件ドキュメントの作成者のみを通じてフィルター処理された情報を取得するのではなく、開発者自身が顧客と協力することも重要です。

最後に、プロジェクトの間、世界は静止していません。外部システムが変わり、優先順位が変わり、人々が変わります。ソフトウェアプロジェクトの要件が変わらないふりをするのは、短いプロジェクトを除いて、悪い考えです。

これらのプロセスレベルの利点はすべて、アジャイルアプローチの日々の大きな利点を見逃しています。正しく実行されれば、アジャイルはすべての人を幸せにします。これらの最大の1つは、アジャイル技術が短期間で真の価値を提供することに焦点を合わせていることです。これにより、開発プロセスが可視化され、利害関係者がプロジェクトを合理的に制御できるようになり、遠くの目標に向かって取り組むよりもはるかに動機付けられます。これに関連するのは、アジャイルチームは大部分が自己組織化されるという考えです。日々の仕事をコントロールしていると感じることで、人々は大切に感じられ、その結果、最善を尽くす可能性が高くなります。

あなたの同僚は、ウォーターフォールスタイルのプロジェクトが自分たちの場所になる可能性があることは間違っていません。また、アジャイルっぽい慣習が時間を浪費する儀式になりうることは間違いではありません。しかし、アジャイルで反復的なアプローチの利点、特にリスク管理と個人への敬意を無視するのは完全に愚かです。これらはすべてのプロジェクトで必要なものです。必要に応じて、チームはこれの一部を内部で実装しようとすることができますが、全員が参加しているとプロセスがよりよく機能します。

これは@Cort Ammonが言っていることを言い換えているのではないかと思いますが、ここに私の見解を示します。

プロジェクトの要件は、外部要件（「成果物」を記述する）だけではありません。外部要件が変わらない場合でも、「内部」要件は変更されるか、作業に応じて変更が許可される必要があります。開発者はアプローチの障害や問題を発見し、これはチームの他の人々の仕事に影響を与えます。毎日のスタンドアップは、これらの内部的な変更を最新の状態に保ちます。

それを考慮してください：

• 機能要件が固定されている場合でも、それらを技術要件に変換する必要があります。そして、これは反復によってより良く行われるかもしれません。プロジェクトの途中で問題を解決するより良い方法を発見するかもしれません。

• 一部の要件は、「使いやすい」、「安全である」など、あまりにも一般的または曖昧な場合があります。システムのセキュリティまたは使いやすさを分析することは、それが完成していないことは困難です。いくつかは隠された意味を持っているか、よく理解されていないかもしれません。

• 一部の要件は改善される可能性があります。200msで応答するのは良いかもしれませんが、100msの方が良いかもしれません。可能な限り最高の結果をターゲットにすることができますが、プロジェクト中に必要に応じて犠牲にします。

• 契約には書かれていないが、プロジェクトを失敗から成功に変える可能性のある隠された要求を発見するかもしれません。プロジェクトを提供しても、クライアントは満足しない場合があります。初期段階でより安価にプロジェクトで設計できる新しい機能を追加（および請求）するために、契約を変更する必要があるかもしれません。

• 指定された時間内に要件を満たすことができない場合があります。ソフトウェアプロジェクトが遅れることはないようではありません。したがって、最高の価値を提供することで、どの機能をドロップするかを再確認することができます。

• より早く何かを提供することは統合に役立ち、このプロジェクトが結果を提供できることを示します。

すべての要件が完全にレイアウトされている場合、それらの要件を可能な限り迅速に達成するトップダウンアプローチが存在するという主張をすることができます。ただし、これらが適切な要件である場合は、作成方法ではなく、作成する内容が指示されます。作り方を教えてくれたら、「要件」ではなく「作業指示書」と呼ぶことにし、別の種類の問題について話し合うことにします。

したがって、要件を実装する企業またはチームの内部にある「方法」を開発するプロセスは常に存在します。経験的に言えば、設計者のチームがこれらの要件を満たすように高レベルシステムを設計し、その高レベルシステムの仕様を使用して詳細を具体化する小規模なチームに「要件」を提供する階層アプローチに強く依存しています。

ウォーターフォールプロセスでは、これは設計と実装の間の一方向矢印で見ることができます。ただし、これらの要件は、顧客が提供した要件のように明確に設定されていません。これらは内部的に定義されており、反復プロセスの余地があります。実際には、設計者はこの反復の欠如を説明するためにプロセスにかなりのマージンを入れるか、反復プロセスを模索することがわかります。

SCRUM、および他の多くの関連アジャイルメソッドは、この反復プロセスを実行するための厳密なフレームワークを提供するだけです。アジャイルアプローチのトレードマークは、厳しい要件の外側の層に焦点を合わせるのではなく、この反復パターンを最適化することをプロセスの中核と考えることです。他の人が述べたように、実際の固定要件はまれですが、それらが存在する場合でも、SCRUMは内部に収まる契約アプローチを制御する方法論として反復アプローチを使用します。

これが成功するかどうかは、オープンな議論の問題です。他の人は、この目的のために多くのメトリックを提供しています。私は単に、リーダーシップの下で発生する反復が上記の契約システムに正しく適合することを確認することはリーダーシップの強さ次第であることに注意します。これは、開発へのあらゆるアプローチに当てはまりますが、よりトップダウンのアプローチが「通常」であり、訓練されたリーダーであると想定するために提起されたため、アジャイルアプローチでより明確になります。