Develop on Cadence-Release Anytime

不確実性の下でフローを制御する。
– Don Reinertsen

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
– アジャイル宣言

開発はリズムに合わせ、必要に応じて納品

開発はリズムに合わせる。フローに基づくシステムにおいて、素早く同期しているリズムを用いて日常的な開発活動を行うことは、システム開発に固有なバラツキを管理するための最もよい戦略である。複雑で大規模なシステムを構築することは、何と言っても、調査と開発である。これはSAFeの基本な前提の1つである。ビッグピクチャー(全体像)から、同期された短い反復は素早いリズムで繰り返す一方、より大きなプログラムインクリメントはこれらの反復の結合からなるということは直接確認できる。

必要に応じて納品する。 しかしながら、SAFeは関心事の分離を提供する。これによって、開発チームに、自分たちの環境における複雑性や激しい変化を管理するために必要なリズムと同期ツールが提供される一方、市場へのリリースは同期や非同期両方でできるようになる。これはSAFeのもう1つの基本的な前提である。ビッグピクチャー(全体像)では、動作するソフトウェアを表す小さなボックス型のアイコンを用いて、これを示す。

詳細:開発はリズムに合わせる

我々のソリューション資産を構築するため、リズムと同期という主要な要素を用いる。リズムは予見性のある規則的な開発リズムである。同期は複数の独立したイベントは同時に発生することである。リズムと同期を用いて、PI計画策定システムデモ及びソリューションデモ、システムの結合、といったような活動、また、リソースの調整やチームの連携作業など頻繁ではないような活動は、定期的に実施できそうな作業が定期的に実施できるようにする。以下の表1と2で、基本的な原則及びSAFeの中でこれらの原則の適用方法を説明する。これらの原則はSAFeの仕組みを理解するために重要である。(Don Reinertsen、Principles of Product Development Flow [1]の著者に感謝する)

フローの原則:リズム SAFeのプラクティス
F5: 一定的なリズムを利用し、バラツキの蓄積を防ぐ 定期的なプログラムインクリメント(PI)の間隔で計画策定することでバラツキを1つのPI時間枠に限定する。そしてアジャイルリリース列車及び価値のストリームの予見性を高める。
F6: リズムを可能にするためには十分な容量のマージンが必要である 確実にPI目標を達成するため、イノベーションと計画策定反復には計画を入れないことでスケジュールのマージンを提供する。計画されたが、確約されなかった背伸び目標は容量のマージンを提供する。両方を用いて、PIのゴールを確実に達成するためのスケジュールやスコープのマージンが提供される。
F7: リズムを用いて待ち時間を予測できるようにする もし高い優先順位を持つフィーチャーが1つのPI(リリース)に入れられなかった場合、次のPI(あるいはスケジューリングされた頻繁なリリース)で提供されることが期待できる。そのため、現在のインクリメントにWIPを超えるような負荷が避けられる。
F8: 一定的なリズムを用いて小さなバッチサイズを可能にする 反復のバッチにおけるストーリーの数への制御は、短い反復が役に立つ。フィーチャーのバッチサイズは短いPIと頻繁なリリースで制御され、それによって高いシステムの予測可能性とスループットを提供する。
F9: 予測可能なリズムで頻繁に開催する打ち合わせをスケジューリングする PI計画策定、反復計画、バックログの手入れ、検査と適応、アーキテクチャの議論など、すべての恩恵はこれらの頻繁に開催されるミーティングからである。各ミーティングは新しい情報の小さなバッチだけを処理する必要である。ミーティングや他の重要なイベントの処理コストを低減することにはリズムは役に立つ。

表1: SAFeに適用されたリズムに関する原則

 

フローの原則:同期 SAFeのプラクティス
F11: 複数のプロジェクトの同期作業で規模の経済を創出する 個々のアジャイルチームは共通の反復の長さに合わせる。システムデモやソリューションデモで作業が同期される。ポートフォリオビジネスエピックとイネイブラーエピックは共通のインフラと顧客のユティリティを促進する。
F10: 容量のマージンは納品の同期を可能にする 背伸び目標を持つチーム計画。実績は計画に合う場合必要に応じ省く。
F12: 機能横断なトレードオフーを促進するため、同期されたイベントを開催する 価値のストリームとプログラムPIイベントは顧客のフィードバック、リソースと予算の調整、使命に関する共通認識、検査と適応改善活動、プログラムレビューと統制を同期する。これらのイベントは協調とチームビュディングも促進する。
F13: 待ち行列を短くするには、隣接するプロセスのバッチサイズとタイミングを同期する チームは共通の時間枠と似たようなバッチサイズに足並みを揃える。プログラムレベル及び価値のストリームレベルにおけるシステムチームは結合をリズム的に支援する。新しいアイディアの迅速的な提供を促進するため、バックログは短く、確約されない状態にする。
F14: 作業を同期するためには複数の調和した入れ子になったリズムを適用する チームは、(少なくとも)反復の区切りで結合し、評価する。プログラムと価値のストリームの結合と評価はPIの区切りで行う。

表2: SAFeに適用された同期の原則

我々の作業にある固有なバラツキを管理できるように、リズムと同期は重要な概念である。リズムと同期を用いて、我々の主要なビジネス利害関係者から信頼できるような、より信頼的、独立的なソフトウェア開発と納品プロセスを創出できる。

詳細: 必要に応じて納品する

