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
160
アジャイル・スクラム勉強会_スプリントとスクラムイベント
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
4.2k
やってやろうじゃないかメカアジャイル! / Let's do it, mechanical agile!
psj59129
2
3k
保育とふりかえりをコネクト! / connect childcare and retrospectives!
psj59129
1
830
焼肉レトロスペクティブ爆誕!遊び心を解放してチームの学習を飛躍させよう
psj59129
6
9.8k
アジャイルのライトウィングとレフトウィングはひとりで両方できなくてもいいんじゃない? - “ひとりでできるもん”から“みんなでできるもん”への道のり
psj59129
0
2.2k
社内アジャイル勉強会コミュニティの火を燃やせ!製造業に入社して4か月でやったこと全部見せます!
psj59129
1
1.4k
Whyから始めよう!スクラムチームが力強く前に進むための「なぜやるのか」を考える
psj59129
1
2.5k
その心理的安全性は間違っている!心理的安全性で陥りやすい間違いとその対策
psj59129
0
1.5k
これからのスクラムマスターのキャリアプランの話をしよう - スクラムマスターの前に広がる世界
psj59129
0
2.8k
Other Decks in Programming
See All in Programming
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
250
都市をデータで見るってこういうこと PLATEAU属性情報入門
nokonoko1203
1
590
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
530
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
710
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
680
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
210
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
340
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
0
370
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
260
ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質の マネジメント
takuya542
0
510
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
3.8k
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Adopting Sorbet at Scale
ufuk
77
9.4k
A better future with KSS
kneath
239
17k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
500
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
We Have a Design System, Now What?
morganepeng
53
7.7k
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つのスプリント期 間に収まらなそうな場合、どの ような対処が考えられますか?