スケールアジャイルフレームワーク

スケールドアジャイルフレームワーク（SAFe ）は、リーンとアジャイルのプラクティスを企業がスケールさせる ための組織とワークフローのパターンのセットです。[ 1 ] [ 2 ]ディシプリンドアジャイルデリバリー（DAD）やS@S（Scrum@Scale）とともに、SAFeは、単一チームを超えてスケ​​ールする際に発生する問題に対処しようとする、増えつつあるフレームワークの1つです。[ 3 ] [ 4 ]

SAFeは、多数のアジャイルチーム間の連携、コラボレーション、そしてデリバリーを促進します。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は、クロスファンクショナルチームなど、多くの同じ原則を、より抽象的なレベルの責任と計画（製品とポートフォリオ）を担当するグループに提供します。

委任された権限の扱い

Scrumでは、プロダクトオーナーは開発決定の投資収益率や市場でのパフォーマンスなど、製品ライフサイクル全体の責任を負うことが期待されています。大規模な開発では、組織はプロダクトマネージャーが提供するような、複数チームのバックログを横断した視点を必要とします。[ 17 ] SAFeではプロダクトオーナーの役割はプロダクトマネジメントにあると想定されていますが、それでもプロダクトオーナーを開発組織に分離しているという批判を受けています。[ 18 ]

成果物の同期

アジャイルフレームワークは、開発チームが自律的に作業方法を自由に設計できるように設計されています。SAFeは、数十または数百の開発チーム規模になると、チームが完全に自己組織化することがますます困難になることを認識しています。[ 19 ]そのため、SAFeはこれにいくつかの制約を設け、チームが同じ製品に取り組んでいる場合、成果物をより同期させて一緒にリリースできるようにします。ただし、この点はSAFeが批判されてきた点の1つです。[ 17 ] [ 18 ]

革新と計画のための時間を確保する

SAFe の計画サイクルでは、リリース後に追加のイテレーションを含めることが推奨されており、これによりチームはプラクティスを改善し、次の計画増分に備えることができます。SAFe の以前の版では、これを強化イテレーション、つまりリリース前に製品を安定化または強化するように設計されていました。これは、依存関係によっていくつかの事項が最後までテストされないような大規模な統合環境での作業の複雑さを前提としていました。SAFe は、これが反アジャイルまたはウォーターフォールの要素を表すとして批判されましたが、13週間になるリーンの 90 日増分と一致しており、2週間のスプリントを実行する場合は、6 つのスプリントに加えて 1 週間の計画または強化サイクルが必要になります。[ 20 ]これは SAFe の最近の版には含まれていません。

実装

SAFeの基本原則

著者によると、SAFeは既存のリーンとアジャイルの原則と観察から導き出された10の基本概念に基づいています。[ 21 ]

  1. 経済的な視点を持つ
  2. システム思考を適用する
  3. 変動性を想定し、選択肢を確保する
  4. 高速な統合学習サイクルで段階的に構築
  5. 稼働中のシステムの客観的な評価に基づいてマイルストーンを設定する
  6. 進行中の作業を視覚化して制限し、バッチ サイズを削減し、キューの長さを管理します。
  7. リズム（タイミング）を適用し、クロスドメイン計画と同期する
  8. 知識労働者の内発的動機を引き出す
  9. 意思決定を分散化する
  10. 価値を中心に組織化する

SAFeはあまりにも多くの異なる実践を集約していると批判されてきた。[ 22 ]

SAFeフレームワーク

SAFeバージョン5.1には、必須、ポートフォリオ、大規模ソリューション、フルの4つの構成があります。[ 23 ]

  • Essential SAFeは最も基本的な構成です。必要不可欠な要素を記述し、フレームワークのメリットの大部分を提供することを目的としています。チームレベルとプログラムレベル（アジャイルリリーストレイン、またはARTと呼ばれます）が含まれます。
  • 大規模ソリューションSAFeは、ポートフォリオを考慮せずに複数のプログラム間の調整と同期を可能にします。SAFeの以前のバージョンでは、このレベルはバリューストリームと呼ばれていました。
  • ポートフォリオ SAFe には、戦略的方向性、投資資金、無駄のないガバナンスに関する懸念事項が含まれます。
  • Full SAFe は他の 3 つのレベルを組み合わせます。

認定資格

Scaled Agileは、さまざまな分野と知識レベルをカバーする認定資格を提供しています。 [ 24 ]

参照

