スクラムの基礎

むか~しアジャイル開発のトレーニングを提供していたときの資料

1. SCRUM BOOT CAMP Ryuzee.com Ryutaro YOSHIBA http://www.flickr.com/photos/angel_medinilla/4365271912/
2. アジャイル開発とは What s Agile development? http://www.flickr.com/photos/yochei/4345723616/
3. 本当に必要なものがわかるか?
4. システムの機能の利用割合 7% 13% 45% 16% まったく使わない ほとんど使わない たまに使う よく使う いつも使う 19% Standishの2000年の調査より
5. あなたの開発はムダだらけ? • 作りすぎのムダ • 手待ちのムダ • 運搬のムダ • 加工のムダ • 在庫のムダ • 動作のムダ • 不良をつくるムダ
6. ワークショップ • みなさんが日々の仕事やプロジェクトを進める上でムダだと 思うことを1人5個以上付箋に書きだしてください • 各チームで議論し、解決すべき順に並べてください • 時間は10分とします http://www.flickr.com/photos/mworrell/108876881/
7. コストの見積りは正しいか? • 不確実性コーン
8. ウォーターフォール(V字) 要件定義 受け入れ試験 、 て ぎ す り 基本設計 総合試験 か か が が 求 要 時間 は に 頃 件 た 要 も 出来 そ も そ と 。 詳細設計 結合試験 こ 化 い 変 な い て っ る あ か が 分 で こ こ が 製造・単体
9. よくみかける光景 要件定義は順調です ○○設計は順調です 多くのリスクが後半になって顕在 開発は遅れていますが挽回可能です 化する。顕在化した時点では取り 返しがつかない 結合試験で重大な問題が出ています 受入れ試験でニーズ不一致が判明 リリースできません
10. 予測主義 vs 経験主義 • ウォーターフォール型の開発手法(予測主義)は、 先のことまで見通した正しい計画が作れること を前提にしている。これは大丈夫か? • アジャイル開発は経験主義に基づく。経験した 事実を踏まえて計画を修正し続ける。修正範囲 にはスコープも含まれる http://www.flickr.com/photos/iain/353671249/
11. アジャイルマニフェスト • 2001年に、ケント・ベック、マーティン・ファウラー、ケ ン・シュウェイバーら、17人によって採択された
 Agileソフトウェア開発の原則を指す。
