Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アジャイル・スクラム勉強会_スプリントとスクラムイベント
Search
Satoshi Harada
February 01, 2023
Programming
0
77
アジャイル・スクラム勉強会_スプリントとスクラムイベント
Satoshi Harada
February 01, 2023
Tweet
Share
More Decks by Satoshi Harada
See All by Satoshi Harada
やってやろうじゃないかメカアジャイル! / Let's do it, mechanical agile!
psj59129
1
1.2k
保育とふりかえりをコネクト! / connect childcare and retrospectives!
psj59129
1
420
焼肉レトロスペクティブ爆誕!遊び心を解放してチームの学習を飛躍させよう
psj59129
6
7.5k
WIP制限体験ワークショップ
psj59129
0
150
アジャイルのライトウィングとレフトウィングはひとりで両方できなくてもいいんじゃない? - “ひとりでできるもん”から“みんなでできるもん”への道のり
psj59129
0
1.5k
社内アジャイル勉強会コミュニティの火を燃やせ!製造業に入社して4か月でやったこと全部見せます!
psj59129
1
1.1k
アジャイル・スクラム勉強会_なぜ今、アジャイルなのか?
psj59129
0
120
アジャイル・スクラム勉強会_カンバンボードを採用する理由
psj59129
0
52
アジャイル・スクラム勉強会_カンバンボードとWIP
psj59129
0
89
Other Decks in Programming
See All in Programming
Progressive Web Apps for Rails developers
siaw23
2
530
GitHub Copilot Workspace で我々のアプリ開発がどう変わるのか?
shuyakinjo
0
860
利用者視点で考える、イテレータとの上手な付き合い方
syumai
4
210
CDKを活用した 大規模コンテナ移行 プロジェクトの紹介
yoyoyopg
0
240
実践Dash - 手を抜きながら本気で作るデータApplicationの基本と応用 / Dash for Python and Baseball
shinyorke
2
230
DevFest Android in Korea 2024 - 안드로이드의 문단속 : 앱을 지키는 암호화 이야기
mdb1217
1
130
C#および.NETに対する誤解をひも解く
ymd65536
0
230
Делим тесты между QA и разработчиком
mariyasaygina
0
500
Removing Corepack
yosuke_furukawa
PRO
9
1.1k
The Efficiency Paradox and How to Save Yourself and the World
hollycummins
0
150
XP2024 っていう国際会議に行ってきたよの記 / XP2024 Conference Report
bonotake
4
180
ROS 2のZenoh対応とZenohのROS 2対応
takasehideki
2
260
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
65
9.9k
Large-scale JavaScript Application Architecture
addyosmani
509
110k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
7.5k
How STYLIGHT went responsive
nonsquared
94
5.1k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
What's new in Ruby 2.0
geeforr
341
31k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Atom: Resistance is Futile
akmur
261
25k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
7
560
Git: the NoSQL Database
bkeepers
PRO
425
64k
Agile that works and the tools we love
rasmusluckow
327
21k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
663
120k
Transcript
スクラム開発入門 スプリントと スクラムイベント アジャイル・スクラム勉強会 Satoshi Harada
スプリントとは • 完成した・利用可能な成果物を作り上げるための、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つのスプリント期 間に収まらなそうな場合、どの ような対処が考えられますか?