nav_Features-Capability

Linuxは革新的である。私が誇りにしている非常に優れた技術フィーチャーが含まれている。Linuxには他のオペレーティングシステムにないシステム能力がある

– Linus Torvalds

フィーチャーとシステム能力の概要

SAFeでは、システムの機能的な振る舞いを表す成果物の階層を、エピック>システム能力>フィーチャー>ストーリーと表現している。このページでは、システムとソリューションの振る舞いを表すのに使用するフィーチャーとシステム能力について説明する。

フィーチャーおよびシステム能力という用語はSAFeに特有のものではない。業界標準に近い用語として、顧客向けのプロダクトやソリューションを指すのに、プロダクト/ソリューション管理者、チーフエンジニア、マーケティング担当、営業担当によって広く使われている。フィーチャーは、ユーザーのニーズに対応するためにシステムが提供するサービスである。システム能力では、ソリューションの高レベルの振る舞いを価値のストリームレベルで表現する。

フィーチャーはプログラムカンバンの中で、システム能力は価値のストリームカンバンの中で開発および管理され、準備、優先順位付け、承認を経て実装を待つことになる。このプロセスは、筋の通った経済分析、技術的影響、インクリメンタルな実装の戦略を前提としている。
重複を避けるため、このページの大部分は、各ART向けにシステムの振る舞いを記述するフィーチャーの定義、表現、実装についての説明にあてる。システム能力はフィーチャーの抽象度を1段階高くしただけのものであり、価値のストリームレベル(使用するかどうかは任意)のソリューションに適用される。持つ属性はほとんど同じである。

詳細

フィーチャーシステム能力は、SAFeの要求モデルの中心部分である。価値を定義、計画、実装するために欠かせないもので、SAFe内のソリューションを前に進めるためのもっとも基本的なメカニズムを表す。図1にこれらの成果物を含むコンテキストを示す。

Figure 1. Feature in context of SAFe
図1. SAFeのコンテキストにおけるフィーチャー

図1に示すように、フィーチャーは、必須かつ主要な機能的システム定義要素である。各フィーチャーには、利害関係者のニーズを満たすためにシステムが提供するサービスが反映される。フィーチャーは、プログラムバックログ内で保持され、それぞれのプログラムインクリメント(PI)で価値を納品できるよう、PIに収まるようにサイズが決められる。フィーチャーは、アジャイルリリース列車というローカルのコンテキストの中から生じることもあれば、エピックやシステム能力を分割した結果として現れることもある。

フィーチャー(とシステム能力)はカンバンシステムで管理される。 プロダクト管理および システムアーキテクト/エンジニアリングの権限のもとにおかれ、WSJF(重みづけされた最短作業から着手)を使って優先順位を付けられる。そして特定の非機能要求のコンテキストで価値を実現する。フィーチャーの計画と見直しはPIの境界で行う。ストーリーとして実装し、使用できるようになったら統合、テスト、デモが行われる。

システム能力はフィーチャーと似ているが、より高いレベルのソリューションの振る舞いを表し、実装には複数のARTが必要なことが多い。システム能力は、各PIでインクリメンタルに測定可能な価値を納品できるよう、PIに収まるサイズに調整される。(エピックは、実装に複数のPIが必要な取り組みを表すのに使われる。)システム能力は、ソリューションというローカルのコンテキストの中から生じることもあれば、複数の 価値のストリームにまたがるポートフォリオエピックを分割した結果として現れることもある。その他にシステム能力が発生する可能性があるのはソリューションコンテキストで、ここでは何らかの環境が原因となって新しいソリューション機能が必要になることがある。

フィーチャーの記述

フィーチャーはフィーチャーと恩恵のマトリックス(FAB)を使って記述する。

  • フィーチャー – 短いフレーズで名前と暗黙的なコンテキストを示す。
  • 恩恵 – 短い説明で、ユーザーやビジネスにとっての利点を記述する。1つのフィーチャーに複数の恩恵がある場合もある。

フィーチャーは複数のユーザー役割に関係することがあるため、SAFeでは一般的にユーザーストーリーの声を使ってフィーチャーを表現することを推奨していない。また、ビジネス担当者は通常はユーザーストーリーに慣れていないため、ストーリーとフィーチャーに同じ書式を使用すると混乱を生じる可能性がある。

フィーチャーと恩恵のマトリックスの例を図2に示す。

Figure 2. Network router features and benefits matrix example
図2. ネットワークルーターのフィーチャーと恩恵のマトリックスの例

フィーチャーの作成と管理