参考文献

  1. ^ Hayes, Will; Lapham, Mary Ann; Miller, Suzanne; Wrubel, Eileen; Capell, Peter (2016).国防総省プログラムにおけるアジャイル手法のスケーリング. ソフトウェアエンジニアリング研究所. CMU/SEI-2016-TN-005.
  2. ^ Athrow, Desiree (2015年1月29日). 「なぜ継続的デリバリーがソフトウェア開発のスピードアップの鍵となるのか」 . TechRadar . 2017年11月27日閲覧。
  3. ^ Linders, Ben (2015年1月22日). 「Disciplined Agile Delivery Frameworkによるアジャイルのスケーリング」 . InfoQ . 2017年11月27日閲覧。
  4. ^ van Haaster, K (2014). Agile in-the-large: Getting from Paradox to Paradigm . Charles Sturt University からの未発表論文。
  5. ^ King, Michael (2017). 「SAFeコンセプトによる連邦政府顧客へのサービス提供」(PDF) . Capability Counts Conference Proceedings . 2017年10月3日時点のオリジナル(PDF)からのアーカイブ。
  6. ^ブリッジウォーター、エイドリアン（2013年8月7日）「真のアジャイルとは、誰もがアジャイルであることだ」ドクター・ドブズ誌。 2017年11月27日閲覧。
  7. ^ Linders, Ben (2014年8月28日). 「アジャイル導入における計画による死」 . InfoQ . 2017年11月27日閲覧。
  8. ^ Leffingwell, Dean (2007).ソフトウェア・アジリティのスケーリング：大企業向けベストプラクティス. Addison-Wesley. ISBN 978-0321458193。
  9. ^ 「Scaled Agile Frameworkについて - SAFeの簡単な歴史」 Scaled Agile Inc. 2020年8月12日閲覧。
  10. ^ 「SAFE 6.0にようこそ」 Scaled Agile Inc. 2023年3月15日. 2023年3月16日閲覧。
  11. ^ 「第13回年次アジャイル状況レポート」。アジャイル状況調査。CollabNet VersionOne。2019年。2019年8月27日閲覧。
  12. ^ Link, P; Lewrick, M (2014年9月29日). 「イノベーションマネジメントの新たな領域におけるアジャイル手法」(PDF) . Science to Business Marketing Conference .
  13. ^バプティスタ、ロベルト (2015 年 1 月 28 日)。「専門分野のブラジルの専門家としての関心」。コンピューターワールドブラジル。2015 年1 月 28 日に取得。
  14. ^ Schwaber, Ken (2013年8月6日). 「unSAFe at any speed」 . Telling It Like It Is . 2017年11月11日閲覧。
  15. ^ Gothelf, Jeff (2021年10月5日). 「SAFeはアジャイルではない」 . 2023年5月21日閲覧。
  16. ^ Eklund, U; Olsson, H; Strøm, N (2014).大量生産された組み込みシステムにおけるアジャイルのスケーリングに関する産業的課題. Springer International Publishing. ISBN 9783319143583。{{cite book}}:|work=無視されました (ヘルプ)
  17. ^ a b Vaidya, A (2014). 「DADは最善を尽くすのか？LeSSの方が良いのか、それともSAFeだけが良いのか？企業におけるアジャイル・プラクティスのスケーリングへの適応」 PNSQC 2014 Proceedingsからの抜粋。pp.  8– 9.
  18. ^ a b Maximini, Dominik (2013年9月11日). 「SAFeに関する批判的見解 - Scrumorakel - ブログ」 . Scrum Oracle . 2017年11月27日閲覧。
  19. ^ Stafford, Jan (2013年12月9日). 「アジャイル開発のスケーリングには明確なプラクティスが必要だとコンサルタントが語る」 . SearchSoftwareQuality . 2017年11月27日閲覧。
  20. ^キリック、ニール（2012年3月21日）「スケールド・アジャイル・フレームワークの恐怖」。アジャイル、スクラム、カンバン、リーン、そしてその間にあるすべて。2017年11月27日閲覧。
  21. ^ 「SAFe Lean-Agile Principles」 。 2016年2月19日閲覧。
  22. ^ Elssamadisy, Amr. 「SAFeは大規模なアジャイル導入の課題を解決したか？」 InfoQ . 2017年11月11日閲覧。
  23. ^ローズ、ダグ（2018年）『エンタープライズ・アジリティ・フォー・ダミーズ』ジョン・ワイリー・アンド・サンズ、 87～ 89頁 。ISBN 9781119446095。
  24. ^ 「認定」 Scaled Agile . 2016年2月19日閲覧。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Scaled_agile_framework&oldid=1291774960」より取得