第5章 要件とユーザーストーリー

スクラムと従来のプロジェクトの要件定義

• 従来のプロジェクト
  • 始める前に詳細化され、独立している用に見える
  • 製造業と同じ、要件が事前に作成されたもので、詳細なドキュメントとともに開発チームに与えられる
  • 実際のものを見てから、必要な要件が出てくる場合が多々ある
• スクラム
  • 開発を始めるときに、必要な文だけあれば良い
  • 事前に要件を詳細化しない
    • その代わりにプロダクトバックログアイテム(PBI)を用意する

PBIはそれぞれ何かしらのビジネス価値を表している
最初は粗く、詳細はほとんど記載なし
スクラムチームはPBIについて開発しならが、より詳細なPBIに分解していく
最終的にはスプリントバックログに入る大きさまで細かくなる

スクラムではいつやるかわからない要件より、すぐに取り掛かる要件の方が小さくて詳細化されている
詳細化されていない要件を小さくて詳細化された要件の集まりにする。
= 段階的洗練戦略

ユーザーストーリー

PBIに期待されるビジネス価値を表現するのに便利な形式

テンプレート

<役割>として、
私は<目的>したい。
なぜなら<利益>だからだ。

具体例

一般的な利用者として、
商品の偏見のない口コミを検索したい。
なぜなら、今検索できる口コミは書いた人が自身の利益のために書いているものが多く含まれているからだ。

ユーザーストーリーには満足条件とし言う形で確認のための情報も含まれている
これらは、受け入れ条件と呼ばれるもので、期待される振る舞いを明示するもの

満足条件の例

# ユーザーストーリー
一般的なユーザーとして、
私はサービスに写真をアップロードしたい
なぜなら、ローカルでは写真を保存する容量に限度があるからだ

# 満足条件
- 画像ファイル(jeg,png)がアップロードできること
- RAWファイルがアップロードできること
- 保存可能な画像のサイズに制限がないこと

ユーザーストーリーの抽象度

ユーザーストーリーは以下のように徐々に詳細化していく

• 数ヶ月、複数回のリリース
  • エピック
  • 概念や概要レベルの全体像
• 数週間程度のもの
  • フィーチャー
• 数日で完成できる規模
  • ストーリー
    • スプリント可能なストーリー、実装可能なストーリーとも
• 一時間程度のもの
  • タスク
  • whatではなく、how決める
    • 逆にユーザーストーリーはタスクレベルの詳細をかかないようにする

INVEST

ユーザーストーリーを評価するための６つの原則

• 独立している(Independent)
• 交渉できる(Negotiable)
• 価値がある(Valuable)
• 見積もり可能(Estimatable)
• 小さい(Small)
• テスト可能(Testable)

ここまでの感想や実際の現場との差異

• PBIについては割と細かくなった状態ですでに入っている
  • 逆に大きな要件はないのではないか
  • 詳細化する際には、エンジニアを含めないで話し合って詳細化している気がする
  • 例: PBI「サービスのruby移行」
    • その詳細化したアイテム
      • 「ユーザー側の画面の移行」
        • 「画面Aの移行」←このレベルがPBIとして入っている
        • 「画面Bの移行」
• プロダクトバックログで入っているのは、全てストーリーレベルかフィーチャーレベル
  • スプリントに入れる前提としてプロダクトバックログに入っているからかな
• エピックは、バックログに入れていない気がする
• 学習のためのストーリーとあって、hogeを試すというのは割と正しい切り方だった