プロジェクト管理の青写真パート2：ウォーターフォール、DAD、SAFe、LeSS、およびScrum@Scaleの包括的な比較

概要

プロジェクト管理ブループリントのパート1では、リーンソフトウェア開発、アジャイル、スクラム、およびかんばんのソフトウェア開発方法論と、それらすべてがリーン生産方式にまで遡る方法について説明しました。 これらの方法論は通常、単一のチームレベルで展開されます。 ただし、プロジェクトとプロジェクトチームが大きくなるにつれて複雑さが増し、大規模なアジャイルには新しいアプローチが必要になります。

第2部では、最初に、プロジェクトマネージャーがウォーターフォール手法をどのように使用するかについて詳しく説明します。これは、従来の企業でソフトウェア開発を行うための最も一般的なフレームワークです。 これに加えて、アジャイルの原則を大規模に取り入れようとする最も一般的なフレームワークである、Disciplined Agile Delivery（DAD）、Scaled Agile Framework（SAFe）、Large Scale Scrum（LeSS）、およびScrum@Scaleについて説明します。

滝

ウォーターフォール手法（ソフトウェア開発ライフサイクルモデル（SDLC）とも呼ばれます）は、ソフトウェア開発がウォーターフォールのようにあるフェーズから次のフェーズにカスケードする、より伝統的な手法です。 フェーズは重複せず、あるフェーズから次のフェーズに移動するための特定の入口と出口の基準があります。

元のウォーターフォールモデルの6つのライフサイクルステージは次のとおりです。

1. 要件：このフェーズでは、プロジェクトの期待と目標が定義され、通常はビジネスアナリストによって、要件が広範囲にわたって分析および文書化されます。 このフェーズを終了する前に、要件が確認および承認されます。
2. 設計：要件が承認された後、承認された要件を満たすように製品を設計および設計する作業が開始されます。 物理アーキテクチャ、コンポーネントアーキテクチャ、データベースデザイン、詳細コンポーネント、モジュールデザイン、およびその他のデザインの側面は、ソフトウェアアーキテクトまたはデザイナーによって文書化されています。 次に、実装を開始する前にレビューおよび承認されます。
3. 実装：設計が承認された後、要件と設計に応じたソフトウェアの実装またはコーディングがソフトウェア開発者によって行われます。
4. 検証：実装が完了した後、ソフトウェアはテストチームまたはQAチームによってテストされ、要件と設計が満たされ、必要なレベルの品質が達成されていることを確認します。 欠陥が検出され、ログに記録され、トリアージされ、多くの場合、修正されます。
5. リリースとメンテナンス：テストとデバッグが完了すると、製品がクライアントにリリースされ、インストールされます。 多くの場合、インストールが成功したことを確認するために一連のテストが行​​われます。 製品が納品された後、製品が設計どおりに機能し続けることを保証するために、継続的なメンテナンスとサポートが行われます。

ウォーターフォールの利点

ウォーターフォールにはいくつかの利点があり、特定のタイプのプロジェクトに適していますが、いくつかの重大な欠点もあります。 Waterfallは、要件、テクノロジーが十分に理解されており、大きな変化がない可能性が高い、より短いプロジェクトに最適です。

適切なタイプのプロジェクトに適用した場合、ウォーターフォールモデルの利点のいくつかは次のとおりです。

• シンプルさ：ウォーターフォールは、スコープを事前に識別し、厳密なフェーズと、あるフェーズから次のフェーズへの明確な移行により、実装が簡単です。
• 可視性：作業の全範囲が事前にわかっていて、プロジェクトが1つの段階から次の段階に移行するときに、利害関係者は進捗状況をより簡単に測定して確認できます。
• ドキュメント：範囲、要件、および計画を徹底的に検討し、十分にドキュメント化することができます。これにより、経験の浅いチームがプロジェクトに取り組むのが容易になります。
• 段階的作業：厳格な役割と段階間の移行により、プロジェクトリソースは、主要な段階が進行していないときに他のプロジェクトで作業することができます。

