Doneの定義虎の巻

2011/12にスクラム道場で話した内容。質問等あれば@ryuzeeまたはhttp://www.ryuzee.com/ まで

Transcript

1. Doneの定義  ⻁虎の巻 2011/12/26  スクラム道場.08 @Ryuzee #scrumdo http://bit.ly/tHvlJa
2. 吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/
3. 今⽇日の進め⽅方 ü 読み⼿手がしゃべります（30分） ü その間に質問とか議論論したい内容を付箋に書い てください ü 休憩＋付箋分類とか（5分） ü あとは議論論。活発に。個⼈人批判はしないこと ü 20:55に撤収準備。ゴミは持ち帰るか所定のゴ ミ箱等に捨ててください。
4. プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 チーム  (6±3⼈人) プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリント 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす Doneの定義 何をもって「完了了」とするかを 定義したリスト 毎⽇日の繰り返し デイリースクラム 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする タスク 時間で⾒見見 積もり
5. Scrumのキホン Cancel Return スプリント 2~∼4週間 返品 スプリントゴール スプリント バックログ プロダクトバックログ ギフト包装 クーポン キャンセル 24時間 出荷可能 な製品 スプリント最後には 出荷可能な製品の増 分が出来上がる
6. 出荷可能な製品？ ü 何をもって出荷可能とするかは製品によって異異 なる ü 実際に出荷するかどうかはプロダクトオーナー に意思決定権限がある ü Time  to  Marketの観点からは早く出荷したほう が当然良良い ü 出荷後の保守やサポートのことも考える http://bit.ly/tvFaGT
7. 銀⾏行行、医療療、携帯電話、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/
8. 社内品質基準？ h"p://bit.ly/uiSNmo 顧客の期待と 関係ない （ことがほとんど）
9. Ready？？ ゴールが 分かっている http://bit.ly/sBsLi5
10. Doneの定義 何ができたら 完了なのかを 決める
11. Doneの定義とは？ ü プロジェクトとして定めた「出荷可能な製品」 を作成するために実施しなければいけないこと の⼀一覧。 ü 例例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く、レ ビューするなど ü ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすると分かりやすい。
12. なぜDoneの定義が必要？ ü もしDoneの定義がなかったら？ このストーリー出来上がりましたよ！ 終わってないだろ？？ ⾃自動化されたテストもないし、リファク タリングもされてない。それをするのは 常識識だろ？ まーた後出しジャンケンか。。。 どこまでやっていいかわからんなぁ
13. All or Nothing
14. 終わったか？ 終わってないか？ ただそれだけで判断 するべきである
15. http://bit.ly/uqQxk3 進捗の透明性
16. あいまいさ の排除
17. 【悪い例】 ソースコードが綺麗なこと 【良い例】 ソースコードをCChheecckkSSttyyllee で検証し、重要度NN以上の違 反がないこと
18. 【悪い例】 多くのブラウザで動作 すること 【良い例】 IIEE77--99,,FFFF33,, CChhrroommeeで動作すること IIEE66では表示が崩れないこと
19. Doneの定義充⾜足の検証 自動化できるものは自動で h"p://bit.ly/sP6BvN
20. 誰が決める？ h"p://bit.ly/vymcXJ PPOO＋SSMM＋チーム
21. どうやって決める？ 11..必要な作業を付箋に書きだす http://bit.ly/sVUXCf
22. どうやって決める？ ストーリー スプリント リリース ２..実施タイミングでグループ分け
23. いつ決める？ 見積や契約 の前に大枠 が決まって いるべき http://bit.ly/u0idYi
24. 荒ぶる四天王 品質は固定パラメータ http://bit.ly/vT9CmC
25. Doneの定義のサンプル1 http://bit.ly/tCotIz
26. ストーリーのDoneの定義 ü テストコード、プロダクションコード含め全て のコードがチェックインされている ü 全てのユニットテストをパスしている ü 全ての受け⼊入れテストが⽤用意され、それにパス している ü ヘルプファイルが⾃自動で作られている ü 機能テストにパスしている
27. スプリントのDoneの定義 ü 全てのストーリーのDoneの定義が満たされてい る ü プロダクトのバックアップが更更新されている ü パフォーマンステストが完了了している ü パッケージ、クラス、アーキテクチャのダイア グラムを更更新されている ü 全てのバグが解決しているか、対応の時期を決 めている ü ユニットテストによるコードカバレージが80% 以上である
28. 内部リリースのDoneの定義 ü 全てのスプリントのDoneの定義を満たす ü インストーラーが作られている ü 操作ガイドが更更新されている ü トラブルシューティングガイドが更更新されてい る ü 障害発⽣生時の復復旧計画が更更新されている ü 全てのテストスイートにパスしている
29. 製品リリースのDoneの定義 ü 全ての内部リリースのDoneの定義を満たす ü 負荷テストが実施されている ü パフォーマンステストが実施されている ü ネットワークダイアグラムが更更新されている ü セキュリティアセスメントに合格している ü 脅威分析試験に合格している ü 障害発⽣生時の復復旧計画がテストされている
30. Doneの定義のサンプル2 h"p://bit.ly/tAf248
31. ストーリーのDoneの定義 ü  約束した要求にあったコードであること ü  ユニットテストをパスしていること ü  機能はFirefox,  Chrome,  Operaで動作すること ü  IEで重⼤大の問題がなく動作すること ü  機能はそのストーリーを実装した⼈人以外の最低１⼈人以上 のチームメンバーによってテスト、受け⼊入れされている こと
32. リリースのDoneの定義 ü  WARファイルと.exeファイルの配布物が作成されてい ること ü  すべてのユニットテストにパスしていること ü  すべての機能バグが修正されていること ü  すべてのUIのバグが修正されているか、⼩小さいUIのバグ については修正のスケジュールが決まっていること ü  インストールおよびアップグレード⽤用のドキュメントが 更更新されていること ü  Windows上とLinux上でインストールテストがなされて いること ü  新しい機能⼀一覧を製品紹介⽤用のWebサイトに掲載するこ と
33. 受け⼊入れ基準との違い h"p://bit.ly/tnokYZ
34. #1  リマインダ 飲み会の幹事として 飲み会の直前に参加者にリマインドするこ とが出来る それによって参加予定者のドタキャンを防 ⽌止する ⾒見見積もり ８ 優先順位 20
35. #1  リマインダ 　受け⼊入れ基準 •  飲み会開催の3⽇日前に参加者にメールで通 知されること •  通知の際には、開催⽇日時、開催場所、緊 急時連絡先が記載されていること •  不不参加者や参加キャンセル者には通知さ れないこと 機能要件適 合性の判定
36. Doneの定義が守れない？ ü なぜなぜなぜなぜなぜ？ ü 別の圧⼒力力に負けてる？ ü チームがオーバーコミット？ ü そもそもDoneの定義があいまいだから？
37. ふりかえり 　 　 　 　 　 　 　 　 　 　 ふりかえりで改善
38. http://bit.ly/sygcE9 プロセスが改�善され ることでDDoonneeの定 義が更新されること もある！
39. Doneの定義の更更新 ü もしプロジェクト途中でDoneの定義が更更新され るとどうなる？ ü チームが成熟すると、⾃自明のDoneの定義や仕掛 けで担保されるものは、定義から外しても良良い ü リリースのDoneの定義をスプリント内で出来る ようになるかもしれない ü やり過ぎ注意
40. Doneの定義の縮⼩小 ü もしプロジェクト途中でDoneの定義が縮⼩小され るとどうなる？ ü プロダクトオーナーや顧客の期待の応えている か？ http://bit.ly/tfbphI
41. Doneの定義は、 チームの成熟度を 映しだすものだ