SCRUMはどのようなプロジェクトに適していると考えられていますか？
私は過去4年間、3つの異なるプロジェクトでSCRUMを使用しています。 SCRUMの利点の1つは、その柔軟性と適応性です。顧客要件の変更に関連して。別の利点は、管理者がプロジェクトの進捗状況を簡単に追跡できることです。
SCRUMの柔軟性は、例えばWebアプリケーションを実装するとき。要件は非常に速く変化し、プロトタイプを見た後、顧客は何が欲しいかを本当に理解します。
一方、要件がかなり固定されている他の種類のソフトウェアプロジェクト（たとえば、航空宇宙産業）があります。要件仕様のドキュメントを取得し、6か月後には有効なソフトウェアと完全なドキュメントを用意する必要があります。この種のプロジェクトでは、SCRUMが提供する柔軟性が必要であるとは思いません（プロトタイプを作成して顧客に見せて要件に関するフィードバックを得る必要がないという意味で）：非常に構造化された体系的なアプローチが必要ですこれはおそらく、プロジェクトごとに何度も何度も繰り返され、驚きの余地はほとんどありません。
それでは、SCRUMはその支持者によって汎用のソフトウェア開発方法論と見なされますか、それともプロジェクトまたはアプリケーション領域の特定のカテゴリに特に適していると見なされますか？
たとえば、私は最近、航空宇宙産業向けのソフトウェアを製造している会社のWebサイトを見て、Vモデルを使用していることに気付きました。 SCRUMの支持者は、SCRUMはこの種のプロジェクトにはあまり適していないと言っているでしょうか、それともこの会社がSCRUMに切り替えてみるように勧めているのでしょうか？
注私はこのフォーラムの読者の意見を求めているわけではありませんが、SCRUM提案者の間で確立された意見は何かを知りたいのです。プロジェクトのみ？後者の場合、どのような種類のプロジェクトですか？
SCRUMは、ほとんどのプロジェクトとチームサイズでうまく機能する汎用的な方法論ですが、非常に大規模なプロジェクトを行う大規模なチームではあまり役に立ちません。一部のプロジェクトには膨大な数の人が関わっているため、秩序を保つにはより厳密な構造が必要となるため、アジャイル手法は極めて困難からほぼ不可能になります。航空宇宙産業は、アジャイルアプローチが常に可能であるとは限らない巨大なプロジェクトを抱える傾向がある業界の良い例です。
あらゆるタイプのプロジェクト！大規模なプロジェクトと小規模なプロジェクトの両方に適しています。
結婚式の計画、引っ越しの家の計画などに使用されてきました。ソフトウェアプロジェクトだけでなく、.
私は、スクラムのようなアプローチの恩恵を受けることができる多くのビジネスオペレーションがあると確信しています。
スクラムは方法論ではなくフレームワークであることに注意してください。
スクラムは、5人から9人の開発者の部門横断型チームで最適に機能します）中規模から大規模のサイズのプロジェクト（4か月から数年）に取り組んでいます。プロジェクトが大きい場合は、 Scrum of Scrums でスケーリングできます。
ここでは、機能横断的なことについては説明しませんが、 公式スクラムガイド がチームの規模について伝えていることは次のとおりです。
最適な開発チームのサイズは、機敏さを保つのに十分小さく、重要な作業を完了するのに十分な大きさです。開発チームのメンバーが3人未満の場合、相互作用が減少し、生産性が向上しません。小規模な開発チームは、スプリント中にスキルの制約に遭遇し、開発チームが潜在的に解放可能な増分を提供できなくなる可能性があります。メンバーが9人を超えると、調整が必要になります。大規模な開発チームは、経験的なプロセスを管理するには複雑すぎます。プロダクトオーナーとスクラムマスターの役割は、スプリントバックログの作業も実行していない限り、この数には含まれません。
スプリントは約1か月です。
スプリントは1暦月に制限されています。スプリントの視野が長すぎると、構築されるものの定義が変更され、複雑さが増し、リスクが増大する可能性があります。スプリントは、少なくとも毎月、目標に向けた進捗状況の検査と適応を確実にすることにより、予測可能性を可能にします。スプリントは、リスクを1か月のコストに制限します。
4か月未満のプロジェクトで反復プロセスに基づくフレームワークを使用することは意味がないと思います。 4ヶ月= 4スプリント。また、3回のスプリントの後に、より正確な velocity が得られることも考慮する必要があります。
とはいえ、私は個人的に小規模なプロジェクトに限定バージョンのスクラムを使用しています。しかし、それを実際にそれをスクラムと呼ぶことはできません。その特定のケースでは、フレームワークの独自の実装でスクラムのいくつかのコア原則を使用しています。
手始めに、SCRUMはアジャイルプラクティスを実装するためのガイドラインの1つのセットと考えてください。それをプロジェクトの実行方法の「聖典」と考えてはいけません。タスクの安定したフローが必要な多くのプロジェクトでは、たとえばKanbamがより適切です。
アジャイルプロジェクトは、固定の終了日または固定のコストを必要とするプロジェクトを実行している場合、傾向が低下します。アジャイルメソッドを使用してこれらのプロジェクトを実行することはできますが、ターゲットに到達する可能性があるかどうかを判断するために事前にすべてを計画する必要は、通常のアジャイル方法ではありません。ほとんどのプロジェクトでは、プロジェクトの途中で要件が変更されるため、これで問題ありません。