ウォーターフォールのデメリット

ウォーターフォールは、要件が十分に理解されていない、および/または変更される可能性がある、および/または重大な技術的リスクがある、より長いプロジェクトには適していません。 市場の状況が絶えず変化し、市場投入までの時間が重要である今日の時代では、これはほとんどのソフトウェアプロジェクトに当てはまります。

ウォーターフォールモデルの欠点は、主に変化に適応できないことを中心にしています。

• モノリシックスコープ：プロジェクトのスコープを定義するときにすべてを考えることは、利害関係者に報酬を与え、モノリシックスコープにつながります。
• クライアントからのフィードバックの遅れ：利害関係者、特にクライアントにとって、プロジェクトの詳細な範囲全体を想像するのは困難です。 ウォーターフォールは、主にプロジェクトの最終段階でクライアントをプロジェクトの結果にさらすため、必然的にクライアントのフィードバックをプロジェクトに組み込むことが難しくなります。
• 要件の変更：より長いプロジェクトでは、市場の状況、したがってプロジェクトの目標と要件は、プロジェクト中に変更されるリスクが非常に高くなります。
• 最後に作成される価値：ウォーターフォールは、事前に多くの作業を必要とします。つまり、プロジェクトの後半まで価値が生み出されません。
• フェーズの相互依存性：変更を組み込むと、多くの場合、プロジェクトの他の領域に影響を与える可能性のある要件や設計のやり直しが発生します。 後の段階が前の段階に依存していると、プロジェクトに小さな変更を加えることが不釣り合いに難しくなる可能性があります。

ディシプリンドアジャイルデリバリー（DAD）

ディシプリンドアジャイルデリバリー（DAD）は、IBMとMarkLinesのScottAmblerによって正式化され、アジャイルとスクラムのフレームワークを拡張して、組織の非アジャイル部分が通常、ソフトウェアプロジェクトのデリバリーに何らかの能力を持っていることを認識しています。 このフレームワークには、IT運用、エンタープライズアーキテクチャ、ポートフォリオ管理、財務、調達から完全な配信ライフサイクルまでのアクティビティが明示的に含まれています。 DADは、実用的な方法で全体的なビジネスの俊敏性を向上させることを目的としています。

主な原則とコンポーネント

役割

DADにはスクラムよりもかなり多くの役割があり、チームの役割の2つのカテゴリに分類されます。 主な役割は、プロジェクトに常に携わっている人々によって満たされます。 通常、二次的な役割は、チームがスケーリングやその他の問題を解決するのを支援するために一時的に導入されます。 DADには、ソリューション配信ライフサイクル全体に対応し、現実の世界で見られるさまざまなタイプの必要な一時的およびサポートの役割を認識するため、これらの追加の役割があります。

主な役割：

1. 利害関係者：プロジェクトを完了するチームに依存している人：クライアント、エンドユーザー、または社内の同僚。
2. チームメンバー：計画された作業を実際に行うチーム内の人々：開発者、設計者、テスターなど。
3. チームリーダー：スクラムマスターと同様に、チームリーダーは、障害を取り除き、チームの結束を促進し、アジャイルな価値観を広めることにより、チームの使用人リーダーとして機能します。
4. プロダクトオーナー： 「顧客の声」と呼ばれることもあります。 プロダクトオーナーは利害関係者を代表し、実行する必要のある作業の優先リストを維持します。
5. アーキテクチャの所有者：大規模なアーキテクチャのリスクを軽減する責任があります。 この役割は、深い技術的背景と確かなビジネスドメインの知識を必要とするため、通常、チーム内の上級開発者が担当します。

二次的な役割：

