Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
アンチパターン・オブ・アジャイル見積もり~目指すべきは、「変化を促進する計画づくり」だった~ ...
Search
面川泰明
September 18, 2020
Programming
670
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
アンチパターン・オブ・アジャイル見積もり~目指すべきは、「変化を促進する計画づくり」だった~ / go to agiled planning
面川泰明
September 18, 2020
More Decks by 面川泰明
See All by 面川泰明
Web API連携でCSRF対策がどう実装されてるか調べた / how to implements csrf-detection on Web API
yasuakiomokawa
3
4.9k
フロー効率の向上から始める開発生産性の高め方 ~ モブワークを沿えて ~ / how to go on high peformance with mob work
yasuakiomokawa
6
7.3k
チームの成功を加速するために、1on1で個人を成長させてみた / growth people makes team good with one on one meeting
yasuakiomokawa
4
3.9k
意外とカンタン!?テストコードの改善から始めるシステム開発の効率化 / a little good way to improve software using readable test codes
yasuakiomokawa
2
3.1k
1on1の「話したいことは特にないです」を解決する ~ 共感から始まる関係性改善のススメ ~ / How to solve rejection on 1on1
yasuakiomokawa
34
41k
雑にならない雑談のはじめかた | チームの気まずさを無くし、楽しさを加速させる秘訣 / Joy work with chat
yasuakiomokawa
1
1.3k
性格診断と価値観分析ではじめる1on1 | 1on1ですべりたくない人へ / one on one meeting with personality guidance
yasuakiomokawa
2
4.8k
心理的安全性に飢えた自分が一周回って辿り着いた1on1のコツ | お互いに疲弊しないための3つのポイント / How to good of 1on1 meeting with three methods
yasuakiomokawa
3
2.4k
ふりかえりの断絶を防ぐにはどうすればいいか | 課題から次のアクションをスムーズにしたい / retrospective keep on going
yasuakiomokawa
2
2.7k
Other Decks in Programming
See All in Programming
AgentCore CLI で進化した AWS での AI エージェントの作り方 : 必要な機能を必要な時に
icoxfog417
PRO
4
400
Findy - エンジニア向け会社紹介/Findy Company Deck
findyinc
6
400k
海上で動くGoサーバー: goroutineとchannelでさばく航行データストリーム
atsuki_seo
0
1k
re:Inventに行く前に知っておきたい現地参加のノウハウ
nokomoro3
0
290
Embedded Swiftで作る自作USBデバイス によるiOSデバイスの自動テスト / iOSDC Japan 2026 glassfiber
glassfiber
0
250
Verilogで学ぶCPU自作入門.pdf
uyuki234
7
3.9k
iOSDC Japan 2026 - Swiftで作って学ぼう!データベース自作入門
kaseken
2
420
[2026-09-26]空論ジェネリックプロセス~テスト資産とAIで紡ぐ、再現可能なパフォーマンスチューニングの話~
tosite
0
250
Vue Fes Japan 2026 タイムテーブル徹底解説
448jp
1
580
速く作れる。その次は、速く確かめられる開発へ 〜AIネイティブ開発を支える、Shift Down〜 / Can build fast. Next, moving to development where we can verify fast.
rkaga
8
5.3k
すこし踏み込む CancellationToken
htkym
2
1.5k
JRuby: Past, Present, and Future
headius
0
220
Featured
See All Featured
WENDY [Excerpt]
tessaabrams
14
40k
4 Signs Your Business is Dying
shpigford
187
23k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
50
10k
WCS-LA-2024
lcolladotor
0
840
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
68
58k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.8k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
390
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Transcript
アンチパターン・オブ・ アジャイル見積もり 吉祥寺.pm24【オンライン】 | 2020/9/18 | @omokawa_yasu 目指すべきは、「変化を促進する計画づくり」だった 1
2
本文 3
スクラム開発を2ヶ月、実施しました 4
本日は、見積もりに失敗した お話をします 5
状況説明 6
スクラムチーム構成 7 開発チーム(3名) プロダクトオーナー スクラムマスター
スプリント バックログ スクラム実施状況 8 デイリー スクラム 1週間の スプリント スプリント レトロスペクティ
ブ スプリント プランニング スプリント レビュー インクリメント プロダクト バックログ
スプリント バックログ 今回話す箇所 9 デイリー スクラム 1週間の スプリント スプリント レトロスペクティ
ブ スプリント プランニング スプリント レビュー インクリメント プロダクト バックログ
見積もりの「精度」が 上がらなかった 10 どんな失敗をしたか?
ストーリーの作業内容を すべて洗い出してから 見積もろうとした 11 どのように精度を上げようとしたか?
何を失敗したか? 12
時間をかけすぎた - 4ストーリーで合計4時間 - みんな疲弊した 13
かけた時間の割に、効果が出ない 見積もり通りに完了したのは、1ストーリーだけ 14
なぜ失敗したか? 15
詳細な作業内容を、想像で見積もった - 事前にいくら細かくしても。。 - ソースコードを見て初めて分かることが多かった - Salesforceとの連携など。。 - 見積もりの場にいないマーケッターに質問しないと作業内容がわから ないストーリーがあった
16
定義された要件を、鵜呑みにした - 要件定義イコール、完成された設計だと勘違いした - プロダクトオーナーは、ソースコードを知らない - 最初から細かく設計しすぎると、後から修正しづらかった 17
見積もりを一回で完璧に しようとしたのが 一番の失敗 18 要するに。。。
19 そもそも 「良い計画」とは?
“あなたの計画が不正確だったにもかかわら ず、それでもなお役に立ったといえるのは、プ ロジェクトの進行中にも計画を定期的に更新し ていた場合だ。” 20 『アジャイルな見積もりと計画づくり』 1章 2. よい計画とはなにか?
計画を定期的に更新する こと 21 大事なのは、ここ
どうすれば 変更しやすい計画がつくれるか? 22
23 1. 「機能」ではなく、「ユーザに届ける価値」を定義する 2. ストーリーポイントを、時間に置き換えない 要件定義のやり方を改善する
1. 「ユーザに届ける価値」を定義する ×)メール送信前に、ポップアップを追加したい 〇)メールの誤送信を防ぎたい 24
目的: 実現方法を、プロダクトオーナーと 開発チームで積極的に議論させたい 25
2. ストーリーポイントを、時間に 置き換えない ×) - 1 .. 2時間 - 2
.. 半日 - 3 .. 1日 - 5 .. 2日くらい 〇) ポイントのままで見積もりをする 26
目的: 「終わらせなければ」という脅迫観念を和ら げ、場当たり的な実装を減らす 27
まとめ 28
変化を促進する計画づくりを目指そう - 「最初から正解を目指す」計画づくりをしても、精度は上がらない - 精度は、「徐々に上げてゆくもの」。積極的に変化しよう 29
不確実 ゆえに成長 楽しめる 30 最後に、ここで一句