Doneの定義虎の巻(スクラム道EXPO) #scrumdo
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Doneの定義虎の巻(スクラム道EXPO) #scrumdo

  • 3,805 views
Uploaded on

2012/10/28のスクラム道EXPOでしゃべったスライドです。過去のものとそんなに変わってません

2012/10/28のスクラム道EXPOでしゃべったスライドです。過去のものとそんなに変わってません

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,805
On Slideshare
2,741
From Embeds
1,064
Number of Embeds
4

Actions

Shares
Downloads
47
Comments
0
Likes
20

Embeds 1,064

http://www.ryuzee.com 1,052
https://twitter.com 8
https://kcw.kddi.ne.jp 2
http://localhost 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Doneの定義虎の巻 2012/10/28   スクラム道EXPO @Ryuzee  #scrumdo
  • 2. 吉羽 龍太郎 Ryutaro  YOSHIBA アジャイルコーチ Web: http://www.ryuzee.com     Twitter:  @ryuzee 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー Microsoft  MVP  for  Visual  Studio  ALM
  • 3. Agile研修やコーチングの提供なにかあれば遠慮なくどーぞこちらからは営業しませんw
  • 4. 会社で大量購入いただくと、筆者たちは大喜びします!!
  • 5. 2013/1/15-­‐16  at  Akihabara  UDX    Scrum  Alliance  Regional  Gathering  Tokyo  2013   http://bit.ly/LtunLe
  • 6. プロダクトオーナー スクラムマスター チーム  (6±3⼈人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を⾏行行う。 製品の利利⽤用者、出資者、管理理職に優先順位を付ける いくようにする。 製品の成功に向けて最⼤大限 などの利利害関係者。鶏と称す 外部からチームを守る の努⼒力力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎⽇日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨⽇日やったこと ンニングポーカーで相対⾒見見積もり。 ・今⽇日やること 項⽬目の追加はいつでも⾃自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了了」とするかを 更更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最⼤大4週間までのタイムボックス ログアイテムを選択する。また選択した項⽬目 各スプリントの⻑⾧長さは同⼀一。この間は外部 をタスクにばらす からの変更更を受け⼊入れない 複 数 回タスク ス時間で⾒見見 プ積もり リ ン ト 毎⽇日の繰り返し を 繰スプリントバックログ スプリントレビュー ふりかえり 出荷可能な りそのスプリント期間中に⾏行行う スプリント中の成果である スプリントの中での改善事項 製品の増分タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる 返 する す
  • 7. Scrumのキホンスプリント最後には出 24時間荷(判断)可能な製品の増分が出来上がる スプリント 2~∼4週間 スプリントゴール 返品 スプリント Return キャンセル バックログ クーポン 出荷可能 Cancel ギフト包装 な製品プロダクトバックログ
  • 8. Doneの定義とは?ü プロジェクトとして定めた「出荷(判断)可能な 製品」を作成するために実施しなければいけな いことの一覧。ü 例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く、レ ビューするなどü ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすると分かりやすい。
  • 9. Doneの定義何ができたら完了なのかを決める
  • 10. Ready = ゴールが 分かっているhttp://bit.ly/sBsLi5
  • 11. Doneの定義がなかったら ここまでできれば 終わりだと思って これもあれもでき たんだけど… てないじゃない?
  • 12. 終わったか?終わってないか?ただそれだけで判断するべきである
  • 13. 進 の透明性http://bit.ly/uqQxk3
  • 14. 受け入れ基準との違いh-p://bit.ly/tnokYZ
  • 15. #1  リマインダ飲み会の幹事として飲み会の直前に参加者にリマインドすることが出来るそれによって参加予定者のドタキャンを防⽌止する⾒見見積もり 8 優先順位 20
  • 16. #1  リマインダ  受け⼊入れ基準•  飲み会開催の3⽇日前に参加者にメールで通 知されること•  通知の際には、開催⽇日時、開催場所、緊 急時連絡先が記載されていること•  不不参加者や参加キャンセル者には通知さ れないこと 機能要件適 合性の判定
  • 17. あいまいで判断できない
  • 18. 【悪い例】ソースコードが綺麗なこと【良い例】ソースコードをCheckStyleで検証し、重要度N以上の違反がないこと
  • 19. 【悪い例】多くのブラウザで動作すること【良い例】IE7-9,FF3,Chromeで動作することIE6では表示が崩れないこと
  • 20. 変な基準を強制される
  • 21. 銀行、医療、携帯電話、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/
  • 22. 社内品質基準? 顧客の期待と 関係ない (ことがほとんど)h-p://bit.ly/uiSNmo
  • 23. ゴージャスすぎて守れない
  • 24. たくさんの定義…•  ストーリーの完了了の定義 •  内部リリースの完了了の定義 –  テストコード、プロダクションコード含 –  全てのスプリントの完了了の定義を満たす め全てのコードがチェックインされてい –  インストーラーが作られている る –  操作ガイドが更更新されている –  全てのユニットテストをパスしている –  トラブルシューティングガイドが更更新され –  全ての受け⼊入れテストが⽤用意され、それ ている にパスしている –  障害発⽣生時の復復旧計画が更更新されている –  ヘルプファイルが⾃自動で作られている –  全てのテストスイートにパスしている –  機能テストにパスしている •  製品リリースの完了了の定義•  スプリントの完了了の定義 –  全ての内部リリースの完了了の定義を満たす –  全てのストーリーの完了了の定義が満たさ –  負荷テストが実施されている れている –  パフォーマンステストが実施されている –  プロダクトのバックアップが更更新されて いる –  ネットワークダイアグラムが更更新されてい る –  パフォーマンステストが完了了している –  セキュリティアセスメントに合格している –  パッケージ、クラス、アーキテクチャの ダイアグラムを更更新されている –  脅威分析試験に合格している –  障害発⽣生時の復復旧計画がテストされている –  全てのバグが解決しているか、対応の時 期を決めている –  ユニットテストによるコードカバレージ が80%以上である
  • 25. とにかく守れないw
  • 26. Doneの定義が守れない?ü なぜなぜなぜなぜなぜ?ü 別の圧力に負けてる?ü チームがオーバーコミット?ü そもそもDoneの定義があい まいだから?
  • 27. 守っているかどうか判断で きない
  • 28. そもそも定義の中身をしら ない
  • 29. ふりかえり                    ふりかえりで改善
  • 30. http://bit.ly/sygcE9プロセスが改善されることでDoneの定義が更新されることもある!
  • 31. Doneの定義の更新ü もしプロジェクト途中でDoneの定義が更新さ れるとどうなる?ü チームが成熟すると、自明のDoneの定義や仕 掛けで担保されるものは、定義から外しても良 いü リリースのDoneの定義をスプリント内で出来 るようになるかもしれないü やり過ぎ注意
  • 32. Doneの定義の縮小 ü もしプロジェクト途中でDoneの定義が縮小さ れるとどうなる? ü プロダクトオーナーや顧客の期待の応えている か?http://bit.ly/tfbphI
  • 33. Doneの定義充足の検証 自動化できるものは自動でh-p://bit.ly/sP6BvN
  • 34. Doneの定義は、チームの成熟度を映しだす
  • 35. いつ決める? 見積や契約 の前に大枠 が決まって いるべき http://bit.ly/u0idYi
  • 36. 誰が決める? PO+SM+チームh-p://bit.ly/vymcXJ
  • 37. どうやって決める? http://bit.ly/sVUXCf 1.必要な作業を付箋に書きだす
  • 38. どうやって決める? ストーリー スプリント リリース 2.実施タイミングでグループ分け
  • 39. リスト化して印刷
  • 40. 荒ぶる四天王 http://bit.ly/vT9CmC品質は固定パラメータ
  • 41. スコープ達成の圧力に負けない
  • 42. 大事だと思うことü プロジェクト開始時点で決めるü スプリントで全部やろうとしない(最初はムリ)ü チームが成熟してきたら拡張するü 品質は固定パラメータü 途中でスコープ実現のために縮小しないü 出来ているかどうかを自動で検証ü 定義をみんな知っている