スクラムは防衛契約にメリットがありますか？
昨日ウォータークーラーで耳にした：「スクラムは防衛契約の場所がありません。」
スクラムは多くのシナリオで機能するように調整でき、防御もその1つであると私は信じているという意味で、私は反対する傾向があります。これは私の同僚（私たちの多くは防衛産業の契約で働いています）の間で大きな議論を引き起こし、賛成/反対でかなり均等に分かれました。
これを適切な質問にするために：防衛契約の状況でスクラムをうまく使用した（または使用した経験がある）人はいますか？何がうまくいったのか、何がうまくいかなかったのか、そしてバニラスクラムにどのような変更を加えましたか？
「スクラムは防衛産業の契約に場所がありません。」
私の経験では、主な障害は顧客です。ほとんどの政府機関は、DNAにウォーターフォールモデルを持っています。契約でさえウォーターフォールフェーズで行われます。最初に要件に資金を提供し、次に設計、次に実装に資金を提供します。古典的なウォーターフォール理論では、彼らはさまざまな会社にさまざまなフェーズを実行させることができるとさえ考えるかもしれません。
IMOを介してそれを回避する方法があります。事前の要件を実行し、ウォーターフォールのように設計してから、実装で要件を反復的なユーザーストーリーに分割します。内部テスト/エキスパートユーザーを使用して、各反復を評価します。お客様によっては、参加に興味がある場合とない場合があります。純粋なスクラムではありませんが、それが最善の方法かもしれません。
スクラムを完全に実装することは難しいかもしれませんが、スクラムの実践のいくつかを採用することは有益である可能性があります。たとえば、要件の収集をどのように行っているかに関係なく、リリースやデモを頻繁に行うことができます。あなたはまだ定期的な回顧展から利益を得ることができます。リーンやかんばんのような他のプロセスを見て、チームにも役立つものがあるかどうかを確認します。
独断的に1つのプロセスに従うのではなく、チーム、プロジェクト、および業界のためにプロセスを改善する方法を考えてください。 プロセスの問題 。チームの方法論は、提供されるソフトウェアに大きな影響を与えます。