Download as KEY, PPTX
![LeSS Study [2015/Dec./16] 資料(公開版)](https://cdn.slidesharecdn.com/ss_thumbnails/20151216lessstudypub-151217003016-thumbnail.jpg?width=640&height=640&fit=bounds)
Scrum
- 1.
- 2.
- 3.
- 4. scrum開発 • Agile開発手法のうちの一つ • 開発方法ではなく、規律である •1993年にJeff Sutherland, John Scumniotales, JeffMcKennによって考案された。 ちなみに、ラグビーのスクラムにから 来ている。
- 5.
- 6. どうやる？ • 決まり事は３つだけ •３つのロール • （３つのリスト） • ４つのMTG
- 7. ３つのロール • プロダクトオーナー １チームに１人 •スクラムマスタ １チームに１人 • 開発者（チーム） １チームに５∼７人が良い
- 8. プロダクトオーナー • プロダクトの方向性を常に決める。 • ROIを管理 •PB（プロダクトバックログ）を管理
- 9. スクラムマスター • 各MTGをファシリテートする • 外部の障害を取り除き、チームに対し よりよい環境を作る • チームのサーバントリーダー、ファシ リテーター • チームのモチベーションを保つ
- 10. 開発チーム • クロスファンクショナルに活動 • PBをもとに、開発を行う •作業を見積もり、小さなタスクに分割
- 11.
- 12. プロダクトバックログ • 作ろうとしているものの為に必要なも のをリスト化したもの。 • 例）動物園を作る • 土地を買う • 動物を選ぶ/買う • 動物の檻を配置 などなど。。。
- 13. スプリントバックログ • POが作成したプロダクトバックログの 項目を、作業しやすいように分解した もの。チームメンバがスプリント計画 MTG時に作成する
- 14.
- 15.
- 16.
- 17. スプリント ディリーMTG スプリント計画 レビュー ふりかえり
- 18.
- 19. スプリント計画MTG • １スプリントの始め、もしくは途中に もう一度 •スプリント内にどれだけプロダクト バックログを行うかを見積もる為の 計画MTG
- 20. スプリント計画MTG 開発チームはプロダ プロダクトバックログを クトバックログをも スプリントバックログに とに、作業見積もり 分解 を行い、スプリント 内にどれだけの開発 を行うかをプロダク トオーナーにコミッ 開発チーム トメントする。 タスクボードという プロダクトバックログ ものを使って管理す るケースが多い。 プロダクトオーナー
- 21. 見積もり方 • 作業の見積もりは人月換算しない • なぜかというと、例えば５日でできると言ったものがあった場 合、その作業だけを行えば５日でできるだろうが実際開発を行っ ていると、トイレや休憩また、実際にやってみたらそれ以上にか かる事が判明する。その場合は、５日以上たってるけどどうして できない？といった問題が起きる。なので、Scrumでは、作業 ボリュームを換算する。
- 22. 見積もり方 • ベースポイントを決める チーム全員で作業のボリュームを共有できる内容の数値を決め る。これはできるだけ作業ボリュームが小さいものが良い。そし て、その作業に対して他の作業は５倍くらいかかりそう、などと 考えてストーリーポイントという数値を各スプリントバックログ に割り当てて行く。 • ストーリーポイントを割り当てて行く この時フィボナッチ数列を用いた数字を使う。何故かというと大 きな作業程、作業ボリュームは精度が低くなる。なので、そこに 対して多くの時間をかけポイントを見積もるよりも、粒度の低い 数値でポイントをつけた方がよい。大きすぎる作業は作業項目を 分けていく。
- 23. ディリーMTG • 毎朝行う。以下の３個について各自1分 以内に話す •昨日やった事 • 今日やる事 • 障害やチームに共有しておきたいこ と
- 24. スプリントレビュー • スプリント内に１回、ふりかえり前に 行う •スプリント内に出来上がった成果物 をPO(プロダクトオーナー）に見て もらう。
- 25. スプリントレビュー • Done(完了)の定義をもとにレビュー を行う チーム内にて、Done(完了)の定義をあらかじめ決める。その定義を 全て完了し、そしてプロダクトオーナーが受理したものを完了項目と する。完了したものにはもう修正は入れない。 完了していないものは終わっていないのでここではレビューを行って もらわない。時間の無駄！！
- 26. ふりかえり • スプリントの最後に行う •スプリント内に起きた問題。改善す べきことについて話す。
- 27.
- 28.
- 29.
- 30. ある程度のルールがあった方が作業がしやすい 日本人だもん。
- 31. 決まり事 • 作業の見積もりは人月換算しない。 •作業量をストーリーポイントという ポイントにて換算する
- 32. 決まり事 • Bugは元々ないもの！！ •でもそれは不可能。あった場合はす みかに直す。また4時間以上Bugの 改善に時間を要する場合は、POに相 談しよう。
- 33. 決まり事 • 各MTGはTimeBoxを決めて行う。 •いくら時間をかけて正確に見積もろ うとしても絶対無理！！長いMTGは 怠惰なものになる。
- 34. 決まり事 • 計画MTGは全員で参加 •開発チームはPOにバックログの内容 を確認する。 • 多人数の方が、ストーリーポイント に誤差が生じにくい。
- 35.
- 36.
- 37.
- 38. scrum精神 • チームメンバー全員の自己組織化 • 短期間サイクル •問題の可視化と改善！！ • コミュニケーション
- 39. チームメンバー全員 の自己組織化 • PMが作るものを全て作るのではな く、チームメンバー全員が考え、意見 をいい開発していく。全員が動くこと によって、より早く良いものができる
- 40. 短期間サイクル • スプリント事にレビューを行い、でき たものが正しく、そして要求していた ものに合っているかを確認する。 またレビューは全員が行う。開発チー ムは自分が作ったものを目の前で見て もらうことによって、肌で感想を聞け る
- 41. 問題の可視化と改善 • チームの中に起きている問題は、見え ないようにするのではなく、全員で共 有するもの。すぐに解決できるものは すぐに解決する。すぐに解決できない ものはふりかえりMTGにてチーム全員 で問題解決方法を考える。
- 42. コミュニケーション • 各MTGを怠惰なものにしない。 Timeboxを決めて行う。MTGに て、チームのメンバーが話し、より飽 和されたチームを作る
- 43.
- 44.