1. スペシャリスト：専門的な役割を支援するために一時的にチームに参加する人。 たとえば、データアナリストが参加して、プロジェクトの初期段階で調査機能を提供する場合があります。
2. ドメインの専門家：税務コンサルタント、法律顧問、およびドメインの専門知識を持ち、関連する課題についてチームを支援するその他の人々。
3. 技術専門家：データベース管理者、セキュリティ専門家ビルドマスターなど。これらの人々は、ライフサイクルの重要なポイントでより一般化されたチームメンバーを支援します。
4. 独立したテスター：テスターは通常メインチームの一部ですが、場合によっては生命規制要件や非常に複雑なシステムですが、独立したテスターは並行して作業を検証します。
5. インテグレーター：大規模な場合、さまざまなチームがシステム全体のさまざまな部分に取り組んでいます。 インテグレーターは、チームが自分の部分をシステム全体と統合し、依存関係を管理するのを支援します。

ライフサイクルサポート

DADは、アジャイル/スクラムでカバーされるプログラミングとリリースの部分だけでなく、プロジェクトのビジョンが定義および承認される開始フェーズと、リリース後のサポートとリタイアのフェーズも含めて、完全な配信ライフサイクルを促進します。 現在、DADは6つの異なるライフサイクルをサポートしています。

• アジャイルライフサイクル：スクラムベースのプロジェクトライフサイクル
• リーンライフサイクル：かんばんベースのプロジェクトライフサイクル
• 継続的デリバリー：アジャイルライフサイクル
• 継続的デリバリー：リーンライフサイクル
• 探索的（リーンスタートアップ）ライフサイクル
• チームのチームのプログラムライフサイクル

これらのライフサイクルは、さまざまなワークスタイル、会社の敏捷性のレベル、およびチームが直面する可能性のあるその他の状況を説明します。主なポイントは、これらのライフサイクルが提案として機能することです。 すべての状況は独特であり、訓練されたアジャイル実践者は彼らのニーズにアジャイルプロセスを採用する必要があるため、DADは純粋主義よりも実用主義を促進します。

プロセスの目標

DADは、目標主導型のアプローチを使用して、アジャイルプロセスを作成および適応させます。 この方法論の作成者は、ほとんどのチームがライフサイクル中に直面する21の最も重要で一般的なプロセスの概要を説明します。

これらのプロセスはすべて、チームがそのプロセスをどのように構成するかを決定する必要がある決定ポイントを文書化しています。 各決定ポイントは、決定を実装するために使用できる推奨される手法または実践を提供します。 下の画像でこの例を見ることができます。 「共通ビジョンの開発」プロセスには、6つの決定が必要です。 それらの決定のそれぞれには、2から5の提案された実践があります。 矢印は、DADの作成者がリストを注文したことを示しています。このリストの一番上の項目がベストプラクティスで、一番下の項目が最悪のプラクティスです。 _太字の斜体_テキストは、DADを始めたばかりの新しいチームにとって良い出発点を示しています。

DADのスケーリング

ディシプリンドアジャイルデリバリーは、2つの異なる角度からスケーリングにアプローチします。

• 大規模な戦術的敏捷性

• 大規模な戦略的敏捷性

戦術的な敏捷性は、プロセスの目標とその提案されたプラクティスの状況に応じた適用を通じて、サイズ、地理的分布、プロジェクトの複雑さなどの個々のチームのスケーリング要因に対処しようとします。

戦略的敏捷性は、組織のさまざまな領域に対応するようにフレームワークを拡張することにより、組織全体に広くアジャイルで無駄のない戦略を適用することにより、スケーリングに対処しようとします。

• 統制のとれたDevOps：組織により効果的な結果を提供するためのDevOpsの使用について説明します。

• ディシプリンドアジャイルIT（DAIT）：ITのすべての側面にアジャイル戦略とリーン戦略を適用する方法について説明します。

• 規律あるアジャイルエンタープライズ：。 企業全体にリーンでアジャイルを適用する方法について説明します。

安全

