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
August 17, 2020
Programming
0
130
アジャイル・スクラム勉強会_スプリントとスクラムイベント
Satoshi Harada
August 17, 2020
Tweet
Share
More Decks by Satoshi Harada
See All by Satoshi Harada
保育士チームが実践している連続的な観察と多面的な観察を共有するための振り返り / Reflection to share “continuous and multifaceted observations” as practiced by a team of childcare professionals
psj59129
0
3.7k
やってやろうじゃないかメカアジャイル! / Let's do it, mechanical agile!
psj59129
2
2.3k
保育とふりかえりをコネクト! / connect childcare and retrospectives!
psj59129
1
770
焼肉レトロスペクティブ爆誕!遊び心を解放してチームの学習を飛躍させよう
psj59129
6
9.3k
アジャイルのライトウィングとレフトウィングはひとりで両方できなくてもいいんじゃない? - “ひとりでできるもん”から“みんなでできるもん”への道のり
psj59129
0
2k
社内アジャイル勉強会コミュニティの火を燃やせ!製造業に入社して4か月でやったこと全部見せます!
psj59129
1
1.3k
Whyから始めよう!スクラムチームが力強く前に進むための「なぜやるのか」を考える
psj59129
1
2.4k
その心理的安全性は間違っている!心理的安全性で陥りやすい間違いとその対策
psj59129
0
1.4k
これからのスクラムマスターのキャリアプランの話をしよう - スクラムマスターの前に広がる世界
psj59129
0
2.8k
Other Decks in Programming
See All in Programming
複雑なフォームと複雑な状態管理にどう向き合うか / #newt_techtalk vol. 15
izumin5210
4
3.3k
Go1.24 go vetとtestsアナライザ
kuro_kurorrr
2
480
eBPF Updates (March 2025)
kentatada
0
130
私の愛したLaravel 〜レールを超えたその先へ〜
kentaroutakeda
12
3.6k
AI時代のプログラミング教育 / programming education in ai era
kishida
23
21k
OUPC2024 Day 1 解説
kowerkoint
0
400
Firebase Dynamic Linksの代替手段を自作する / Create your own Firebase Dynamic Links alternative
kubode
0
180
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
720
ニックトレイン登壇資料
ryotakurokawa
0
140
remix + cloudflare workers (DO) docker上でいい感じに開発する
yoshidatomoaki
0
120
snacks.nvim内のセットアップ不要なプラグインを紹介 / introduce_snacks_nvim
uhooi
0
350
フロントエンドテストの育て方
quramy
9
2.6k
Featured
See All Featured
Statistics for Hackers
jakevdp
798
220k
Being A Developer After 40
akosma
90
590k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Optimising Largest Contentful Paint
csswizardry
35
3.2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
12
1.4k
A designer walks into a library…
pauljervisheath
205
24k
Code Reviewing Like a Champion
maltzj
522
39k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
GitHub's CSS Performance
jonrohan
1030
460k
The Pragmatic Product Professional
lauravandoore
33
6.5k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
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つのスプリント期 間に収まらなそうな場合、どの ような対処が考えられますか?