私は過去4年間、3つの異なるプロジェクトでSCRUMを使用しています。 SCRUMの利点の1つは、顧客の要件の変化など、柔軟性と適応性にあるようです。もう1つの利点は、管理者がプロジェクトの進行状況を簡単に追跡できることです。
SCRUMの柔軟性は利点になります。例えばWebアプリケーションを実装する場合、要件は非常に速く変化し、顧客はプロトタイプを見た後、自分が何を望んでいるかを本当に理解します。
一方、他の種類のソフトウェアプロジェクトがあります（航空宇宙など）。業界）要件がかなり固定されている場合：要件仕様書を入手し、6か月後に動作するソフトウェアと完全な文書を提出する必要があります。この種のプロジェクトでは、SCRUMが提供する柔軟性が必要かどうかは疑問です（ある意味で）プロトタイプを作成して、要件に関するフィードバックを得るために顧客に提示する必要はありません）：非常に構造化された体系的なアプローチが必要です。これは、プロジェクトごとに何度も繰り返され、驚きの余地はほとんどありません。
SCRUMは、その提案者によって汎用ソフトウェア開発方法論と見なされていますか、それとも特定のカテゴリのプロジェクトまたはアプリケーション領域に特に適していると見なされていますか？
Forたとえば、最近、航空宇宙産業向けのソフトウェアを製造している会社のWebサイトを見て、Vモデルを使用していることに気付きました。 SCRUMの支持者は、SCRUMはこの種のプロジェクトにはあまり適していない、またはむしろこの会社がSCRUMに切り替えてみるべきだと提案しますか？
注このフォーラムの読者の意見を求めているわけではありませんが、SCRUMの提案者の間で確立された意見は何ですか。SCRUMは汎用と見なされますか、それとも特定のクラスに適していますか。プロジェクトのみ？後者の場合、どのような種類のプロジェクトですか？
コメント
- stackoverflow.comを参照してください/ questions / 596916 / when-should-you-not-scrum および eweek.com/c/a/IT-Management/ …
- その"要件仕様書を入手し、6か月後に動作するソフトウェアを使用して戻ってくる必要があります"のことは神話です。正式に定義された言語用のコンパイラのようなものを構築する場合でも（機能要件が本当に明確で修正されているように見える場合）、実装するものを決定して優先順位を付ける必要があります。ユーザーと話し合う必要のある非機能要件があります。 、そしてあなたは物事をどのように解決するかを決定しなければならないためにいくつかの自由度を持っています。したがって、アジャイルアプローチはそのような種類のプロジェクトにも意味があります。
- "したがって、アジャイルアプローチはそのような種類のプロジェクトにも意味があります。"：アジャイルはより柔軟かもしれませんが、他の方法も同様に柔軟です。他の方法は十分に柔軟性があり、アジャイルは特定のプロジェクトには柔軟性が高すぎる可能性があります。ここでブレインストーミングを行うだけです。
- "要件仕様書を入手してください。6か月後に戻ってくる必要があります。動作するソフトウェアを使用する場合"は神話です。"：'そうは思いません。顧客がボタンを見た後に気が変わったため、Webページのボタンのラベルをすばやく変更できますが、飛行機の可動部分を制御するアビオニクスソフトウェアの重要な部分を簡単に変更することはできません。遅い変更が必要になるかもしれませんが、アジャイルな方法がそれらを管理する正しい方法なのか、それとも別の方法（Vモデルなど）のより複雑な反復が必要なのか疑問に思います。
回答
SCRUMは、ほとんどのプロジェクトとチームサイズでうまく機能する汎用方法論ですが、非常に大規模な大規模なチームではあまり役に立ちません。プロジェクト。一部のプロジェクトに関与する人の数が非常に多いため、秩序を維持するにはより堅固な構造が必要になるため、アジャイル手法は非常に困難またはほぼ不可能になります。航空宇宙産業は、アジャイルアプローチが常に実行可能であるとは限らない巨大なプロジェクトを抱える傾向がある産業の良い例です。
コメント
- ありますプロジェクトが大きすぎてSCRUMで実行できない場合についての情報はありますか？たとえば、15人のチームで18か月のプロジェクトを検討してください。そのようなチームはSCRUMから利益を得るのでしょうか、それともVモデルのような別のモデルも適しているのでしょうか。 。私が質問している理由は、18か月以上にわたって、要件と実装には熟成と安定化に十分な時間があり、SCRUMによって提供される柔軟性は実際には必要ないためです。むしろ、ここではより中長期的なアプローチが適しています。これに関する文献はありますか？
- @Giorgioプロジェクトの時間は'重要ではありませんが、複数のスクラムを作成することでメリットが得られるのは15人で十分です。グループですが、それでもSCRUMの管理可能な範囲内にあります。コミュニケーション管理がチームのフルタイムの仕事になり始めたら、Vモデルを検討し始めます
- あなたは本気ですか？以前はVモデルを使用していて、SCRUMに切り替えました。実際、私たちは'まさにこの理由で遅くなっていると感じています：簿記が多すぎます。
- @Giorgioは、どのスイッチにも当てはまります。ピエール303のように、新しいものは数回のスプリントでより良いアイデアが得られると言っていたため、最初は遅く感じます。
- @ Giorgio-その'は本当です、多くの"アジャイル"方法論は、想定される重いプロセスよりも重いです'交換する！明らかに、これは彼らが'間違っていることを意味します-アジャイルは軽くて自由であり、部外者には混沌としているように見えるはずです。これは、チームが非常に組織化され、統制されている必要があることを意味しますが、'は一般的にメリットがあります。代わりに、Alistair Cockburn（アジャイルの創設者の1人）のCrystalを試してください。
回答
あらゆるタイプのプロジェクト！！大小のプロジェクトの両方でうまく機能します。
人々は結婚式や引っ越しなどの計画に使用しています。したがって、ソフトウェアプロジェクトだけでなく、
私はスクラムのようなアプローチの恩恵を受ける可能性のある多くの事業運営があります。
コメント
- あなた自身の意見は共有されていますかSCRUMの提案者、つまりSCRUMを体系化して宣伝した著者によって？
- はい-最近、Cheryl Hammond（ blog.bsktcase.com ）、ノースウエストケイデンスのALMコンサルタントが、"スクラムマスターズデイインザライフ：新しいビジュアルスタジオ"。ここで見ることができます： msevents.microsoft.com/CUI/ …
回答
スクラムは方法論ではなく、フレームワークであることに注意してください。
スクラムが最適に機能します。 c内ross-functional チーム 5人から9人の開発者が
中規模から大規模のサイズのプロジェクト（4か月から複数年）。プロジェクトが大きい場合は、スクラムオブスクラムで拡張できます。
ここでは部門の枠を超えたものについては説明しませんが、ここでは説明します。 公式スクラムガイドがチームの規模について説明していることは次のとおりです。
最適な開発チームのサイズは、機敏性を維持するのに十分小さく、重要な作業を完了するのに十分な大きさです。開発チームのメンバーが3人未満の場合、相互作用が減少し、生産性の向上が小さくなります。小規模な開発チームは、スプリント中にスキルの制約に遭遇する可能性があり、開発チームがリリース可能な増分を提供できなくなる可能性があります。メンバーが9人を超えると、調整が必要になります。大規模な開発チームは、経験的なプロセスで管理するには複雑すぎます。プロダクトオーナーとスクラムマスターの役割は、スプリントバックログの作業も実行していない限り、このカウントには含まれません。
スプリントは約1か月です。
スプリントは1暦月に制限されています。 Sprintの期間が長すぎると、構築されているものの定義が変更され、複雑さが増し、リスクが高まる可能性があります。スプリントは、少なくとも暦月ごとに目標に向けた進捗状況の検査と適応を確実にすることにより、予測可能性を可能にします。スプリントはまた、リスクを1暦月のコストに制限します。
プロジェクトが小さい反復プロセスに基づくフレームワークを使用することは意味がないと思います4か月以上。4か月= 4スプリント。3回のスプリント後に、より正確な速度が得られることも考慮する必要があります。
、私は個人的に小さなプロジェクトには限定バージョンのScrumを使用していますが、実際にはそれをScrumと呼ぶことはできません。その特定のケースでは、フレームワークの独自の実装でスクラムのいくつかのコア原則を使用しています。