特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係

ユースケースとストーリーカードの関係、特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係についてメモ。

【1】「システム要求、システム要件をどのように書くか？」はどのSW開発手法でもバラバラ。
オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。

ユースケース記述書の書き方で一番優れていると思うのは、コーバーン著の「ユースケース実践ガイド―効果的なユースケースの書き方」。
ユースケースの書き方、観点のノウハウが詰まっている。
特に、ユースケースの観点を、アイコン(雲・凧・海水面・魚・貝)で表示して区別するのを推奨しているのは要注意。

ユースケース記述書のサンプルは下記を参考。

ユースケースについて

システムユースケース記述 [C02あんしん電話（高齢者] ユースケース ...

ユースケース番号：
ユースケース名：動詞句で記述する
主アクター：
従アクター：
事前条件：
成功時保証：
トリガー：
主シナリオ(メインフロー)：
拡張シナリオ(代替フロー)：
備考：

とはいえ、ユースケース記述書を最初からきちんと書ききるのは非常に難しい。

例えば、非機能要件を明示的に書く欄がないため漏れやすい。
又、代替フローの定義から大きな要件漏れが発生しやすい。
あるいは、ユースケース記述をIF文できちんと書こうとして、どんどん複雑化し、要件ではなくフローチャートを描いているに過ぎない場合もよく見受けられる。

【2】XPならストーリーカードに要件を書いて、タスクカードに作業を書く。
重要なことは、ストーリーは顧客が分かる観点で書くこと。
ストーリーカードは顧客が優先順位付けしたり、操作する重要なカードだから。

ストーリーカードのフォーマットは、下記が分かりやすい。

Article 626 at 00/07/17 16:48:01 From: hiranabe Subject: [XP-jp:00626] Virtual XP ストーリカード (1)

顧客ストーリカード
────────────────────────────────
番号 : 1
────────────────────────────────
日付 : 2000/7/17
────────────────────────────────
アクティビティ種別 : ■新規 □ 修正 □ 拡張
────────────────────────────────
優先度 : ユーザ 技術
────────────────────────────────
リスク:
────────────────────────────────
技術見積り:
────────────────────────────────
記述:
メーリングリスト(以下ML)のユーザが，ML のアドレスにメールを
送信すると，ML に所属するメンバ全員に，そのメールが配信され
る．配信されるメールの Subject は，[ML名:23] のような文字が
先頭に付加される(XP-jp のような仕様)．ただし，そのメールに返
信した場合，[ML名:xxx]という文字は重複しないような配慮がなさ
れる．ML に属するメンバは，members というファイルに1行1名で
記述されている．メンバ以外から来たメールは，エラーとして差出
人に返す．
────────────────────────────────
備考:
後のストーリにて，メンバの追加，削除をメールにて行う方法が記
述されることを考慮にいれよ．また，特定のML のみをサポートす
るのではなく，設定によって ML 名，ML アドレス等は変更できること．
────────────────────────────────
タスク記録:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
日付 状態 ToDo コメント
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

上記のフォーマットは分かりやすいとはいえ、ユースケース記述書に比べると曖昧な部分が多く、要件漏れが発生しやすくなるかもしれない。

【3】Scrumのプロダクトバックログについて、下記の優れた解説記事がある。

特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayangの日記（ピスト通勤他

[Agile]プロダクトバックログについて海外の例も踏まえ考えたこと | Ryuzee.com

以下、まとめてみる。

特徴(Feature)、粗筋(Story)、脚本(Scenario)を意識して区別することを推奨している。

特徴(Feature)は、顧客から見たシステムの特徴。
粗筋(Story)は、その特徴(Feature)を利用者が具体的に体験する過程を記述したもの。
脚本(Scenario)は、粗筋(Story)をより具体的に記述したもの。

Feature(特徴)：カンファレンス運営原価管理

粗筋(Story)：カンファレンス目標人数までの到達度を測定する
* (As a)カンファレンス主催者として
* (I want)カンファレンス申込状況の報告書を見たい
* (So that I can)これにより、申込目標人数までの到達度を知ることができる。

脚本(Scenario)：　一人の登録が1%進捗と表示される場合
* (Given: 前提) 200人が目標人数の場合
* (When: 操作) 一人が申込登録すると
* (Then: 結果) 1%進捗と表示される

Feature(特徴)はシステムの機能。

粗筋(Story)は、XPならストーリーカード、Scrumならプロダクトバックログに相当し、これを見積もりや計画ゲームに使う。
上記の例の構造は下記と対応付ければ、非常に分かりやすい。
(As a)は主アクター。
(I want)は目的または要求。
(So that I can)はサービス、ユースケース名、又はユースケース概要。

脚本(Scenario)は、受入テストの根拠、つまり受入テストケース。
Given＝受入テストケースの事前条件、When＝受入テストケースのテスト手順、Then＝受入テストケースの期待値のように対応付けることもできる。

上記をユースケース記述書の事前条件・ステップ・事後条件に該当できるように見えるが、そうするとユースケース数が受入テストケース数とほぼ同値になってしまって爆発してしまう。
脚本(Scenario)は受入テストケースとほぼ同値とみなし、ユースケース記述はもう一段抽象化した方が良いように思う。

上記がユースケース記述書やストーリーカードよりも優れていると思う点は、要求(変更理由)と要件(変更内容)を粗筋(Story)と脚本(Scenario)で区別していることだ。
特に、何故システムのこの機能が必要なのか、その目的や要求を表現する項目がある点に着目したい。
結局、目的や要求が曖昧な場合、何を実現すればいいのか、何度要件定義をやっても決まらないから。

【4】特徴(Feature)、粗筋(Story)、脚本(Scenario)をRedmineによるチケット駆動開発では、どのように表現できるか？

Feature(特徴)は、Redmineならチケットの属性である「カテゴリ」に相当するだろう。
カテゴリはシステムの機能であり、カテゴリ単位にチケットを分類しているからだ。

粗筋(Story)は、チケットのトラッカー(種類)を「ストーリーカード」で登録すればいい。
このストーリーカードを作業単位にチケットへ分割すれば、「タスクカード」になる。
ストーリーカードに見積もり工数・実績工数・作業期間も記入すれば、TiDD上で進捗管理できる。

脚本(Scenario)は、TestLinkの「受入テストケース」に相当するだろう。
この時、粗筋(Story)をTestLinkの「受入テストの要件」として登録すれば、要件管理ができるし、テストカバレッジや要件カバレッジをリアルタイムに出力できる。
つまり、ストーリーカード(粗筋(Story))を経由して、RedmineとTestLinkを紐付けることができるはず。

色々試してみたい。