現在の開発プロセスは情報を大きなまとまりで非同期に通常届ける。フローに基づくプロセスは、情報を一定のリズムで小さなまとまりで届ける。リズムは、処理コストを下げ、小さなまとまりをより経済的に好ましいものにする。

足踏みを揃える原則: 局所の卓越より、全体の足踏みを揃えることによってより多くの価値を創出する。

—Don Reinertsen

アジャイルリリース列車の概要

SAFeでは、アジャイルリリース列車(ART)はプログラムレベルで価値を納品する仕組みである。ARTは通常50-125人からなり、複数のアジャイルチームに基づく長期に渡り存続するチームである。企業の大きな価値のストリーム、すなわち、最適化された開発と納品戦略によりもっとも優れた経済メリットを創出する長く存続する価値フローの周りに、リリース列車が組織化される。ARTによって、チームが共通のミッションに対し足踏みを揃え、8-12週の計画策定、開発と振り返りのリズムを用いて、継続的なプロダクト開発フローを実装する。各列車は、継続的に2週間の単位で価値がある、評価ができるシステムレベルのソリューションを定義、構築とテストするために、必要な専用リソースを持つ。

詳細

説明

アジャイルリリース列車は複数のアジャイルチームに基づくチームであり、その周りにSAFeプログラムレベルのチーム、役割と作業が組織化されている。ARTにより、1つの価値のストリームに継続的に一連な価値をインクリメンタル的なリリースで提供する。ソフトウェア資産の開発は標準的なリズムで行われるが、列車は随時にリリースできる。
これは「リリース」のページや「リズムに合わせて開発、要望に合わせてリリース」のページで説明される。

開発のリズムについて、ビッグピクチャー(全体像)では、リリース計画策定セッションと、それに続く4回の開発反復と、最後となる1回のイノベーション・計画策定(IP)反復の期間を図示している。SAFeはこの期間をプログラムインクリメント(PI)と呼ぶ。

特別注意:このパターンは示唆的であるが、任意である。PIに何回の反復があるべきか、IPスプリントにどれくらいの時間が必要か、ということに関する確定したルールはない。多くの企業はこのリズムを選択し、ソフトウェアをリリースするが、実際にいつリリースするかはこのリズムに依存していないし、その意思決定が各企業の判断に委ねられている。

アジャイルリリース列車の原則

我々は、以下の概念を伝達するため「列車」のメタファーを用いる。

  • 列車が、信頼できるスケジュールで、駅から出発し、次の目的地に到着する。このスケジュールが、固定されたリズム、標準なARTベロシティー、予測可能な計画策定、(多くの場合リズムに基づくリリース)を提供する、
  • 列車がコードやドキュメントなどの「貨物」を運ぶ。
  • 機能的な報告ルートにもかかわらず、列車に乗らなければならないほとんどの人が列車に専属する。

このように、アジャイルリリース列車は、プログラムレベルのリズムと同期を提供することでチームの足並みを揃え、リスクと多様性を管理することを助ける。これは以下の共通な運営原則に基づく。

  • 頻繁で定期的な計画策定とプログラムインクリメント(PI)日付が確定している
  • 日付が確定し、品質が確定し、スコープが可変である
  • スコープとスケジュールは分散計画でチームよって決める
  • プログラムレベルの見積もり、計画策定と結合をサポートするため、チームは共通の反復期間と正規化されるベロシティーを適用する
  • 継続的なシステムインテグレーションが、列車に乗っているすべてのチームを横断的に実装される
  • 2週間毎に、システムデモを通じ、主要な利害関係者に完全に統合されたシステムレベルの動作するソフトウェアを見せる
  • イノベーションと計画策定スプリントは見積もりに対する保護帯を提供し、リリース計画策定、イノベーション、継続的な教育やインフラ作業のための専用時間を提供する。
  • ユーザーエクスペリエンス設計、インターフェース、共通コンポーネント、アーキテクチャー滑走路のような一定のインフラコンポーネントは通常先行して開発しなければならない

リリース列車の役割

