スクラム開発

スプリントプランニング

• 決めること:
  • 何を、どうやって、どこまでやるか
• 決めないこと:
  • 納期
• タスクの粒度:
  • 0.5-1日で終わるサイズまで分解する
• 受入条件を決定する

規模の尺度

ストーリーポイント「1」を決める

• 単純な作業ではなく一連の開発フローまで含めた作業セットを「1」とする
• 最小のデプロイ単位

ストーリーポイントの工数感

• 1ポイント: 0.5人日
• 2ポイント: 1人日
• 3ポイント: 2-3人日
• 5ポイント: 4-5人日以上
• 8ポイント: 1週間以上、見積もり不可

ストーリーポイント「1」の具体的な規模感

• DBから1行レコードを取得して返却するシンプルなAPI

タスクの受領

タスクの前提条件

• 仕様、実現方式、完了条件が明確になっていること

チェックリスト

• データモデル:
  • どのテーブルの、どのカラムを読み書きするのか明確になっている
• 外部システム:
  • 外部システムのIO、データモデル、その制約事項が明確になっている
• ロジック/処理フロー:
  • 最も複雑な部分の検討がついている
  • その部分の実装イメージを説明できる
• テスト設計:
  • どうやってテストするか明確になっている

設計はいつするか

• (1) スパイクを実施する
• (2) バックログリファイメントで外部設計
  • バックログリファイメントで大まかな外部設計を行う
  • 実現可能性、システムの適合性を確認しチームで合意する
• (3) スプリントプランニング
  • タスクに分割できるレベルまで設計する
  • 実際のコードベースに何を追加するか、何を修正するかというレベルまで確認する

実装準備完了（Definition of Ready、DoR）の基準

• ユーザーストーリーが明確:要件が具体的に記述されている
• 受け入れ条件が定義済み:完成時の検証方法が明確
• 依存関係が整理済み:他のタスクやチームへの依存が把握されている
• 見積もりが完了:チームがストーリーポイントや工数を見積もっている
• 技術的な実現可能性の確認:大きな技術的障害がない
• 必要なリソースが利用可能:API仕様、デザインモックなど必要な情報が揃っている
• 適切なサイズ:1スプリント内で完了可能な大きさ

ユーザーストーリーの大きさ

• 標準: 0.5日〜2日以内で完了する大きさ
• 最大: スプリントの半分（スプリントが2週間なら1週間かかるサイズ）

ユーザーストーリーの分割パターン

SPIDR:

• (1) Spike（スパイク）- 調査・研究
  • 調査活動を別ストーリーとして抽出し、元のストーリーを小さくする
  • 例: 「クレジットカード処理の調査」→「クレジットカード処理の実装」
• (2) Paths（パス）- 処理経路
  • ユーザーが複数の方法で同じことを実行できる場合に分割
  • 例: 「動画を共有する」→「URLをコピーして共有」「SNSボタンで共有」
• (3) Interfaces（インターフェース）
  • ブラウザ、ハードウェア、または複雑なインターフェースを段階的に提供する形で分割
  • 例: 「Chrome版」→「Safari版」、または「シンプルなUI」→「リッチなUI」
• (4). Data（データ）
  • データの種類や範囲で分割
  • 例: 「全顧客データ」→「国内顧客」「海外顧客」
• (5). Rules（ルール）
  • ビジネスルールのバリエーションで分割
  • 例: 「支払い処理」→「通常の支払い」「割引適用の支払い」

その他

• Workflow Steps（ワークフローステップ）
  • ユーザーがタスクを完了するために取る一連のアクションで分割
  • 例: 「商品検索」→「検索バーに入力」「検索候補表示」「結果一覧表示」
• CRUD Operations（CRUD操作）
  • 作成、読取、更新、削除の各操作で分割
  • 例: 「顧客管理」→「顧客作成」「顧客表示」「顧客更新」「顧客削除」
• Simple/Complex（シンプル/複雑）
  • シンプルな機能を先に完成させ、後から複雑さを追加
  • 例: 「全顧客表示」→「トップ10表示」→「ページング」→「検索機能」
• Acceptance Criteria（受け入れ基準）
  • 各受け入れ基準を独立したストーリーにできるか検討

スクラムイベントの時間配分

• リファイメント: 10%
• プランニング: 5-10%
• 実装とテスト: 70-80%
• つまり、8-16時間はリファイメントとプランニングに費やすことになる

ユーザーストーリーの分割

• フル機能ではなく、スプリントレビューで公開可能な単位の機能で分割する
• 先述した通り、技術レイヤーのスライスはしない

スプリントレトロスペクティブ

• スクラムイベントの評価（時間は十分だったか、不足していないか）
• タスクの粒度感（適切か、過大・過小か）
• 設計の粒度感
• など

アンチパターン

タスクをレイヤー単位で分割してはいけない

• UI層、API層、DB層...
• レイヤー単位ではスプリントレビューで見せることができない
• レイヤー単位では作業難易度も変わってくるので適切な見積もりにならない

バックログのユーザーストーリーをそのまま開発者に投げてはいけない

• バックログは設計されていない要件
• バックログをそのまま開発者に渡すと、スプリント内で実現性の検討、設計、実装、テストまで行うことになる
• スプリント内で仕様の矛盾や実現が困難であることが発覚し、スプリントの進捗が0になることがありえる
• バックログはリファイメントとプランニングで設計と仕様を明確化してからタスクに落とし込む

参考資料

• スクラムガイド - スクラムマスター