Scaled Agile Framework（SAFe）は、現在最も人気があり、最も複雑で包括的なスケーリングされたアジャイルフレームワークです。 アジャイルの年次報告書の回答者の29％は、組織でこのフレームワークを使用していると述べています。 同様に、市場には多くのSAFeプロジェクトマネージャーがいます。

SAFeの始まりは、2007年に発行されたDean Leffingwellの著書「ScalingSoftwareAgility：Best Practices for Large Enterprises」でした。現在、LeffingwellはSAFeの主任方法論者ですが、他の多くの人々もこのフレームワークに貢献しています。 現在、バージョン4.6では、このフレームワークは、バージョン管理、下位互換性、およびさまざまなコンポーネントを備えたソフトウェア製品に似ています。

主な原則とコンポーネント

SAFeの主な目標は、リーンエンタープライズの作成と成長を促進することです。これは、多くの異なるタイプの企業が、部分的には、最短で持続可能な期間で継続的に価値を提供する必要があるソフトウェア企業であることを認識しているためです。

SAFe for Lean Enterprisesは、実証済みの原則、能力、およびベストプラクティスの知識ベースを提供することにより、リーンエンタープライズを作成しようとします。

SAFe 4.6は、リーンエンタープライズの5つのコアコンピテンシーを定義しています。 各コンピテンシーは、関連する知識、スキル、および行動のセットであり、これらを組み合わせることで、組織は次のことを実現できます。

1. リーンアジャイルリーダーシップ：SAFeのリーンアジャイルマインドセットを学習、教育、および実装することにより、リーダーが組織の変化を推進および維持する方法について説明します。

2. チームと技術の敏捷性：高性能のアジャイルチームを作成するために必要なスキル、原則、および実践について説明します。

3. DevOpsとオンデマンドリリース：DevOpsと継続的デリバリーパイプラインを実装することで、組織が需要を満たすために必要なときにいつでも製品の増分をリリースできるようになる方法について説明します。

4. ビジネスソリューションとリーンシステムエンジニアリング：大規模で複雑なソフトウェアアプリケーションの仕様、開発、展開、および進化にリーンアジャイルの原則と実践を適用する方法について説明します

5. リーンポートフォリオ管理：戦略と投資資金調達、アジャイルポートフォリオ運用、およびガバナンスにリーンおよびシステム思考アプローチを適用することにより、戦略と実行を調整します。

プロセス全体を網羅するリーンアジャイルリーダーシップを除いて、各コアコンピテンシーはSAFeプロセス図のそれぞれのレベルに直接マッピングされます。

リーンアジャイルリーダーシップコンピテンシー

リーンアジャイルリーダーシップコンピテンシーの主な目標は、組織をリーンアジャイル企業に変革するのを支援することです。 これは、SAFeのリーンアジャイルの考え方、価値観、原則、および実践を学び、実践し、教えることによって行われます。

SAFeのコアバリューは、無駄のない企業への変革を導きます。 あらゆる機会において、リーダーの行動は彼らを促進する上で重要な役割を果たします。 コアバリューは次のとおりです。

1. 調整：ミッション、ポートフォリオ戦略、およびソリューションのビジョンを伝えます。 関連するブリーフィングを実施し、プログラム増分（PI）計画とバックログ保守に参加します。

2. 透明性：関連するすべての作業を視覚化します。

3. 組み込みの品質：ライフサイクル全体で品質を提供するための実践に従事します。 質の低い仕事を受け入れることを拒否します。 メンテナンスへの投資をサポートし、技術的負債を削減します。

4. プログラムの実行：PIの実行にビジネスオーナーとして参加し、ビジネス価値を確立します。 スコープが需要と容量に合っていることを確認してください。 障害物やデモチベーターを積極的に取り除きます。

SAFeコアバリューは、リーンアジャイルマインドセットを採用し、SAFe原則を適用することでサポートされます。

1. 経済的な見方をする

2. システム思考を適用する

3. 変動性を想定します。 オプションを保持

