ストーリーは利用者と開発者双方が一緒に効果的に仕事を行うのに十分なだけの合意を取れる「ピジン言語」のように作用するのである。

Bill Wake、エクストリーム・プログラミングの共同提唱者

どのストーリーにも一枚の写真があるのではないか……

ロッド・スチュワートの歌ではない

ストーリーの概要

SAFeでは、機能的なシステム振る舞いを記述する成果物のため、3階層(エピック>フィーチャー>ストーリー)を用いる。エピックやフィーチャーがより大きな意図的な振る舞いを記述する一方、ストーリーを介して、すべての実装作業が記述される。ストーリーはチームバックログの主要な構成要素である。ストーリーの多くはプログラムのフィーチャーから由来するが、一部はローカルなチームコンテキストから生まれる。ストーリーは、ユーザーに価値を提供し、インクリメンタルに実装できる小さな、独立した振る舞いである。反復毎に新た価値を確実に提供するため、ストーリーは1つの反復内で完了できるように必要に応じ分割される。

ストーリーは要求仕様ではない。一般的に、ストーリーは交渉可能である。それによってストーリーは契約上の(内部または外部)特定の振る舞いを表すよりも、むしろ意図の文を表す。しかしながら、受け入れ基準を通じ、ストーリーは実装と共により明確になり、システム品質を確保するために役に立つ。ここでは、「このシステムによって、誰が何をするか、なぜするか」を回答するユーザーストーリーについて解説する。さらに、システム振る舞いが必要となる別の種類の技術ストーリーを解説する。

詳細

SAFeのエンタープライズバックログモデルでは、ストーリーが一般的にフィーチャーによって促進され、その他の関係もあることが示されている。図1が示されているが、すべてのストーリーが受け入れテストと関連付けられ、新しいコードが作成する理由となるストーリーには、関連する単体テストが1つ以上必要である。

Figure 1. Story and related objects in the backlog metamodel

図1. SAFeバックログモデルにおけるストーリーと関連対象

ストーリーは小さな独立な価値のかたまりを納品する。最初に、インデックスカード(物理的なカード、あるいはソフトウェアツールにあるカードのメタファー)に書かれることが多い。各ストーリーはユーザーやプロダクトオーナー(通常大多数のストーリーを定義し、優先順位をつけるアジャイルチームのユーザーの代理)、実装に責任を持つ開発者とテスト担当者にとっては理解可能である。ストーリーを書き出す時に、価値を中心に据えたフォーマットや触ることができる物理的なストーリーカードにより、チーム全体、および適用可能なユーザーを巻き込むことを支援する。誰でもストーリーを書けるが、バックログに取り入れることの承認や、メインライン開発に受け入れることはプロダクトオーナーの責務である。

ユーザーストーリー

主要なシステムの振る舞いとユーザー価値を記述する手段はユーザーストーリーである。ユーザーストーリーは関心の対象をシステムではなく、ユーザーに置くので、ユーザーと価値を中心とする。推奨された表現形式はユーザーの声の形式であり、以下のような形である。

<役割>として、私は<活動>を行え。それにより<ビジネス価値>がある

このような形式を採用し、がシステムを利用するか、システムを利用することによってをするか、なぜそのようにするかに関して、チームは絶えずに理解しなければならない。これによって、チームがユーザーの真のビジネスニーズをよりよく理解することとともに、日常的に継続的にチームのドメイン能力が向上する。以下は例である。

図2. ユーザーストーリーの例

図2. ユーザーストーリーの例

ユーザーストーリーはXPの「3C」、つまり、カード(意図に関する短い文)、会話(ユーザー/プロダクトオーナー間の議論)と確認(ストーリー完了に関する満足条件を定義するための受け入れ基準)に従う。

カード は、ユーザーストーリーの意図を説明するために用いる文を物理的に捉えたものを表す。カードメタファーはチームと「ユーザーがやりたいこと」との間に有形で動きを感じさせる関係を提供する。性質的に、カードは物理的にストーリーの長さ、そして、システムの振る舞いのあまり早い具体化に制限を掛けている。ストーリーを軽量で柔軟なものに保つことも支援する。カードはチームが将来のスコープに関する「感覚」を持つことも支援する。(手に10枚のカードを持つのと、スプレッドシート上10行を見るのとでは感覚は明らかに違う)

会話 は、チーム、顧客/ユーザー、プロダクトオーナー及びその他の利害関係者間の「会話の約束」を表す。これは、意図を実装するため、より詳細な振る舞いを決定するため必要な議論である。ユーザーストーリーに添付されたもの(モックアップ、スプレッドシート、アルゴリズム、タイミング図など)として、会話はさらなる具体性を引き出す可能性がある。

