変化はわれわれの時代のもっとも重要な特徴(フィーチャー)である。

デヴィッド・ブリン

フィーチャーの概要

フィーチャーは、利害関係者のニーズを満たすためにシステムにより提供されるサービスである。フィーチャーはプログラムバックログで維持される。また、各PI(プログラムインクリメント)が「完全なユーザー価値を納品するため、すべて一緒に作業する」という概念的な一貫性を提供するため、各フィーチャーはPIにて対応できるように規模が調整される。フィーチャーはユーザーストーリー(反復に収まるように規模が調整される)とエピック(PIやリリースをまたがる)間のギャップを橋渡しする。フィーチャーは「重みづけされた最短作業から着手」(WSJF)によって、優先順位が調整される。この優先順位の調整はPIの境界で更新される。この継続的なローリングウェーブな優先順位付けのメカニズムは、フィーチャーの納品に最適化された順序をもたらす。その結果として、アジャイルリリース列車に向け、次々に最適化された経済利益がもたらされる。

詳細

「フィーチャー」という用語はSAFe独自のものではない。フィーチャーは業界標準の専門用語であり、通常プロダクト管理者、マーケティングやセールス担当者が、提供するフィーチャーや各フィーチャーによってもたらした恩恵の観点から、顧客にプロダクトを説明する時に利用する。フィーチャーはSAFeのバックログモデル(エピック > フィーチャー > ストーリー)の中心的な部分である。フィーチャーは、問題領域(ユーザーや利害関係者のニーズを理解するもの)とソリューション領域(これらのニーズを満たすために設計された具体的なシステムの振る舞い)との間のギャップを橋渡しする。実装までに、フィーチャーはプログラムバックログに保管される。大半のフィーチャーは、ユーザーのニーズに基づいてプログラムレベルで局所的に発生する。その他のフィーチャーはポートフォリオプログラムエピックの分解から由来する。

フィーチャーと恩恵

フィーチャーはユーザーの声を反映するフォーマットで記述できるが、我々は必ずしもそれを推奨しない。主要な理由はプロダクト管理者はそのようなやり方が教えられなかったし、抽象度のより低いレベルにあるユーザーストーリーと混同しやすいからである。代わりに、より簡単的な、従来のアプローチを推奨する。それはプロダクト管理者にとってお馴染みのアプローチ:フィーチャーと恩恵のマトリックス、あるいはFABである。図1に例を示す。

図1.フィーチャーと恩恵のマトリックス(Ping Identity社の好意により掲載)

図1にあるFABで示すように、フィーチャーは以下2つの側面で説明される:

  • フィーチャー – 短いフレーズで、フィーチャーの名称やコンテキストを示す
  • 恩恵 – 短い説明で、ユーザーやビジネスに対する価値を記述する。各フィーチャーに複数の恩恵があるかもしれない

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

SAFeは重みづけされた最短作業から着手 (WSJF)を用いて、プログラムバックログにあるフィーチャーの優先順位付けを継続的に行う。正しい順序(時間)で正しい作業(フィーチャー)を選択することは、アジャイルリリース列車、そして、価値ーのストリームやポートフォリオに主要な経済恩恵をもたらす。従って、この重要なプロセスが過小評価できない。実に、市場ではこれが上手にやったプログラムはより優れている。

WSJFの計算式では、分子が遅延のコストである。SAFeの世界では、遅延のコストはユーザー/ビジネス価値、時間価値、リスクの低減/機会の増加の合計からなる。選択する対象となるバックログ項目にバラツキがあるため、単にバックログにあるフィーチャーをほかと相対的に比較することによって、個々のパラメータを迅速に見積もることができる。WSJFに時間要素(時間価値)があるため、フローに基づく、ジャストインタイムなローリングウェーブな計画策定、PIの境界におけるフィーチャーの優先順位再調整に特に適する。(注意: WSJFの計算式の分母は作業の期間である。以下の節でこの重要なパラメータを議論する。)

また、プログラムバックログに容量の割り当てを適用することは、技術とビジネスの関心事の分離に役に立つ。それによって、現在のビジネスニーズに一致するように技術とビジネスそれぞれを対処する。プロダクト管理は、このプロセスを用いて、プログラムバックログの継続的な発展、更新、手入れ、優先順位付けに責任を持ち、そして最大化された経済価値を納品するために列車を運転する。

フィーチャーの規模を見積もりする