4. 高速で統合された学習サイクルで段階的に構築する

5. 作業システムの客観的評価に基づくマイルストーン

6. WIPの視覚化と制限、バッチサイズの削減、キューの長さの管理

7. ケイデンスを適用し、クロスドメイン計画と同期します

8. 知識労働者の本質的な動機を解き放つ

9. 意思決定を分散化する

これらの原則は、リーンおよびアジャイルの原則に似ています。 最後に、組織の変革は、SAFe実装ロードマップに従うことによって達成されます。

チームおよび技術的敏捷性/チームレベル

チームおよび技術的敏捷性コンピテンシーは、高品質のソリューションを作成する高性能のアジャイルチームを作成するために必要なスキル、原則、および実践について説明します。 2つの重要な特性が重要です。

• チームの敏捷性：チームはアジャイルの実践と原則を採用し、信頼できるリズムで作業、学習、適応できるようにします

• 技術的敏捷性：チームは、コードとコンポーネントの品質、および生成するコードの保守性を保証するアジャイル技術手法を適用します\品質は、チームと技術的敏捷性の能力において大きな焦点です。 これを実現するために、ビヘイビア駆動開発（BDD）やテスト駆動開発（TDD）などのアジャイルエンジニアリング手法を適用して、品質とフローを向上させます。 エラーはフローに深刻な影響を与え、リリースを遅らせる可能性があるため、高速フローはシステム全体の建物の品質に依存します。

SAFeダイアグラムのチームレベルは、個々のアジャイルチームがどのように機能するかを示しています。 すべてのチームは、製品増分の提供に向けて取り組むアジャイルリリーストレインの一部です。 従来のアジャイル/スクラムフローのほとんどが適用され、チームは反復して作業システムを提供します。 スクラムマスター、プロダクトオーナー、およびチームメンバーの役割は、ほとんどのスクラムアクティビティおよびアーティファクトと同様に、SAFeで使用されます。 チームは、製品管理、システムアーキテクト、その他の共有サービスなどのプログラムレベルの役割によってもサポートされます。 かんばんは、配信ライフサイクル全体の機能の流れと、チーム間の相互作用およびハンドオフを視覚化するために使用されます。

DevOpsとリリースオンデマンドコンピテンシー/プログラムレベル

DevOpsとリリースオンデマンドコンピテンシーは、「DevOpsと継続的デリバリーパイプラインを実装することで、市場と顧客の需要を満たすために必要なときに、全体的または部分的に価値をリリースする機能を企業に提供する」方法を説明しています。

DevOpsは、開発、運用、ビジネス、およびその他の領域を連携させて、ビジネス結果を提供するために連携します。 すべての組織がDevOpsムーブメントの業界リーダーの一部ほど頻繁にリリースする必要はありませんが（Amazonは数秒ごとにリリースします）、すべての組織がオンデマンドでリリースできる必要があります。

• DevOpsは、継続的デリバリーとオンデマンドのリリースを可能にするカルチャー、自動化、リーンフロー、測定、およびリカバリ（CALMR）アプローチを提供します

• アジャイルリリーストレイン（ART）は、継続的デリバリーパイプラインを介してオンデマンドで価値を提供するように編成されたアジャイルチームのチームです。

図のプログラムレベルは、アジャイルリリーストレイン（ART）を介して継続的に提供するために必要な役割とアクティビティを示しています。 このレベルは、チームレベルと同様の反復的な方法で機能しますが、複数のアジャイルチームを統合し、より多くのサイクルを含みます。 ARTは、従来の機敏な役割だけでなく、リリーストレインエンジニア（RTE）や製品管理などの重要なプログラムの役割を含む5〜12チーム（50〜125人）で構成されるチームの機敏なチームです。 ARTは、 PI Planningを介して計画され、プロダクトマネージャーが主導する、8〜12週間のプログラム増分（PI）で提供します。

