Slide 1

Slide 1 text

Doneの定義  ⻁虎の巻 2011/12/26  スクラム道場.08 @Ryuzee #scrumdo http://bit.ly/tHvlJa

Slide 2

Slide 2 text

吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/

Slide 3

Slide 3 text

今⽇日の進め⽅方 ü 読み⼿手がしゃべります(30分) ü その間に質問とか議論論したい内容を付箋に書い てください ü 休憩+付箋分類とか(5分) ü あとは議論論。活発に。個⼈人批判はしないこと ü 20:55に撤収準備。ゴミは持ち帰るか所定のゴ ミ箱等に捨ててください。

Slide 4

Slide 4 text

プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 チーム  (6±3⼈人) プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリント 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす Doneの定義 何をもって「完了了」とするかを 定義したリスト 毎⽇日の繰り返し デイリースクラム 毎⽇日チームが以下の3つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする タスク 時間で⾒見見 積もり

Slide 5

Slide 5 text

Scrumのキホン Cancel Return スプリント 2~∼4週間 返品 スプリントゴール スプリント バックログ プロダクトバックログ ギフト包装 クーポン キャンセル 24時間 出荷可能 な製品 スプリント最後には 出荷可能な製品の増 分が出来上がる

Slide 6

Slide 6 text

出荷可能な製品? ü 何をもって出荷可能とするかは製品によって異異 なる ü 実際に出荷するかどうかはプロダクトオーナー に意思決定権限がある ü Time  to  Marketの観点からは早く出荷したほう が当然良良い ü 出荷後の保守やサポートのことも考える http://bit.ly/tvFaGT

Slide 7

Slide 7 text

銀⾏行行、医療療、携帯電話、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/

Slide 8

Slide 8 text

社内品質基準? h"p://bit.ly/uiSNmo 顧客の期待と 関係ない (ことがほとんど)

Slide 9

Slide 9 text

Ready?? ゴールが 分かっている http://bit.ly/sBsLi5

Slide 10

Slide 10 text

Doneの定義 何ができたら 完了なのかを 決める

Slide 11

Slide 11 text

Doneの定義とは? ü プロジェクトとして定めた「出荷可能な製品」 を作成するために実施しなければいけないこと の⼀一覧。 ü 例例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く、レ ビューするなど ü ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすると分かりやすい。

Slide 12

Slide 12 text

なぜDoneの定義が必要? ü もしDoneの定義がなかったら? このストーリー出来上がりましたよ! 終わってないだろ?? ⾃自動化されたテストもないし、リファク タリングもされてない。それをするのは 常識識だろ? まーた後出しジャンケンか。。。 どこまでやっていいかわからんなぁ

Slide 13

Slide 13 text

All or Nothing

Slide 14

Slide 14 text

終わったか? 終わってないか? ただそれだけで判断 するべきである

Slide 15

Slide 15 text

http://bit.ly/uqQxk3 進捗の透明性

Slide 16

Slide 16 text

あいまいさ の排除

Slide 17

Slide 17 text

【悪い例】 ソースコードが綺麗なこと 【良い例】 ソースコードをCChheecckkSSttyyllee で検証し、重要度NN以上の違 反がないこと

Slide 18

Slide 18 text

【悪い例】 多くのブラウザで動作 すること 【良い例】 IIEE77--99,,FFFF33,, CChhrroommeeで動作すること IIEE66では表示が崩れないこと

Slide 19

Slide 19 text

Doneの定義充⾜足の検証 自動化できるものは自動で h"p://bit.ly/sP6BvN

Slide 20

Slide 20 text

誰が決める? h"p://bit.ly/vymcXJ PPOO+SSMM+チーム

Slide 21

Slide 21 text

どうやって決める? 11..必要な作業を付箋に書きだす http://bit.ly/sVUXCf

Slide 22

Slide 22 text

どうやって決める? ストーリー スプリント リリース 2..実施タイミングでグループ分け

Slide 23

Slide 23 text

いつ決める? 見積や契約 の前に大枠 が決まって いるべき http://bit.ly/u0idYi

Slide 24

Slide 24 text

荒ぶる四天王 品質は固定パラメータ http://bit.ly/vT9CmC

Slide 25

Slide 25 text

Doneの定義のサンプル1 http://bit.ly/tCotIz

Slide 26

Slide 26 text