すでに見たように、リズムに合わせて開発することはけっこうだが、実際のリリースの価値に関して、異なるルールを適用したほうがよいだろう。プログラムインクリメントの信頼できるストリームを前提に、次より大きな検討事項は、いつ、どんな方法でエンドユーザーに増え続ける価値を実際にリリースするかを理解することだ。ビッグピクチャー上では、アジャイルリリース列車(ART)のフローにさまざまなタイミングでのリリースが描かれた。しかし、それは1枚の図に過ぎない。各企業、各プログラム及び価値のストリームは、自分たちの開発とビジネス背景に合うようなソフトウェアをリリースするための戦略を持たなければならない。次の節では、リリース頻度に関する考えを示す。

継続的な納品に向けて

いろんな意味で、継続的な納品は望ましい最終状態を表すかもしれない。電話に1つの自動更新が提供される場合、我々はもうパニックにならないだろう。その更新が価値を提供してくれるという前提で、我々はたくさんの考えや心配なしで、「即時更新」ボタンを押す。着実に、電話にあるソフトウェアは我々の企業システムと同じ量で、あるいはより多いだろう。しかしながら、エンタープライズの世界では、常に足並みがそろわない。多分、セキュリティや可用性、財務(銀行、取引)や個人の重要度(医療設備、人評価されたシステム)などの理由で、顧客の運用環境は大きな新しい価値の継続的な更新に合わないかもしれない。もしかすると、我々のエンタープライズ開発とリリース能力は、顧客にリスクフリーの大きなアプローチに至らなかったかもしれない。あるいは、何らかの理由で、経済的に見て意味がないだけだろうかもしれない。

さらに、継続的な納品をサポートするシステムは継続的に納品できるように設計されなければならない。それでも、リリースは均質なものではない。この簡単なWebサイトであっても、複数のリリース段階がある。例えば、もし我々はビックピクチャーを毎週更新する場合、SAFeをサポートするツールや教材にとってはよいことではない。同時に、もし、我々も新しいコンテンツを提供する能力(ブログ、ガイダンス、新しい文書へのローリングウェーブの更新を通じ)もない場合、我々の継続的な価値の納品というゴールに達成できない。アジャイルにならないだろう!これらを設計しなければならない。

リリースの関心事と開発の関心事を分離する

システムの開発とリリースは違うことだと認識しなければならない。柔軟性と俊敏性を最大にするため、SAFeはこれらの潜在的に違うイベントをお互い干渉しないように関心事の分離を提供する。各プログラム、価値のストリームは自分特化のアジャイルリリース列車の開発リズムを定義し、アジャイルリリース列車は自分の反復パターンを選択する。この概念モデルに基づいて、我々はリリースのための3つの独立したケースを検討する。

プログラムインクリメントのリズムでリリース。もっとも単純なケースは企業がプログラムインクリメントの区切りでリリースすることである。この場合、PI計画策定、リリース、検査と適応は同じリズム、同じ日程で調整される。さらに、最終な検査と妥当性検証、ユーザー受け入れテスト、リリースドキュメントの作成などを含むより広範なリリース活動をサポートするために、イノベーションと計画策定(IP)反復は、時間を合わせられ、設計され、連携されることができる。また、すべてのリリース日が事前に周知できる!(固定された日程、変動できるスコープ)。もし、組織はこのモデルの効率性と便宜性を追求する場合、すべてのPIパターンは任意であるため、沢山の企業はこのシンプルな構造の利用方法を見つかった。(例として、ロードマップの図1をご参照)

頻繁ではないリリース。多くの場合、素早くPIリズムでリリースすることは不可能かもしれない。例えば、いくつかの企業における顧客の動作環境の重要なインフラを構成するシステムの設定と配置。顧客は新しいソフトウェアを持ちたくても、サービスレベルとライセンス契約はこれを禁止するかもしれないし、また、インストールのオーバヘッドと混乱があるかもしれない。他の場合、モバイルフォンなどソフトウェアとハードウェアの両方を含むシステムを構築する企業のタイムラインは、ディスプレイ、チップセットなど長期ハードウェアによって駆動される。新しいハードウェアはまず利用可能でなければならないので、早期かつインクリメンタル的なリリースは選択肢の1つではない。これらの場合、PIリズムでのリリースは単純な選択肢の1つではなく、計画策定とリリース活動は切り離さなくではならない。

より頻繁にリリース。複雑なシステムのシステムを構築する企業にとっては、上記の2つのケースはいずれ単純すぎるかもしれない。これらの場合、より大きなシステムは上記のモデルを利用するかもしれないが、システムの多種多様なコンポーネントはより頻繁にリリースしなければならないかもしれない。定期的な計画機能はリズムを提供し、多様性を管理するため、また期待からの逸脱を制限するために企業のニーズを同期と整理する。しかし、強引に、すべての資産の開発を同じリズムにすることは、システムに対する過度な束縛であり、避けるべきである。

リリースしたいときにリリースする

もっと現実的に考えましょう。大きなシステムは均質ではない。自分のリリースを必要となる異なる種類のコンポーネントやサブシステムを含むかもしれない。上記の3つのモデルのそれぞれの要素が同時に表すかもしれない。この場合、図1で示すように「好きな時に好きなものをリリースする」という最も一般的なモデルを検討することは一番やりやすいだろう。

Figure 1. Fully decoupling development concerns from release concerns
図1. リリースの関心事から開発の関心事を完全に分離する

SAFeを導入する企業は、上記すべてのケースでは、開発とリリースが異なるという事実に安心できる。また、ビジネス状況を満たすに必要な任意な時間で高品質の資産をリリースすることが可能である。


さらに知りたい場合

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

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chapter 16.(邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス 、翔泳社、2010)

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

Last update: 16 September 2015