【読書メモ】SCRUM BOOT CAMP THE BOOK
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 13回
- この商品を含むブログ (33件) を見る
年末に読み直したので読書メモとしてまとめます。実践編の中でも触れられていますが、スクラムのルールはシンプルではあるものの、その最低限のイベントやロールの責務を守り続けるための規律は自分たちで作って維持する必要があります。そのためにはまず基礎編を何度も読み返して目的をしっかり理解することが重要になります。実践編では自分たちのスタイルでスクラム開発を進めていくためのヒントになりそうなポイントが、スクラムを進めていくシーンごとに説明されています。「こういう場合はこうした方がいいだろう」という説明もたくさん散りばめられているため、スクラム開発に取り組む際に状況に合わせて読み返してヒントを得ながら進めていくのが良さそうです。
- 基礎編 Scrumってなに？
- 実践編 どうやればうまくいくの？
- ロールを現場に当てはめる
- プロジェクトを理解する
- プロダクトバックログをつくる
- 見積もりをする
- 見積もりをより確実にする
- プロジェクトの計画を立てる
- 詳細な計画を立てる
- 素早くリスクに対処する
- 何が終わったかを明確にする
- 状況をうまく把握する
- 先を予測しやすくしておく
- 次にやることを明確にする
- みんなの自立を促していく
- ベロシティを上げていく
- 問題を見つけやすくする
- 意図を明確にしておく
- プロジェクトを支援していく
- より良い状態にしていく
- 先のことをいつも明確にする
- 手戻りをなくしていく
- あふれそうなものを調整する
- さまざまな状況に対応する
- より確実な判断をしていく
- リリースに必要なことをする
基礎編 Scrumってなに？
スクラムはアジャイルの開発手法の1つで、最低限の定義されたルールに従い、重要なものから最短ルートでプロダクトを作ることで成果を最大化するためのフレームワークである。定義されている最低限のロール、会議体、成果物に沿ってスプリントを繰り返し実行することでプロダクトを作る。
スプリント
- スクラムでは固定の期間に区切って繰り返し開発を行う
- スプリントの期間内で開発チームはプロダクトの特定の要求についてリリース判断に必要な作業をすべて行う
- 期間は必ず固定で作業が残っていても延期しない
- プロダクトオーナーの判断でのみスプリントを途中で終了することができる
- スプリントの期間は通常1週間〜4週間程度で、プロジェクトの特性や開発チームの体制などを考慮して決める
成果物
- プロダクトバックログ
- 実現したい要求を1番目から順番に一列に並べる
- 常にメンテナンスして最新に保つ
- 要求の一番上から順に開発する
- それぞれの項目は開発するまでに見積もりをしておく
- スプリントバックログ
- プロダクトバックログの1つ1つを具体的なタスクに分割したもの
- 開発チームが洗い出して管理する作業計画
- 開発チームが自由に追加・削除可能
- 個々のタスクは1日以下の単位にする
- リリース判断可能なプロダクト
- スプリント内で開発するプロダクト
- スプリントの完了の定義を満たすもの
- 完了の定義はプロジェクトであらかじめ決定し、途中で縮小しない
ロール
- プロダクトオーナー
- 開発チーム
- リリース判定可能なプロダクトを作る
- 3〜9人で構成
- 全員揃えばプロダクトを作れる
- 上下関係はない
- スクラムマスター
- プロダクトオーナーや開発チームを支える
- プロセスがうまくまわるようにする
- 妨害を排除する
- 支援と奉仕をする
- 教育、ファシリテート、コーチ、推進役
会議体
- スプリント計画ミーティング
- スプリントで開発するための計画を立てる
- プロダクトオーナーのほしいものと開発チームができそうなものをすり合わせる（第一部）
- 開発チーム内でどうやって実現するかのタスクを決める（第二部）
- デイリースクラム
- スプリントレビュー
- 開発チームの成果物をプロダクトオーナーが確認する
- プロダクトオーナーは完了を判断する（完了していなければプロダクトバックログに戻す）
実践編 どうやればうまくいくの？
ロールを現場に当てはめる
- ロールが求めていることに熱心に取り組める人を探す
- 肩書や役職とは別もの
プロジェクトを理解する
- プロジェクトの ゴール と ミッション を知る
- プロダクトオーナーがプロダクトバックログをうまく作るため
- 開発チームがどういう作業を優先させるべきかを考えて日々行動するため
- インセプションデッキ ：プロジェクトを始める前にプロジェクトのことを知るための活動
- プロジェクトに関する10個の質問についてまとめる
- スクラムチーム全員で話し合って資料にまとめていく（プロジェクト計画書や要件定義書のスクラム版のようなもの）
- インセプションデッキ の テンプレート (日本語版)
プロダクトバックログをつくる
- プロジェクトの見通しを立てるために致命的な漏れを無くす
- プロジェクトのゴールを達成するために必要なものやっておいたほうがいいものを全て書き出す
- 出てきた項目を縦一列に並べる
- 例）超重要、重要、普通、なくてもいいの分類から順番を決める
- 上位の順番は詳細に考える（直近のプロジェクトで取り組む）
- 全体は大雑把に順序をつける（絶えず見直す）
見積もりをする
- 好きな方法で見積もる
- 実際に作業をする人が最終的な見積もりをする
- 相対見積もり：特定の作業を基準に決めて、その作業と比較してどれくらいの作業量かを見積もる
- プロダクトバックログの項目の作業量を的確に把握するために適切な基準を選ぶ
- フィボナッチ数（1,2,3,5,8,13...）で見積もる⇒大きな数字ほどブレが出るため重要な場合は細かく分割して見積もる
- 詳細な見積もりは直近のものだけにする
見積もりをより確実にする
- 見積もりポーカー：フィボナッチ数の書かれたカードを全員に配り、自分が考える見積もりポイントのカードを出す
- プロダクトバックログの項目ごとに全員で一斉にカードを出す
- 数字が違う場合は理由を話し合ってからまた一斉に数字を出し直す
- 開発チームのメンバーで見積もるが、疑問点などはプロダクトオーナーが解消に協力する
- 実際に作業する人同士の対話が重要
プロジェクトの計画を立てる
- 見積もったプロダクトバックログの項目ごとのポイントの合計でプロジェクトの見通しを立てる
- ベロシティ ：1スプリントで開発できるポイント数
- ベロシティがわかれば全て実現するまでの期間を予測できる
- スクラムチームの実力に合わせて考える
- リリースに関する作業はスクラムと分けても良い
- スプリントが終わったあとでリリースのための作業をする期間を別途用意する
詳細な計画を立てる
- スプリント計画ミーティングは二部構成で進める
- 第一部：スプリントでどこまで終わらせそうかをプロダクトオーナーと開発チームで話し合って見当をつける
- プロダクトオーナーから開発チームに実現してほしい内容を詳細に説明する
- 各項目の完了条件を決める
- 話し合い中に項目を入れ替えても良いが開発チームが準備できている項目以外は除外する
- 第二部：開発チーム全員で必要な作業を洗い出して詳細に見積もり、本当に終わるかを判断する
- 実装、テストなどのタスクを洗い出して時間で見積もる
- タスクの単位は1日以下にする
- 開発チームがスプリントの期間で実現できると判断したらプロダクトオーナーに連絡してスプリント計画ミーティングを終了する
- 第一部：スプリントでどこまで終わらせそうかをプロダクトオーナーと開発チームで話し合って見当をつける
- スクラムチーム全員が確実に終わらせられると見極められる具体的で詳細な計画をつくる
- スプリントごとの目標を決める
- デモの手順などを決めて終わりの認識を揃える
- 性能や品質などの受け入れ基準を設ける
素早くリスクに対処する
デイリースクラム
- 1日分の予想の前提を揃えるために毎日同じ時間に同じ場所で開催する
- 直近1日分の最新の予想を伝えて、翌日その結果を報告する
- 予想のズレの原因を問題点として報告する
- スクラムマスターは必要や要望があれば司会をする
- スプリントの目標を達成できるかを検査する
- 特定の誰かに向けての報告ではない
- 問題解決の場でもない（開発の課題などは別の場で解決する）
何が終わったかを明確にする
スプリントレビュー
- 実際に動作するプロダクトで確認する
- 開発チームがそれぞれ実現したものをデモする
- プロダクトオーナーは気になったことを質問し問題ないかどうかを判断する
- スプリントを始める前に考えていたことが実現できたかどうかで判断する
- 考えていたことが変わったり新しく気づいたことは判断に含めない⇒プロダクトバックログに追記
- 問題なければその項目は終了
- 問題があれば次のスプリント以降で実現するかどうかから考える
- 完了の定義はスクラムチームで合意する
- プロダクトオーナーがどこまで終わっていてほしいかを伝える
- 開発チームはどんな基準を設けるか話し合って決める
- プロダクトオーナーが本当にそれでいいかを判断する
- 完了の定義は実際のリリースで求められる品質基準とは分けて考える
状況をうまく把握する
- タスクボード（カンバン）
- スプリントバーンダウンチャート
先を予測しやすくしておく
- スプリントの期間を一定にしてどこまでできたかを計測することで全ての作業を終わらせるのにどれくらいのスプリントが必要かを予測する
- 期間内に終わらかなったものは次のタイムボックス（スプリント）に回す
次にやることを明確にする
- スプリントが予定より早く終わったらプロダクトバックログの次の項目に着手する
- 手頃な項目が無い場合は項目を分割する
- 最低限スプリントレビューでデモできる単位である必要がある（画面だけつるくなどはNG）
- 開発チームが中心となって分割などの調整した項目を書き込む
- 項目の順序はプロダクトオーナーが最終判断する
みんなの自立を促していく
ベロシティを上げていく
- ベロシティは安定が求められる
- 安定していないベロシティは予測に使えない
- 人を増やしてもベロシティはすぐに上がらない
- 引き継ぎや教育を計画する
- スクラムマスターが今より仕事を進めやすくすることを考える
- よりうまく進める方法を考える機会としてスプリントレトロスペクティブを活用する
問題を見つけやすくする
- 問題がどこにあるかをすぐに把握するためにロールがある
- それぞれのロールにはやらなければならない事があり簡単に代理できない
意図を明確にしておく
- ユーザーストーリー ：実際に使う人達の視点で機能を簡潔に記述
- ＜どういったユーザーや顧客＞として＜どんな機能や性能＞がほしいそれは＜「どんなことが達成したい＞ためだ
- ほしいものだけでなく意図を伝える
- 実現したいことの理由をスクラムチーム全員で共有する
プロジェクトを支援していく
- サーバントリーダーシップ ：スクラムマスターがスクラムチームを良い状態に保つ
より良い状態にしていく
先のことをいつも明確にする
- プロダクトバックログはいつでも誰でも書けるようにしておく
- 見積もりなおして最新の状態にしておく
- 定期的なイベントにするなどして整理する
手戻りをなくしていく
- プロダクトオーナーは直近で実現したい項目を明確にすることに注力する
- 手戻りをなくすために次のスプリントが始まる前に着手できる状態にする
- 次のスプリントの準備に10〜20％確保する
あふれそうなものを調整する
- ゴールに向けて問題が起きた時の対処法は2つ
- スコープの調整はスクラムチームとって頼みの綱であり腕の見せ所
さまざまな状況に対応する
- スクラムの開発チームに求められること
- 自己組織化 ⇒状況に応じて誰かがリーダーシップを発揮
- 機能横断的 ⇒スプリント中に必要な様々なことをチームでできるようにする
- スキルマップを作る
- プロジェクトに必要なスキルや知識を列挙する
- 開発メンバーの「得意」「経験有」「未経験」を書き込む
- 誰か一人ではなく開発チームで色々なことができるようにする
より確実な判断をしていく
- コミットメント⇒スクラムチームが現場の様々な状況から判断する
- 必ず何かを達成させるためのもので、無理をして守るものではない
- プロジェクトの大事な判断はスクラムチームでないとできない
- 失敗から学ぶ⇒失敗しても構わないので自分たちで判断する
- スプリントをくりかえしながら学ぶ
リリースに必要なことをする
- リリーススプリント ：リリースまでに必要な作業を行う期間
- セキュリティやパフォーマンスの確認、社内手続きなど
- リリースを満たす基準とスプリントの完了の定義との差分の作業
- やり方は特に決まっていない。スクラムイベントも必須ではない。
- リリーススプリントがあるからといってスプリントでできる事を後回しにしない
- 残された時間は少ないので問題が見つかればすぐに対処する必要がある
