スクラム開発まとめ

スクラム開発とは

プロダクトバックログ（Product Back Log 以下PBL）

• そのPJに関するエンジニアのtodoが全て入っている
• ユーザーストーリーを集めたものがプロダクトバックログ
• 項目は以下6項目
  • 大カテゴリ（どのページか（URLベース））
  • 誰が（どのユーザーが）
  • 何をする（なんの行動をする機能か）
  • Sprint数（どのSprintにて行う予定のものか）
  • 工数（工数見積もりを予測×1.5倍程度でつける）
  • ステータス
    • Todo:タスク
    • OnGoing：進捗中
    • Inreview：責任者の確認中
    • Done：終了

スプリントバックログ（Sprint Back Log　以下SBL）

• 現在のスプリントのtodoが全て入っている
• mtgや面談などの時間も加味してSBLを設計
• その週したいtodoを優先順位高い順に、ベロシティ消化するまで入れる

ユーザーストーリー

• 要求仕様を自然言語で分かり易く書いたもの
• 曖昧な言葉はさけて誰でも理解出来る言葉で書く
• PJメンバー全員に通じる会話のための道具であること

ユーザーストーリーのひき方

• 上記ルールに従って全部出す
• 工数の見積もりが可能な粒度で分ける
• 互いに独立している（依存関係はなるべく排除）
• 全てのストーリーを長くても半日程度にする

ベロシティ

• そのチームで消化可能な工数（/日・チーム or /日・人）

スクラム開発のルール

開発初め

• PBLを以下2点作成
  1. env.PBL：開発以外のtodoを入れるもの
  2. deb.PBL：ユーザーストーリー（開発todo＝テスト仕様書）を入れるもの
• 各ストーリーにストーリーポイントを当てはめる 　* 開発者皆でやること

週次

• 1Sprintを1週間とする
• 毎週頭にPBLからSBLにその週のtodoを移動
  • その週したいtodoを優先順位高い順に、ベロシティ消化するまで入れる
  • env.PBL：該当日時の項目をそのまま入れる
  • dev.PBL：ユーザストーリーをある程度のtodoに分解して入れる
• spread sheet運用の場合、上から順番に優先度高く入れて、上から消化する

日次

• 毎朝エンジニアだけの朝礼で、本日のtodo確認を行う
• 毎朝全体朝礼で、前日までの進捗共有と本日のtodo共有を行う
• バグが出た場合、何を学んだか、何が原因で起きたかを、記載する
• Todo - OnGoing - Inreview - Done のルール
  • 取り組んでいる行を「Ongoing」にして、そこへ自分の名前を記入
  • ひと通り終了したらcommit→pushをして項目を「Inreview」にする
  • 責任者が動作+コードを確認して、ダメならコメント付きで突き返し、okならmergeして、該当する行を「Done」にする

その他

• 初めに書いたSBLはそのままテスト仕様書にする
• 必須項目で出たバグはdoneにせずにバグの理由だけ書いてtodoに戻す
• 追加機能は項目として追加する
• 完成後出てきた軽いバグはバグリストに入れる

スクラム開発に関する良記事

nanapiでスクラム開発を半年やってみて分かった事まとめ

スクラムガイドを読む（第２回）

SCRUM/アジャイル開発の入門資料を全力でまとめてみた

スプリントのタスクに関するTips29個

SCRUMによる実践的アジャイル開発手法（寺本隆彦）

社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について