12. アジャイルマニフェスト • プロセスやツールより人と人同士の相互作用を重視する • 包括的なドキュメントより動作するソフトウェアを重視する • 契約上の交渉よりも顧客との協調を重視する • 計画に従うことよりも変化に対応することを重視する
13. アジャイル開発の原則 • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に 提供します • 要求の変更はたとえ開発の後期であっても歓迎します • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ 短い時間間隔でリリースします • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に 働かなければなりません
14. アジャイル開発の原則 • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と 支援を与え仕事が無事終わるまで彼らを信頼します • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・ フェイスで話をすることです • 動くソフトウェアこそが進捗の最も重要な尺度です • アジャイル・プロセスは持続可能な開発を促進します。一定の ペースを継続的に維持できるようにしなければなりません
15. アジャイル開発の原則 • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高め ます • シンプルさ(ムダなく作れる量を最大限にすること)が本質で す • 最良のアーキテクチャ・要求・設計は、自己組織的なチームか ら生み出されます • チームがもっと効率を高めることができるかを定期的に振り返 り、それに基づいて自分たちのやり方を最適に調整します
16. 手法の利用割合 State of Agile Survey 2011 (c)VersionOne
17. Scrum概要 http://www.flickr.com/photos/18091975@N00/3654141771/
18. Scrumとは • 可能な限り価値の高いプロダクトを生産的かつ 創造的に届けるためのもの • 複雑で変化の激しい問題に対応するための仕事 の進め方 • 既知のことより未知のことが多い領域に向いて いる • 役割・成果物・会議体を定めている
19. Scrumの特徴 • 軽量 • 理解が容易 • 習得は結構大変
20. 従来型と異なる点 • リソースと期間によって総量規制をかける • 総量をあふれる要求は実現されない • もしくは必要な機能を作り終わるまで期間が延 びる
21. 大事なことから始める 1番目に欲しい 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい 6番目に欲しい 7番目に欲しい 8番目に欲しい 9番目に欲しい ... 99番目に欲しい 100番目に欲しい • 欲しいものをリストにして 順位をつける • リストには項目が追加され たり、削除される • この順番は定期的に見直す • 優先度ではない!
22. 【 成果物1】 プロダクトバックログ http://www.flickr.com/photos/38793485@N00/3600409147/
23. 【ロール1】プロダクトオーナー • プロダクトバックログの管理者 • 優先順位の意思決定の最終決定 権限をもつ • プロダクトの責任者(結果責任) • プロジェクトに1人必ず必要 • プロダクトの価値を最大化する
24. 【ロール2】開発チーム http://www.flickr.com/photos/jurvetson/43922369/ • モノを作る • 3人∼9人で構成 • 全員揃えばプロダクトを作れる能力が揃う • 上下関係なし
25. 自己組織化 • 最良のやり方を自分たちで決める • 一番やり方をしっているのは現場の人
26. 一定のリズムで仕事する ◎同じ長さに区切って繰り返す 2週間 2週間 2週間 2週間 2週間 ☓期間の長さが変わってはいけない 2週間 4週間 1週 2週間 • 一定間隔で意思決定と作業と確認を行う • 最大4週間の固定の期間 • これをスプリントと呼ぶ 1週
27. 【会議1】スプリント計画会議 1番目に欲しい 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい 6番目に欲しい • スプリントで開発をするため には計画が必要 • プロダクトオーナーは何をほ しいか(第一部) 7番目に欲しい 8番目に欲しい 9番目に欲しい ... 99番目に欲しい 100番目に欲しい • 開発チームはどれくらいでき そうか(第一部) • 開発チームはどうやってそれ を実現するか(第二部)
28. 【成果物2】スプリントバックログ 1番目に欲しい 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい 6番目に欲しい タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク 7番目に欲しい 8番目に欲しい 9番目に欲しい ... 99番目に欲しい 100番目に欲しい • プロダクトバックログを具体 的なタスクに分割する • 後から増えることもある • 1タスクは1日以内のサイズ
29. 【成果物3】出荷判断可能な増分 • 開発チームは出荷判断可能なプロダクトの増分 をつくる
30. 出荷判断可能 • 部品だけでは出荷判断できない • 小さくても使えるものを作る
31. 完了の判断 あれもこれも できてないじゃ ない! ここまでできれ ば終わりだと思っ たんだけど
32. 完了の定義 • 完了の定義を作り、何をもって出荷判断可能か を定める • スプリントでどこまでやるか決める コード
 レビュー チェックイン ユニット テスト カバレッジ 75% 結合テスト 受け入れ テスト クロス ブラウザ 静的解析 ドキュメント 性能 セキュリティ デプロイ
33. 開発をすすめる • 開発チーム全員で仕事をすすめる • 特定の誰かに特定の責任が付与されるわけでは ない • 外部からやり方は指示しない http://www.flickr.com/photos/globalgamejam2009/3241345650/
34. 【会議2】デイリースクラム • 開発チームの状況を毎日検査する
35. 【会議2】デイリースクラム • 開発チームがスプリントゴールに向かって進ん でいるかを検証。残作業を追跡する • 毎日、同じ場所で同じ時間に開始 • 15分間で延長なし • たった3つの質問 • 開発チームのための会議で部外者は口出しなし
36. スプリントゴールへ進む • スプリント開始時点で決めたスコープを外圧に よって変更してはいけない
37. 【会議3】スプリントレビュー • 開発チームの成果物をプロダクトオーナーが確 認し、受け入れ可否を決める
38. デモを確認し受け入れを判断する 1番目に欲しい 頼んだ通りなのでOKです 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい これクリックした時の遷移先が 違うのでNGです 6番目に欲しい 7番目に欲しい 8番目に欲しい なるほど。今回はOKだけど次のス プリントで機能追加しようか 9番目に欲しい ... 99番目に欲しい 100番目に欲しい • プロダクトオーナーが厳密に判断する • 新しいアイデアはプロダクトバックロ グに項目を追加する
39. 短いフィードバックサイクル • 短いスプリント単位で頻繁に確認と調整を行い
 プロダクトをよりよくする • もちろん仕事のやり方ももっとうまくできるは ずなのでカイゼンを繰り返す
