目次
概要
Scrumについて学ぶ為にSCRUM BOOT CAMP THE BOOK（翔泳社）*1を読んだので、重要そうなポイントを以下に纏める。
Scrumとは
Agile開発を実現する為の開発手法の1つ。 基本的には、下記の要素から成り立つ。
- 3つのロール
- 6つのイベント
- 3つの成果物
- 5つの価値基準
3つのロール
下記3ロールを合わせて、Scrumチームと呼ぶ。
プロダクトオーナー（PO）
プロダクトのWhyとWhatを担当。
何に責任を持つか（何を保証するか）
プロダクトの品質と価値（投資対効果,収益性）。
特徴
- プロダクトの価値を最大化する事が役目で、プロダクトバックログ（PBL）の管理者。
- PBLの並び順の最終決定権限を持ち、開発によりPBLが完成しているかを確認する。
- Devチームと相談は行えるが、干渉はできない（直接指示出しなどはできない）。
- ステークホルダーと協力し、下記の様な項目を実施する。
- スプリントで実現するPBL（スプリントゴール）とその受入条件を明確に定義し、Devチームに共有する。
- PBLの優先順位や受入条件を定期的にメンテナンスする。
- PBLの内容をステークホルダーに説明する。
- リリース計画を定め、予算を管理する。
- PBLの作成,更新は、Devチームと協力してやる事も有るが、最終的な責任は全てPOが背負う。（POが決定した事を他人が勝手に変更してはならない。）
- Devチームが作成したPBLの成果をRVし、
受入れor却下する。
開発チーム（Dev）
プロダクトのHowを担当。
何に責任を持つか（何を保証するか）
PBLをスプリント内でどのように実現するか。
特徴
- POが定めたPBLを定められた順番に従って実現（開発）する。
- 3~9人が適切。
- 3人未満の場合は相互作用が少ない。
- 10人以上の場合はコミュニケーションコストが増える。
- 全員揃えばプロダクトを作る能力が揃う様に構成されるべきで、肩書きやサブチームは無し。
- これを
機能横断的なチームという。 - 特定の作業しかしないチームやメンバーはなるべく作らない。
- メンバー毎にできる事,できない事は有りつつも、作業を進める過程で、なるべく多くの事をできる様になる事が望ましい（作業を属人化させない）。
- これを
- Devチームの作業の進め方は、Devチームメンバーの合意でのみ決定され、外部から指示されるべきではない。
- これを
自己組織化と呼ぶ。 - Devチームで主体的に作業を進める事によって、Devチームの能力は継続的に向上する。
- これを
スクラムマスター（SM）
サーバントリーダーシップ。Scrumの門番を担当。
何に責任を持つか（何を保証するか）
Scrumプロセスの円滑性。
特徴
- Scrumプロセスを円滑に回し、プロセスの品質を担保できるように、PO,Devチームを支える。
- Scrum外部からの妨害や割り込みからPO,Devチームを守る。
6つのイベント
スプリント
目的（存在意義）
他のイベントのコンテナ（入れ物）。
- 開発期間を最長1ヶ月の繰り返し単位で区切った時の、その1区切りの事。
- 各スプリントの長さは同じでなければならない。
- 例えば、1ヶ月を4スプリントで構成する場合、5日/スプリントとなる。
- Devチームはこの期間の中で、決められた作業を行う。
- スプリント期間の大きさは、プロダクトの規模やDevチームの人数,成熟度やビジネス状況などを踏まえて決定する。
- 最短1週間、最長4週間が一般的らしい。
- スプリント最終日に作業が残っていても、スプリント期間は固定値なので、必ずスプリントは終了し、スプリント期間の延長は行わない。*2
- 固定期間で区切り、それを繰り返す事で、Devチームに集中しやすいリズムが生まれると同時に、全体のゴールに対する進捗把握やリスクへの対応が容易となる。
成果物
- インクリメント
- スプリント終わりにPOがRVする。
- 包括的なドキュメントや説明ではなく、実際に動くモノ。
スプリント計画会議（スプリントプランニング）
目的（存在意義）
スプリントを始める前に、大きく下記2点を明確にする為の会議。
①このスプリントで何を作るのか？（Why,What）
②どうやって作るのか？（How）
- スプリントの冒頭で実施する。
- 会議時間は一般的に1スプリント期間の5%分の時間。
- 1ヶ月/スプリントなら約8h。
- 第一部と第二部から構成される。
第一部
上記①をPOが明確に定義し、Devチームに共有する会。
第二部
第一部の内容を受けて、上記②をDevチームが明確に定義する会。
成果物
- スプリントゴール（スプリント目標）
- スプリントバックログ
デイリースクラム
目的（存在意義）
Devチームがスプリントゴールに向かって進んでいるかの進捗を日次で検査する事が目的。
- 基本的に、Devチームの人数に関係無く15分のタイムボックスで行い、延長はしない。
- 下記3項目をDevメンバー各自が皆に向けて報告する形式。
- スプリントゴール達成の為に、昨日何をやったか。
- スプリントゴール達成の為に、今日何をやるか。
- スプリントゴール達成に向けて、障害となるモノ（ボトルネック）が有るか。
- もし、ボトルネックが有る場合でもデイリースクラムでは問題解決方法の相談話はしない。（タイムボックスを守る事が大切。）
- 相談話は、別途それ用の会議を設ける。
- スプリントの残り時間でどの様に作業を進めていくかをPOに報告できる様にしておく。
スプリントRV
目的（存在意義）
スプリントの終わりに、スプリントの成果物（インクリメント）をPOやステークホルダーがRVし、フィードバックを得る事が目的。
スプリントレトロスペクティブやバックログリファインメントよりも前に行う。- POが主催し、RVしてもらいたいステークホルダーをPOが招待する。
- 今回のスプリントについて話し合う。
- Devチームは、プロダクトバックログの中で
できたモノ,できなかったモノを事前に整理しておく。 - スプリントで上手くいかなかった事,直面した問題,解決法なども共有,議論する。
- プレゼンテーション等による説明などではなく、実際に動くモノ（インクリメント）を見せる。
- Devチームは、プロダクトバックログの中で
- 今後のスプリントについて話し合う。
- スプリントRVに使える時間は、1スプリントの約2.5%。
- 1ヶ月/スプリントなら、4h。
スプリントレトロスペクティブ
目的（存在意義）
Devチームだけで今回のスプリントを振り返り、下記3点を決めて次に生かす事が目的。
①Keep（Devチームとして良かった点,継続したい点。）
②Problem（Devチームとしての問題点,改善すべき点。）
③Try（Devチームとして次スプリントでの挑戦事項。今後のアクションプラン。）
- もっと成果を出す為に改善すべき点を洗い出し（検査）、次回スプリント以降のアクション項目を決める。
- 1度に多くを改善しようとし過ぎると難しいので、Tryは多すぎない方が良い
- 恐らく、1〜3項目程度。
- レトロスペクティブに使える時間は、1ヶ月/スプリントなら約3h。
成果物
- KPT項目。
バックログリファインメント
目的（存在意義）
スプリントRVの結果から把握したプロダクトの現状と進捗を基に、次スプリントに向けてPBLを更新,修正する事が目的。
- PBIの追加や修正を行う。
- PBIの優先順位決めを行う。
- スプリント計画会議（スプリントプランニング）第一部にてDevに向けて説明するPBIを決定する為。
- 優先順位が高いPBIについては、着手可能な状態にする為に、受け入れ条件等の具体化を行う。
- 全体の残作業や進捗を踏まえ、今後の予定や見通しを再考する。
成果物
- 最新化されたPBL。
- スプリント計画会議（スプリントプランニング）第一部にてDevに向けて共有するPBI。
3つの成果物
プロダクトバックログ（PBL）
概要,ルール
- 機能,要求,要望,修正などの、プロダクトに必要な項目のリスト。
- プロダクトにつき1つ。
- PBLの項目は、ユーザーストーリー形式で記載する。
- ユーザーストーリーとは、「〜として、〜ができる。」など。
- 例）「ユーザーとして、ID,Passを入力してログインできる。」など。
- ユーザーストーリーとは、「〜として、〜ができる。」など。
- PBLは、一度作成して終わりではなく、常にメンテナンスして最新に保つ（項目の追加,削除,並べ替えなど）。
- 順番は優先度ではなく、明確な優先順位。実現する（したい）順番に上から並べる。
- その項目が実現された時に得られる価値やリスク,必要性などによって決定する。
- それぞれの項目は、PBL上で一意の順番を持ち、devチームはその順番に従って開発する。
- 順番は優先度ではなく、明確な優先順位。実現する（したい）順番に上から並べる。
- 優先順位上位の項目については、作業工数見積もりを済ませておく。
- 見積値は、時間などの絶対値ではなく、作業量の相対値で見積もる（基準値に対する相対見積り）。
責任者,作成者,管理者
PO。
作成されるタイミング
スプリント計画会議第一部よりも前。
スプリントバックログ（SBL）
概要,ルール
- 選択したPBLと、その具体的な作業一覧を合わせてSBLと呼ぶ。
- スプリントで実現する為に選択したPBLをどう実現するか（How）を具体的な作業として洗い出し作業計画を立てる際（スプリント計画会議第二部）の成果物。
責任者,作成者,管理者
Devチーム。
作成されるタイミング
スプリント計画会議第二部。
インクリメント
概要,ルール
- これまでのスプリントでの成果と、今スプリントで完成したPBL項目を、合わせたモノ。スプリントの成果物。
- リリースするかどうかに関わらず、実際に動いて、検査可能な状態でなければならない。
責任者,作成者,管理者
Devチーム。
作成されるタイミング
スプリント終了時。
5つの価値基準
- 確約：それぞれの人がゴールの達成に全力を尽くす事を確約する。
- 勇気：正しい事をする勇気を持ち、困難な問題に取り組む。
- 集中：全員がスプリントでの作業やゴールの達成に集中する。
- 公開：全ての仕事や問題を公開する事に合意する。
- 尊敬：お互いを能力有る個人として尊敬する。
Agileとは
VUCAの時代の中で、目的を達成し、その成果を最大化する為の考え方,概念。
詳細
Agileについての詳細は下記記事を参照。 daisukeinoue.hatenablog.com
Scrumの全体像
所感
- PBLの作成タイミングがいつなのか、明示的に示せなかった（スプリント計画会議第一部よりは前なんだろうけど。。。）。
- 開発チームの適正人数が3~9人で、10人を超えるとコミュニケーションコストが高くなってしまうルールが、個人的には腹落ちしなかった（そういう研究結果が有るんだろうけど。論文読んでみたい。）。
Scrumのルールはテンプレートで、実案件ではこれ通りにはいかない事が多いので、案件毎にカスタマイズしなければならないらしいが、下記2点がどこなのか気になった。- Scrumルールの中で比較的テンプレ通りにいきやすい点、もしくは、テンプレ通りをなるべく遵守すべき点。
- Scrumルールの中で比較的カスタマイズする事が多い点、もしくは、テンプレ通りを遵守する必要性が比較的低い点。
所感に対する追記（先輩方からのお言葉や提供情報など）
PBLの作成タイミングがいつなのか、明示的に示せなかった（スプリント計画会議第一部よりは前なんだろうけど。。。）。
スプリント計画会議第一部より前に、PBL作成用のsprintを設ける事が多いらしい。
sprint0がそれにあたるらしい。 （要勉強）
開発チームの適正人数が3~9人で、10人を超えるとコミュニケーションコストが高くなってしまうルールが、個人的には腹落ちしなかった（そういう研究結果が有るんだろうけど。論文読んでみたい。）。
Amazonのジェフベゾスが提唱しているtwo pizza teamの記事が参考になる。
Scrumルールの中で比較的テンプレ通りにいきやすい点、もしくは、テンプレ通りをなるべく遵守すべき点。
Scrumのルールとして明記されているルールやプロセス。
Scrumルールの中で比較的カスタマイズする事が多い点、もしくは、テンプレ通りを遵守する必要性が比較的低い点。
Scrumのルールとして明記されているルールやプロセスの中でも、案件を推進していく中で、案件や部署やプロダクトの特性を考慮しテーラリングすべきと考えられるような点。
*1:参考文献：https://www.amazon.co.jp/SCRUM-BOOT-CAMP-BOOK%E3%80%90%E5%A2%97%E8%A3%9C%E6%94%B9%E8%A8%82%E7%89%88%E3%80%91-%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%83%81%E3%83%BC%E3%83%A0%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA/dp/4798163686。 一部、他サイトからの補足事項アリ。
*2:ただし、状況によって、現在のスプリントでの作業が意味を為さなくなった場合などは、POの判断によってのみスプリントを中断する事も有る。
