スクラム開発入門スプリントとスクラムイベントアジャイル・スクラム勉強会Satoshi Harada
View Slide
スプリントとは● 完成した・利用可能な成果物を作り上げるための、1か月以下の期間のことをスプリントと呼ぶ► 単に開発期間を短く区切って繰り返すだけではスプリントとは呼べない► スプリント内で完成した・利用可能な成果物を作り、リリース判定まで行う► スプリントの期間は1週間が推奨されている8月 10月9月計画・設計・実装・テスト・リリースをスプリント内で繰り返し実施3ヶ月の場合の例これが1つのスプリント
スクラムのイベント1つのスプリント期間内では、以下の5つのスクラムイベントを開催する。1. スプリントプランニング初日に、スプリント期間内の計画を行う。2. デイリースクラム毎朝、朝会を行う。3. スプリントレビュー最終日に、成果物をプロダクトオーナーに見てもらう。4. スプリントレトロスペクティブ最終日に、スプリント期間の反省会を行う。5. プロダクトバックログリファインメントプロダクトバックログ(優先順に並べた機能の一覧)の見直しを行う。
スプリントプランニング● 開催タイミングスプリント期間の初日に、一番最初に行うイベント。● タイムボックス(制限時間)スプリント期間が1週間の場合は最大2時間まで。● 何をするのかスプリント期間内で開発する機能について、開発メンバー全員でタスク分解とタスクの所要時間の見積を行う。この時点ではタスクに対する担当者割り振りを行わない。※プロダクトバックログ(優先順に並べた機能の一覧)の一番上にある機能がスプリント期間内で開発する機能になる● 成果物機能に対して、分解したタスクとタスクの所要時間の一覧。これを、スプリントバックログと呼ぶ。※タスクかんばんを併用する場合は、このスプリントバックログをタスクボードを用いてステータス管理する
スプリントプランニングの肝● タイムボックス(制限時間)を守る1週間のスプリント期間の場合、2時間でタスク分解と所要時間の見積を行うが、開発チームの練度が上がっていないと大抵時間をオーバーする。絶対に制限時間を超えたらいけないわけではないが、制限時間内に収まるように努力・工夫しなければいけない。※スプリントプランニングの開催前に、機能の内容を把握しておく・必要となるタスクを予想しておくなどまた、そのように制限時間を守るように促す・初期のファシリテートをするのがスクラムマスターのお仕事。● スプリントのゴールを共有し、コミットするタスク分解とタスクの所要時間の見積は、開発メンバー全員で行う。これには以下の2つの目的がある。► 開発メンバー全員でスプリントの成果(ゴール)を共有する。► 成果(ゴール)を実現させることに対して、開発メンバー全員のコミット(約束)を取る。
デイリースクラム● 開催タイミング毎朝、1日の作業を開始する前。● タイムボックス(制限時間)1回の朝回につき15分程度。● 何をするのか開発メンバー全員で顔を合わせ、以下の内容を順番に発言する。✔ 前日の作業状況✔ 今日の作業予定✔ 何か困っていること● 成果物なし
デイリースクラムの肝● 管理者に進捗を報告する場ではない前日の作業状況や今日の作業予定を各自が発言していくが、これは管理者に向けて報告することが目的ではない。開発チームの全員に対して状況を共有することが目的なので、特定の人(リーダーやスクラムマスター)に向かって発言をするのではなく、開発チーム全員に向けて発言をすること。● 作業状況を正直に発言できる場にする仮に予定よりも遅れがある場合でも、開発チーム内の自発的な相互援助が発生することを期待している。自発的な相互援助が発生するためには、開発チーム内に心理的安全性が担保されている必要があり、以下のような空気を作っていく必要がある。✔ 他の人を支援するのは当然という共通の雰囲気✔ 他の人を支援したことによって仮に自分の作業が遅れたとしても、それが原因で叱責されたりしないという安心感✔ 他の人を支援したら、自分が困ったときもきっと支援をしてくれるはずという信頼感
スプリントレビュー● 開催タイミングスプリント期間の最終日に実施する。● タイムボックス(制限時間)スプリント期間が1週間の場合は最大1時間まで。● 何をするのか約束していたスプリント期間の成果物(完成させた機能)をプロダクトオーナーに見せてリリース判定を受ける。✔ 約束していた成果物ができあがっていない場合でも、できていないことをプロダクトオーナーに伝えなければいけない。✔ プロダクトバックログ(優先順に並べた機能の一覧)には受入判定基準も書かれており、それに沿って受入判定を行う。次回スプリントで開発する機能について、プロダクトオーナーと認識を合わせる(約束をする)。● 成果物プロダクトオーナーのレビュー結果(受入判定結果)をプロダクトバックログに反映する。
スプリントレトロスペクティブ● 開催タイミングスプリント期間の最終日、スプリントレビュー後に実施する。● タイムボックス(制限時間)スプリント期間が1週間の場合は最大1時間まで。● 何をするのかスプリント期間中で起きたこと・気がついたことについて開発メンバー全員でふりかえり、次のスプリントがより良いものになるように改善策を検討する。✔ KPTフレームワークを用いて、良かったこと・問題だったこと・改善したいことの順に整理していくことが多い● 成果物次のスプリントの改善策。✔ 作成した改善策をプロダクトバックログや、次のスプリントのスプリントバックログに反映させるとより効果的。
プロダクトバックログリファインメント● 開催タイミングスプリント期間中に、任意のタイミングで1回開催する。※プロダクトバックログの見直し結果が次回スプリントに影響するので、スプリント期間の中間時点もしくは最終日に行うことが多い● タイムボックス(制限時間)スプリント期間が1週間の場合は1時間程度。● 何をするのかプロダクトバックログ(優先順に並べた機能の一覧)について優先順の見直しを行い、以下に挙げる機能開発のための準備ができた機能について準備完了(Ready)にする。✔ 直近で開発予定の機能について、内容を把握・不明点を調査✔ 機能の規模が大きい場合(1スプリントでの開発が難しい場合)、機能の分割を検討✔ プロダクトオーナーと協力して受入判定条件を定義● 成果物優先順の見直し、および機能開発の準備まで追記したプロダクトバックログ
スクラムイベントの全体像https://www.ryuzee.com/contents/blog/7147出典:Ryuzee.com
雑談Timeもしもプロダクトオーナーが忙しくてスプリントレビューに参加できない場合、どうすれば良いと思いますか?スプリントバックログの機能が大きすぎて1つのスプリント期間に収まらなそうな場合、どのような対処が考えられますか?