SCRUMはどのようなプロジェクトに適していると考えられていますか？

私は過去4年間、3つの異なるプロジェクトでSCRUMを使用しています。SCRUMの利点の1つは、柔軟性と適応性にあります。たとえば、変化する顧客の要件に対応できます。別の利点は、管理者がプロジェクトの進捗状況を簡単に追跡できることです。

SCRUMの柔軟性は、要件が非常に速く変化し、プロトタイプを見た後、顧客が何を望んでいるかを本当に理解しているWebアプリケーションを実装する場合などに有利です。

一方、要件がかなり固定されている他の種類のソフトウェアプロジェクト（たとえば、航空宇宙産業）があります。要件仕様のドキュメントを取得し、6か月後には有効なソフトウェアと完全なドキュメントを用意する必要があります。この種のプロジェクトでは、SCRUMが提供する柔軟性が必要であるとは思いません（プロトタイプを作成して顧客に見せて要件についてフィードバックを得る必要がないという意味で）：非常に構造化された体系的なアプローチが必要ですこれはおそらく、プロジェクトごとに何度も何度も繰り返され、驚きの余地はほとんどありません。

それでは、SCRUMはその支持者によって汎用のソフトウェア開発方法論と見なされますか、それともプロジェクトまたはアプリケーション領域の特定のカテゴリに特に適していると見なされますか？

たとえば、私は最近、航空宇宙産業向けのソフトウェアを製造している会社のWebサイトを見て、Vモデルを使用していることに気付きました。SCRUMの支持者は、SCRUMはこの種のプロジェクトにはあまり適していないと言いますか、それともこの会社がSCRUMへの切り替えを試みる必要があると提案しますか？

注私はこのフォーラムの読者の意見を求めていないのですが、私はSCRUMの提案者の間で定評が何であるかを知りたいこと：SCRUMは、汎用またはプロジェクトのみの特定のクラスのためにかなり適していると考えられますか？後者の場合、どのようなプロジェクトですか？

SCRUMは、ほとんどのプロジェクトとチームサイズでうまく機能する汎用的な方法論ですが、非常に大規模なプロジェクトを行う大規模なチームではあまり役に立ちません。一部のプロジェクトには膨大な数の人が関わっているため、秩序を保つにはより厳密な構造が必要となるため、アジャイル手法は非常に困難からほぼ不可能になります。航空宇宙産業は、アジャイルアプローチが常に可能であるとは限らない巨大なプロジェクトを抱える傾向がある業界の良い例です。

あらゆるタイプのプロジェクト！大規模なプロジェクトと小規模なプロジェクトの両方に適しています。

結婚式の計画、引っ越しの家の計画などに使用されてきました。ソフトウェアプロジェクトだけでなく、

私は、スクラムのようなアプローチから利益を得ることができる多くの事業運営があると確信しています。

スクラムは方法論ではなくフレームワークであることに注意してください。

スクラムは、中規模から大規模のプロジェクト（4か月から数年）に携わる5〜9人の開発者からなるクロスファンクショナルチームで最適に機能します。プロジェクトが大きい場合は、Scrum of Scrumsでスケーリングできます。

ここでは機能横断的なことについては説明しませんが、公式スクラムガイドがチームの規模に応じて次のように述べています。

最適な開発チームのサイズは、機敏さを保つのに十分小さく、重要な作業を完了するのに十分な大きさです。開発チームのメンバーが3人未満の場合、相互作用が減少し、生産性の向上が小さくなります。小規模な開発チームは、スプリント中にスキルの制約に遭遇する可能性があり、開発チームは潜在的に解放可能な増分を提供できなくなります。メンバーが9人を超えると、調整が必要になります。大規模な開発チームは、経験的なプロセスを管理するには複雑すぎます。製品所有者とスクラムマスターの役割は、スプリントバックログの作業も実行していない限り、この数には含まれません。

スプリントは約1か月です。

スプリントは1暦月に制限されています。スプリントの視野が長すぎると、構築されるものの定義が変更され、複雑さが増し、リスクが増大する可能性があります。スプリントは、少なくとも毎月、目標に向けた進捗状況の検査と適応を確実にすることにより、予測可能性を可能にします。スプリントはまた、リスクを1か月のコストに制限します。

4か月未満のプロジェクトで反復プロセスに基づくフレームワークを使用することは意味がないと思います。4ヶ月= 4スプリント。また、3回のスプリント後により正確な速度が得られることも考慮する必要があります。

とはいえ、私は個人的に小規模なプロジェクトに限定バージョンのスクラムを使用しています。しかし、それをスクラムと呼ぶことはできません。その特定のケースでは、フレームワークの独自の実装でスクラムのいくつかのコア原則を使用しています。

手始めに、SCRUMはアジャイルプラクティスを実装するためのガイドラインの1つのセットと考えてください。それをプロジェクトの実行方法の「聖典」と考えてはいけません。タスクの安定したフローが必要な多くのプロジェクトでは、たとえばKanbamがより適切です。

アジャイルプロジェクトは、固定の終了日または固定のコストを必要とするプロジェクトを実行している場合、傾向が崩れます。アジャイルメソッドを使用してこれらのプロジェクトを実行することはできますが、ターゲットに到達する可能性があるかどうかを判断するために事前にすべてを計画する必要は、通常のアジャイル方法ではありません。ほとんどのプロジェクトでは、プロジェクトの途中で要件が変更されるため、これで問題ありません。