No023-01-suc3rum-20110527
- 1. 第23回すくすくスクラム
～Scrum の概要～
認定スクラムマスター
認定プロダクトオーナー
Thanks: www.flickr.com/photos/cdm/2336025560
海江田 兼輔 (@Qooh0)
- 3. プロダクト・オーナー
• プロダクトのビジョンを確立し、チームに伝える
• 投資ビジョンに対して、費用対効果 を管理する
• リリース可能かどうかを判断する
- 4. チーム
• 機能横断的
• メンバーを長期的に安定させる
• 最も重要なものから順に作業する
• 作業を見積もりやすい小さいタスクに分割する
• スプリントといわれるタイムボックスで開発する
- 5. スクラム・マスター
• サーバント・リーダーシップで臨む
• プロダクト・オーナーは問題点を隠したがる
• チームを守り、問題を解消する
• 実権限はない
• 各種ミーティングを主宰する
• チームに直接指示は出さない
- 6. 顧客
• 顧客は、Scrum で規定されている役割ではない
• 顧客は必ず存在する
• エンドユーザーは最も大切。
• 結果のフィードバックを提供します
- 8. PO が
プロダクトの
Vision を決める
Thanks: http://www.flickr.com/photos/anselm23/2812005967
- 11. プロダクトバックログ
• 機能、技術、課題のリスト
• 明示されており、優先順位がある
• 優先順位は、プロダクト・オーナーがつける
• 更新されており、だれでも見れる
• 価値について記載する
• チームによって見積もられている
• 見積もりは、相対的な見積もりを行う
• 例として、プラニングポーカーによる見積り方法がある
- 13. スプリント計画ミーティング
• プロダクトバックログからのタスクの切り出し ( 1-4 H)
• スプリントのゴールを決定する
• スプリント計画バックログの見積もり( 1-4 H)
- 14. 完了の定義を決めておきましょう
• プロダクト・オーナーが出荷可能と認めるレベル
についてのチームでの合意
• プロダクト・オーナーが出荷可能か判定するのに
使用する
• タスクが完了したとは、
知りうる限り残作業が
残っていないこと
• チェック判定の根拠
Thanks: http://www.flickr.com/photos/taedc/5091487939/
- 15. 完了をサポートするためのツール
すべてを確認するのは手作業では無理
• バージョン管理
• 自動ビルドツール
• 自動テストツール
• Q/A 環境
Thanks: http://www.flickr.com/photos/bre/552152780/
- 16. PBI の見積もり
• 相対的に見積もる
• プラニング・ポーカーなどで見積もる方法がある
• 大事なことは、各個人の意見の差異をチェックにして
話し合うこと、合意することが大事
Thanks: http://www.flickr.com/photos/alandd/3180887085/
- 17. スプリント計画 2
• スプリントバックログを作成する
• 仕様の確認を必要ならする
Thanks: http://www.flickr.com/photos/24469297@N05/4297558881/
- 18. スプリントバックログ
• PBI を、タスクに分割したもの
• チームメンバーが作成する
• チームメンバーで理想時間で見積る
• すべての項目は、スプリント内で終わらせる
• タスクは 1 – 16 時間 (個人的には 1-8 時間)
- 19. デイリー・スクラム
日々の開発において
開発を進めるうえで問題がないかを確認する
Thanks: http://www.flickr.com/photos/klean-dk/5424689186
- 22. 障害リスト
• スクラムマスターのプロダクトバックログ
• チームの障害になっているものを記載する
• 毎日のデイリースクラム、ふりかえりでアップデートする
• オープンで、だれでも見れる
• 定期的に、優先順位を見直す
- 23. バーンダウンチャート
Scrum の管理ツールの中心的存在
開発スピードの確認をする
今後の見積もりのための情報を収集する
Thanks: http://www.flickr.com/photos/kakutani/2761992149/
- 25. スプリント・レビュー
• チームがプロダクト・オーナーと顧客に向けて行う
• Demo or Die
Thanks: http://www.flickr.com/photos/yoavshapira/5490350050/
- 26. スプリントレビュー
• 開発 or テスト環境で行う
• チームがプロダクトオーナーと顧客に向けて行う
• Demo or Die
• プロセス改善を行う
- 27. ふりかえり
• 改善を行う
• チームとスクラムマスターが中心となって
スプリントミーティングからスプリントレビュー
までをふりかえる
• 問題があれば障害リストを更新する
- 28. イテレーティブに！
Product
Backlog
Demo
Sprint
Or
Backlog
Die
Development Estimate
スプリントを、およそ 2 – 4 週(固定)開発を行っていく
- 30. アジャイルな開発の核
Thanks: http://www.flickr.com/photos/lel4nd/4277978437
- 33. 世の中は変化に富んでいる
あらゆる予測は不可能
一人一人が現実に向き合うこと
による開発をしたほうがよい
フィードバックを利用し
自己組織化を行うことによって、
開発の効率を高める
- 35. 自己組織化を体感する
ワークショップ
ほかの人の動きからフィードバックをもらい
自ら動くことによって
より早く収束することを実感してください！
- 36. 僕が最初にやったこと…
• スプリントミーティング
• スプリントバックログ
• 完了の定義を決める
• デイリースクラム
• スプリントレビュー
実はこのとき、障害リストを知らなかった…
- 40. とりあえず読んだ方が良い資料
本
• アジャイルな見積もりと計画づくり
• アート・オブ・アジャイル デベロップメント
• アジャイルプラクティス
• レトロスペクティブ
• 闘うプログラマー
• セムラーイズム
PDF
• Scrum Guide
• 塹壕より XP Scrum
• Scrum Primer