適切な経済的優先順位付けは作業の規模を理解しなければならない。要するに、何か新しいことをするのにいくらかかるかを知ることなく、投資対効果の比較を理解できないだろう。正しい、次の最も良いフィーチャーを選択することはARTの技能であり、作業規模の見積もりはその目的を達成するために重要なスキルである。 適切な経済性に対する理解のレベルに応じ、フィーチャーの見積もりは三段階で行う:予備的な相対見積もり、大まかな絶対見積もり、と最終的な絶対見積もりである。それぞれの見積もり結果はWSJFの分母の代理として利用できる。(容量が固定される前提で、期間が規模に依存する)

  1. 予備的な相対見積もり – 選択対象となるフィーチャーが十分あるので、プロダクト管理は単に初期な、大まかな見積もりが必要となる場合がある。このレベルの理解では、フィーチャーの「大きさ」をほかと対比するために相対見積もりが利用できる。設計、実装とテストの複雑性によって、フィーチャーはプロダクト管理だけによって見積もられる。見積もり時に、システムアーキテクチャー、開発からのインプットを含む。
  2. 大まかな絶対見積もり – 上記の相対見積もり方法は早くて直接的であるが、優先順位付けにおいては、相対的なFibonacci数値の幅の増加がかなり大きな不確実性をもたらした。精度を向上するために、あるいは潜在的なコストの早い見積もりを得るため、過去データとの比較を利用する。新しいフィーチャーの規模を、今まで類似したフィーチャーを納品するために必要なストーリーポイントと対比することによって見積もりする。
  3. 最終的な絶対見積もり – 最終的に、見積もりの精度をさらに向上しなければならない場合、チームはフィーチャーをストーリーに分解し、個々のストーリーを見積もる。関連するすべてのチームの見積もり結果の合計は潜在的なスコープとコストに対する最も精度の高い見積もりを作り上げる。

これらの仕組みは作業規模の見積もりを提供する。WSJFでは作業規模は期間と優先順位付けの代理として利用する。(注意:もし、リソースの可変性と拡張性によって、規模はよい代理ではない場合、期間を利用してください)。チームが正規化された見積もりを利用する場合、ストーリーポンインからコストへの換算は直接的であるため、後ろの二つの仕組みはコストの見積もり結果も提供する。

フィーチャーの受け入れ基準

フィーチャーは受け入れ基準にも関連付けられる。受け入れ基準を用いて、フィーチャーの実装が正しいかどうか、ビジネス恩恵を納品しなければならないことを判断する。以下の例では、ユーザーログイン機能に関するフィーチャー、恩恵と受け入れテスト基準を示す。

フィーチャー: 多要素認証
恩恵: セキュリティー強化のため、1パスワードと1デバイスでのユーザー認証をサポートする
受け入れ基準:
1. 第1レイヤはUSBトークン
2. 第2レイヤはパスワード認証
3. 1つのデバイスに複数のトークンをサポートする
4. 2つの要素に関するユーザー活動のログ反映

受け入れ基準の推敲は、1つのPIにフィーチャーが実装されることに関するリスクを確実に管理できることに役に立つ。さらに、受け入れ基準は通常さまざまなユーザーストーリーや機能テストの源である。これらの機能テストは将来のリファクタリングや回帰テストのために開発され、自動化される。

フィーチャーの分割

1つのPIに収めるように、フィーチャーを分割しなければならない。ストーリーを分割するためのテクニクは同様にフィーチャーで利用可能である。以下のリストは参考資料[1、第6章:ユーザーストーリー]に紹介されたストーリーを分割する10個のパターンを示す。

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

複数のチームによって実装されたフィーチャー

理想的に、1つのフィーチャーは1アジャイルチームによって構築され、ART組織はその目的のために迅速に発展することが望ましい。しかしながら、大規模のシステムでは、チームはフィーチャーチームやコンポーネントチーム、またハイブリッドチームになる可能性がある。また、多くの場合、1つのチームによって実装できないほどフィーチャーが大きすぎるため、連携が必要である。フィーチャーはより大きく、より価値があるほど、より多くのチームが関与する可能性がある。

このような場合において、1つのフィーチャーが複数のインプットを持ち、それらのインプットを納品のために実装しなければならないことがある。各チームは自分が担当するフィーチャーの一部をユーザーストーリーに分解し、その部分の見積もりを行う。すべてのチームからの見積もりが集約され、フィーチャー全体の見積もりとなる。

リリース計画策定における上位10位までのフィーチャー

フィーチャーとその恩恵を利用し、リリース計画策定でプロダクト管理によって提示されたビジョンを表す。近い将来にあるPIが注力する仕掛作業(WIP)を最小限にするため、プロダクト管理者たちは通常チームに上位10位までのフィーチャーを提示する。リリース計画策定中に、フィーチャーが必要に応じ分割され、フィーチャーを実装するために、ストーリーが識別される。スコープが交渉される可能性がある。もし、PI内に収まるように、フィーチャーが分割できない、また、スコープが調整できない場合には、このフィーチャーがプログラムバックログにそのまま残り、次回のリリース計画策定の前に再評価される。


さらに知りたい場合

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

 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.