今こそスクラムを組む時だ！～責任と権利を持つチームの振る舞い～ Web
- 1. 今こそスクラムを組む時だ！ ～責任と権利を持つチームの振る舞い～ 2009.10.10 minamo
- 6. プロジェクトを
- 7. 自分を
- 8. チームを！
- 9. 今回の キーワード
- 10. チーム
- 11. １ ．スクラムとは？
- 12. スクラム スクラム（ＳＣＲＵＭ） １９９３年生まれ 反復型開発／素早い開発 キャノンやＭ３などは以前からスクラム的手法を使っていた アジャイルソフトウェア開発手法の一種
- 13. ゲーム業界でも・・・ ＣＥＤＥＣ２００９ 「 SCM 最新技術事例～「 Star Wars:The Old Republic 」での大容量ゲーム開発～ 」 ＧＤＣでは毎年講演がある？ 北米が多いが、日本でも事例がちらほらと
- 15. チームが一体となって進める手法
- 16. スクラムの範囲 プロジェクトに対する思想 プロジェクトライフサイクル タスクマネジメント （チームビルディング）
- 17. チームが一体となって進める手法
- 18. スクラムの範囲 チームが一体となるための プロジェクトに対する思想 チームで進める プロジェクトライフサイクル チームで進める タスクマネジメント （ チームが一体となるための チームビルディング）
- 19. スクラムの価値（思想）
- 20. ５つの価値 コミットすること 集中すること オープンであること 敬意を払うこと 勇気を出すこと これらについては後で触れます
- 21. ２．スクラムのプラクティス
- 22. プロジェクトライフサイクル
- 23. スクラムのＰＪライフサイクル 計画 準備 リリース スプリント（イテレーション） による繰り返し 開発
- 24. 計画フェイズ 企画立案 予算確保 初期のプロダクトバックログの作成 （調査のための設計とプロトタイプ作成）
- 25. 準備フェイズ さらに詳細な仕様を策定 最初のイテレーションに必要な優先順位付け （調査のための設計とプロトタイプ作成）
- 26. 開発フェイズ スプリント（イテレーション）を繰り返し、実装を進める スプリント内のＰＤＣＡ 各種バックログの更新
- 27. リリースフェイズ 最終デバッグ リリースのための文書等の作成 リリース
- 28. バックログ
- 30. バックログの種類 プロダクトバックログ リリースバックログ リリースバックログ スプリントバックログ スプリントバックログ スプリントバックログ リリースバックログ
- 32. リリースバックログ プロダクトバックログから、次期リリース（ α とか β とか）の項目を抜き出したもの 抜き出し後、さらに粒度を細かくすることもある
- 33. スプリントバックログ あるスプリントで行うことのリスト（ＴｏＤｏリスト） 残作業時間を日々トレースする ひとつのタスクは通常４～１６時間くらい
- 34. スプリント
- 35. スプリント（イテレーション） 一定期間の開発サイクル プロダクトバックログの中から一部を抜き出して、この期間中の完成を目指す スクラムでは１スプリント３０日が推奨されている （ただし、ゲームの場合もっと短い方がいい気がする）
- 36. スプリント計画ミーティング スプリントを開始する前（もしくはスプリントの最初）に２つのミーティングを行う １つはステークホルダー（利害関係者）が集まり、 プロダクトバックログとリリースバックログの精度を上げる もう１つは、スクラムチームとプロダクトオーナーが集まって スプリントバックログを作る
- 40. スクラムミーティングの内容 １．この１日で何をしたか ２．この１日で何を行うか ３．スプリントの目標を達成するための障害 （４．スプリントバックログに追加するものはあるか？） （５．新たに学んだことはあったか？）
- 41. スプリントレビュー スプリントの最後にスクラムマスター主催で行うレビュー ステークホルダーにスプリントの成果物を見せる ＰｏｗｅｒＰｏｉｎｔなどは使わずに、開発して動いている状態のものを見せることを中心に進める
- 42. スクラムマスター
- 43. スクラムマスターとは スクラムチームの代表 スクラムを成功させる責任を持つ人 スクラムの価値（思想）、プラクティス、ルールを正しく守って運用する人
- 44. スクラムマスターの役割 スクラムを主導する チームの障害を取り除く 決断が必要な際に素早く下す（基本１時間以内）
- 45. ３．スクラムに関するその他知識
- 46. 中規模・大規模開発の場合
- 47. 中規模・大規模開発の場合 スクラムは基本的に７人（最大でも１０人）以下を想定している 中規模・大規模開発の場合は、スクラムチームを複数で構成する スクラムマスターたちで、スクラムチームを組む
- 48. 複数チームでのスクラム スクラムチーム スクラムチーム スクラムチーム スクラム スクラムマスター メンバーＡ メンバーＢ メンバーＣ メンバーＤ メンバーＥ スクラムマスター メンバーＡ メンバーＢ メンバーＣ スクラムマスター メンバーＡ メンバーＢ メンバーＣ メンバーＤ
- 49. 他手法との併用 スクラムは他のアジャイル開発手法と競合しないので、併用されることが多い 特にＸＰとの併用は有名 ＸＰ スクラム 技術的要素が強い マネジメント要素が強い
- 50. 苦労しそうな点
- 51. タスクの見積もり 各タスクごとに時間で見積もりをつけるのは難しい（特にプログラム作業） 誤差が３倍ほど出ることは日常茶飯事 悩んだ時は、「三点見積もり法」でとりあえず数値を決めておけば大体問題ないはず
- 52. 三点見積もり法 楽観値：全てが上手くいった場合 通常値：期待値。普通に考えた場合。 悲観値：進みが最悪だった場合。 （ 楽観値 ＋ 通常値 × ４ ＋ 悲観値 ） ÷ ６ 個人的には次のくらいでも悪くない気がする （ 楽観値 ＋ 通常値 × ２ ＋ 悲観値 ） ÷ ４
- 53. ４．スクラムの価値を振り返って
- 54. ５つの価値 コミットすること 集中すること オープンであること 敬意を払うこと 勇気を出すこと
- 55. コミットすること スクラムチームは、イテレーションの達成目標にコミットする（ 責任を負う ） その代わり、達成するためにどうするかを自分たちで判断する権限と 自治権を与えられる イテレーション内での仕様追加が許されないのもこのため
- 58. 敬意を払うこと チームメンバーそれぞれの長所／短所に敬意を払う 何か失敗しても、責任転嫁しないのはもちろんのこと、誰か一人の責任にしない 自己組織化と自立によって、問題を解決する
- 60. ５．スクラムは結局なんなのか
- 61. こう考えると 見えてくる
- 62. 普通にプロジェクトのフローを考える １．基本仕様を起こして「機能リスト」を作成する ２．実装順番を考える ３．細かいタスクを考える ４．進捗を把握し、問題を解決する ５．機能がある程度出来たらフィードバックを受ける
- 63. １．基本仕様を起こして「機能リスト」を作成する ２．実装順番を考える ->計画・準備フェイズ ->プロダクトバックログの作成
- 67. “ 当たり前”のこと
- 68. しかし
- 70. つまりスクラムとは
- 74. チームが一体となって進める手法
- 75. スクラムを組んでみましょう！
- 76. ありがとうございました！
- 77. 参考文献 初めてのアジャイル開発 ~ スクラム、 XP 、 UP 、 Evo で学ぶ反復型開発の進め方 ~ （クレーグ・ラーマン著） アジャイルソフトウェア開発スクラム （ケン シュエイバー著）