##スクラム開発とは
プロダクトバックログ（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点作成
- env.PBL：開発以外のtodoを入れるもの
- deb.PBL：ユーザーストーリー（開発todo＝テスト仕様書）を入れるもの
- 各ストーリーにストーリーポイントを当てはめる
* 開発者皆でやること
####週次
- 1Sprintを1週間とする
- 毎週頭にPBLからSBLにその週のtodoを移動
- その週したいtodoを優先順位高い順に、ベロシティ消化するまで入れる
- env.PBL：該当日時の項目をそのまま入れる
- dev.PBL：ユーザストーリーをある程度のtodoに分解して入れる
- その週したいtodoを優先順位高い順に、ベロシティ消化するまで入れる
- spread sheet運用の場合、上から順番に優先度高く入れて、上から消化する
####日次
- 毎朝エンジニアだけの朝礼で、本日のtodo確認を行う
- 毎朝全体朝礼で、前日までの進捗共有と本日のtodo共有を行う
- バグが出た場合、何を学んだか、何が原因で起きたかを、記載する
- Todo - OnGoing - Inreview - Done のルール
- 取り組んでいる行を「Ongoing」にして、そこへ自分の名前を記入
- ひと通り終了したらcommit→pushをして項目を「Inreview」にする
- 責任者が動作+コードを確認して、ダメならコメント付きで突き返し、okならmergeして、該当する行を「Done」にする
####その他
- 初めに書いたSBLはそのままテスト仕様書にする
- 必須項目で出たバグはdoneにせずにバグの理由だけ書いてtodoに戻す
- 追加機能は項目として追加する
- 完成後出てきた軽いバグはバグリストに入れる
####スクラム開発に関する良記事
[SCRUM/アジャイル開発の入門資料を全力でまとめてみた]
(http://morizyun.github.io/blog/scrum-agile-xp-book-review/)