40. 【会議3】スプリントふりかえり • スプリントレトロスペクティブとも言う • 人、関係、プロセス、ツールなどの観点で今回 のスプリントを検査する • うまくいったこと、今後の改善点を整理する • 今後のアクションプランを作る
41. KPTをはじめ様々なやり方 http://www.flickr.com/photos/magnus_d/5121009259/
42. スプリントの中の過ごし方 スプリント計画会議第一部 スプリント計画会議第二部 デイリースクラム デイリースクラム デイリースクラム .......... スプリントレビュー スプリントふりかえり • すべてのスプリントで同じ過 ごし方をする • イベントの省略は不可 • スプリントに入るためには準 備が完了しているプロダクト バックログ項目が必要 • スプリント中に次スプリント のためにプロダクトバックロ グの手入れをするイベントを 行うこともある
43. イベントのタイムボックス イベントの種類 スプリント スプリント計画会議 1ヶ月スプリント 1週間∼4週間 8時間 デイリースクラム スプリントレビュー スプリントふりかえり それ以下 5% 15分以内 4時間 5% 3時間以内 • スクラムの基本はタイムボックス • 時間は原則延長しない
44. 繰り返す 2週間 2週間 2週間 2週間 2週間 • タイムボックスを繰り返して • POがほしいものから順に • 出荷判断可能なプロダクトを届け続ける • うまく届けられるように改善し続ける
45. 【ロール3】スクラムマスター • このプロセスがうまくまわるよ うにする • 妨害の排除 • 支援と奉仕
 (サーバントリーダーシップ) • 教育、ファシリテート、コーチ、 推進役
