• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Doneの定義 虎の巻 #scrumdo

on

  • 3,466 views

2011/12/26に実施したスクラム道場.08の資料です。

2011/12/26に実施したスクラム道場.08の資料です。

Statistics

Views

Total Views
3,466
Views on SlideShare
2,718
Embed Views
748

Actions

Likes
7
Downloads
60
Comments
0

2 Embeds 748

http://www.ryuzee.com 499
http://www.taoofscrum.org 249

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Doneの定義 虎の巻 #scrumdo Doneの定義 虎の巻 #scrumdo Presentation Transcript

    • Doneの定義  ⻁虎の巻 2011/12/26  スクラム道場.08 @Ryuzee #scrumdo http://bit.ly/tHvlJa
    • 吉羽龍太郎アジャイルコーチhttp://www.ryuzee.com/
    • 今⽇日の進め⽅方 ü 読み⼿手がしゃべります(30分) ü その間に質問とか議論論したい内容を付箋に書い てください ü 休憩+付箋分類とか(5分) ü あとは議論論。活発に。個⼈人批判はしないこと ü 20:55に撤収準備。ゴミは持ち帰るか所定のゴ ミ箱等に捨ててください。
    • プロダクトオーナー スクラムマスター チーム  (6±3⼈人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を⾏行行う。 製品の利利⽤用者、出資者、管理理職に優先順位を付ける いくようにする。 製品の成功に向けて最⼤大限 などの利利害関係者。鶏と称す 外部からチームを守る の努⼒力力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎⽇日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨⽇日やったこと ンニングポーカーで相対⾒見見積もり。 ・今⽇日やること 項⽬目の追加はいつでも⾃自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了了」とするかを 更更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最⼤大4週間までのタイムボックス ログアイテムを選択する。また選択した項⽬目 各スプリントの⻑⾧長さは同⼀一。この間は外部 をタスクにばらす からの変更更を受け⼊入れない 複 数 回タスク ス時間で⾒見見 プ積もり リ ン ト 毎⽇日の繰り返し を 繰スプリントバックログ スプリントレビュー ふりかえり 出荷可能な りそのスプリント期間中に⾏行行う スプリント中の成果である スプリントの中での改善事項 製品の増分タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる 返 する す
    • Scrumのキホンスプリント最後には 24時間出荷可能な製品の増分が出来上がる スプリント 2~∼4週間 スプリントゴール 返品 スプリント バックログ Return キャンセル クーポン 出荷可能 Cancel ギフト包装 な製品プロダクトバックログ
    • 出荷可能な製品? ü 何をもって出荷可能とするかは製品によって異異 なる ü 実際に出荷するかどうかはプロダクトオーナー に意思決定権限がある ü 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 orNothing
    • 終わったか?終わってないか?ただそれだけで判断するべきである
    • 進捗の透明性http://bit.ly/uqQxk3
    • あいまいさ の排除
    • 【悪い例】 ソースコードが綺麗なこと 【良い例】ソースコードをCheckStyleで検証し、重要度N以上の違反が ないこと
    • 【悪い例】 多くのブラウザで動作 すること 【良い例】 IE7-9,FF3, Chromeで動作することIE6では表示が崩れないこと
    • Doneの定義充⾜足の検証 自動化できるものは自動でh"p://bit.ly/sP6BvN
    • 誰が決める? PO+SM+チームh"p://bit.ly/vymcXJ
    • どうやって決める? http://bit.ly/sVUXCf 1.必要な作業を付箋に書きだす
    • どうやって決める? ストーリー スプリント リリース 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プロセスが改善されることでDoneの定義が更新されることもある!
    • Doneの定義の更更新 ü もしプロジェクト途中でDoneの定義が更更新され るとどうなる? ü チームが成熟すると、⾃自明のDoneの定義や仕掛 けで担保されるものは、定義から外しても良良い ü リリースのDoneの定義をスプリント内で出来る ようになるかもしれない ü やり過ぎ注意
    • Doneの定義の縮⼩小 ü もしプロジェクト途中でDoneの定義が縮⼩小され るとどうなる? ü プロダクトオーナーや顧客の期待の応えている か?http://bit.ly/tfbphI
    • Doneの定義は、チームの成熟度を映しだすものだ