システムが自らを管理することができないから、人がシステムを管理しなければならない。放置すると、システムの構成要素は、利己的になり、互いに競争し、別々のプロフィットセンターになり、かくしてシステムを破壊してしまう …秘訣は、組織の目的に向け構成要素間で協力を図ることである。

エドワーズ・デミング

リズムを用いて開発し、需要に応じてリリースする

SAFeの教義

プログラムレベルの概要

企業および企業の利害関係者のニーズを満たし、より高い価値を創出するために、SAFeのプログラムレベルでは、一部のチームメンバーの労力が使われる。このレベルまでアジャイルを展開するには、価値チームタイムボックス(時間枠)という3つの主要な構成要素を拡大しなければならない。

価値 – システムの規模が大きくなって複雑になるとより高い抽象レベルでシステムの振る舞いを説明する必要があるが、それには追加の構成要素が必要である。

  • プログラムバックログにおけるシステムのフィーチャー
  • プログラムが目指しているビジョン
  • 時間と共にソリューションはどのように進化するかを示すロードマップ

チーム – 我々のシステム思考のアプローチには、より多くの多様な人とスキルが求められる。

  • プロダクト管理はより大きなビジョンを確立し、市場との連携を維持する
  • システムチームは、すべてのソフトウェア資産の統合と、(場合により)エンドツーエンドのユースケースやその他の必要なシステム品質(NFR)のテストを支援する
  • リリース管理チームは品質やリリース基準を定義および評価するための権限を持ち、実際のリリースをコーディネートする

タイムボックス(時間枠) – チームレベルでは2週間の反復がちょうど良いが、意味のあるシステムやプログラム、顧客やビジネスレベルのフィードバックにとっては、短かすぎる。それよりも、8~10週間前後の規則的なリズム間隔のプログラムインクリメント(PI)に合わせて計画策定を行うと便利であることが分かる。リリースはこれらの区切りで行うことができるし、市場のニーズに合わせることもできる。そのため、主に計画策定や、より高いレベルのプログラム評価、検査と適応のプログラム改善には、この長い時間枠を使用する。

詳細

アジャイルリリース列車が貨物を運ぶ

プログラムインクリメントと呼ばれる固定されたリズムで、アジャイルリリース列車価値のストリームを実現する。通常1つのプログラムインクリメントは8~12週で、複数の反復の時間枠からなる。これらの時間枠内で明確な価値のあるシステムのインクリメントが開発される。1つのリリース列車は5~15のアジャイルチームを保有し、完全にテストされた、システムレベルの動作するソフトウェアを納品するために必要な役割とインフラを含む。

リリース列車エンジニアは、チーフスクラムマスターの役割を勤め、列車が常に軌道から外れないように支援する。この役割はPIのリズムで開催するリリース計画策定セッションを促進する。アジャイルチームはリリース計画策定セッション中に主要なプログラム利害関係者と顔合わせし、次のインクリメントを計画する。メンバーは全員、物理的に、あるいは仮想的にこの1~2日間のセッションに参加する。このセッションでは、ビジョンを共有し、相互依存関係を解明し、次のPIのためにチームPI目標プログラムPI目標を確立する。

計画には、フィーチャーを納品するための確約が含まれている。これらのフィーチャーには、プロダクト管理者により重み付けされた最短作業から着手する(WSJF)という経済的優先順位付け方法を用いて、優先順位が付けられる。フィーチャーはビジョンロードマッププログラムエピックによって進められ、PIの区切りで提供される。フィーチャーはプログラムバックログ(予測される今後の作業に対する唯一決定的なリポジトリ)から取り出される。非機能要求(NFR)はパフォーマンス、セキュリティ、信頼性、可用性、スループットなど必要なシステム品質に関する統制を提供する。チームは計画を策定し、ビジネス責任者に説明して承認を得る。ビジネス責任者は列車に不可欠な役割で、列車が必要とする迅速な市場フィードバックを確実に得るという明確な責務を果たす。

その後、リリース列車は、PIのリズムで、完全にテストの済んだシステムレベルのソリューションインクリメントを作り上げる。リリースは、独立した関心事で、市場のニーズに応じて行われる。リズムを用いて開発し、需要に応じてリリースする。持続的に高いベロシティーで価値を納品できるように、アーキテクチャーフィーチャーによりアーキテクチャー滑走路を構築するための主要なメカニズムが提供される。列車は選択されたARTメトリックスを用いて、パフォーマンスを向上させる。

システムのコードを結合し、洗練し、妥当性検証するためには、リリース列車に専門的なスキルが必要である。これらの能力は、システムチームのほか、システムアーキテクトユーザーエクスペリエンス設計者などの主要な専門家、および共有リソースによって提供される。リリースは外部に対して確約され、リリース管理チームの管理下で行われる。このチームはマーケティング、営業、開発、品質、運営、インフラに関する権限を持つ。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley. 2011. (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

 Last updated 28 June, 2014 (WIP)

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.