Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scrum概要 #tfsug

5,084 views

Published on

2013/2/1に日本マイクロソフトさんでしゃべった際に使ったスライドです。スクラムの概要なので、まぁいつものような感じです。

Published in: Technology

Scrum概要 #tfsug

  1. 1. Scrum概要 2013/2/1 Ryutaro YOSHIBAhttp://www.flickr.com/photos/18091975@N00/3654141771/13年2月1日金曜日
  2. 2. 吉羽 龍太郎 Ryutaro YOSHIBA アジャイルコーチ Ryuzee.com Twitter: @ryuzee13年2月1日金曜日
  3. 3. Agile研修やオンサイトコーチングの提供13年2月1日金曜日 こちらからは営業しませんw
  4. 4. • これから超大事なこと言います!http://www.flickr.com/photos/32397140@N00/3744438913年2月1日金曜日
  5. 5. 2013年2月に Scrum Boot Camp の本が出ます!13年2月1日金曜日
  6. 6. 2013年2月発売 先行予約受付中 定価:2520円 http://www.seshop.com/ product/detail/15395/ #scrumbcbook13年2月1日金曜日
  7. 7. http://flickr.com/photos/99174151@N00/2976156645 • 大事な話おわり!13年2月1日金曜日
  8. 8. 手法の利用割合State of Agile Survey 2011 (c)VersionOne13年2月1日金曜日
  9. 9. 本当に必要なものがわかるか?13年2月1日金曜日
  10. 10. 13年2月1日金曜日
  11. 11. 期待のマネジメントに失敗13年2月1日金曜日
  12. 12. システムの機能の利用割合 7% 13% 45% 16% 19% Standishの2000年の調査より13年2月1日金曜日
  13. 13. システムの機能の利用割合 7% 13% まったく使わない ほとんど使わない 45% たまに使う 16% よく使う いつも使う 19% Standishの2000年の調査より13年2月1日金曜日
  14. 14. あなたの開発はムダだらけ? • 作りすぎのムダ • 手待ちのムダ • 運搬のムダ • 加工のムダ • 在庫のムダ • 動作のムダ • 不良をつくるムダ13年2月1日金曜日
  15. 15. コストの見積りは正しいか? • 不確実性コーン13年2月1日金曜日
  16. 16. 予測主義 vs 経験主義 http://www.flickr.com/photos/iain/353671249/13年2月1日金曜日
  17. 17. 予測主義 vs 経験主義 • ウォーターフォール型の開発手法(予測主義) は、先のことまで見通した正しい計画が作れる ことを前提にしている。これは大丈夫か? • アジャイル開発は経験主義に基づく。経験した 事実を踏まえて計画を修正し続ける。修正範囲 にはスコープも含まれる http://www.flickr.com/photos/iain/353671249/13年2月1日金曜日
  18. 18. Scrumとは • 可能な限り価値の高いプロダクトを生産的かつ 創造的に届けるためのもの • 複雑で変化の激しい問題に対応するための仕事 の進め方 • 既知のことより未知のことが多い領域に向いて いる • 作業・成果物・会議体を定めている13年2月1日金曜日
  19. 19. Scrumの特徴 •軽量 •理解が容易 •習得は結構大変13年2月1日金曜日
  20. 20. 従来型と異なる点 • リソースと期間によって総量規制をかける • 総量をあふれる要求は実現されない • もしくは必要な機能を作り終わるまで期間が延 びる13年2月1日金曜日
  21. 21. 大事なことから始める 1番目に欲しい 2番目に欲しい 3番目に欲しい • 欲しいものをリストにして 4番目に欲しい 順位をつける 5番目に欲しい 6番目に欲しい • リストには項目が追加され 7番目に欲しい たり、削除される 8番目に欲しい 9番目に欲しい • この順番は定期的に見直す ... 99番目に欲しい • 優先度ではない! 100番目に欲しい13年2月1日金曜日
  22. 22. 【 成果物1】 プロダクトバックログhttp://www.flickr.com/photos/38793485@N00/3600409147/13年2月1日金曜日
  23. 23. 【ロール1】プロダクトオーナー • プロダクトバックログの管理者 • 優先順位の意思決定の最終決定 権限をもつ • プロダクトの責任者(結果責任) • プロジェクトに1人必ず必要 • プロダクトの価値を最大化する13年2月1日金曜日
  24. 24. 【ロール2】開発チーム http://www.flickr.com/photos/jurvetson/43922369/ • モノを作る • 3人∼9人で構成 • 全員揃えばプロダクトを作れる能力が揃う • 上下関係なし13年2月1日金曜日
  25. 25. 自己組織化 • 最良のやり方を自分たちで決める • 一番やり方をしっているのは現場の人13年2月1日金曜日
  26. 26. 一定のリズムで仕事する ◎同じ長さに区切って繰り返す 2週間 2週間 2週間 2週間 2週間 ☓期間の長さが変わってはいけない 2週間 4週間 1週 2週間 1週 • 一定間隔で意思決定と作業と確認を行う • 最大4週間の固定の期間 • これをスプリントと呼ぶ13年2月1日金曜日
  27. 27. 【会議1】スプリント計画会議 1番目に欲しい 2番目に欲しい • スプリントで開発をするため 3番目に欲しい には計画が必要 4番目に欲しい 5番目に欲しい 6番目に欲しい • プロダクトオーナーは何をほ しいか(第一部) 7番目に欲しい 8番目に欲しい 9番目に欲しい • 開発チームはどれくらいでき そうか(第一部) ... 99番目に欲しい • 開発チームはどうやってそれ 100番目に欲しい を実現するか(第二部)13年2月1日金曜日
  28. 28. 【成果物2】スプリントバックログ 1番目に欲しい タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク 2番目に欲しい 3番目に欲しい タスク タスク タスク タスク タスク 4番目に欲しい タスク タスク タスク タスク タスク 5番目に欲しい タスク タスク タスク タスク タスク 6番目に欲しい タスク タスク タスク タスク タスク 7番目に欲しい 8番目に欲しい • プロダクトバックログを具体 9番目に欲しい 的なタスクに分割する ... 99番目に欲しい • 後から増えることもある 100番目に欲しい • 1タスクは1日以内のサイズ13年2月1日金曜日
  29. 29. 【成果物3】出荷判断可能な増分 • 開発チームは出荷判断可能なプロダクトの増分 をつくる13年2月1日金曜日
  30. 30. 出荷判断可能 • 部品だけでは出荷判断できない • 小さくても使えるものを作る13年2月1日金曜日
  31. 31. 完了の判断 あれもこれも ここまでできれ できてない ば終わりだと じゃない! 思ったんだけど13年2月1日金曜日
  32. 32. 完了の定義 • 完了の定義を作り、何をもって出荷判断可能か を定める • スプリントでどこまでやるか決める コード ユニット カバレッジ チェックイン レビュー テスト 75% 受け入れ クロス 結合テスト 静的解析 テスト ブラウザ ドキュメント 性能 セキュリティ デプロイ13年2月1日金曜日
  33. 33. 開発をすすめる • 開発チーム全員で仕事をすすめる • 特定の誰かに特定の責任が付与されるわけでは ない • 外部からやり方は指示しない http://www.flickr.com/photos/globalgamejam2009/3241345650/13年2月1日金曜日
  34. 34. 【会議2】デイリースクラム • 開発チームの状況を毎日検査する13年2月1日金曜日
  35. 35. 【会議2】デイリースクラム • 開発チームがスプリントゴールに向かって進ん でいるかを検証。残作業を追跡する • 毎日、同じ場所で同じ時間に開始 • 15分間で延長なし • たった3つの質問 • 開発チームのための会議で部外者は口出しなし13年2月1日金曜日
  36. 36. スプリントゴールへ進む • スプリント開始時点で決めたスコープを外圧に よって変更してはいけない13年2月1日金曜日
  37. 37. 【会議3】スプリントレビュー • 開発チームの成果物をプロダクトオーナーが確 認し、受け入れ可否を決める13年2月1日金曜日
  38. 38. デモを確認し受け入れを判断する 1番目に欲しい 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい 6番目に欲しい 7番目に欲しい 8番目に欲しい 9番目に欲しい ... 99番目に欲しい 100番目に欲しい13年2月1日金曜日
  39. 39. デモを確認し受け入れを判断する 1番目に欲しい 頼んだ通りなのでOKです 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい 6番目に欲しい 7番目に欲しい 8番目に欲しい 9番目に欲しい ... 99番目に欲しい 100番目に欲しい13年2月1日金曜日
  40. 40. デモを確認し受け入れを判断する 1番目に欲しい 頼んだ通りなのでOKです 2番目に欲しい 3番目に欲しい 4番目に欲しい これクリックした時の遷移先が 5番目に欲しい 違うのでNGです 6番目に欲しい 7番目に欲しい 8番目に欲しい 9番目に欲しい ... 99番目に欲しい 100番目に欲しい13年2月1日金曜日
  41. 41. デモを確認し受け入れを判断する 1番目に欲しい 頼んだ通りなのでOKです 2番目に欲しい 3番目に欲しい 4番目に欲しい これクリックした時の遷移先が 5番目に欲しい 違うのでNGです 6番目に欲しい 7番目に欲しい なるほど。今回はOKだけど次のスプ 8番目に欲しい リントで機能追加しようか 9番目に欲しい ... 99番目に欲しい 100番目に欲しい13年2月1日金曜日
  42. 42. デモを確認し受け入れを判断する 1番目に欲しい 頼んだ通りなのでOKです 2番目に欲しい 3番目に欲しい 4番目に欲しい これクリックした時の遷移先が 5番目に欲しい 違うのでNGです 6番目に欲しい 7番目に欲しい なるほど。今回はOKだけど次のスプ 8番目に欲しい リントで機能追加しようか 9番目に欲しい ... 99番目に欲しい 100番目に欲しい • 厳密に判断する13年2月1日金曜日
  43. 43. 短いフィードバックサイクル • 短いスプリント単位で頻繁に確認と調整を行い プロダクトをよりよくする • もちろん仕事のやり方ももっとうまくできるは ずなのでカイゼンを繰り返す13年2月1日金曜日
  44. 44. 【会議3】スプリントふりかえり • スプリントレトロスペクティブとも言う • 人、関係、プロセス、ツールなどの観点で今回 のスプリントを検査する • うまくいったこと、今後の改善点を整理する • 今後のアクションプランを作る13年2月1日金曜日
  45. 45. KPTをはじめ様々なやり方 http://www.flickr.com/photos/magnus_d/5121009259/13年2月1日金曜日
  46. 46. 繰り返す 2週間 2週間 2週間 2週間 2週間 • タイムボックスを繰り返して • POがほしいものから順に • 出荷判断可能なプロダクトを届け続ける • うまく届けられるように改善し続ける13年2月1日金曜日
  47. 47. 【ロール3】スクラムマスター • このプロセスがうまくまわるよ うにする • 妨害の排除 • 支援と奉仕 (サーバントリーダーシップ) • 教育、ファシリテート、コー チ、推進役13年2月1日金曜日
  48. 48. 13年2月1日金曜日
  49. 49. Scrumまとめ • 欲しいものを作る順番に並べ替える。その順にモノを作るこ とで成果を最大化する(価値を基準) • 短い時間に区切って繰り返す(タイムボックス) • 現在の状況や問題点を関係者の間で常に共有(透明性) • 定期的に進捗状況や作っているモノが正しいのか、仕事の進 め方に問題がないかどうかを確認(検査) • 問題があったりもっとうまくできる方法があれば、やり方を 変える(適応)13年2月1日金曜日
  50. 50. XPと組み合わせる ! ! ! YAGNI13年2月1日金曜日
  51. 51. アジャイル失敗の理由 • 失敗の定義はなんだろう?13年2月1日金曜日
  52. 52. アジャイル失敗の理由 組織変革が必要なことを理解 してなかった • 失敗の定義はなんだろう?13年2月1日金曜日
  53. 53. アジャイル失敗の理由 組織変革が必要なことを理解 してなかった 組織文化や哲学がアジャイル の考えとあってない • 失敗の定義はなんだろう?13年2月1日金曜日
  54. 54. Scrumで大事なこと • Scrumで問題は分かるかもしれない • でもScrumが解決するわけじゃない • 解決するのは現場の皆さん自身http://www.flickr.com/photos/rowanbank/8066004236/13年2月1日金曜日

×