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.8k
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
15k
自動テストvs手動テスト
ryuzee
1
2k
Agileってなんだっけ?
ryuzee
2
170
20110127_devloveテストの話.pdf
ryuzee
0
130
スプリントバーンダウンチャート虎の巻 #scrumdo
ryuzee
1
540
アジャイルコーチで学んだ30+αのこと
ryuzee
2
250
Agile Japan '12 Agileな開発からAgileな組織へ
ryuzee
3
420
ワンクリックデプロイ101
ryuzee
2
350
Other Decks in Technology
See All in Technology
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
6
690
Goss: New Production-Ready Go Binding for Faiss #coefl_go_jp
bengo4com
0
1.1k
事業価値と Engineering
recruitengineers
PRO
6
4.5k
モバイルアプリ研修
recruitengineers
PRO
4
1.4k
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
11
2.9k
カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys
kaminashi
2
460
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
660
広島銀行におけるAWS活用の取り組みについて
masakimori
0
160
microCMS 最新リリース情報(microCMS Meetup 2025)
microcms
0
250
ここ一年のCCoEとしてのAWSコスト最適化を振り返る / CCoE AWS Cost Optimization devio2025
masahirokawahara
0
100
Backboneとしてのtimm2025
yu4u
5
1.7k
Microsoft Fabric のネットワーク保護のアップデートについて
ryomaru0825
1
110
Featured
See All Featured
Being A Developer After 40
akosma
90
590k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
284
13k
Music & Morning Musume
bryan
46
6.8k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
How to Think Like a Performance Engineer
csswizardry
26
1.8k
Side Projects
sachag
455
43k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
The Pragmatic Product Professional
lauravandoore
36
6.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
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の定義は、 チームの成熟度を 映しだすものだ