少し前に読んだのでアウトプットします。

実践編(P92〜137)

05 見積もりをより正確にする

見積もりは誰がすべき?

開発チーム
- 多くの情報、知識を持っている専門家
- 見積もりポーカー
- 対話して決めることが重要
なぜ開発チームが見積もる必要があるのか？
- プロジェクト開始前の見積もりは当てずっぽう
- 素早く終わったほうがいい
  - 推測に時間を費やすよりも、実際に試してみて確実にした方がいい
- 要件、要求に関しては
  - PBL決定時に、プロダクトオーナーと共に行っているから分かっている

06 プロジェクトの計画を立てる

いつ何が手に入るのか

これから先のことを知っておく

Scrumではどうやってプロジェクトの先のことを知るのか
- プロダクトバックログから読み取る
  - PBLの項目を見積もれば、プロジェクトの先の事を考えることが出来る
  - ポイントで見積もられているので、スクラムチームがスプリント毎にこなせる作業量がわかれば様々なことが見えてくる
- ベロシティ
  - スプリント毎に終わらせられるポイント数
  - スクラムチームのスピード
```
絶対に必要な項目の見積もりの合計 ÷ ベロシティ = 必要なスプリント数（期間）
ベロシティ x 期間内に実施できるスプリント数 = 実現できるポイント(どこまで実現出来そうか)
```

ベロシティはどうやってわかる？

誰かに決めてもらうわけではない
決められたリリース日からの逆算でもない
決めるものではなくて測るもの。実際に測ってみるのが最も確実
- スプリントを1つやってみて終わらせたPBLの項目の見積もりを合計する
- 直近の数スプリントの平均を出す

プロジェクトを始める前にはわからない

同じチームであれば、過去のベロシティを参考にする
同じチームでないならば、スプリントが始まる前に、幾つかの項目を実際にやってみる
スクラムに慣れていないチームはスプリント数に余裕をもたせる

ベロシティだけではわからないこともある

リリース作業
- 普段の作業とは異なる
- 慣れていないならば、リリーススプリントとして別に考えること
- ホントはスプリント毎にリリース出来た方がいい

PBL以外にも先の事を分かるように整理する

重要な会議、夏休みなどのイベントをPBLだけで扱うには慣れが必要
別の表を用意して、ステークホルダーにも予定が分かるようにした方がいい

ベロシティと最新の状況から、確実だと思える計画に何度も見直す

Scrumでは実際に終わらせた結果だけを確実なものとして信用している。それ以外は全て予想や推測
- ベロシティは変えてはいけない

07 詳細な計画を立てる

確実に終わる計画を作る

スプリント計画MTG

これから始まるスプリントの計画を立てる活動
- 第一部：POと開発チームでPBLの終わらせる範囲を決める
  - 上から４つとか
  - 何を実現して欲しいのか確認する。PBLだけでは全て伝わらないのでホワイトボード、資料などを作って確認する
  - 作業の終わりをどうやって確認するか決めておく
- 第二部：開発チーム中心で実際の開発作業を洗い出し具体的な計画を立て、今回のスプリントで達成するPBLの項目を決める
  - ベロシティを目安にして、1スプリントでどこまでできるか判断する
  - タスクの洗い出し
  - 見積もり。時間単位（1日に使える時間は5〜6時間で考えておく)
    - タスクと見積もりは、スプリントバックログにまとめる
- PBLに書かれている項目の意図を理解する
  - どう実現するか最適解がみつかる
  - 出来たものが違ったなど言われない
  - そのために、スプリントの目標を意図に沿って決めておく
- 終わりの認識を揃えておく
  - デモ手順を決めておく
- タスクの洗い出しと見積もりを確実にする
  - 大きな疑問や不安がない状態にしておく
  - 着手と完了の判断ができるようにしておく
- 1スプリントのPBLの項目が多いのは良くない
  - スクラムチームが確実な計画を立てにくい
  - タスクを洗い出すのに時間がかかる
- スプリントが達成できなくても、次のスプリントで確実に出来るように計画を考え直す
  - 問題点を隠すことが良くない
- 確実にこれだけは終わらせられると確信を持てる計画を作ることが重要

08 素早くリスクに対処する

スプリントが順調か？どこかに問題はないか検査する

スプリントが始まったら、スプリント計画MTGで洗い出したタスクをこなしていくだけ。

デイリースクラム

スプリントのゴールを守るために毎日やる

前回のデイリースクラムからからやったこと
次回のデイリースクラムまでにやること
問題点を話す

やり方
- 立ってやる
- 毎日15分だけ集まる
  - 長時間やっても集中力が続かない、問題点を見落としがち
誰かへの進捗報告ではない
問題が見つかったら
- すぐに対策
- デイリースクラムのあと必要な人だけが残って話し合う
見積もりは予想なので、状況に応じて更新する
- 予想がどうだっかを確認して、問題を見つける
- 問題があれば、スプリントの残りの進め方を見直す

09 何が終わったかを明確にする

確実に終わらせてから進む

スプリントの終わり
- スプリントレビューとスプリントレトロスペクティブの2つの開催で終わる
スプリントレビュー
- スプリント計画MTGで決めたPBLの項目をPOにお披露目・
- 開発チームがデモする
- POが判断する
- 少しずつ確認することで、要求との乖離を最小限にする
- デモは重要
  - 実際に動く、認識がずれていない、使い勝手
- 事前に決めた決めたデモの手順通りになっていれば終わり
  - 中身についても終わったと判断出来るようにしておく
    - チェックリストを作っておく

完了の定義はどうやって決める？

POがスプリント毎にどこまで終わって欲しいか伝える
開発チームでどのような基準を設けるか話し合う
POが基準を判断
スプリントレビューでは、それをリリースしたときに周りの期待に応えられるかどうかを判断する事が重要
- 完了の定義は実際のリリースで求められる品質基準とは分けて考える
- よりリリースに近い形になるように定義も更新していく
何が本当に終わったのか2つの視点で考える
- POの視点（要求を満たしているか）
- 開発チームの視点（品質）