[XP]ストーリーの定義と運用事例（前編）（2024 Advent Calendar 16日目）
この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の16日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。
ストーリー
本記事ではXPのストーリーの定義と自分たちのプロジェクトでの運用を紹介します。
ストーリーの定義
ストーリーとは、顧客に見える機能（フィーチャー）の単位を指します。例えばブログを作る場合、「ユーザーはブログを投稿できる」「ユーザーは一度公開したブログを非公開にできる」といった形で記述します。これによりプロダクトオーナー、デザイナー、エンジニアがユーザーのために何を作るかという観点でコミュニケーションを取れるようになります。機能を網羅した膨大な1000ページに及ぶ要件書よりも、このような一連のストーリーの方がビジネスメリットを認識しやすいです。
ストーリーに対しては、実装開始からデプロイまでにかかる時間をすぐに見積もります。XP本では時間で見積もる方法が紹介されていますが、現代ではストーリーポイントを使った見積もりが一般的です。
ストーリーポイントは時間ではなく、あるタスクのサイズを基準としてそれより大きいか小さいかの相対値で見積もりをする方法です。全てのストーリーのポイントを合計すれば、全体リリースのおおよその時期を見積もることができます。
ストーリーとその見積もりがあれば、どのストーリーを優先すべきかをビジネス的、技術的観点から議論しやすくなります。また、ユーザーのニーズに基づいてストーリーを再考しやすくなります。
例えば、前提条件がない状態で「ポルシェと軽トラックのどちらが欲しいか」と問われた場合、自分ならポルシェを選ぶかもしれません。しかし、来月自分で引っ越し作業を行う予定がある場合、軽トラックを選ぶ可能性がありますし、場合によってはレンタルで済ませるという選択肢も考えられます。さらに、引っ越し作業を業者に依頼する予定であれば、そもそも車は必要ないかもしれません。
機能ではなくストーリーを記述するとき、そもそも何でそれが必要なのかという背景や前提情報まで抑えることができます。このチームメンバー間のこのコミュニケーションのプロセスこそが重要なのです。
このようにストーリーを書いて見積もりを行ってチーム全体で共有することで、ユーザーの前提条件や制約に応じた適切なストーリーを選べます。また、ソフトウェアの価値を最大化するために優先順位を決める際にも大いに役立ちます。
ストーリーの運用
ストーリーの運用: ストーリーはユーザーを主語にして記述する
ここでは、ストーリーとストーリーポイントについて説明します。
ストーリーはタスクとは異なります。タスクは機能を実現するためにやるべき作業を指しますが、ストーリーはユーザーから見た機能の説明です。ユーザーがその機能を使ってできることを記述します。このため、ストーリーは一般的にユーザーストーリーと呼ばれます。
ストーリーを記述する際には、「ユーザーとして、Xができる（それはYだからだ）」というフォーマットを使用します。例えば、「ユーザーとして、ブログを投稿できる」「ユーザーとして、ブログを削除できる」という形です。
ユーザーという言葉が広義で曖昧になる場合には、ロールごとにストーリーを分解しても良いでしょう。
例えば、「レビュワーは、レビュー中ステータスのブログのみ閲覧できる。それは、執筆者が下書き記事をレビュワーに見せたくないからだ」や、「著者は、下書きステータスの記事のみ編集できる。それは、レビュー中に記事を編集するとレビュワーがどこまでレビューしたかわからなくなるからだ」といった具合です。
ストーリーの運用: 事前に完了条件を設定する
ストーリーを作成する際には、必ず前もって完了条件を記述しておく必要があります。どの条件を満たしたらそのストーリーが完了したとみなせるのかをチーム内で合意しておきます。
例えば「レビュワーは、レビュー中ステータスのブログのみ閲覧できる」というストーリーの場合、完了条件は次のように設定できます。
[完了条件]
- 管理者は、レビュワーというロールでユーザーを追加できる
- ブログ記事一覧画面でステータスを表示できる
- レビュワーは、下書きの記事を選択できない
- レビュワーは、レビュー中ステータスのブログを開ける
完了条件を事前に設定しておくことで、プロダクトオーナーは受け入れテストで迷うことがなくなります。事前に合意した完了条件を満たしているかをテストで確認すれば良いからです。また、受け入れテストを自動化する場合には、この完了条件をそのままテストケースの記述に利用できます。手動テストであっても観点は同じです。
さらに、完了条件を設定することでスコープクリープが起こりにくくなります。もしスコープが広がりそうになった場合は、別のストーリーとして切り出してその優先順位を決め直せば良いのです。
例えば、「ブログ記事一覧画面でステータスを表示する」という内容は、「ユーザーは、ブログ記事一覧画面で各記事のステータスが分かる」という別のストーリーに分けて管理できます。
こうすることで、後者のストーリーを完了させてから前者のストーリーに取り組むという依存関係を整理できます。
ストーリーの運用: ストーリーを作る前に調査タスクを作成する
調査タスクもストーリーから派生します。他チームに問い合わせたり、ドキュメントやコードを読んで開発に必要な知識を得るといった調査作業もタスクとして扱います。
これはスパイクと呼ばれるもので、ストーリーに着手する前に発生することがほとんどです。スパイクの結果を踏まえてストーリーの見積もりを正確に行ったり、複数の案（A案とB案など）のうちどれを採用するかを決定することもあります。
スパイクも漫然と進めるのではなく完了条件を設定して目的を明確にしておくことが重要です。自分たちのチームでスパイクを作るときはユーザーを主語にするよりも「XXを調査する」というタスク形式で記述していました。
次回はストーリーの後編をお届けします。
Happy Coding 🎉