46. ワークショップ • ここまで説明したScrumのフレームワークを 1枚の絵で書いてください • 2人または3人一組で1枚作ってください • 5分で作成しそれが終わったらテーブルでお 互いに内容を確認してください • 分からないところを明らかにする http://www.flickr.com/photos/purecaffeine/4325067780/
47. Scrumまとめ プロダクトオーナー スプリント計画会議 開発チーム デイリースクラム スクラムマスター スプリントレビュー スプリントふりかえり プロダクトバックログ スプリントバックログ 出荷判断可能な増分
48. Scrumまとめ • 欲しいものを作る順番に並 と 替える。その順にモノを作るこ 成果を最大化する(価値を基準) • 短い時間に区切って繰り返す(タイム • 現在の状況や問題点を関係者の間 • 定期的に進捗状況や作っているモノ め方に問題 • 問題 ないか ックス) 常に共有(透明性) 正しいのか、仕事の進 うかを確認(検査) あったりもっとうまく きる方法 あれ 、やり方を
50. 復習用リソース • http:// www.scrum.org/ Scrum-Guides • 全員がルールを理解しない とゲームは成り立たない • プロジェクト関係者すべての 人が読むこと
51. アジャイル失敗の理由 組織変革が必要なことを理解 してなかった 組織文化や哲学がアジャイル の考えとあってない • 失敗の定義はなんだろう?
52. Scrumで大事なこと • Scrumで問題は分かるかもしれない • でもScrumが解決するわけじゃない • 解決するのは現場の皆さん自身 http://www.flickr.com/photos/rowanbank/8066004236/
53. スクラムチーム Scrum Team http://www.flickr.com/photos/basictheory/4056636664/
54. 責任を明らかにする • プロダクトオーナー、開発チーム、スクラムマ スターが責任を持つ(権限も移譲される)
55. プロダクトオーナーの責任 • ビジネス価値を最大化する責任 • プロダクトのビジョンを周りに示し理解させる責任 • プロダクトの結果責任 • プロダクトバックログの管理責任 • プロダクトバックログ優先順位決定の責任 • 予算の管理責任 • リリース日を決める責任 • 開発チームをうまく使う責任 • 開発チームの成果物の受け入れ可否を決める責任 http://www.flickr.com/photos/id-iom/6915530375/
56. 複雑な組織構造が及ぼす影響 http://www.flickr.com/photos/mwichary/2356663850/
57. 開発チームの責任 • スプリント計画会議で選択したプロダクトバックログ項目を完 了させるように最善を尽くす • 最善とは持続不能なペースで働くことではない • これは開発チームの責任であり、個人の責任ではない • 「必ず完了させる」責任があるわけではない • 見積りは予測にしか過ぎない。達成を必ず約束できるわけでは ない • 集中して仕事に取り組む責任 • 常に改善する責任 http://www.flickr.com/photos/eole/2750626364/
58. 集中して仕事をする責任 • マルチタスクは仕事の成果に問題を及ぼす
59. 複数プロジェクトを兼任しない • マルチタスクはストレスの原因になる • マルチタスクはエラーを起こしやすい。従って仕事の質が低下 する • タスクの切り替えは高コスト • 中途半端なタスクは全て未完了 • 稼働率は生み出す価値と関連性はない
60. 改善の責任 • 常に改善を続けること • スプリント1とスプリントNの やり方が同じであってはなら ない • 従って文書による過度な標準 化は弊害が多い • スプリントふりかえりは改善 の機会 http://bit.ly/mRLszj
61. ふりかえりによる改善 • プロセス改善の場 • 個人攻撃はしない • 個人の評価に結び付けない • Tryはほんとうにできている? 追跡重要 • 同じProblemが毎回でてきていない? • 一度に全部手をつけない • 出来ることから改善する
62. ルールに従う責任 • 各種会議に参加する責任 • 完了の定義に従って作業を行う責任 • みんなで決めたことに従う責任 http://bit.ly/qFy4Aq
63. 人材育成の責任 http://bit.ly/qb0Jd4 • 全員で人を育てる・協力しあい助け合う • OJTによるマンツーマンな人材育成ではなく、全員が協力し あってお互いの能力を向上させる
64. プロダクト バックログ Product Backlog
65. プロダクトバックログとは • 要求事項の一覧 • プロジェクト中求められる全ての成果の一覧 • 理想的には、各アイテムごとに利用者、顧客における価値が記 述されていることが望ましい • プロダクトオーナーによって優先順位付けされる • 各スプリントの開始前に再度優先順位は振り直される • 全ての項目が詳細である必要はなく、直近のスプリントが実行 可能な程度に優先順位上位の項目が詳細化されていること • 定期的に中身を見直す
66. 誰が作るか? • 特に決まりはない • プロダクトオーナーがプロダクトバックログの管理者 • プロダクトオーナーは優先順位付けの責任 • 通常はプロダクトオーナーがある程度作る • 開発チームやスクラムマスターは作成に協力する • アナリストが参加するケースもある • 誰でも項目を追加できる http://www.flickr.com/photos/funky64/6357504019/
67. プロダクトバックログの例 # プロダクトバックログアイテム 優先順位 見積り 1 ゲストとしてホテルを予約することができる 1 3 2 ゲストとしてホテルの予約をキャンセルできる 2 5 3 ゲストとして予約日時を変更できる 3 3 4 ホテルの従業員として部屋ごとの収支レポートを 作成できる 4 8 5 システム管理者としてエラーログが見れる 5 8 ... ... 99 20 ... ... 100 40 • スプレッドシート、情報カード、専用ツールなどで管理 • 誰でも追記できるが順番はプロダクトオーナーが決める
68. プロダクトバックログ項目 • 書き方に決まりはない • プロジェクト関係者の会話の道具なので、多くの人が理解 できるように書く • ユーザーストーリーやユースケースを使うことが多い http://www.flickr.com/photos/shewatchedthesky/2895159006/
69. ユーザーストーリーとは • 要求を自然言語で簡潔に記したもの <役割>として <機能や性能>が出来る それは<ビジネス価値>のためだ http://www.flickr.com/photos/koalazymonkey/3343007130/
70. ユーザーストーリーの例 顧客との会話に役立つ 計画づくりに役立つ 無駄な詳細化から解放される
71. ユーザーストーリーのINVEST • Independent • Negotiable • Valuable • Estimable • Sized Right • Testable http://www.flickr.com/photos/wonderwebby/2723279741/
72. Independent • 互いに独立していること • 依存関係や前後関係はなるべく排除 • 依存関係が高いと見積もりが難しくなる http://www.flickr.com/photos/infinitejeff/6143582/
73. Negotiable • 交渉可能 • 会話のための道具 • 一度決めたことが絶対なわけではない http://www.flickr.com/photos/netzkobold/2574295816/
74. Valuable • 価値がある • ユーザーにとって • ビジネスにとって • 開発チームにとって http://www.flickr.com/photos/lilcrabbygal/218495576/
75. Estimable • 見積もり可能 • 見積もりできるくらいの粒度と具体性 http://www.flickr.com/photos/42931449@N07/5336414318/
76. Sized Right • 自分たちが扱える適切な大きさ • 十分に項目が分割されている http://www.flickr.com/photos/openeye/4905602656/
77. Testable • 出来たか出来ていないかを判断できる • 受け入れテストを記述できる http://www.flickr.com/photos/alancleaver/4439276478/
78. 受け入れ基準とセットにする • 受け入れ基準(Acceptance Criteria)を使う • 受け入れ基準がある=テスト可能 • プロダクトバックログ項目は最低3∼5個の受け入れ基準を 持つ • デモ手順を予め作成することもある • ここで作成した受け入れ基準は、テストシナリオとなる(可能 ならBDDフレームワーク等を使って自動テスト化)
79. 受け入れ基準の例
80. ユーザーストーリーマッピング • 項目をグループ分けしてテーマにする • テーマ分けすることで網羅性が分かる • テーマ分けすることで優先度の高い項目が分かる 懸田氏の資料より引用 http://www.slideshare.net/kkd/user-story-mapping-for-agile-team
81. プロダクトバックログ項目の分割 プレミアムメンバーと してギリギリまで予約を キャンセルできる 利用者としてホテルの予 約をキャンセルできる • 分割によってそれぞれの項 目が異なる優先順位を持ち うる 一般客として24時間前 まで予約をキャンセルで きる 宿泊をキャンセルした 場合はそれを通知するメー ルが送られる
82. 優先順位決定の原則 • 高い価値のものから • 市場投入への時間を短く • リスクを最小化 • 将来の無駄を避ける http://www.flickr.com/photos/totifruity15/3890593890/
83. 狩野モデル Q1:ホテルの部屋に無料のミネラルウォーがあっ たらどう思いますか?  とても嬉しい  それって普通でしょ  特になんとも思わない  別にそれでも構わない  それは困る • その機能が実現された場合、実現さ れない場合にどう考えるかを5択で Q2:ホテルの部屋に無料のミネラルウォーターが なかったらどう思いますか? 選ぶ  とても嬉しい  それって普通でしょ  特になんとも思わない  別にそれでも構わない  それは困る
84. ワークショップ プロダクトバックログ作成 http://bit.ly/sC9vZ3
85. お題 あなたたちは会社の中で、飲 み会管理システムを作ること になりました。あなたたちは プロダクトオーナーに任命さ れました。プロダクトバック ログを作ってみてください。 ※ 他のお題を自分たちで設定しても構いません
86. ルール • プロダクトバックログ項目は付箋紙に記入 • プロダクトバックログ項目はユーザーストーリー形式で書く • チームで10個以上作成 • 項目には優先順位をつける • 模造紙に上から下に優先順位順に並べて貼る • タイムボックスは20分 • 終了後各3分間タイムボックスで発表 http://www.flickr.com/photos/koalazymonkey/3343007130/
87. プロダクトバックログの例 # プロダクトバックログ項目 見積り 優先順位 1 幹事として、飲み会企画の作成をすることができる 8 1 2 幹事として、飲み会候補日程と場所候補を参加者にメールとWeb上で通知すること が出来る 5 2 3 幹事として、飲み会の会場候補を手入力することによって複数提示することが出来る 2 3 4 幹事として、飲み会の候補日程を複数提示することが出来る 2 4 5 幹事として、会場候補への投票結果を確認することが出来る 2 5 6 幹事として、参加候補者を追加することが出来る 1 6 7 幹事として、参加者数や参加者情報を見ることが出来る 2 7 8 幹事として、飲み会の詳細情報を参加者に伝えることが出来る 2 8 9 幹事として、飲み会料金の徴収状況を管理することが出来る 5 9 10 幹事として、飲み会の直前に参加者にリマインドすることが出来る 3 10
88. 見積り Estimation http://www.flickr.com/photos/hifumiyo/761317988/
89. 見積りは誰がやる? • 見積もりは開発チームが行う • プロダクトオーナーやスクラムマスターは見積もらない • プロダクトオーナーやスクラムマスターは見積りの現場に いる http://bit.ly/rH6aaU http://bit.ly/pUG9Gp
90. 見積もり時のプロダクトオーナー • 聞きたいことがあったら何でも聞いてよ! http://bit.ly/rH6aaU
91. 見積もり時のスクラムマスター • プロダクトオーナーの見積に 対する圧力から開発チームを 守る • プロダクトオーナーと開発チー ムとの間の会話を促進する • タイムボックスを守らせる • プロダクトオーナーと開発チー ムを支援する http://bit.ly/skvs8c
92. 相対的な見積り
93. プランニングポーカー
94. プランニングポーカーの方法 • 基準となる小さいプロダクトバックログ項目を開発チームで 選択する • その項目のストーリーポイントを2とする • さらに上記の項目の2∼3倍程度の項目を選択する • その項目のストーリーポイントを5とする 2 5
95. 見積りの出し方 1 2 3 5 • 基準の2点を比較に使う! 8
96. 見積りの出し方 • 全員の見積が隣接する2つの数字に 収束していないので、最大値と最少 値を出した人は見積もり根拠を説明 した上でポーカーを繰り返す 議論することによって、見落としが分かったり
 理解が深まったりする
