スケーリングされたアジャイルフレームワーク

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

スケーリングされたアジャイルフレームワークSAFe )は、リーンアジャイルなプラクティスをスケーリング する際に企業をガイドすることを目的とした一連の組織およびワークフローパターンです。[1] [2]大規模スクラム(LeSS)、ディシプリンドアジャイルデリバリー(DAD)、およびNexusとともに、SAFeは、単一のチームを超えてスケ​​ーリングするときに発生する問題に対処しようとするフレームワークの数が増えています。[3] [4] SAFeは、著作権および登録商標を保持するScaled Agile、Inc。によって無料で提供されています。[5]

SAFeは、多数のアジャイルチーム間での調整、コラボレーション、および配信を促進します。これは、アジャイルソフトウェア開発無駄のない製品開発システム思考という3つの主要な知識を活用して、実践者によって開発されました[6]

スケーリングされたアジャイルフレームワークの主な参考資料は、元々、製品管理(または他の利害関係者)からガバナンスプログラム、および開発チームを経て顧客に至るまでの作業の全体像の開発でした。[7] [8]アジャイルコミュニティの他の人々の協力により、これは徐々に洗練され、2007年の本で最初に正式に説明されました。[9]フレームワークは引き続き開発され、公に共有されています。SAFeの採用について他者を実装、サポート、またはトレーニングしようとする人々をサポートするアカデミーと認定スキームを備えています。

2011年の最初のリリースから、5つのメジャーバージョンがリリースされ[10]、最新版のバージョン5.1は2021年2月にリリースされました。[11]

SAFeは、アジャイルプラクティスをスケーリングするための最も一般的なアプローチとして認識され続けていますが(30%で成長)、[12] [13] [必要なページ][14]階層的すぎ、柔軟性がないという批判も受けています。[15]

アジャイルの原則と実践をスケーリングする際の課題

より長い計画期間への対処

開発チームは通常、バックログを最大2〜3回先に調整しますが、大規模な組織では、製品マーケティングチームは、市場への取り組みと顧客との話し合いについて、さらに前もって計画する必要があります。[16]彼らは多くの場合、非常に高いレベルの12〜18か月のロードマップで作業し、その後3か月の作業についてチームと協力して計画します。[17]開発チームは、2〜3回の反復で詳細な改良を行い、次の反復の詳細なタスク計画のみを実行します。[18]

責任の抽象的なレベルでアジャイルを維持する

開発チームには、アジャイルのあり方を定義するフレームワークがいくつかありますが、管理のためにこれを説明するものはほとんどありません。SAFeは、クロスファンクショナルチームなど、同じ原則の多くを、より抽象的なレベルの責任と計画(製品とポートフォリオ)を処理するグループに提供します。[19] SAFeは、あまりにも多くの異なる慣行を集約していることでも批判されています。[20]

委任された権限の処理

スクラムでは、製品の所有者は、開発決定の投資収益率や市場でのパフォーマンスなど、製品のライフサイクル全体に責任を持つことが期待されています。大規模な開発では、組織は、製品マネージャーによって提供されるような、複数のチームバックログにわたるビューを望んでいます[21] SAFeは、製品所有者の役割が製品管理にあると想定していますが、それでも、製品所有者を開発組織に分離したことで批判されています。[22]

成果物の同期

アジャイルフレームワークは、開発チームが自律的であり、それらがどのように機能するかを自由に設計できるように設計されています。SAFeは、数十または数百の開発チームの規模で、チームが完全に自己組織化することがますます混沌としていることを認めています。[23]したがって、これにはいくつかの制約があり、チームが同じ製品に取り組んでいる場合、SAFeが批判されている分野の1つですが、成果物をより適切に同期して一緒にリリースできます。[21] [22]

イノベーションと計画のための時間を確保する

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

実装

SAFeの基本原則

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

  1. 経済的な見方をする
  2. システム思考を適用する
  3. 変動性を想定します。オプションを保持
  4. 高速な統合学習サイクルで段階的に構築する
  5. 作業システムの客観的評価に基づくマイルストーン
  6. 仕掛品の視覚化と制限、バッチサイズの削減、およびキューの長さの管理
  7. ケイデンス(タイミング)を適用し、クロスドメイン計画と同期します
  8. 知識労働者の本質的な動機を解き放つ
  9. 意思決定を分散化する
  10. 価値を中心に整理する

SAFeフレームワーク

SAFeバージョン5.1には、エッセンシャル、ポートフォリオ、大規模ソリューション、およびフルの4つの構成があります。[26]

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

認定

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

も参照してください

