SCRUM BOOT CAMP THE BOOKを読んでみた（基礎編）

SCRUM BOOT CAMP THE BOOK の基礎編を読んだ時に参考になった考え方や用語について説明したいと思います。
もし、これから Scrum を初めてみようと思っている方がいれば参考にしてもらえればと思います。

SCRUM BOOT CAMP THE BOOK: スクラムチームではじめるアジャイル開発 

増補改訂版も出てるみたいです。

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 

アジャイル開発とは

• 関係者は目的の達成の為にお互いに協力し合いながら進める。
• 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する。
• 一度にまとめてではなく、少しずつ作る。そして実際に出来上がったものが求めているものと合っているかを頻繁に確認する。

アジャイル開発が持つ前提

• 事前に全てを正確に予測し、計画することはできない。

SCRUMとは

• アジャイル開発の1つ
• 作業、会議、成果物を定めたもの

SCRUMの特徴

• 要求を常に順番に並べ替え、その順にプロダクトをつくることで成果を最大化する。
• Scrum では実現されている「価値」や「リスク」や「必要性」を基準にする。
• 固定の短い時間に区切って、作業を進める。（＝タイムボックス）
• 現在の状況や問題点を常に明らかにする。（＝透明性）
• 定期的に進捗状況や作っているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認する。（＝検査）
• やり方に問題があったり、もっとうまくできる方法があれば、やり方そのものを変える。（＝適応）

上記を継続的に実施し、プロジェクトを進める。

Scrum では仕事の進め方にフォーカスした最低限のルールだけを定めている。
→ ルールをどのように実際に適用していくかは自分たちで考える。

Scrumで決められていること

要求を並べ替える

成果物１：プロダクトバックログ

• 実現したい要求をリストにして並び替える。
• 常にメンテナンスして最新に保つ。

順番は、その要求が実現されたときに得られる価値、リスク、必要性等によって決定される。
一度作って順番に並び替えたら完成ではない。プロダクトをつくっている間は常に修正され、最新に保たなければならない。

書き方は特に決まりはないが、ユーザストーリーと呼ばれる形式で書くことが一般的。

プロダクトの責任者

ロール１：プロダクトオーナー

• プロダクトの結果責任を取る。
• プロダクトバックログの管理者で並び順の最終決定権限を持つ。
• プロジェクトに必ず一人必要。
• 開発チームを活用して、プロダクトの価値を最大化する。
• 開発チームに相談できるが、干渉はできない。

プロダクトオーナーがやること

• プロダクトのビジョンを明らかにし、周りと共有する。
• おおよそのリリース計画を定める。
• 予算を管理する。
• 顧客、プロダクトの利用者や経営者などのプロジェクト関係者と、プロダクトバックログの項目の内容を確認したり、つくる順番や実現時期を相談したりする。
• 既存のプロダクトバックログの項目の内容を最新の状態に更新する。
• プロダクトバックログの項目の内容を関係者が理解できるように説明する。
• 作られたプロダクトが要求に合っているかどうか検査する。

動作するプロダクトを開発する

ロール２：開発チーム

• リリース判断可能なプロダクトを作る。
• 3人〜9人で構成する。
• 全員揃えばプロダクトを作れる。
• 上下関係はない。

開発チームが3人未満の場合
お互いの相互作用が少なかったり、個人のスキルに依存する場合が多くなり、開発チームとして活動した効果が出にくくなる。

開発チームが10人以上の場合
コミュニケーションコストが増えることによって開発チームのスピードが落ちる。

プロダクトを作る為に必要な全ての作業ができなければならない。
機能横断的なチームであること

開発チーム内では年齢や役職などによる上下関係はない。
開発チーム内での仕事の進め方は、開発チームのメンバーの合意のもとに決められ、外部から仕事の進め方を指示されることがあってはならない。
あくまで開発チーム全体で責任を持って作業を進める。（＝自己組織化されたチーム）

開発チーム主体で作業を進めることで、開発チームの能力を継続的に向上させる。

短く区切ってくりかえす

スプリント

• スプリント期間は固定する。
• スプリント期間が変動してはいけない。

スプリントの期間の中で計画、設計、開発、テスト等のプロダクトのリリース判断に必要な全てのことを行います。

スプリントの最終日に作業が残っていても、スプリントは終了し、期間は延長しない。

