nav-portfolio-kanban-02

最良のアーキテクチャー、要求、設計は、自己組織的なチームから生み出されます。

- アジャイル宣言

設計とシステム開発における創発を認識しなければならないが、少しの計画策定が沢山の無駄を省くことができることも認識する必要がある。

- James Coplien, Lean Architecture: for Agile Software Development

アーキテクチャーエピックカンバンの概要

SAFeでは、ビジネスとアーキテクチャーのポートフォリオエピック用に、カンバンシステムを開発し実装することを推奨している。この2種類のカンバンシステムは非常によく似たやり方で運用されるが、通常異なるチームの管理下にあるため、独立したシステムとしてそれぞれを説明する。このページではアーキテクチャーエピックのためのカンバンシステムの実装と利用についてまとめる。ビジネスエピックポートフォリオカンバンシステムは別のページで説明する。

効果的なアーキテクチャーエピックカンバンシステムの実装は、通常、プログラムポートフォリオ管理チームの管理下で行う。これを実装するには、リーンとアジャイル開発、そしてすべてのリリース列車の生産能力(新規開発のために利用できるベロシティー)に関する基本な理解が必要である。しかし、カンバンのメカニズム自体はとても簡単なので、まずは単に企業の既存プロセスに載せ、その後自然に発展進化させることができる。

詳細

アーキテクチャーエピックのカンバンシステムの動機づけ

以下の理由でカンバンシステムを利用する。

  • すべての人に対して、アーキテクチャーエピックバックログと進行中の分析を公開する。
  • これらの取り組みを実装に移すための分析や意思決定を構造化し、そのプロセスが全員に見えるようにする。
  • WIP(仕掛かり作業)制限を設定する。これによって、アーキテクトやチームが責任を持って分析すること、処理能力や現実をはるかに超えた実装や時間枠を期待しないことを保証する。
  • ビジネス、 アーキテクチャーチーム開発チームの主要利害関係者間の協調体制を作り上げることを支援する。
  • もっとも重要な技術決定に関して、経済的な意思決定ができるよう透明性のある定量的な根拠を提供する。

アーキテクチャーエピック用のカンバンシステムのプロトタイプ

このカンバンシステムを図に表すと図1のようになる。

Figure 1.

図1. アーキテクチャーエピックカンバンシステム

このポートフォリオカンバンシステムでは、1つのエピックがシステムを通って実装(または拒否)へ進むときの5つの状態が述べられている。

  1. じょうご – 取り込むための状態。どのような新しいビジネスアイディアも歓迎される。
  2. レビュー – 機会、労力と遅延コストの初期の見積もりが確立される。
  3. 分析 – 実行可能性、測定可能なメリット、開発と配置の影響、潜在的なリソースの提供可能性を確立するため、より徹底した作業が行われる。エピックの承認を得るために、軽量ビジネス企画を作成する。
  4. ポートフォリオバックログ – ポートフォリオカンバンを通過し「ゴー」の承認が得られたエピック。
  5. 実装 – 影響を受けるアジャイルリリース列車、あるいは実装に必要なリソースとスキルを提供できるアジャイルリリース列車にエピックが割り当てられる。ポートフォリオメトリックスのページで説明したレポートを用いて、エピックを継続的に追跡する。

システムの説明

1. じょうご – 問題/ソリューションニーズの特定

じょうご待ち行列は「取り込む」ための待ち行列である。この待ち行列では、どのような新しい「大ビジネスアイディア」も歓迎される。誰が提出しても構わない。但し、通常、これらの大きな取り組みは次のようなものから発生する。

  • 新しいプロダクトやサービスの機会
  • 複数のプロダクトやサービスに影響を与える技術の変化
  • 既存のソリューションの問題
  • 共通標準、プラットフォームなどの、アーキテクチャーガバナンス
  • 共通インフラの構築や重複作業を避けるための努力
  • イノベーションの促進
  • ソリューションコストの低減

この待ち行列では、エピックのビジネス企画や見積もりは必要ない。形式は任意であり、通常は「すべてのソリューションをJBOSSに移行する」のような短いキーワードや短文である。ツールは重要ではない。ドキュメントやスプレッドシート、あるいは壁に貼った目に見えるカンバンシステムで通常は十分である。

2. レビュー

レビュー待ち行列に進んだエピックは、さらに時間を投資して検討されることになる。この待ち行列では、エピックの大ざっぱな規模が割り出され、ある程度の価値の見積もりが行われる。時間の投資は、議論レベルと、必要であればごく予備的な調査に限られる。エピックをエピック価値の短文記述テンプレートの形式で詳細化し、説明と、この取り組みによって得られる価値および戦略的差別化を記述することもある。

投資額が増えるため、この待ち行列にはWIP制限がかけられ、検討中の項目の数が限定される。レビューエピックは定期的に議論される。各エピックには遅延のコスト(COD)が割り当てられる。待ち行列の一番上に上がってきたエピックは、空きができ次第、分析にプルされる。

3. 分析

この待ち行列に到達したエピックはより厳密な分析を行う価値があるため、さらなる投資が必要になる。通常はエピックオーナーとして1人のシステムアーキテクトを割り当てる。影響を受ける可能性のあるアジャイルリリース列車のエンタープライズアーキテクト、開発、プロダクト管理、利害関係者との積極的な協調作業が始まる。ソリューション、設計と実装の代替案を調査する。社内開発かアウトソーシングかを検討する。軽量のビジネス企画を開発して「ゴー」か「ストップ」かの提言をする。

この待ち行列の項目には稀少な要員をつぎ込むことになるため、アーキテクチャーチームおよび開発チームの処理能力や、この待ち行列内の項目をどれだけの速度で処理したいかに応じて、WIP制限が決められる。分析から実装へ進めるかどうかは企業にとって重要な経済的意思決定なので、作成されたビジネス企画に基づいて適切な権限を持った人が判断しなければならない。「ゴー」の基準を満たしたエピックは、実装に進む。

4. ポートフォリオバックログ

この待ち行列に到達したエピックは、適切な権限を持つ人から「ゴー」の判断を得ている。通常は、プログラムポートフォリオ管理、あるいは技術審議会の一部がこの判断を行う。これらのエピックは定期的なリズムでレビューされる。この待ち行列は次の実装作業向けの低コストの保持パターンを表す。1つ以上のアジャイルリリース列車に十分な処理能力がある場合、この待ち行列のエピックが実装待ち行列へ進める。

5. 実装

この待ち行列では、エピックに関する主な責任がプログラムに移る。アーキテクト要員は「プル」ベースで残る。つまり、実装の責任は開発チームにあるが、アーキテクトは開発チームを支援し、必要な作業についてチームが十分に理解するまで責任を共有する。

この待ち行列にはWIP制限がある。この制限は主に、開発チームの処理能力と、必要なアーキテクチャーへの投資額によって決まる。


さらに知りたい場合

このシステムに関するより詳細な説明は以下の書籍を参照してください。

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

カンバンシステムに関する包括的な説明は以下の書籍を参照してください。

[2] Anderson, David. KANBAN. Blue Hole Press. 2010.(邦訳:カンバン ソフトウェア開発の変革、リックテレコム、2014)

Last update: 25, 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.