フィーチャーは、プロダクト管理者プロダクトオーナーやその他の主要利害関係者と協力しながら、ARTのローカルのコンテキストで作成する。その他に、エピックを分解した結果として現れるものもある。イネイブラーフィーチャーは、アーキテクチャー滑走路の整備や調査に役立つもので、取り組みの開発、テスト、統合に必要なインフラとなることもある。イネイブラーフィーチャーは、通常、アーキテクトやエンジニアによって作成され、プログラムバックログの中でビジネスフィーチャーと一緒に保持される。

イネイブラーフィーチャーは、ビジネスフィーチャーと同様に、エピックから生じることもあれば、アジャイルチームやARTや価値のストリームのニーズに応えてARTレベルでローカルに現れることもある。カンバンシステムを通り抜けたイネイブラーは、ソリューションを先に進めることとアーキテクチャー滑走路を延長することの両方が重要視されるよう、プログラムバックログ内で処理能力の割り当ての対象として管理される。処理能力の割り当ては、イネイブラーの作業全体を対象として行うことも、イネイブラーの種類ごとに分けて行うことも可能である。

フィーチャーの優先順位付け

SAFeでは、フィーチャーの優先順位付けをWSJFを使ってプログラムバックログ内で継続的に行う。正しい作業項目を正しい順序で選択することで、大きな経済的恩恵がARTひいてはソリューションにもたらされるため、この不可欠のプロセスの重要性は計り知れない。

フィーチャーの見積もり

フィーチャーを見積もることで、価値の納品の予測や、WSJFによる優先順位付け、エピックなど規模の大きな取り組みのサイズ分割がしやすくなる。フィーチャーの見積もりは、通常、プログラムカンバンの「洗練」状態において、アジャイルチームがストーリーの見積もりに使用するのと同じ標準化された見積もり技法を使って行う(標準化されたストーリーポイントを使った見積もりの詳細はストーリーのページを参照)。しかし、この時点のフィーチャー見積もりでは、ストーリーに細かく分解したり、フィーチャーの開発に携わる可能性のあるすべてのチームを巻きこんだりする必要はない。そのかわりに、選ばれたその分野の専門家に基本的な調査やサイズ分割に加わってもらうことがある。

フィーチャーの受け入れ

フィーチャーにも受け入れ基準があり、それを使って、実装が正しいかどうか、ビジネス上の恩恵が納品されるかどうかの判断が行われる。図3に、フィーチャーとその受け入れ基準の例を示す。

Figure 3. Feature acceptance criteria example
図3. フィーチャーの受け入れ基準の例

受け入れ基準を詳細化すると、実装リスクを軽減できるだけではなく、フィーチャーの範囲にビジネスにとって望ましい価値が含まれているかどうかを早期に検証することができる。さらに、通常は受け入れ基準をもとに、さまざまなストーリーや機能テスト(リファクタリングや回帰テストを行うために作成して自動化されたもの)が作成される。

フィーチャーの受け入れの責任を持つのはプロダクト管理である。プロダクト管理は、受け入れ基準を使って、機能が適切に実装されているか、非機能要求が満たされているかを判断する。

価値のストリームのシステム能力

このページの大部分は、フィーチャーの定義、表現、実装についての説明にあてられている。フィーチャーがシステムの振る舞いについてもっともよく使われる記述だからである。システム能力はフィーチャーをソリューションレベルでまとめたものなので、フィーチャーと同じ特性やプラクティスを持つ。たとえばシステム能力には次のような特徴がある。

  • フィーチャーと恩恵のマトリックスと同様のマトリックスを使って記述され、受け入れ基準が関連付けられる。
  • 価値のストリームのローカルのコンテキストから生じたり、エピックから導き出される。
  • PIに合わせてサイズ分割される。
  • 価値のストリームのカンバンを使って検討し承認される。承認済みのシステム能力は価値のストリームのバックログで保持される。
  • ビジネスシステム能力の効率的な開発および納品のために必要なすべての技術的作業を記述して可視化したイネイブラーが関連付けられる。
  • ソリューション管理者によって受け入れられる。ソリューション管理者は、受け入れ基準を使って、機能が適切に実装されているかを判断する

フィーチャーとシステム能力の分割

システム能力を実装するにはフィーチャーに分割しなければならない。そして、フィーチャーは、チームが反復の時間枠の中で対処できるストーリーに分割される。以下のリストに挙げるのは、Leffingwellが参考文献[1]の第6章で記述している「作業の分割」のための10のパターンである。これは上記すべての場合に適用できる。

  1. ワークフローステップ
  2. ビジネスルールのバリエーション
  3. 大半の労力
  4. 単純/複雑
  5. データのバリエーション
  6. データ入力方法
  7. システム品質を後回しにする
  8. 操作
  9. ユースケースシナリオ
  10. スパイクを始める

システム能力をフィーチャーに分割する例を図4に示す。

Figure 4. A capability split into features
図4. システム能力のフィーチャーへの分割

 


さらに知りたい場合

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

Last update: 30 December 2015