スプリント期間は、プロダクトの規模や開発チームの人数や成熟度、ビジネスの状況等を踏まえて決定する。
短ければ1週間、長くて4週間、週単位で設定されることが多い。

頻繁に計画する

会議体１：スプリント計画ミーティング

• スプリントで開発をする為には計画が必要
• プロダクトオーナーは何を欲しいのか（第一部）
• 開発チームはどれくらいでできそうか（第一部）
• 開発チームはどうやってそれを実現するか（第二部）

スプリントで何を作るのか（ What ）、どのように作るのか（ How ）を計画する

スプリント計画ミーティングに使える時間は一ヶ月スプリントであれば8時間、2週間スプリントであれば4時間

スプリント計画ミーティングは二部構成で行われる

第一部

参加者
プロダクトオーナー、開発チーム、スクラムマスター

内容
どのプロダクトバックログの項目を開発するのかを検討し、内容を確認する。
開発する量は過去のスプリントの実績と今後の予測を参考に決定する。
この過去の実績のことをベロシティと呼ぶ

プロダクトバックログの順位が上のものから順に、今回のスプリントで開発する対象として検討を行う。
プロダクトバックログの上位の項目は、なるべく具体的な計画ができるように、そして、
計画が終了したらすぐに開発を行えるように内容を事前に詳細化しておく必要がある。
あらかじめ受け入れ基準を用意することもある。

第一部で検討した内容を踏まえて今回のスプリントの目標を簡潔にまとめる。（＝スプリントゴール）

第二部

参加者
開発チーム

内容
第一部で選択したプロダクトバックログの項目を完了させる為に、必要な全ての作業を洗い出す。

タスクの一覧＝スプリントバックログ＝開発チームの作業計画
スプリント期間中も自由にタスクを追加したり削除したりすることができる。
個々のタスクは1日以下の単位とする。

成果物２：スプリントバックログ

• プロダクトバックログを具体的なタスクに分割する。
• タスクは後から増えることもある。

タスクを洗い出した結果、開発チームがスプリント中にタスクを完了できないと判断した場合は、プロダクトオーナーと相談し、選択したプロダクトバックログの項目の一部を外したり、実装の方式を検討し直すことによって、作業量を調整する。

注意

開発チームはスプリント計画で合意した内容を完了させることについて全力を尽くす必要はあるものの、計画したことを全て完了させることを約束している訳ではない。

なぜか？
全ての完了を約束してしまうと、見積もりが外れたり、難易度が高かったり、不足の事態が発生した場合に、開発チームが長時間残業したり、必要な作業を省いてしまい、その結果、プロダクトに様々な問題が発生してしまうため。

スプリントバックログの項目の担当を特定の人が決めることはない。
スプリント計画会議の時点で、全ての項目の担当を決めることもない。
実際に着手するときに、作業する人自身がスプリントバックログの項目を選択するようにする。

リリース判断可能とは

成果物３：リリース判断可能なプロダクト

• 開発チームはリリース判断可能なプロダクトを作る。

スプリント単位でリリース判断可能なプロダクトを作ることが求められる。
プロダクトオーナーと開発チームが「リリース判断可能」の指す内容について共通の基準を持つ必要がある。（＝完了の定義）

開発チームは、この定義を満たしたプロダクトを作らなければならない。

完了の定義は、品質基準と言い換えることもできる。
途中で定義の追加はできるが、削除すると要求される品質を達成できなくなるのでさけた方がよい。

完了の定義

• 完了の定義によって、何をもってリリース判断可能かを定める。
• 途中での縮小は避ける。

毎日状況を確認する

会議体２：デイリースクラム

• 開発チームの状況を毎日確認する。

スプリント期間中、開発チームは毎日、同じ場所、同じ時間に状況を確認する為の会議をする。
15分間のタイムボックスで行われ、延長できない。

デイリースクラムの内容

• 前回のデイリースクラムからやったこと
• 次回のデイリースクラムまでにやること
• 困っていること

スプリントがゴールに向かって進んでいるか、作業の進捗はどうなっているか、
メンバー間の協力が必要なことがないか等を確認する。

開発チームのための会議であり、特定の誰かに向けての報告会議ではない。
問題解決の場ではない。

