ING、TomTom、T-Mobile、IBMなどの多くのグローバル企業は、SAFeに長い間関心を持っています。 Swisscom、SwissPost、Kuoni、Credit Suisseなどのスイス企業も、認定された外部コンサルタントを通じてSAFeを実装しています。
未解決の問題
Scaled Agile Framework（SAFe）が急速に普及した理由の1つは、大企業のプログラムマネージャーとVPの目でソフトウェア開発を管理するための柔軟なアプローチに苦しんでいる大失敗です。 アジャイルソフトウェア開発の価値と原則への条件付きのコンプライアンスにもかかわらず、大多数はそれにもかかわらず、製品の納期と数百または数千人の研究開発部門に「展開」できる実証済みのアプローチを予測しようとしました。
中小企業は、重複する役割や他の形式のプロセス逸脱の贅沢を許容できますが、企業規模の企業は、明確な構造と効率的な責任配分モデルに依存しています。
これは、プロジェクトのポートフォリオを管理するソリューション（PRINCE2のようなこのタスクに最適ではない「旧式」アプローチに基づく）とスクラムを介したチーム内の動的な開発を組み合わせる必要がある企業に特に関連します。
それぞれが5〜10の主要な利害関係者を含む20を超える製品のポートフォリオを、7〜10のチームによって4か国で開発する必要があると想像してください。 このレベルのタスクは、非常にベテランのCTOまたは開発のVPでさえも一生懸命働きます。
残念ながら、クライアントとのコミュニケーションで会社がチームレベルでアジャイルを成功裏に導入したとよく耳にしますが、経営陣は製品ポートフォリオレベルで古いドグマについて考え続け、潜在的な能力を有効に活用できないため、会社の根本的な変化はありませんビジネスの柔軟性。
SAFe教育プログラム
SAFeの恩恵と大企業にとってのその主な利点は、明確で責任の割り当てモデルと組み合わせたシンプルで透明な組織構造をもたらすことです。 どちらのアイデアもRUPに根ざしています（SAFeの著者であるDean Leffingwellは、Rational SoftwareでRUPの開発と商業化を担当しました）。
SAFeモデルは、あらゆる企業をポートフォリオ、プログラム、およびチームの3つのレベルに分割します。SAFeの管理モデルは、2つのカテゴリで表されます。
1）製品の垂直の「コンテンツ」（会社がリリースする）。製品マネージャー、UX、およびアーキテクトのチームによって表されます。
2）プロジェクトおよびプログラム管理者の垂直的な「供給」（会社が製品を市場にリリースする方法）。
管理は、各垂直の各レベルで唯一の責任者によって提供されます。 コンテンツと配信、およびそれらの間の定期的な同期が必要です。 この原則は、各レベルの供給サイクルの絶え間ない同期が必要な大規模な組織の基本です。
アジャイルプログラムを開始することがまさにその目的です
企業は、ソフトウェア製品、プラットフォーム、またはサービスを作成するプログラムを立ち上げます。 したがって、さまざまなタイプのプロジェクトオフィス（PMO）は、プログラムの実行を最も効率的な方法でサポートするように設計されています。
スクラムのようなアプローチは、あらゆる種類のPMOに「苦労」をもたらしました。 従来、ポートフォリオレベルで形成されたビジネスイニシアチブは、個別の一時的なプロジェクトチームが作成されるプロジェクトの形で表現されていました。 ビジネスの別のイニシアチブが必要なプロジェクトの継続的な作成は、組織の顕著なコンポーネント構造で行われます（つまり、機能、技術層、またはシステムコンポーネントを担当するチームがあります）。
スクラムは、固定チームのレベルでクロス機能を達成するためにPMOマネージャーを「要求」し始めましたが、その構成は6〜12か月間変更されていません。 これは、アジャイルレールへの移行において多くの企業にとって障害となっています。
SAFeは、スクラムモデルをプログラム実装レベルに移行することにより、この問題に対するエレガントなソリューションを提供します。 仕組みを見てみましょう。
開発者、QA、DevOpsがプラットフォームの特定のコンポーネントで作業している5〜7人のグループを想像してください（または、ソフトウェア製品の個々の機能に取り組んでいるチーム：機能チームを想像してください）。 プラットフォームに同様の方法で編成された別の5〜7のコンポーネントチームがあるとします。 すべてのチームは2週間のスプリントを使用して同期して作業し、各スプリントの後に機能する機能を非常に予想どおりに提供します。 ここで、各チームが「スーパーマン」であると想像してください。 すべての「スーパーマン」を1つのチームにまとめると、プラットフォーム全体をカバーするチームができます。 しかし、「スーパーマンチーム」のアジャイル開発プロセスを開始し、大規模にするとどうなるでしょうか？各「スーパーマン」は2週間ごとに配信するため、反復（サイクル）の期間は2〜3か月になります
製品マネージャー（別名スーパープロダクトオーナー）と供給マネージャー（別名スーパースクラムマスター）をチームに割り当てましょう。 スーパーマンのチームが計画を立て、反復の開始時に責任を取り、「スーパーマン」間の関係を定義および解決します。 「スーパーマンチーム」の同期には、毎週（または隔週）の会議（スクラムオブスクラム）が不可欠です。 2〜3か月の反復の終わりに、チームは作業の結果を実証し、将来の作業を遡及的に改善します。 そして、もう一度戻って、個々の「スーパーマン」をコンポーネントチームまたは別のソフトウェア機能に取り組んでいるチームに変換しましょう。 このようなトリッキーな方法で、アジャイルスタイルのソフトウェア管理レイヤーを作成しました。
Ghm、すみませんが、建築はどうですか？
既にご存じのとおり、ビジネス機能を開発するためのアジャイルアプローチは、企業全体でうまく機能します。 しかし、新しい機能を作成するために新しいアーキテクチャまたは「リファクタリング」を必要とする多くの廃止されたモジュールまたはコンポーネントを含む複雑なソリューション（原則として現実のもの）がある場合はどうでしょうか。
アジャイルの原則の初期の支持者は時として行き過ぎて、将来の使用のために将来の機能のためのアーキテクチャを開発する必要性を否定し、進化的な設計原則のみに依存しました。 このアプローチは、「新興企業」や中規模の企業には有効かもしれませんが、多くの場合、チームの数が多く、チーム間の同期が必要なため、大規模に失敗します。
上記のすべてを考慮して、SAFeはArchitecture runwayと呼ばれる概念を提供します。 実際、このアプローチには魔法はありません。単純なロジックに基づいています。 アーキテクチャを担当するチームは、他のチームよりも少なくとも2〜3か月サイクル早く動作し、機能/コンポーネントチームのアーキテクチャ上の予備を作成します。これにより、後続のサイクルでビジネス機能を効果的に開発できます。
このアプローチは、アーキテクチャチームをコンテンツ管理部門と結び付け、企業に常に存在するジレンマを解決します。アーキテクチャチームが報告するのは、プロダクトマネージャーまたはプロダクトデリバリーマネージャーですか。
まとめ
この記事は当初の予定よりも長いことが判明したため、Scaled Agile Framework（SAFe）の主要なアイデアの簡単な要約で締めくくりました。
- 責任の2つの分野（コンテンツと配信）の明確な分離
- チームレベル、プログラムレベル（複数のチームの共同作業）、ポートフォリオレベル（製品/チームを発行するグローバルなイニシアチブ）の明確な分離
- プログラムチームによる2〜3か月サイクルの共同計画
- 機能の調査のためのアーキテクチャチャネルの事前割り当て。
期待される結果
上記の側面は、アジャイルトラックを利用したり、既に完了した移行から新しい役割と用語のセット以上のものを取得したい大企業のニーズの完全なリストからはほど遠いものです。
SAFeの著者は、顧客を引用して以下の結果について話します。
- 製品の市場投入までの期間を27週間短縮
- 顧客満足度が25％向上
- 製品開発コストの50％削減
私たちの経験は、SAFeアプローチの原則を実装することにより、より控えめでありながら、多くの顧客が製品の市場投入までの時間を20％短縮することについて語り、プロセスの透明性と管理性の向上、従業員の満足度の向上にも注目しています。
他のコンサルティング会社や民間コンサルタントとの多くの議論の後、SAFeの実装から同様の結果が得られました。 多くのパートナーは、SAFeは「特効薬」ではないという意見を共有していますが、ソフトウェア開発のさまざまな分野で多くの問題を解決できます。 この見解は、SAFe実装の成功を例示し、業界標準になる可能性のある大規模な組織にアジャイルを実装するためのアプローチの1つとしてSAFeを検討させる国際企業の急速に増加するリストによってサポートされています。