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
120
アジャイル・スクラム勉強会_スプリントとスクラムイベント
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.3k
やってやろうじゃないかメカアジャイル! / Let's do it, mechanical agile!
psj59129
2
2.1k
保育とふりかえりをコネクト! / connect childcare and retrospectives!
psj59129
1
740
焼肉レトロスペクティブ爆誕!遊び心を解放してチームの学習を飛躍させよう
psj59129
6
9.1k
アジャイルのライトウィングとレフトウィングはひとりで両方できなくてもいいんじゃない? - “ひとりでできるもん”から“みんなでできるもん”への道のり
psj59129
0
1.9k
社内アジャイル勉強会コミュニティの火を燃やせ!製造業に入社して4か月でやったこと全部見せます!
psj59129
1
1.3k
Whyから始めよう!スクラムチームが力強く前に進むための「なぜやるのか」を考える
psj59129
1
2.3k
その心理的安全性は間違っている!心理的安全性で陥りやすい間違いとその対策
psj59129
0
1.4k
これからのスクラムマスターのキャリアプランの話をしよう - スクラムマスターの前に広がる世界
psj59129
0
2.7k
Other Decks in Programming
See All in Programming
Linux && Docker 研修/Linux && Docker training
forrep
24
4.5k
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
160
Formの複雑さに立ち向かう
bmthd
1
850
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
9
1.8k
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
10
3.6k
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
0
190
SwiftUI Viewの責務分離
elmetal
PRO
1
230
第3回 Snowflake 中部ユーザ会- dbt × Snowflake ハンズオン
hoto17296
4
370
Rails アプリ地図考 Flush Cut
makicamel
1
120
DROBEの生成AI活用事例 with AWS
ippey
0
130
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
Grafana Cloudとソラカメ
devoc
0
170
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Writing Fast Ruby
sferik
628
61k
Music & Morning Musume
bryan
46
6.3k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
The Language of Interfaces
destraynor
156
24k
Code Reviewing Like a Champion
maltzj
521
39k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
Into the Great Unknown - MozCon
thekraken
35
1.6k
Scaling GitHub
holman
459
140k
We Have a Design System, Now What?
morganepeng
51
7.4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.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つのスプリント期 間に収まらなそうな場合、どの ような対処が考えられますか?