問題を報告した場合は、デイリースクラム終了後に改めて、問題解決に必要な人を集めた別の会議を設定する。

デイリースクラムの結果を踏まえて、開発チームはスプリントの残り時間でどのように
作業を進めるかについて、プロダクトオーナーやスクラムマスターに報告できるようにしておく。

できあがったプロダクトを確認する

会議体３：スプリントレビュー

• 開発チームの成果物をプロダクトオーナーが確認する。

スプリントの最後にプロダクトオーナーがプロダクトを確認する機会を設定する。
開発チームがスプリント中に作り終わったプロダクトバックログの項目を確認する。
開発チームは確認用の環境等を用意して、作ったものを見ながら確認できるようにする。
実際に操作しながら説明を行う。

プロダクトバックログの項目が依頼した通りのものであれば作業完了と判断する。
依頼したものと異なる場合は、作業は完了していないものとし、プロダクトバックログに戻す。

スプリントごとにプロダクトが要求通りに作られているかを検査することで、最後にまとめて確認して多くの手戻りが出たりすることを避ける。

スプリントレビューで確認するのはあくまでも実際に動作するプロダクトである。

スプリントレビューで実施すること

• 開発チームが完了できなかったプロダクトバックログの項目について説明する。
• プロダクトオーナーがプロダクトの状況やビジネスの環境について説明する。
• プロダクトバックログに追加すべき項目の有無について議論する。
• プロジェクトを進めるうえで問題となっている事項について関係者で議論する。
• 現在の進捗を踏まえて、リリース日や完了日を予測する。

使える時間

一ヶ月スプリントであれば4時間、2週間スプリントであれば2時間実施する

もっとうまくできるはず

会議体４：スプリントレトロスペクティブ（振り返り）

• プロセスやツール等の観点で今回のスプリントを検査する。
• うまくいったこと、今後改善すべき点を整理する。
• 今後のアクションプランをつくる。

直近のスプリントでのプロダクトの開発に関わる活動において問題がなかったか、もっと成果を出す為にできることがないか検査を行い、次回のスプリント以降のアクションプランを決める。

より効果がありそうな項目から取り組んで、より成果が出せるように自分たちの仕事のやり方を変える。

使える時間

一ヶ月スプリントであれば4時間、2週間スプリントであれば2時間
スプリントの期間に関係なく毎週レトロスペクティブを実施する例もある。

縁の下の力持ち

ロール３：スクラムマスター

• このプロセスがうまくまわるようにする。
• 妨害を排除する。
• 支援と奉仕をする。
• 教育、ファシリテート、コーチ、推進役。

プロセスを円滑にまわして、プロダクトをうまくつくれるようにプロダクトオーナーや開発チームを支える。

Scrum のルールや成果物、進め方をプロダクトオーナーや開発チームに理解させ、効果的な実践を促し、 Scrum 外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守る。

Scrum になれていない時期
先生役やトレーナーとして振る舞う。

Scrum になれてきた時期
プロダクトオーナーや開発チームの求めに応じて作業を助けたり、よりうまく仕事を進められる様なヒントを与える。

スクラムマスターが実施すること

• わかりやすいプロダクトバックログの書き方をプロダクトオーナーや開発チームに教える。
• プロダクトバックログの良い管理方法を探す。
• プロダクトオーナーや開発チームに、アジャイル開発やScrumについて説明して理解してもらう。
• スプリント計画ミーティングやスプリントレトロスペクティブ等の会議の進行を必要に応じて行う。
• プロダクトオーナーと開発チームの会話を促す。
• プロダクトオーナーや開発チームの生産性が高くなるように変化を促す。

仕事を進める上で妨げとなっていることをリスト化（＝妨害リスト）し、優先順位をつけて解決の方法を検討し、必要に応じて、しかるべき人に解決を依頼するといったことも行う。

プロダクトオーナー、開発チーム、スクラムマスターを合わせて、スクラムチームと呼ぶ。

最後に

SCRUM BOOT CAMP THE BOOK の基礎編について、いろいろまとめてみましたが、もし、「もっと詳しく知りたい」と言った方がいましたら、一度本を読んでみることをオススメします。今までのウォーターフォール型の開発とは異なる考え方などがあり、参考になることも多いと思います。

SCRUM BOOT CAMP THE BOOK: スクラムチームではじめるアジャイル開発 

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発