スクラム開発入門 スプリントと スクラムイベント アジャイル・スクラム勉強会 Satoshi Harada

スプリントとは ● 完成した・利用可能な成果物を作り上げるための、１か月以 下の期間のことをスプリントと呼ぶ ► 単に開発期間を短く区切って繰り返すだけではスプリントとは 呼べない ► スプリント内で完成した・利用可能な成果物を作り、リリース 判定まで行う ► スプリントの期間は１週間が推奨されている 8月 10月 9月 計画・設計・実装・テスト・リリースを スプリント内で繰り返し実施 3ヶ月の場合の例 これが1つの スプリント

スクラムのイベント １つのスプリント期間内では、以下の５つのスクラムイベントを 開催する。 1. スプリントプランニング 初日に、スプリント期間内の計画を行う。 2. デイリースクラム 毎朝、朝会を行う。 3. スプリントレビュー 最終日に、成果物をプロダクトオーナーに見てもらう。 4. スプリントレトロスペクティブ 最終日に、スプリント期間の反省会を行う。 5. プロダクトバックログリファインメント プロダクトバックログ（優先順に並べた機能の一覧）の見直しを行 う。

スプリントプランニング ● 開催タイミング スプリント期間の初日に、一番最初に行うイベント。 ● タイムボックス（制限時間） スプリント期間が１週間の場合は最大２時間まで。 ● 何をするのか スプリント期間内で開発する機能について、開発メンバー全員でタ スク分解とタスクの所要時間の見積を行う。 この時点ではタスクに対する担当者割り振りを行わない。 ※プロダクトバックログ（優先順に並べた機能の一覧）の一番上に ある機能がスプリント期間内で開発する機能になる ● 成果物 機能に対して、分解したタスクとタスクの所要時間の一覧。 これを、スプリントバックログと呼ぶ。 ※タスクかんばんを併用する場合は、このスプリントバックログをタス クボードを用いてステータス管理する

スプリントプランニングの肝 ● タイムボックス（制限時間）を守る １週間のスプリント期間の場合、２時間でタスク分解と所要時 間の見積を行うが、開発チームの練度が上がっていないと大抵 時間をオーバーする。 絶対に制限時間を超えたらいけないわけではないが、制限時間 内に収まるように努力・工夫しなければいけない。 ※スプリントプランニングの開催前に、機能の内容を把握しておく・必要と なるタスクを予想しておくなど また、そのように制限時間を守るように促す・初期のファシリ テートをするのがスクラムマスターのお仕事。 ● スプリントのゴールを共有し、コミットする タスク分解とタスクの所要時間の見積は、開発メンバー全員で 行う。これには以下の2つの目的がある。 ► 開発メンバー全員でスプリントの成果（ゴール）を共有す る。 ► 成果（ゴール）を実現させることに対して、開発メンバー 全員のコミット（約束）を取る。

デイリースクラム ● 開催タイミング 毎朝、１日の作業を開始する前。 ● タイムボックス（制限時間） １回の朝回につき１５分程度。 ● 何をするのか 開発メンバー全員で顔を合わせ、以下の内容を順番に発言す る。 ✔ 前日の作業状況 ✔ 今日の作業予定 ✔ 何か困っていること ● 成果物 なし

デイリースクラムの肝 ● 管理者に進捗を報告する場ではない 前日の作業状況や今日の作業予定を各自が発言していくが、こ れは管理者に向けて報告することが目的ではない。 開発チームの全員に対して状況を共有することが目的なので、 特定の人（リーダーやスクラムマスター）に向かって発言をす るのではなく、開発チーム全員に向けて発言をすること。 ● 作業状況を正直に発言できる場にする 仮に予定よりも遅れがある場合でも、開発チーム内の自発的な 相互援助が発生することを期待している。 自発的な相互援助が発生するためには、開発チーム内に心理的 安全性が担保されている必要があり、以下のような空気を作っ ていく必要がある。 ✔ 他の人を支援するのは当然という共通の雰囲気 ✔ 他の人を支援したことによって仮に自分の作業が遅れたとして も、それが原因で叱責されたりしないという安心感 ✔ 他の人を支援したら、自分が困ったときもきっと支援をしてく れるはずという信頼感

スプリントレビュー ● 開催タイミング スプリント期間の最終日に実施する。 ● タイムボックス（制限時間） スプリント期間が１週間の場合は最大１時間まで。 ● 何をするのか 約束していたスプリント期間の成果物（完成させた機能）をプロダクトオーナー に見せてリリース判定を受ける。 ✔ 約束していた成果物ができあがっていない場合でも、できていないことをプロダ クトオーナーに伝えなければいけない。 ✔ プロダクトバックログ（優先順に並べた機能の一覧）には受入判定基準も書かれ ており、それに沿って受入判定を行う。 次回スプリントで開発する機能について、プロダクトオーナーと認識を合わせる （約束をする）。 ● 成果物 プロダクトオーナーのレビュー結果（受入判定結果）をプロダクトバックログに 反映する。

スプリントレトロスペクティブ ● 開催タイミング スプリント期間の最終日、スプリントレビュー後に実施する。 ● タイムボックス（制限時間） スプリント期間が１週間の場合は 最大１時間まで。 ● 何をするのか スプリント期間中で起きたこと・気がついたことについて開発 メンバー全員でふりかえり、次のスプリントがより良いものに なるように改善策を検討する。 ✔ KPTフレームワークを用いて、良かったこと・問題だったこと ・改善したいことの順に整理していくことが多い ● 成果物 次のスプリントの改善策。 ✔ 作成した改善策をプロダクトバックログや、次のスプリントの スプリントバックログに反映させるとより効果的。

プロダクトバックログリファインメント ● 開催タイミング スプリント期間中に、任意のタイミングで１回開催する。 ※プロダクトバックログの見直し結果が次回スプリントに影響するの で、スプリント期間の中間時点もしくは最終日に行うことが多い ● タイムボックス（制限時間） スプリント期間が１週間の場合は１時間程度。 ● 何をするのか プロダクトバックログ（優先順に並べた機能の一覧）について優先 順の見直しを行い、以下に挙げる機能開発のための準備ができた機 能について準備完了(Ready)にする。 ✔ 直近で開発予定の機能について、内容を把握・不明点を調査 ✔ 機能の規模が大きい場合（１スプリントでの開発が難しい場合）、 機能の分割を検討 ✔ プロダクトオーナーと協力して受入判定条件を定義 ● 成果物 優先順の見直し、および機能開発の準備まで追記したプロダクト バックログ

スクラムイベントの全体像 https://www.ryuzee.com/contents/blog/7147 出典：Ryuzee.com

雑談Time もしもプロダクトオーナーが忙 しくてスプリントレビューに参 加できない場合、どうすれば良 いと思いますか？ スプリントバックログの機能が 大きすぎて１つのスプリント期 間に収まらなそうな場合、どの ような対処が考えられますか？