確認。ユーザーストーリーは意図的に短く、粗い文で記述するが、ストーリーの受け入れ基準は、必要な精度で、ストーリーが正しく実装され、関連する機能と非機能要件がチームでカバーしていることを保証する。可能な限り、アジャイルチームはビジネス側で読める、ドメイン特化な言語を利用し、受け入れテストの自動化を図る。これによって、コードの「自動的に実行可能な仕様とテスト」が作成される。自動化は迅速なシステムの回帰テストを提供し、そして、システムの機能強化、継続的なインテグレーション、リファクタリングと保守を行う。図3は1つの例である。

図3. Cucumber受け入れテストフレームワーク向けに、Gherkin言語で書かれたストーリーの受け入れテスト

図3. Cucumber受け入れテストフレームワーク向けに、Gherkin言語で書かれたストーリーの受け入れテスト

 

チームによって、ストーリーカードの第3セクションを利用し、ストーリーのデモに関する記述を行う。

良いユーザーストーリーに関するINVEST

チームはBill Wakeの「INVEST」(独立している、交渉できる、価値のある、見積もれる、小さい、テストできる。参考文献[1]と[2]を参照する)という頭字語を用いて、ストーリーを評価する。

デバイスあるいはシステムユーザーストーリー

ユーザーストーリーは主要な、ストーリーの望ましい形であるが、一方開発するシステムは全部エンドユーザーと相互作用するとは限らない。時々、「ユーザー」はデバイス(例:プリンター)であり、その他のシステム(例:トランザクションサーバー)である。この場合、ストーリーは図4に示す形式を利用する。

図4. ユーザーがシステムの場合のユーザーストーリーの例

図4. ユーザーがシステムの場合のユーザーストーリーの例

 

技術ストーリー

時々、開発チームは、いくつかの異なるユーザーストーリーを実装する、あるいはシステムの他のコンポーネントを支援するために必要なコンポーネントの機能を開発しなければならない。この場合、ストーリーはエンドユーザーに直接的にはまったく触れないかもしれない。これらのストーリーを表現するため、図5に示したように、ユーザー中心の言語より、技術中心の言語を利用できる。

図5. 技術ストーリーの例

図5. 技術ストーリーの例

その時でも、ストーリーの動機を理解させるため、「……のため」の形式を推奨する。当然、技術ストーリーのデモはユーザーストーリーと変わらない。通常、UI、スタッブやモックを利用する。

技術ストーリーは大規模システムにおけるコンポーネントの開発と更新によく利用される(フィーチャーとコンポーネントを参照)。技術ストーリーは、a) 作業範囲は1つのサブシステムあるいはコンポーネントに限る、b) 明確な外部ユーザーやデバイス、システムが1つもない、いずれの場合で利用される。それ以外の場合、ユーザーストーリーの形式が利用すべきである。

ストーリーの分割

小さなストーリーで、迅速な、より信頼性の高い実装(小さいほど、より迅速にシステムを通過し、複雑性と管理リスクを低減する)が実現できる。大きなストーリーをより小さく分割するのは、各アジャイルチームの必須なサバイバルスキルであり、インクリメント開発の技能と科学である。参考資料[1]に、ユーザーストーリーを分割する10個の方法を紹介した。10個の方法を以下のように列挙する。

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

図6は「ワークフローステップによる分割」の例である。

図6. 図2に示すユーザーストーリーを2つより小さなユーザーストーリーに分割する

図6. 図2に示すユーザーストーリーを2つより小さなユーザーストーリーに分割する

ストーリーポイントとベロシティーについて

ストーリーの性質(自分自身によって価値を提供し、1つのユニットとして定義/構築/テストされる)によって、「ストーリーポイント」という観点で見積もりが導出できる。「ストーリーポイント」を用いて、完全にテストされたストーリーを実装するために必要な労力レベルを予測する。1つの反復で完了したすべてのストーリーポイントの集計の平均値はチームのベロシティーとなる。ベロシティーは見積もりのメカニズムとして、将来の反復に対する仕掛作業数の制限として利用できる(反復計画策定を参照)。さらに、SAFeでは、チームやプログラム横断的なストーリーポイントの「おおよその正規化」は、正確かつ柔軟なプログラムの見積もりと計画が可能になる。

その他のチームバックログ項目

システム振る舞いのストーリー以外、スパイクリファクタリング作業を含むその他のチームバックログ項目がSAFeにて説明されている。さらに、価値が提供し、労力がかかるが、新しいコードに直接関係ない他のバックログ項目がある。これらの項目は以下のように生じる。

  • 開発/開発インフラの構築あるいは改善
  • 人間の制御が必要な運営作業(例:百万のWebページに索引を掛け、初期のデータベースを構築でき、性能測定ができる)
  • 異なる目的のため、必要なプロダクトあるいはコンポーネントの設定を作成する
  • 特殊なシステム品質検証(脆弱性テストなど)を行う

さらに知りたい場合

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

Last update 15 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.