scrum初心者に向けた資料です。 keynote処女作。

1. SCURMとは

2. It s SCURM!!

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. ４つのMTG
•スプリント計画MTG
•ディリーMTG
•スプリントレビュー
•ふりかえりMTG
それらをスプリントという開発周期
にあてこんで開発を行っていく

16. スプリント（開発周期）を決めその中で、
各MTGを行い開発を行って行く。

17. スプリント
ディリーMTG
スプリント計画 レビュー
ふりかえり

18. このスプリントを何度もまわしていくことが大事！！
スプリントは2∼4週間。できるだけ短いサイクルで
まわした方がよい。何故かというと、ふりかえりにて
チームの改善を試みるのだが、チームはできるだけ多
くの改善を行った方が良いから！！

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. 決まり事
• 計画MTGで、作業する人は決めない。
作業する人はディリーMTGにて決める

36. それだけ守れば立派なスクラム開発！！

37. でも、より楽しく良いものが作りたい！！

38. scrum精神
• チームメンバー全員の自己組織化
• 短期間サイクル
• 問題の可視化と改善！！
• コミュニケーション

39. チームメンバー全員
の自己組織化
• PMが作るものを全て作るのではな
く、チームメンバー全員が考え、意見
をいい開発していく。全員が動くこと
によって、より早く良いものができる

40. 短期間サイクル
• スプリント事にレビューを行い、でき
たものが正しく、そして要求していた
ものに合っているかを確認する。
またレビューは全員が行う。開発チー
ムは自分が作ったものを目の前で見て
もらうことによって、肌で感想を聞け
る

41. 問題の可視化と改善
• チームの中に起きている問題は、見え
ないようにするのではなく、全員で共
有するもの。すぐに解決できるものは
すぐに解決する。すぐに解決できない
ものはふりかえりMTGにてチーム全員
で問題解決方法を考える。

42. コミュニケーション
• 各MTGを怠惰なものにしない。
Time boxを決めて行う。MTGに
て、チームのメンバーが話し、より飽
和されたチームを作る

43. それらのルールとScrum精神を守れば、よ
り良いチームが作って行ける。世の中には
色々なツールが出回っているけど、チームの
障害を取り除くのは人なので、ツールにこ
だわる事はない。ただ、解決する方法が自
動化できるようなものがあればツールを使
うべきである。

44. • 終わり。