97. 見積りの出し方 • 隣接する数字に収束したので見積も り完了。大きい数字側を見積もりポ イントにする 素早く見積もり、ひとつの項目に時間をかけすぎないように
 する。素早いことに価値がある。
98. 見積りの出し方 1 2 • 人の意見を聞いて見積りを変えても良い • 人の意見は見落としや認識相違をみつけるチャンス
99. ワークショップ 見積り http://bit.ly/sC9vZ3
100. お題 • あなたたちは開発チーム のメンバーです • 先ほど作った飲み会管理 システムのプロダクトバッ クログ項目の見積もりを お願いします
101. ルール • 先ほど作ったバックログ項目を利用します • 手元に1,2,3,5,8,13のカードがあるか確認してください • チームで基準となる2および5ポイントのバックログ項目を決 めてください • それが出来たら他の項目を見積もってください • タイムボックスは20分 • 終了後各3分間タイムボックスで発表
102. スプリント バックログ Sprint Backlog http://www.flickr.com/photos/karthikc/333796870/
103. スプリントバックログ • スプリントで実施するプロダクトバックログアイテムをタスク に細分化する • タスクは理想時間単位で開発チームで見積もる • 開発チームの平均的なスキルの人を基準にする • 1タスクの最大時間は8時間位まで (=大きくなればなるほど 見積もり精度は下がる) • このタスクを一覧化したものがスプリントバックログ • 一日に実作業で使える時間は就業時間の60%ほど。キャパシ ティを考える
104. スプリントバックログの例 # スプリントバックログ項目 見積り(h) 1 htmlテンプレートの作成 8 2 受け入れテストの作成 5 3 fixtureの準備 2 4 テーブルスキーマの作成(マイグレーション) 2 5 モデルの作成(ユニットテスト含む) 8 6 コントローラーの作成 4 7 仕様書のWikiを更新する 2 8 ヘルプファイルの更新 2 9 Jenkinsにプラグインを導入する 5 性能測定をおこなう 3 10
105. スプリントバックログの扱い方 • 開発チームのメンバーが自身でタスクを選択し、指示による 割り当てを避ける • 作業の想定残り時間を随時更新する • 開発チームメンバーのだれでも、スプリントバックログの追 加、削除、変更ができる • 作業が不明確な場合, 大きな時間を割り当てたスプリントバッ クログ項目を定義し、後で細分化する
106. SMARTなタスク • Specific • • Measurable • • 達成可能。誰もがタスクを達成するのに必要な助けを開発チームの他のメンバー に求めることが出来る。 Relevant • • 測定可能。そのタスクの「完了」について全員が同じ理解を持っていること Achievable • • 関係者全員が理解できるくらい具体的であること。それによって他のタスクと の重複を防ぐ 全てのタスクはプロダクトバックログ項目の達成と関係があること。 Time-boxed • 時間で見積もりが行われていること。もしタスクが見積もりより時間がかかり そうだったり難しそうだったら複数のタスクに分割されること。
107. スプリントバーンダウンチャート http://www.flickr.com/photos/kakutani/2761992149/
108. スプリントバーンダウンチャート • 推定残り時間を更新してプロットする • 今までに使った時間を計測するのではない(それを測定したと ころでムダ) • 異常に素早く気づくツール • 異常に気づいたらチームで対応を考える • 改善のためのツール • 他の指標と組み合わせても良い
109. タスクボード I   : 3 24 C 4 4 4 : 3 24 C 4 4 4 : 3 24 C 4 4 4   : 3 24 C 4 4 4 : 3 24 C 4 4 4 : 3 24 C 4 4 4  # : 3 24 C 4 4 4 : 3 24 C 4 4 B 43 B 43 4 : 3 24 C 4 4 4 1 2 4 B 43 1 2 4 : 3 1 2 4 : 3 24 1 2 24 4 B 43 B 43 1 2 4 : 3 24 C 4 4 4 1 2 4 B 43 4 : 3 4 24 B 43 : 3 1 2 : 3 24 C 4 4 4 1 2 1 2 4 : 3 D 24 C 4 4 4 4 B 43 24 B 43 1 2 B 43 B 43 1 2 4 : 3 D 24 C 4 4 4 4 24 B 43 : 3 D 1 2 : 3 24 C 4 4 4 B 43 1 2 B 43 1 2 4 4 : 3 : 3 24 C 4 4 B 43 D 4 B 43 24 C 4 4 4 24 C 4 4 4 4 : 3 D D 1 2 24 C 4 4 4 4 1 2 4 D 4 : 3 1 2 B 43 D 4 B 43 24 C 4 4 4 24 C 4 4 4 D 4 4 D : 3 C 4 1 2 D C 4 4 4 1 2 24 D : 3 D B 43 B 43 C 4 4 4 D : 3 D C 4 4 4 D 4 C 4 4 4 24 C 4 4 4 D B 43 1 2 D C 4 4 4 D B 43 B 43 : 3 D D 4 1 2 D 1 2 B 43 1 2 B 43 1 2 4 D 1 2 : 3 24 C 4 4 4 B 43 1 2 4 1 2 4 1 2 4 D B 43 D B 43 D 4 D 4 D 4 : 3 24 C 4 4 B 43 1 2 4 D 4 • タスクの状況を可視化して毎日検査する
110. ワークショップ スプリントバックログ作成 http://bit.ly/sC9vZ3
111. お題 • あなたたちは開発チーム のメンバーです。 • プロダクトオーナーが選 択した上位3個の項目の スプリントバックログを 作ってください。
112. ルール • 先ほど作成したプロダクトバックログの優先順位が上位の3 個を選択する • タスクの洗い出しと個々の時間見積もりを行う • タスクの洗い出しが出来ない場合はプロダクトバックログ項 目の粒度が荒すぎるので分割 • 洗い出すタスクのサイズは0.5∼8時間程度 • そのプロダクトバックログ項目を実現するのに必要な全ての 項目を入れる • タイムボックスは20分。終了後3分間タイムボックスで発表
113. 応用トピック Advanced topics http://www.flickr.com/photos/nasamarshall/4365671029/
114. ベロシティ 第1スプリント 第2スプリント 第3スプリント 第4スプリント 第5スプリント 5 3 8 8 8 3 3 5 5 3 1 開発チームの生産能力を表す 完了したプロダクトバックログ項目の見積りの合計 3 1 3 1 1 9 10 1 14 15 14
115. ベロシティ • スケジュールはベロシティから予測する • もちろんあくまで予測 • スプリント数固定であれば、総生産量は • 平均ベロシティ スプリント数 • フィーチャー固定であれば、所要期間は • 総ストーリーポイント 平均ベロシティ • 最初の数スプリントが終わると、予測の精度は向上する(計算 の根拠となるベロシティが安定するため)
116. プロジェクトバーンダウン 140" 120" 100" 80" SP" SP" 60" SP" 40" 20" 0" #1" #2" #3" #4" #5" #6" #7" #8" #9" #10" • いつ頃プロジェクトが終わりそうか、期限が定められている 場合にどこまで作れそうか分かる
117. 品質の作り込み 単体テスト、結合テスト、受け入れ テストがスプリント単位(もしくはリ リース単位)で行われる
118. テスト自動化の必要性 小規模リリースのたびに手動でテス トするとコードベースが大きくなるに つれてテストコストが膨らむ • Scrumではフレームワークの定義のみで、テスト自動化につ いては触れられていない.
 しかしアジャイル開発においてはテスト自動化は必須
