SAFeとは何ですか？
アジャイルとは、多くの人が知っています。 さらに多くのIT関係者が用語を使用しています。 アジャイルについてもっと知りたい。
アジャイルという言葉を自信を持ってコミュニケーションや批判に使用している人がいるわけではありません。 チームまたは会社をより良い観点から示すために、たとえば、SCRUMとアジャイルの違いは何かを理解しています。 多くの場合、これら2つの異なる概念の間に等号を付けます。 しかし、それほど前ではなく、2015年にSAFeも登場しました。 それは何で、なぜ必要なのですか？
SCRUMの重要な長所と短所の1つは、コマンドの規定サイズがプロダクトオーナーを含む7 + -2（またはスクラムガイドからの3-9の最新データ）であると考えていることです。
もちろん、9人の高級で意欲的な専門家は多くの能力を備えていますが、最終的には多数の手、頭、目、脳を使って何かを構築する必要がある場合もあります。 チームを膨らませるのは悪いので、チームの数を増やす必要があり、ここでチーム間のコミュニケーションの問題が発生します。仕事とSCRUM自体の同期はこれらのタスクの解決策を提供しません。 SCRUMコマンド管理のレベルでSCRUMを使用する試みがあります（アジャイルマニフェストの著者の1人であるJeff Sutherlandがアドバイスしているように）、大規模なスクラムがあり、統制のとれたアジャイル配信がありますが、もっとたくさんありますが、SAFe-Scaled Agile Frameworkもあります。
SAFeは、5つ以上のSCRUMチームの特定のプロジェクトまたは関連プロジェクトの作業の調整を必要とする企業管理フレームワークです。 つまり これはSCRUMの上部構造であり、100人以上のチームを管理できます。
恩恵？
もちろん、まず第一に、方法論は、それを販売し、トレーニングに従事する人々に必要です。 Dave Thomas（アジャイルマニフェストの著者のもう一人）は、このテーマについて非常によく話していました。GOTO2015でのアジャイルのプレゼンテーションで、彼は死んでいます
第二に、プログラム管理部門。 以前にプロジェクト管理に関与していた人々は、PMP認定を取得し、ガントチャートを作成し、ハードソフト管理の概念を実装しました（管理者にはソフトサイド、実行者にはハードサイド）。 実際のところ、典型的なSCRUMには機能がありませんが、SAFeではそうです。 同じことがあらゆる種類の建築家に当てはまります。 SCRUMにはSAFeには機能がありません-キャリアパスがあります。
さらに、管理者が膨大な工数を費やして大規模なプロジェクトに取り組み、（時には客観的な理由で）これらのプロジェクトを独立させることができないビジネスオーナーにとっても有益です。
平均より低い資格を持つ多くの開発者 多くの場合、何かをするためには、最も経験豊富でやる気のある専門家よりも指数関数的に大きくする必要があります。
業界全体。 なぜなら 開発者の数は5年ごとに2倍になります（ ボブおじさんのプログラミングの未来を参照）。その結果、 常に少なくとも半分の開発者が5年未満の実務経験を持っています。 傾向が変わらないが、明らかに変わらない場合、作業機能、参加者とプロセス全体の相互作用のメカニズムを規定および形式化するプロセスが必要です。
エッセンス
SAFeは、さまざまなアジャイル技術のレイヤーケーキです。 一番下のレベルには、従来の2〜3週間のスプリントを備えたほぼ従来のスクラムがあり、プロダクトオーナーを含む3〜9人のチームです。 すべての典型的な儀式は、毎日の計画から立ち直りまで、そして再会での報告会で終わります。 1つの重要な違いがありますが。 このコマンドは、完全に機能する独立したモジュールではなくなります。 そして、スプリントは完全なライフサイクルを持つ独立した期間ではなくなります。 スプリントは、通常5つのスプリントで構成されるプログラムインクリメントで結合されます。 つまり クラシックSCRUMでクライアントが好きなものを構築しなかった場合、次のスプリントでコース修正を行い、SAFeではプログラムインクリメントの終わりまで最悪の場合、次の4スプリントまでエッジに向かって進みます（もちろん誇張します）。
次のレベルでは、列車があります-いわゆるアジャイルリリース列車です。 5つのスプリントセグメントを管理するための新しい機能があります。システムアーキテクト（アーキテクチャを所有するチーム-つまり、チームではなくなります）、プロダクトマネージャー（プロダクトを所有するのではなくプロダクトを管理する人、後者はアドバイスのためにPMに行きます）およびRTE -滝の遠い世界からの同じPMP。 ここでは、特にボード、優先順位の割り当て方法、および一般的にチームの履歴パフォーマンス（速度）を測定し、時間間隔の終わりに構築されるものを予測するという原則と、すでに修正された機能の期限を割り当てるアプローチとは対照的に、カンバンのいくつかの開発が適用されます（スコープ）。 革新の1つは、最後のスプリント5が組織的であると宣言され、その間に大規模な会議が開催され（すべてのチームが一緒に-これは100人以上です）、技術的負債の分析が実行され、アーキテクチャの開発計画が作成され、すべてのチームの作業が同期されることです。
列車のレベルを超えて、部門、ディレクター、クライアントの間で調整を行っています。 リーンアジャイルからはさらに多くの借用がありますが、かんばんからの同じツールが保持されます。 これは、変化の経済的実現可能性の分析です。 理想的には、すべての変更は予備的な分析を経て、今後の変更に関する測定可能な仮説が提示されます（たとえば、データセンターからクラウドにオンラインストアを作成し、季節営業のピーク時に容量を急速に増やすと、トランザクション数を10％増やすことができます）、この仮説が確認されますいや 10億ドル未満の企業の場合、これが最後のフロアになる可能性があります。 ここで12〜36か月の作業計画が作成されます（品質、数量などの5年間の計画）
大規模システムのレベルを超えるものは、ポートフォリオ管理です。 資金はビジネスのさまざまな分野に割り当てられます。 リーンポートフォリオ管理が使用され、会社の開発戦略を使用して、収益を得ることができる領域が選択されます。 ここでは、他の企業の買収または合併について決定が行われます。 新しいビジネスラインの作成、古いビジネスラインの閉鎖。 予算は定期的に調整され、再割り当てされます（四半期または年次計画とは対照的）。 ポートフォリオの各コンポーネントについて、多かれ少なかれ標準化されたメトリックのセットが確立され、すべてに従ってそれらが評価されます。 前の3つのレベルと同様に、2週間ごと（通常）の同期のための特別な儀式があります-ステータスと重要なインジケータの交換があります。
戦略全体が主導します。 定義方法-フレームワークは記述しません。
長所
- 非常に多くの非常に優れたツール（WSJF、Kanban、Gembaなど）
- コードの記述（TDDで規定）から静的スキャンおよびCI / CDおよび機能トグルの実行までのSDLCの正式かつ規定された手順。 各プラクティスが良いかどうかは別の問題ですが、少なくとも計画があり、誰もがそれに従います。
- プロセスを理解、説明、実装できます。
- このプロセスのフレームワーク内の各人は、かなり厳密に定義された関数を受け取ります。
- 会社で働く人々の会社の透明性を高めます。
短所
- 現実の期待の不一致に対応するのに十分な時間
- 莫大なお金とお金がコミュニケーションと会議に費やされています
- 多くの場合、フレームワーク内で推奨されるソリューションは時代遅れです
実装するかどうか 選択肢があれば、いいえ、部門とプロジェクト間の依存関係を減らす方が良いと思います。 選択の余地がなく、巨大なプロジェクトを管理する必要がある場合は、かなり可能です。