ストーリーのDoneの定義 ü テストコード、プロダクションコード含め全て のコードがチェックインされている ü 全てのユニットテストをパスしている ü 全ての受け⼊入れテストが⽤用意され、それにパス している ü ヘルプファイルが⾃自動で作られている ü 機能テストにパスしている

Slide 27

Slide 27 text

スプリントのDoneの定義 ü 全てのストーリーのDoneの定義が満たされてい る ü プロダクトのバックアップが更更新されている ü パフォーマンステストが完了了している ü パッケージ、クラス、アーキテクチャのダイア グラムを更更新されている ü 全てのバグが解決しているか、対応の時期を決 めている ü ユニットテストによるコードカバレージが80% 以上である

Slide 28

Slide 28 text

内部リリースのDoneの定義 ü 全てのスプリントのDoneの定義を満たす ü インストーラーが作られている ü 操作ガイドが更更新されている ü トラブルシューティングガイドが更更新されてい る ü 障害発⽣生時の復復旧計画が更更新されている ü 全てのテストスイートにパスしている

Slide 29

Slide 29 text

製品リリースのDoneの定義 ü 全ての内部リリースのDoneの定義を満たす ü 負荷テストが実施されている ü パフォーマンステストが実施されている ü ネットワークダイアグラムが更更新されている ü セキュリティアセスメントに合格している ü 脅威分析試験に合格している ü 障害発⽣生時の復復旧計画がテストされている

Slide 30

Slide 30 text

Doneの定義のサンプル2 h"p://bit.ly/tAf248

Slide 31

Slide 31 text

ストーリーのDoneの定義 ü  約束した要求にあったコードであること ü  ユニットテストをパスしていること ü  機能はFirefox,  Chrome,  Operaで動作すること ü  IEで重⼤大の問題がなく動作すること ü  機能はそのストーリーを実装した⼈人以外の最低1⼈人以上 のチームメンバーによってテスト、受け⼊入れされている こと

Slide 32

Slide 32 text

リリースのDoneの定義 ü  WARファイルと.exeファイルの配布物が作成されてい ること ü  すべてのユニットテストにパスしていること ü  すべての機能バグが修正されていること ü  すべてのUIのバグが修正されているか、⼩小さいUIのバグ については修正のスケジュールが決まっていること ü  インストールおよびアップグレード⽤用のドキュメントが 更更新されていること ü  Windows上とLinux上でインストールテストがなされて いること ü  新しい機能⼀一覧を製品紹介⽤用のWebサイトに掲載するこ と

Slide 33

Slide 33 text

受け⼊入れ基準との違い h"p://bit.ly/tnokYZ

Slide 34

Slide 34 text

#1  リマインダ 飲み会の幹事として 飲み会の直前に参加者にリマインドするこ とが出来る それによって参加予定者のドタキャンを防 ⽌止する ⾒見見積もり 8 優先順位 20

Slide 35

Slide 35 text

#1  リマインダ  受け⼊入れ基準 •  飲み会開催の3⽇日前に参加者にメールで通 知されること •  通知の際には、開催⽇日時、開催場所、緊 急時連絡先が記載されていること •  不不参加者や参加キャンセル者には通知さ れないこと 機能要件適 合性の判定

Slide 36

Slide 36 text

Doneの定義が守れない? ü なぜなぜなぜなぜなぜ? ü 別の圧⼒力力に負けてる? ü チームがオーバーコミット? ü そもそもDoneの定義があいまいだから?

Slide 37

Slide 37 text

ふりかえり                     ふりかえりで改善

Slide 38

Slide 38 text

http://bit.ly/sygcE9 プロセスが改�善され ることでDDoonneeの定 義が更新されること もある!

Slide 39

Slide 39 text

Doneの定義の更更新 ü もしプロジェクト途中でDoneの定義が更更新され るとどうなる? ü チームが成熟すると、⾃自明のDoneの定義や仕掛 けで担保されるものは、定義から外しても良良い ü リリースのDoneの定義をスプリント内で出来る ようになるかもしれない ü やり過ぎ注意

Slide 40

Slide 40 text

Doneの定義の縮⼩小 ü もしプロジェクト途中でDoneの定義が縮⼩小され るとどうなる? ü プロダクトオーナーや顧客の期待の応えている か? http://bit.ly/tfbphI

Slide 41

Slide 41 text

Doneの定義は、 チームの成熟度を 映しだすものだ