アジャイルチーム以外に、いくつかの役割がある。

  • フルタイムのリリース列車エンジニアは列車のためのチーフスクラムマスターである
  • リリース管理はリリース統制に対する権限を持ち、スコープ管理に関する難しい意思決定を支援できる。また、リリースの影響に関する計画をサポートする
  • プロダクト管理者プログラムバックログに内容に対する権限を持ち、プロダクトオーナーとともに積極的にスコープと品質を管理する
  • ビジネス責任者は成果に関する最終的な責任を持つ。列車に対し、特定な責任を持つ。
  • システムチームはインフラを支援し、ソリューションの結合をサポートし、エンド・ツー・エンドのシステムテストを実施し、非機能要求との適合性を評価することができ、システムデモを支援する
  • UX設計者システムアーキテクトは新しいフィーチャー開発をサポートするアーキテクチャー滑走路の構築を支援することがもちろん、共通のシステム振る舞い、共有されたコンポーネント、関心事の分離も提供する
  • 共有されたリソースは列車に専用できない専門的なサービスでチームを支援する。
  • DevOps は列車と統合され、安定的な一連の小さなリリースを促進するため、開発チームは具体的なDevOpsプラクティスを適用する

戦略的なベクトル合わせ

迅速な価値の提供に注力するように個別のアジャイルチームに権限を委譲することで、おそらくアジャイル以前のソフトウェアモデルで誇張されてきた生のエネルギー、動機、イノベーションが通常解放される。しかしながら、チームは自然に局所最適化に陥る傾向があるので、それだけでは不十分である。チームは自分の担当部分の顧客に要求を納品できるようにできるだけのことを行うが、より全体的な視点を取ることは難しい。しかし、全体最適は最大の恩恵をもたらすため、SAFeはリリース列車を用いて、集団共通の方向に足並みを揃えるように、また目標となる機会に対処するためにはるかに多くの力を得るように支援する。

列車を設計する

SAFeを実装する時、1つ重要な作業は、価値のストリームと個々のリリース列車のドメインを決定することである。つまり、一緒に計画し、作業を行う人が誰だろう、列車が価値のストリームで納品しようとするのがどんなプロダクト、サービス、フィーチャー、コンポーネントなのかということを決めるのである。より小さな価値のストリーム(例えば、小規模の会社や大企業内の小さなビジネスユニット)では、列車は単純に成果に関与する全員によって構成できる。これは簡単なケースである。

より大きな企業では、そのようなたくさんのチームや複数の価値のストリームがあるかもしれない。異なるソリューションに作業し、全員ですべてを計画するのは希望があっても無理がある。その場合、複数の価値のストリームが必要されるだろう。一部の価値のストリームに複数のリリース列車が含まれているかもしれない。この場合、同じ境界で足踏みを揃え、列車横断で連携をするのは便利であるかもしれない。

リリース計画策定と実行

一旦ARTのドメインが確立すれば、リリース計画策定のリズムと日程を事前に決めることができる。これにより、施設、出張、オーバーヘッド、リリースイベントに伴うその他の処理コストを減らすことができる。一旦計画され、実行に対する責務はリリース列車自身に属する。

報告

一般的に、2週間ごとに、システムデモ時に動作するシステムソフトウェアで進捗を測る。報告時に、図1に示すリリースバーンダウンチャートやフィーチャー状況報告も利用する。

Figure 1. Example Program Burn Down and Feature Complete reports

図1. プログラムバーンダウンチャートとフィーチャー状況報告の例

 

フィーチャー状況報告は、プログラムインクリメントの目標を構成するための大きなフィーチャーをもっと詳細的に追跡可能にする。

スクラム・オブ・スクラムズ

通常、RTEは2週間ごとにスクラム・オブ・スクラムズミーティングを開催する。図2にこのようなミーティングの推奨されたアジェンダを示す。

図2. スクラム・オブ・スクラムズのテンプレートの例

図2. スクラム・オブ・スクラムズのテンプレートの例

検査と適応

PIの時間枠(タイムボックス)が終了した時点で、PIは終了する。(PIはプログラムレベルのスプリントで、タイムボックスが終了時に、それも終了する)。各PIに続いて、結果のデモや、定性化的なART測定に関する決定があり、その後に構造化された振り返りや問題解決と是正活動ワークショップを開催する。これらに関しては検査と適応にて説明する。


さらに知りたい場合

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

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 22 July, 2014

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.