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
Doneの定義虎の巻
Search
Ryutaro YOSHIBA
April 13, 2012
Technology
2
2.6k
Doneの定義虎の巻
2011/12にスクラム道場で話した内容。質問等あれば@ryuzeeまたは
http://www.ryuzee.com/
まで
Ryutaro YOSHIBA
April 13, 2012
Tweet
Share
More Decks by Ryutaro YOSHIBA
See All by Ryutaro YOSHIBA
Vagrant (+Amazon EC2)
ryuzee
16
6.3k
CakePHP+Jenkinsによるアジャイル開発 #phpmatsuri
ryuzee
34
14k
自動テストvs手動テスト
ryuzee
1
2k
Agileってなんだっけ?
ryuzee
2
160
20110127_devloveテストの話.pdf
ryuzee
0
120
スプリントバーンダウンチャート虎の巻 #scrumdo
ryuzee
1
450
アジャイルコーチで学んだ30+αのこと
ryuzee
2
210
Agile Japan '12 Agileな開発からAgileな組織へ
ryuzee
3
400
ワンクリックデプロイ101
ryuzee
2
310
Other Decks in Technology
See All in Technology
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
0
15k
同一クラスタ上でのFluxCDとArgoCDのリソース最適化の話
kumorn5s
0
160
Amazon Bedrock Multi-Agent Collaboration Workshop の紹介 - ワークショップでAIエージェントを学ぼう
nasuvitz
4
360
Replit Agent
kawaguti
PRO
2
210
【AWS re:Invent 2024】Amazon Bedrock アップデート総まとめ
minorun365
PRO
7
660
TimeTreeが経た3つの転換点 ー プロダクト成長過程でその時、その瞬間、何を考えてたか
ysmtysts
1
3.9k
検証と資産化を形にするプロダクト組織へ/tapple_pmconf2024
corin8823
1
10k
イベントをどう管理するか
mikanichinose
1
120
コーポレートデータマスター構築への道
kworkdev
PRO
0
140
AWS re:Invent 2024 re:Cap CloudFront編
yoshimi0227
0
180
ミスが許されない領域にAIを溶け込ませる プロダクトマネジメントの裏側
t01062sy
8
8.7k
tokyo_re_Growth2024_yoshi
yoshi22
0
120
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Designing Experiences People Love
moore
138
23k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
420
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.2k
Faster Mobile Websites
deanohume
305
30k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Become a Pro
speakerdeck
PRO
25
5k
Transcript
Doneの定義 ⻁虎の巻 2011/12/26 スクラム道場.08 @Ryuzee #scrumdo http://bit.ly/tHvlJa
吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/
今⽇日の進め⽅方 ü 読み⼿手がしゃべります(30分) ü その間に質問とか議論論したい内容を付箋に書い てください ü 休憩+付箋分類とか(5分) ü あとは議論論。活発に。個⼈人批判はしないこと ü 20:55に撤収準備。ゴミは持ち帰るか所定のゴ ミ箱等に捨ててください。
プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 チーム (6±3⼈人) プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限
の努⼒力力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリント 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす Doneの定義 何をもって「完了了」とするかを 定義したリスト 毎⽇日の繰り返し デイリースクラム 毎⽇日チームが以下の3つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする タスク 時間で⾒見見 積もり
Scrumのキホン Cancel Return スプリント 2~∼4週間 返品 スプリントゴール スプリント バックログ プロダクトバックログ
ギフト包装 クーポン キャンセル 24時間 出荷可能 な製品 スプリント最後には 出荷可能な製品の増 分が出来上がる
出荷可能な製品? ü 何をもって出荷可能とするかは製品によって異異 なる ü 実際に出荷するかどうかはプロダクトオーナー に意思決定権限がある ü Time to Marketの観点からは早く出荷したほう が当然良良い ü 出荷後の保守やサポートのことも考える
http://bit.ly/tvFaGT
銀⾏行行、医療療、携帯電話、Webサイトのど れもが同じ品質⽔水準を求められるわけで はない! http://www.flickr.com/photos/30854583@N07/4424574772/ http://www.flickr.com/photos/christianacare/4642178916/ http://www.flickr.com/photos/phossil/4849753531/ http://www.flickr.com/photos/deia/2235006720/
社内品質基準? h"p://bit.ly/uiSNmo 顧客の期待と 関係ない (ことがほとんど)
Ready?? ゴールが 分かっている http://bit.ly/sBsLi5
Doneの定義 何ができたら 完了なのかを 決める
Doneの定義とは? ü プロジェクトとして定めた「出荷可能な製品」 を作成するために実施しなければいけないこと の⼀一覧。 ü 例例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く、レ ビューするなど ü ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすると分かりやすい。
なぜDoneの定義が必要? ü もしDoneの定義がなかったら? このストーリー出来上がりましたよ! 終わってないだろ?? ⾃自動化されたテストもないし、リファク タリングもされてない。それをするのは 常識識だろ? まーた後出しジャンケンか。。。 どこまでやっていいかわからんなぁ
All or Nothing
終わったか? 終わってないか? ただそれだけで判断 するべきである
http://bit.ly/uqQxk3 進捗の透明性
あいまいさ の排除
【悪い例】 ソースコードが綺麗なこと 【良い例】 ソースコードをCChheecckkSSttyyllee で検証し、重要度NN以上の違 反がないこと
【悪い例】 多くのブラウザで動作 すること 【良い例】 IIEE77--99,,FFFF33,, CChhrroommeeで動作すること IIEE66では表示が崩れないこと
Doneの定義充⾜足の検証 自動化できるものは自動で h"p://bit.ly/sP6BvN
誰が決める? h"p://bit.ly/vymcXJ PPOO+SSMM+チーム
どうやって決める? 11..必要な作業を付箋に書きだす http://bit.ly/sVUXCf
どうやって決める? ストーリー スプリント リリース 2..実施タイミングでグループ分け
いつ決める? 見積や契約 の前に大枠 が決まって いるべき http://bit.ly/u0idYi
荒ぶる四天王 品質は固定パラメータ http://bit.ly/vT9CmC
Doneの定義のサンプル1 http://bit.ly/tCotIz
ストーリーのDoneの定義 ü テストコード、プロダクションコード含め全て のコードがチェックインされている ü 全てのユニットテストをパスしている ü 全ての受け⼊入れテストが⽤用意され、それにパス している ü ヘルプファイルが⾃自動で作られている ü 機能テストにパスしている
スプリントのDoneの定義 ü 全てのストーリーのDoneの定義が満たされてい る ü プロダクトのバックアップが更更新されている ü パフォーマンステストが完了了している ü パッケージ、クラス、アーキテクチャのダイア グラムを更更新されている ü 全てのバグが解決しているか、対応の時期を決 めている ü ユニットテストによるコードカバレージが80%
以上である
内部リリースのDoneの定義 ü 全てのスプリントのDoneの定義を満たす ü インストーラーが作られている ü 操作ガイドが更更新されている ü トラブルシューティングガイドが更更新されてい る ü 障害発⽣生時の復復旧計画が更更新されている ü 全てのテストスイートにパスしている
製品リリースのDoneの定義 ü 全ての内部リリースのDoneの定義を満たす ü 負荷テストが実施されている ü パフォーマンステストが実施されている ü ネットワークダイアグラムが更更新されている ü セキュリティアセスメントに合格している ü 脅威分析試験に合格している ü 障害発⽣生時の復復旧計画がテストされている
Doneの定義のサンプル2 h"p://bit.ly/tAf248
ストーリーのDoneの定義 ü 約束した要求にあったコードであること ü ユニットテストをパスしていること ü 機能はFirefox, Chrome, Operaで動作すること ü
IEで重⼤大の問題がなく動作すること ü 機能はそのストーリーを実装した⼈人以外の最低1⼈人以上 のチームメンバーによってテスト、受け⼊入れされている こと
リリースのDoneの定義 ü WARファイルと.exeファイルの配布物が作成されてい ること ü すべてのユニットテストにパスしていること ü すべての機能バグが修正されていること ü すべてのUIのバグが修正されているか、⼩小さいUIのバグ
については修正のスケジュールが決まっていること ü インストールおよびアップグレード⽤用のドキュメントが 更更新されていること ü Windows上とLinux上でインストールテストがなされて いること ü 新しい機能⼀一覧を製品紹介⽤用のWebサイトに掲載するこ と
受け⼊入れ基準との違い h"p://bit.ly/tnokYZ
#1 リマインダ 飲み会の幹事として 飲み会の直前に参加者にリマインドするこ とが出来る それによって参加予定者のドタキャンを防 ⽌止する ⾒見見積もり 8 優先順位
20
#1 リマインダ 受け⼊入れ基準 • 飲み会開催の3⽇日前に参加者にメールで通 知されること • 通知の際には、開催⽇日時、開催場所、緊 急時連絡先が記載されていること • 不不参加者や参加キャンセル者には通知さ
れないこと 機能要件適 合性の判定
Doneの定義が守れない? ü なぜなぜなぜなぜなぜ? ü 別の圧⼒力力に負けてる? ü チームがオーバーコミット? ü そもそもDoneの定義があいまいだから?
ふりかえり ふりかえりで改善
http://bit.ly/sygcE9 プロセスが改�善され ることでDDoonneeの定 義が更新されること もある!
Doneの定義の更更新 ü もしプロジェクト途中でDoneの定義が更更新され るとどうなる? ü チームが成熟すると、⾃自明のDoneの定義や仕掛 けで担保されるものは、定義から外しても良良い ü リリースのDoneの定義をスプリント内で出来る ようになるかもしれない ü やり過ぎ注意
Doneの定義の縮⼩小 ü もしプロジェクト途中でDoneの定義が縮⼩小され るとどうなる? ü プロダクトオーナーや顧客の期待の応えている か? http://bit.ly/tfbphI
Doneの定義は、 チームの成熟度を 映しだすものだ