このドキュメントは
「スクラムを始めるぞ！」というチームに対し
- スクラムとは
- 何のためで
- どんな役割があり
- 何をやるのか
をスクラムマスターがざっくり説明するための資料
参考にすべき書籍
-
スクラムガイド(2016年版)
- たった17ページ。無料。
- スクラムの大元
-
エッセンシャルスクラム
- 過去のスクラムの経験や例を元に、実践的なプラクティスの紹介
スクラムは何のためのものか
向いている対象
-
物事を予期できない
- ユーザーに出してみるまで何がウケるか分からない、等
-
検証が可能
- 数値を計測する等の方法によりそれが良かったのか悪かったのか検証可能
思想
設計段階から全てを見通すのは無理
少しずつ作って、検証と適応を繰り返す
- スクラムの核心
- 透明性
- 今何が起きているかチームの皆が知れる
- 検査
- 作ったもの・作り方を評価する
- 適応
- 検査に従ってより良いやり方を探索する
- 透明性
スクラムの3つの役割
プロダクトオーナー（PO）
プロダクトの価値の最大化に責任を負う
- プロダクトがどのような価値を持つか
- 最後には PO が決めるべき
- 各価値の重要度の決定
- 各価値（機能）のチームへの共有
スクラムマスター(SM)
プロセスの責任者、スクラムのコーチ
- スクラムを使ってどう仕事を進めるか
- チームのスクラム的な教育
- スクラムイベント(会議等)のファシリテーション
- 障害の除去
開発チーム
プロダクトを作成する人々
- エンジニアから、テスターなども含む
- 一通りチーム内で作れる人材が揃っている
- 自己組織化
- やり方は自分たちで考える
- 3〜9人程度
使うツール
プロダクトバックログ (PB)
価値を届けるフィーチャー（機能等）等を集めたもの
各フィーチャー等をプロダクトバックログアイテム(PBI)と呼ぶ
- 優先度順に並んでいる
- 操作できるのは PO のみ
スプリントバックログ
1スプリント（後述する仕事の時間単位）毎に行うバックログアイテムをタスクに分解したもの
- そのスプリントのゴールを達成するための道筋
- 各タスクは工数見積もりを行う
- 開発チームが操作する
完成の定義
PBI の完成の定義の認識を合わせることが重要
例えば
- リリースされていること
- コードレビューが完了していること
- ユニットテストが書かれていること
等。全ての PBI について満たしておきたい条件は予め完成の定義に含めておきたい。
完成の定義はプロダクトのフェーズによって変化していく。
スクラムイベント
スプリント
お仕事をする一区切りの時間
- 1週間〜1ヶ月の固定期間
- スプリント毎に何かしら価値を届けるべき
- ユーザーが◯◯できるようになる、等
スプリントプランニング
今スプリントで何をするのか計画
- 何を成し遂げるか（スプリントゴール）
- PO: PB から作るべき PBI を選択
- どうやって成し遂げるか
- 開発: 各 PBI をスプリントバックログに移す
- 開発: 各 PBI をタスクに分解
- PO と開発チームでゴールについて合意
デイリースクラム
毎日15分、進捗を検査・適応・再計画
- 昨日やったこと
- 今日やること
- スプリントゴールの障害になっていること
スプリントレビュー
スプリントの終わりの、成果物の検査・適応
- 成果物をデモ
- うまく行ったこと、うまく行かなかったこと、解決方法
- 次に何をするかを皆で議論
- PB、今後のスケジュール予測等を修正
振り返り
スプリントの終わりの、プロセスの検査・適応
- 人・関係・プロセス・ツール について議論
- うまく行ったこと、改善が必要なもの、対応策
プロダクトバックログリファインメント
PO による PBI の詳細化と優先順位の調整
- ロードマップやビジョンから PBI に
- 直近でやるもの：詳細に。まだ先のもの：アバウトに。
- 重要な PBI ほど上にくるよう並び替え
最後に
この資料ではスクラムの思想の深いところや、実際のプラクティスの詳細については書いてありません。
冒頭で上げた資料を読むことをお勧めします。