119. アジャイルテストの4象限 1 1
120. XPと組み合わせる ! ! ! YAGNI
121. DevOps • 開発と運用が協力しあって、継続的にプロダク トを顧客に届けつづける
122. 妨害事項リスト • プロジェクトを進める上で妨害となっている項目のリスト • スクラムマスターが管理し、項目には解決の優先順位を付ける • スクラムマスターは優先順位の高いものからスクラムチーム内 外と交渉して解決する • 物理的に解決不可能な項目は入れない • リストの項目は多くしすぎない
123. ドキュメントの扱い • ドキュメントを全く書かないわけではない • 必要な時期に必要なものを書く • 法令順守に必要な文書は、開発初期から必要なわけではない • 一方で保守・運用の資料はひとたびProductionリリースし たタイミングから常に保守される必要がある • 自動化できるものは自動化する • 完了の定義にドキュメントを含める • 文書承認主義の組織の場合、組織自体を改革する必要がある
124. 大規模化 Scrum of Scrum チーム1 チーム2 チーム3
125. ふりかえり・Q&A http://www.flickr.com/photos/an_untrained_eye/6630719431/
126. 発売中!! 定価:2520円 http://www.seshop.com/ product/detail/15395/ #scrumbcbook
No comments...
272013
Agile Coach / Certified Scrum Professional / Certified ScrumMaster / Certified Scrum Product Owner Twitter : @ryuzee Web : http://www.ryuzee.com

Related Slides