参考文献

  1. ^ ヘイズ、ウィル; ラファム、メアリーアン; ミラー、スザンヌ; Wrubel、Eileen; カペル、ピーター(2016)。国防総省プログラムのアジャイル手法のスケーリングソフトウェア工学研究所。CMU / SEI-2016-TN-005。
  2. ^ Athrow、Desiree(2015年1月29日)。「継続的デリバリーがソフトウェア開発をスピードアップするための鍵となる理由」TechRadar 2017年11月27日取得
  3. ^ Linders、Ben(2015年1月22日)。「規律あるアジャイルデリバリーフレームワークによるアジャイルのスケーリング」InfoQ 2017年11月27日取得
  4. ^ van Haaster、K(2014)。アジャイルインザラージ:パラドックスからパラダイムへの移行チャールズスタート大学からの未発表の論文。
  5. ^ 「許可FAQ」スケーリングされたアジャイル2018年7月13日取得
  6. ^ キング、マイケル(2017)。「SAFeの概念で連邦政府の顧客にサービスを提供する」(PDF)機能は会議議事録をカウントします。
  7. ^ ブリッジウォーター、エイドリアン(2013年8月7日)。「本当のアジャイルとは、誰もがアジャイルであることを意味します」ドブ博士の2017年11月27日取得
  8. ^ Linders、Ben(2014年8月28日)。「アジャイル採用の計画による死」InfoQ 2017年11月27日取得
  9. ^ レフィンウェル、ディーン(2007)。ソフトウェアの俊敏性のスケーリング:大企業向けのベストプラクティスアディソン-ウェスリー。ISBN 978-0321458193
  10. ^ 「スケーリングされたアジャイルフレームワークについて-SAFeの簡単な歴史」Scaled AgileInc 2020年8月12日取得
  11. ^ 「SAFe5.1全体像の新機能」Scaled AgileInc 2020-02-10を取得
  12. ^ 「アジャイルレポートの第13回年次状態」アジャイル調査の状態CollabNetVersionOne。2019 2019年8月27日取得
  13. ^ リンク、P; ルーリック、M(2014年9月29日)。「イノベーションマネジメントの新しい分野におけるアジャイル手法」(PDF)科学からビジネスへのマーケティング会議
  14. ^ バプティスタ、ロベルト(2015年1月28日)。"Profissionais brasileiros eo interesseportreinamentosdeespecialização"Computerworldブラジル2015年1月28日取得
  15. ^ Schwaber、ケン(2013-08-06)。「どんな速度でもunSAFe」それがそうであるようにそれを伝える2017年11月11日取得
  16. ^ Eklund、U; オルソン、H; Strøm、N(2014)。大量生産された組み込みシステムでアジャイルをスケーリングするという産業上の課題アジャイルメソッド。大規模な開発、リファクタリング、テスト、および見積もりスプリンガーインターナショナルパブリッシング。ISBN 9783319143583
  17. ^ Heusser、マット(2014年9月23日)。「複数のチームのためのアジャイルテスト方法」SearchSoftwareQuality 2017年11月27日取得
  18. ^ Stettina、C; Horz、J(2015)。「アジャイルポートフォリオ管理:使用中の実践に関する経験的視点」。プロジェクトマネジメントの国際ジャーナル33(1):140–152。土井10.1016 /j.ijproman.2014.03.008
  19. ^ Laanti、M(2014)。スケーリングされたアジャイルの特性と原則XP2014ワークショップスプリンガーインターナショナルパブリッシング。
  20. ^ Elssamadisy、Amr。「SAFeは大きなアジャイル採用ナットをクラックしましたか?」InfoQ 2017年11月11日取得
  21. ^ a b Vaidya、A(2014)。DADは最もよく知っていますか、LeSSを実行する方が良いですか、それとも単にSAFeになる方が良いですか?スケーリングアジャイルプラクティスをエンタープライズに適応させるPNSQC2014議事録からの抜粋。pp。8–9。
  22. ^ a b Maximini、Dominik(2013年9月11日)。「SAFeに関する批判的見解-Scrumorakel-ブログ」スクラムオラクル2017年11月27日取得
  23. ^ スタッフォード、1月(2013年12月9日)。「アジャイル開発のスケーリングには、定義されたプラクティスが必要です」とコンサルタントは言います。SearchSoftwareQuality 2017年11月27日取得
  24. ^ キリック、ニール(2012年3月21日)。「スケーリングされたアジャイルフレームワークの恐怖」アジャイル、スクラム、かんばん、リーン、およびその間にあるすべてのもの2017年11月27日取得
  25. ^ 「SAFeリーン-アジャイル原則」2016年2月19日取得
  26. ^ ローズ、ダグ(2018)。ダミーのためのエンタープライズアジリティジョン・ワイリー&サンズ。pp。87–89。ISBN 9781119446095
  27. ^ 「認証」スケーリングされたアジャイル2016年2月19日取得

さらに読む

外部リンク