PI機能、エピックなどの進行状況は、プログラムかんばんボードを介して追跡および管理されます。 RTEは、ARTのスクラムマスターとして機能します。 毎日の同期会議には、チームの毎日のスタンドアップ、スクラムオブスクラム（RTEとスクラムマスター）、PO Sync（製品管理と製品所有者）、ART Sync（スクラムオブスクラムとPO Syncを一緒に）が含まれます。 各PIには、システムデモと回顧展があります。

ビジネスソリューションとリーンシステムエンジニアリングコンピテンシー/大規模ソリューションレベル

ビジネスソリューションとリーンシステムエンジニアリングコンピテンシーでは、「リーンアジャイルの原則と実践を、大規模で複雑なソフトウェアアプリケーションとサイバーフィジカルシステムの仕様、開発、展開、進化に適用する方法」について説明しています。

SAFeの原則に加えて、大規模なソリューションに取り組む際に次の8つの原則を適用することが、この能力の鍵となります。

大規模ソリューションレベルには、大規模で複雑なソリューションを構築するために必要な役割、成果物、およびプロセスが含まれています。 複数のARTがソリューショントレインに協力してソリューションを提供しています。 主な目的は次のとおりです。

• 頻繁な統合を管理する

• コンプライアンスの懸念に継続的に対処する

• 規模、モジュール性、リリース可能性、および保守性のためのアーキテクト

ソリューション管理はソリューションのコンテンツを制御し、ソリューショントレインエンジニア（STE）が作業をガイドします。 ソリューションアーキテクトは、ソリューション内のすべてのARTの優れたアーキテクチャを維持する責任があります。 事前および事後PI計画は、複数のプログラム増分を介して提供されるソリューションを計画するために使用されます。 ソリューションバックログには、機能とソリューションエピックが含まれ、ソリューションかんばんボードを介して追跡されます

ポートフォリオレベル/リーンポートフォリオ管理能力

リーンポートフォリオ管理コンピテンシーは、「リーンとシステム思考のアプローチを戦略と投資の資金調達、アジャイルポートフォリオ運用、およびガバナンスに適用することにより、戦略と実行を調整します」。

リーンポートフォリオ管理は、次の分野に焦点を当てています。

1. 戦略と投資資金調達：ポートフォリオを企業戦略に結び付け、バリューストリームに資金を提供し、ポートフォリオフローを確立します

2. アジャイルポートフォリオ運用：バリューストリームを調整し、プログラムの実行をサポートし、優れた運用を実現します

3. リーンガバナンス：予算を予測し、ポートフォリオのパフォーマンスを測定し、コンプライアンスを実施します

ポートフォリオレベルには、一連の開発バリューストリームを開始および管理するために必要な原則、実践、および役割が含まれています。 ポートフォリオバックログには、ビジネスエピックとイネーブラーエピックが含まれ、ポートフォリオかんばんボードを介して追跡されます。 **リーンポートフォリオ管理（LPM）は、ポートフォリオに含まれるバリューストリームを決定し、企業の最高の意思決定者を含みます。 エンタープライズアーキテクトは、バリューストリーム全体の作業と調整をガイドします。

以下

大規模スクラム（LeSS）フレームワークは、金融および電気通信業界での経験に基づいて作成されたCraigLarmanとBasVoddeによって作成されました。 名前が示すように、LeSSは、多くのスクラムチームが連携できるように、プロセスと手順をできるだけ少なくすることを推進しています。 スケーリングは人が複雑にするため難しいので、ここでの目標は可能な限り単純にすることです。

主な原則とコンポーネント

「LeSSはスクラムであり、多くのチームに適用され、1つの製品で協力しています」。 LeSSは、リーンアジャイルの原則に精通している人なら誰でも知っていると思われる10の原則に基づいています。

1. 大規模スクラムはスクラムです

2. 経験的プロセス制御

3. 透明性

4. より少ないものでより多く

5. 製品全体の焦点

6. 顧客中心

