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
まりも
September 24, 2024
Programming
0
25
スプリント計画の手順
スプリント計画は、TDDと並んで、非常にシンプルでありながら緻密に計画を立てられるルーチンになっていますが、なんとなくやっていると意味がよくわかりません。その辺について解説しました。
まりも
September 24, 2024
Tweet
Share
More Decks by まりも
See All by まりも
メンタルモデルから見るオブジェクト設計
hrmstrsmgs
0
200
技術的負債
hrmstrsmgs
0
220
よい設計のプログラムを作るには
hrmstrsmgs
0
73
歴史から理解するJavaScript
hrmstrsmgs
0
56
論理的な考え方
hrmstrsmgs
0
56
論理的な話し合いはなぜ必要か
hrmstrsmgs
0
27
腕のある技術者はなぜ
hrmstrsmgs
0
71
疑似乱数の生成
hrmstrsmgs
0
39
構造化プログラミング
hrmstrsmgs
0
130
Other Decks in Programming
See All in Programming
なぜGoのジェネリクスはこの形なのか? - Featherweight Goが明かす設計の核心
qualiarts
0
250
GC25 Recap: The Code You Reviewed is Not the Code You Built / #newt_gophercon_tour
mazrean
0
110
kiroとCodexで最高のSpec駆動開発を!!数時間で web3ネイティブなミニゲームを作ってみたよ!
mashharuki
0
910
Software Architecture
hschwentner
6
2.3k
Cursorハンズオン実践!
eltociear
2
1.2k
Things You Thought You Didn’t Need To Care About That Have a Big Impact On Your Job
hollycummins
0
250
AkarengaLT vol.38
hashimoto_kei
1
120
Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地
imkaoru
4
890
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
470
contribution to astral-sh/uv
shunsock
0
540
組込みだけじゃない!TinyGo で始める無料クラウド開発入門
otakakot
2
370
技術的負債の正体を知って向き合う
irof
0
250
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
303
21k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
4 Signs Your Business is Dying
shpigford
185
22k
Code Reviewing Like a Champion
maltzj
526
40k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
Keith and Marios Guide to Fast Websites
keithpitt
411
23k
Stop Working from a Prison Cell
hatefulcrawdad
272
21k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Transcript
スプリント計画の手順
スクラムのシステムを理解するのに重要 なこと • 先に延ばせば先に延ばすほど情報が増える • キチンとアジャイル的に進めておかないと できませんね 決定はできるだけ先に延ばす
スクラムのシステムを理解するのに重要 なこと 想定外のことに対する対策を事前に行う 具体的に、どんな問題が起こるか? わかりません。 でも対策は万全です。
スクラムのシステムを理解するのに重要 なこと • 間に合うように頑張れとかそういうこと は言わない。 • 必須の機能だから無理やり押し込むとか やらない。 • できることを粛々とやる。
精神論は 徹底排除
精神論について補足 • それがアジャイルの目的 顧客の難しい要望を聞くのは大事ですからね • やりますと言っても結局できないから顧客のためにならない • いかに無理ですと言わずに実質断る方向にもっていくかを考えるとかいかに も無駄な労力 •
そういう交渉がどうしても必要な場合はプロダクトオーナーに一任すべき 無理なことを断れないのがよくない
スクラムのシステムを理解するのに重要 なこと 常にホームポジションを 保つ
スクラムのシステムを理解するのに重要 なこと コンテナ
スクラムのシステムを理解するのに重要 なこと •誤差以下の数字を丁寧に計算しているのはとても無駄です •誤差以下を省きながら計算をすると大体暗算で済むので俊敏な管理ができます 誤差 •平均×数=合計という計算方法は役に立ちます •判断するときに誤差を減らすために重要です •ある程度の数の平均を取ると、109109 •1が減るので無視できます 平均
•確実なことなど何もない。 •全ては期待値。 確率
スクラムの計画の由来 たぶんXP由来 •ケント・ベックは偉大 •いや関係ないかもしれませんけど
スクラムの計画 前提条件の決定 バックログ・ストーリー整理 ストーリーポイント見積もり 計画の決定 タスクわけ
前提条件の決定 終了条件 •リファクタリング •自動テスト •CI/CD •…etc
前提条件の決定 ルールを明確にする •終了条件など
バックログ・ストーリー整理 最新情報に合わせて整理。 必要に応じて分割 …etc
バックログ・ストーリー整理 曖昧である現実を受け止める •整理ための整理はしない •整理する必要があるものを整理する •曖昧でいいものは曖昧のままのほうが扱いやすい
ストーリーポイント見積もり ストーリーポイントを見積もる 以前のストーリーポイントと比較して 全員で数字を出す 意見が分かれたら話し合い
なぜ時間を使わないか? 時間見積もったら必ず実際より少なく予 測されるってみんな分かり切ってるで しょ? • なんでわざわざ目盛りが狂っているこ とが分かっている測りにこだわるの? 時間見積もりの誤差は±が均等にならな いことが分かっているが、個人の誤差の 比率は平均して一定であることが経験則
としてわかっている。 • 比を取ることにより、誤差が±0になる
フィボナッチ数列 1,2.3.5.8.13,21のフィボナッチ数列で 意味のない細かい差で悩むことを防ぐ 分割しやすい 覚えやすい
ヴェロシティ ヴェロシティ ストーリーポイントの合計 適度な数を合計することにより、 誤差は気にしなくてよくなる • 見積もり誤差 • 個人の作業効率の差
計画の決定 前回のヴェロシティと同じストーリーポイントだけ選ぶ 優先順位+工数も加味した選択ができる 比で計算することにより、相対的な大きさ以外の要素は全 て計算する必要はない
タスクわけ これは普通のタスクわけ 作業者に分配しやすいように細かく分ける 作業管理がしやすいように細かく分ける なんとなくやっていると時間がかかるので注意