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
RCPと宣言型ポリシーについてのお話し
kokitamura
2
150
パスキーのすべて / 20250324 iddance Lesson.5
kuralab
0
120
フロントエンドテストの育て方
quramy
9
2.5k
NestJSのコードからOpenAPIを自動生成する際の最適解を探す
astatsuya
0
180
体得しよう!RSA暗号の原理と解読
laysakura
3
530
なぜselectはselectではないのか
taiyow
2
310
Develop Faster With FrankenPHP
dunglas
2
2.4k
S3静的ホスティング+Next.js静的エクスポート で格安webアプリ構築
iharuoru
0
190
Coding Experience Cpp vs Csharp - meetup app osaka@9
harukasao
0
110
令和トラベルにおけるコンテンツ生成AIアプリケーション開発の実践
ippo012
1
260
読もう! Android build ドキュメント
andpad
1
240
Devin入門と最近のアップデートから見るDevinの進化 / Introduction to Devin and the Evolution of Devin as Seen in Recent Update
rkaga
7
3.7k
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
28
1.6k
Documentation Writing (for coders)
carmenintech
69
4.7k
For a Future-Friendly Web
brad_frost
176
9.6k
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
177
52k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.4k
Git: the NoSQL Database
bkeepers
PRO
429
65k
Agile that works and the tools we love
rasmusluckow
328
21k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
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つのスプリント期 間に収まらなそうな場合、どの ような対処が考えられますか?