7. 完璧に向けた継続的な改善

8. システム思考

9. リーン思考

10. 待ち行列理論

LeSSには2つの主要な役割しかなく、どちらもスクラムから借用されています。

1. プロダクトオーナー： 2〜8チームで作業します。
2. スクラムマスター： 1〜3チームで動作します。

すべてのチームは、1〜4週間のスプリントで同じ製品バックログを処理します。 チームは並行して作業します。つまり、スプリントの開始と終了を同時に行います。 スプリントの最後に、チームは集合的に製品の増分を提供します。 1人の製品所有者が8チームで作業することはほぼ不可能に思えるかもしれません。 LeSSは、製品バックログ項目の明確化の責任をチームに移すことを促進します。 同様に、チームは部門の枠を超えており、コーディング、設計、テストの能力だけでなく、ビジネスドメインの知識も含まれている必要があります。 さらに重要なことに、チームは顧客に連絡できるように権限を与える必要があります。

スプリント計画

計画は2つの部分に分かれています。

1. スプリント計画1：チームの代表者がプロダクトオーナーと会い、どのバックログアイテムを引き受けるかを決定し、スプリント中にチーム間で必要となる可能性のある潜在的な協力について話し合う場所。
2. スプリント計画2：従来のスクラムと同じように、各チームは個別に集まり、バックログ項目がどのように行われるかについての計画を作成します。

製品バックログの改善

スプリント計画のために製品バックログアイテムを準備するために、スプリント中に製品バックログリファインメント（PBR）が実行されます。 LeSSは、PBRの実行方法に関するルールを提供しておらず、最も効果的なプロセスを自ら把握するのは企業に任されています。 PBRには、次の3つの主要なアクティビティが含まれます。

1. 大きなアイテムを分割します。
2. 準備ができるまでアイテムを詳しく説明します。
3. 見積もり。

スプリントの終わり

各スプリントの終わりに、3つのことが起こります。

1. スプリントレビュー：共有されたスプリントデモ。チームと顧客は、スプリント中に何が行われ、次に何をすべきかを探ります。
2. ふりかえり：各チームは、プロセスを改善するために独自の回顧展を開催します。
3. 全体的な回顧：チーム、製品所有者、およびスクラムマスターが集まり、組織の慣行を調査して適応させ、より効果的にします。

Scrum @ Scale

ScrumatScaleとScrum@Scaleは同じ意味で使用されます。 この方法論は、スクラム方法論を作成し、アジャイルマニフェストの署名者の1人であるJeffSutherlandによって2014年に導入されました。

Scrum @ Scaleは、スクラムを出発点とし、「最小限の実行可能な官僚主義」でスクラムをスケーリングするためのシンプルで軽量なフレームワークを提供します。 これは、他のスケーリングされたアジャイル手法よりも規範的ではなく、メタフレームワークと見なすことができます。 スケーリングの問題と領域を強調し、それらに対処するための精神的なフレームワークを提供します。

主な原則とコンポーネント

Scrum @ Scaleは、スクラムを使用してスクラムをスケーリングすることにより、スケーリングを大幅に簡素化するフレームワークです。 スクラムでは、「what」（プロダクトオーナー）は「how」（スクラムマスター）から明確に分離されています。 同じ戦略がScrum@Scaleでも使用されているため、管轄権と説明責任が十分に理解され、無駄と競合が排除されます。

Scrum @ Scaleには、管轄区域を明確に分離するための2つのサイクルが含まれています。スクラムマスターサイクルと、チームレベルプロセスと製品リリースフィードバックの2つのタッチポイントを持つプロダクトオーナーサイクルです。

スクラムマスターサイクル

スクラムマスターサイクルは、プロダクトオーナーサイクルが特定したものがどのように構築されるかを担当します。 Scrum @ Scaleでは、個々のスクラムチームは、従来のスクラムと同じ役割、成果物、活動、および儀式を持っています。

