Scaled Agile Framework ( SAFe ) は、 リーン およびアジャイルな プラクティスを企業が拡張できるようにするための組織およびワークフローパターンのセットです。[ 1 ] [ 2 ] DAD や S @S (Scrum@Scale)とともに、SAFe は、単一チームを超えて拡張する際に発生する問題に対処しようとするフレームワークの増加傾向にあるものの 1 つです。[ 3 ] [ 4 ]
SAFeは、多数のアジャイルチーム間での連携、コラボレーション、および成果物の納品を促進します。これは、アジャイルソフトウェア開発 、リーン製品開発 、システム思考 という3つの主要な知識体系を活用して、実践者によって、また実践者のために開発されました。[ 5 ]
スケーラブルアジャイルフレームワークの主な参照元は、当初、製品管理 (またはその他の利害関係者 )からガバナンス 、プログラム 、開発チームを経て 顧客 に至るまでの作業の流れの全体 像の開発でした。[ 6 ] [ 7 ] アジャイルコミュニティの他の人々の協力により、これは段階的に洗練され、2007年の書籍で初めて正式に記述されました。[ 8 ] このフレームワークは開発され、一般に共有され続けており、SAFeの導入、サポート、またはトレーニングを希望する人々を支援するアカデミーと認定制度があります。
2011年の最初のリリースから、6つのメジャーバージョンがリリースされ[ 9 ] 、最新バージョンであるバージョン6.0は2023年3月にリリースされました[ 10 ]。
SAFeはアジャイルプラクティスをスケールアップするための最も一般的なアプローチとして認識され続けている(30%で増加中)が、[ 11 ] [ 12 ] [ 13 ] 階層的 すぎ、柔軟性に欠けるという批判も受けている。[ 14 ] また、組織にアジャイル を採用しているという錯覚を与えながら、慣れ親しんだプロセスをそのまま維持しているという批判も受けている 。[ 15 ]
アジャイルの原則と実践をスケールアップする際の課題
より長期的な計画期間への対応 開発チームは通常、バックログを 2 ~ 3 回のイテレーション先まで洗練しますが、大規模な組織では、製品マーケティングチームは市場へのコミットメントと顧客との議論のために、さらに先の計画を立てる必要があります。[ 16 ] 彼らは多くの場合、非常に大まかな 12 ~ 18 か月のロードマップで作業し、その後、チームと協力して 3 か月分の作業を計画します。開発チームは、2 ~ 3 回のイテレーション先まで詳細な洗練を行い、次のイテレーションの詳細なタスク計画に取り掛かります。
抽象的な責任レベルでアジャイル性を維持する 開発チームには、アジャイルな働き方を定義するフレームワークが数多く存在する一方で、マネジメント層向けのアジャイルなアプローチを説明するものはほとんどありません。SAFeは、クロスファンクショナルチームなど、開発チームと同様の原則を、より抽象的なレベルの責任と計画(製品およびポートフォリオ)を担うグループにも提供します。
成果物の同期 アジャイルフレームワークは、開発チームが自律的に作業方法を設計できるように設計されています。SAFeは、数十または数百もの開発チームの規模になると、チームが完全に自己組織化することがますます混沌としてきていることを認識しています。[ 19 ] そのため、SAFeはこれにいくつかの制約を設けており、チームが同じ製品に取り組んでいる場合、成果物を同期させて一緒にリリースできるようにしていますが、これはSAFeが批判されている領域の1つです。[ 17 ] [ 18 ]
イノベーションと計画のための時間を確保する SAFe の計画サイクルでは、リリース後にイテレーションを追加して、チームがプラクティスを改善し、次の計画インクリメントの準備ができるようにすることを推奨しています。SAFe の以前のバージョンでは、これを強化 イテレーションとして設計し、つまり、リリース前に製品を安定または強化するようにしていました。これは、依存関係によっていくつかの事項を最後までテストできない大規模な統合環境で作業する際の複雑さを前提としていました。SAFe は、これがアジャイルやウォーターフォールに反する要素を表しているとして批判されましたが、13 週間になる 90 日のリーンインクリメントと一致しており、2 週間のスプリントを行う場合は、6 つのスプリントと 1 週間の計画または強化サイクルが必要になります。[ 20 ] これは、最近の SAFe のバージョンには含まれていません。
実装
SAFeの基本原則 SAFeの著者らによると、SAFeは既存のリーンおよびアジャイルの原則と観察から導き出された10の基本概念に基づいている。[ 21 ]
経済的な観点から見てみよう システム思考 を適用する変動性を想定する。選択肢を維持する。 迅速な統合学習サイクルで段階的に構築する 作業システムの客観的評価に基づいてマイルストーンを設定する 進行中の作業を可視化して制限し、バッチサイズを縮小し、キューの長さを管理する リズム(タイミング)を適用し、ドメイン横断的な計画と同期する 知識労働者の内発的動機を引き出す 意思決定を分散化する 価値を中心に組織する SAFeは、あまりにも多くの異なるプラクティスを統合しているとして批判されてきた。[ 22 ]
SAFeフレームワーク SAFe バージョン 5.1 には、エッセンシャル、ポートフォリオ、ラージ ソリューション、フルの 4 つの構成があります。[ 23 ]
Essential SAFeは最も基本的な構成です。これは、必要となる最も重要な要素を記述しており、フレームワークのメリットの大部分を提供することを目的としています。これには、チームレベルとプログラムレベル(アジャイルリリーストレイン、略してARTと呼ばれる)が含まれます。 大規模ソリューションSAFeでは、ポートフォリオの考慮なしに、複数のプログラム間での調整と同期が可能になります。SAFeの以前のバージョンでは、このレベルはバリューストリーム と呼ばれていました。 ポートフォリオSAFeには、戦略的方向性、投資資金調達、リーンガバナンスに関する懸念事項が含まれます。 フルSAFeは、他の3つのレベルを組み合わせたものです。
参考文献 ↑ Hayes, Will; Lapham, Mary Ann; Miller, Suzanne; Wrubel, Eileen; Capell, Peter (2016).国防総省プログラムのためのアジャイル手法のスケーリング 。ソフトウェアエンジニアリング研究所。CMU/SEI-2016-TN-005。 ↑ Athrow, Desiree (2015年1月29日)。 「継続的デリバリーがソフトウェア開発のスピードアップに重要な理由」 。TechRadar 。 2017年11月27日 取得 。 ↑ Linders, Ben (2015年1月22日). 「規律あるアジャイルデリバリーフレームワークによるアジャイルのスケーリング」 . InfoQ . 2017年11月27日 取得 。 ↑ van Haaster, K (2014). Agile in-the-large: Getting from Paradox to Paradigm . Charles Sturt University の未発表論文。 ↑ King, Michael (2017). 「SAFe コンセプトによる連邦政府顧客へのサービス提供」 (PDF) . Capability Counts Conference Proceedings . 2017 年 10 月 3 日の オリジナル (PDF) からアーカイブ済み。 ↑ ブリッジウォーター、エイドリアン(2013年8月7日)。 「真のアジャイルとは、全員がアジャイルであることだ」 。 ドクター・ドブス。 2017年11月27日 取得 。 ↑ Linders, Ben (2014年8月28日). 「アジャイル導入における計画による死」 . InfoQ . 2017年11月27日 取得 。 ↑ レフィングウェル、ディーン(2007)。 ソフトウェアの俊敏性を高める:大企業のためのベストプラクティス 。アディソン・ウェスリー 。ISBN 978-0321458193 。↑ 「Scaled Agile Frameworkについて - SAFeの簡単な歴史」 。Scaled Agile Inc. 2020年 8月12日 取得 。 ↑ 「SAFE 6.0 をご紹介します」 。Scaled Agile Inc. 2023年3月15日。 2023年3月16日 取得 。 ↑ 「第13回アジャイルの現状レポート」 。 アジャイルの現状調査 。CollabNet VersionOne。2019年。2019 年8月27日 取得 。 ↑ Link, P; Lewrick, M (2014年9月29日) 「イノベーションマネジメントの新分野におけるアジャイル手法」 (PDF) . Science to Business Marketing Conference . ↑ バプティスタ、ロベルト (2015 年 1 月 28 日)。 「専門分野のブラジルの専門家としての関心」 。コンピューターワールドブラジル 。 2015 年 1 月 28 日 に取得 。 ↑ シュワバー、ケン (2013-08-06). "unSAFe at any speed" . Telling It Like It Is . 2017-11-11 に取得。 ↑ ゴセルフ、ジェフ (2021-10-05). "SAFe はアジャイルではない" . 2023-05-21 に取得。 ↑ Eklund, U; Olsson, H; Strøm, N (2014). 大量生産組み込みシステムにおけるアジャイル開発のスケーリングに関する産業上の課題 . Springer International Publishing. ISBN 9783319143583 。1 2 Vaidya, A (2014). Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Adapting Scaling Agile Practices into the Enterprise . Excerpt from PNSQC 2014 Proceedings. pp. 8–9 . 1 2 Maximini, Dominik (2013年9月11日). 「SAFeに関する批判的見解 - Scrumorakel - ブログ」 . Scrum Oracle . 2017年11月27日 取得 。 ↑ Stafford, Jan (2013年12月9日). 「アジャイル開発の規模拡大には明確なプラクティスが必要だとコンサルタントが語る」 . SearchSoftwareQuality . 2017年11月27日 取得 。 ↑ キリック、ニール (2012 年 3 月 21 日)。 「大規模アジャイル フレームワークの恐怖」 。 アジャイル、スクラム、カンバン、リーン、そしてその間のすべて。2017 年 11 月 27 日 取得 。 ↑ 「SAFe Lean-Agile Principles」 。 2016年 2月19日 取得 。 ↑ エルサマディシー、アムル。 「SAFeは大規模アジャイル導入の難題を解決したのか?」 。 InfoQ 。 2017年11月11日 取得 。 ↑ ローズ、ダグ(2018)。 『エンタープライズ・アジリティ入門 』ジョン・ワイリー・アンド・サンズ。87 ~ 89ページ 。ISBN 9781119446095 。↑ 「認証」 . Scaled Agile . 2016年 2月19日 取得 。 ↑ https://www.thoughtworks.com/radar/techniques ↑ https://safedelusion.com/
さらに読む Dingsøyr, Torgeir; Falessi, David; Power, Ken (2019年2月)、「大規模アジャイル開発:次のフロンティア」、IEEE Software 、36 (2): 30–38 、arXiv : 1901.00324 、doi : 10.1109/MS.2018.2884884 、S2CID 57373760 Heusser, Matthew (2015年6月17日)、「スケーラブル・アジャイル・フレームワークの紹介」 、CIO 、 1~ 2ページ — この論文には、その手法の長所と短所のレビューが含まれており、完全なアジャイルシステムへの中間段階であると結論付けている。レフィングウェル、ディーン(2011)、『チーム、プログラム、および企業のためのリーン要件実践』 、アディソン・ウェスリー・プロフェッショナル、ISBN 978-0321635846 リンダース、ベン(2015年1月15日)、「スケーラブル・アジャイル・フレームワーク(SAFe)によるリーンおよびアジャイル・リーダーシップ」 、InfoQ