スクラムチームはスクラムオブスクラム（SoS）にグループ化され、共同で製品の増分を生成する責任があります。 彼らは共同のバックログのグルーミングと優先順位付けに参加し、回顧を行い、障害のバックログを維持し、チームを調整して障害を取り除くためにスケールドデイリースクラム（SDS） （デイリースクラムと同様の形式）を保持します。 SDSには、参加している各チームの少なくとも1人の代表者（通常はチームのスクラムマスター）が参加し、スクラムチームおよび製品所有者との調整を担当するスクラムオブスクラムマスター（SoSM）が主導します。

さらにスケーリングが必要な場合は、複数のSoSから作成されたスクラムのスクラム（SoSoS）があり、これも毎日会合します。 全体的なリーダーは、組織内でアジャイルを促進し、必要に応じてスクラムチームを調整し、障害を取り除くための最終的な手段となる責任を負うエグゼクティブアクションチーム（EAT）です。

プロダクトオーナーサイクル

プロダクトオーナーサイクルは、作成される製品またはサービスと、それをサポートするために必要なすべてのアクティビティに責任があります。 プロダクトオーナーはスクラムチームに割り当てられ、スクラムで定義されている役割のすべてのアクティビティを実行します。 プロダクトオーナーは、SoSチームにマップされるプロダクトオーナーチームにグループ化されます。 プロダクトオーナーチームは、メタスクラムで毎日会合し、チームの高レベルの戦略について話し合い、必要に応じて、対応するSoSMや他のプロダクトオーナーおよび利害関係者と調整します。メタスクラムは、チーフプロダクトオーナー（CPO）が主導します。

プロダクトオーナーは、組織の規模に応じてスクラムマスターサイクルと同様の方法でスケーリングし、会社全体の優先順位設定を担当するエグゼクティブメタスクラム（EMT）に到達します。

Scrum@Scaleの実装

Scrum @ Scaleの実装は、スケーラブルな参照モデル、つまり小規模なスクラムを使用するチームの小さなセットを作成することから始まります。 これは、アジャイルを妨げる組織のポリシーと開発慣行を解決するために行われます。 Scrum @ Scaleは、すべてのチームがこれらの組織全体の問題に直面する可能性が高く、その結果として生じる欲求不満がアジャイルの採用を妨げる可能性があるため、これらを早期に解決することを提案します。 参照モデルは、スクラムを他のチームや部門にスケーリングするためのパターンとして使用されます。

参照モデルを実装するには、最初にエグゼクティブアクションチーム（EAT）を作成する必要があります。 EATは、組織のポリシー変更を実装できるため、組織内で政治的および財政的に権限を与えられた個人で構成されます。

結論

プロジェクト管理の青写真のこの第2部では、大規模なプロジェクトまたはプログラムで使用される最も一般的なフレームワークのいくつかについて説明しました。 ウォーターフォールは依然として多くの組織で広く使用されており、プロセスの柔軟性がないために多くの欠点がありますが、プロジェクトが小さく、スコープが明確で変更されにくい場合は、このフレームワークを使用することが理にかなっている場合があります。

企業は、要件や目標が絶えず変化する、より大きく、より複雑なプロジェクトに遭遇するにつれて、よりアジャイルなアプローチに目を向けます。 アジャイルはもともと5〜9人の小さなチームを対象としていたため、さまざまなアジャイル実践者が、単一のチームから複数のチーム、企業全体にアジャイルを拡張するための複数の方法を用意しています。 この記事では、Disciplined Agile Delivery（DAD）、Scaled Agile Framework（SAFe）、Large Scale Scrum（LeSS）、およびScrum@Scaleについて説明しました。

プロジェクト管理の青写真の最後の部分では、PMP（PMBOK）やPRINCE2などのプロジェクト管理固有のフレームワークについて説明します。 また、「やるべき仕事」（JTBD）や「デザイン思考」などのイノベーションプロセスやフレームワークについても説明します。