Tweet
Tweet

Slide 1

Slide 1 text

Introduction to Scrum

Slide 2

Slide 2 text

About me Yoshitaka Terazawa Twitter: @locol23 GitHub: locol23 WORKING AT Gurunavi, Inc. as a frontend developer A MEMBER OF React Japan User Group FAVORITE React + TypeScript Architecture

Slide 3

Slide 3 text

スクラムとは アジャイル開発の中のひとつ 改善のフレームワーク 全員が⼀丸となって⾏うべき 作業、会議、成果物 を定めたもの

Slide 4

Slide 4 text

ウォーターフォール開発とアジャイル開発の違い

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

ウォーターフォール開発 開発中に要件が頻繁に変わらないプロジェクト ダムの⽔量制御システム等 アジャイル開発 開発中に要件が頻繁に変わるプロジェクト 夏向けに BBQ 特集をしようとしていたが、 コロナの影響で急遽、テイクアウト特集に変更等

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

ロール プロダクトオーナー 開発チーム スクラムマスター

Slide 10

Slide 10 text

プロダクトオーナー プロダクトの結果責任を取る プロダクトバックログの管理者で、 ストーリーの並び順の最終決定権限を持つ プロジェクトに必ず⼀⼈必要 開発チームを活⽤して、プロダクトの価値を最⼤化する 開発チームに相談できるが、⼲渉はできない

Slide 11

Slide 11 text

開発チーム リリース判断可能なプロダクトをつくる 3-9⼈で構成する 全員揃えばプロダクトをつくれる 上下関係はない

Slide 12

Slide 12 text

スクラムマスター スクラムがうまくまわるようにする プロダクトバックログの書き⽅を プロダクトオーナーや開発チームに教える プロダクトバックログの良い管理⽅法を探す 妨害を排除する 妨害リストを作成する プロジェクト B の急な作業がよく割り込んでくるなど

Slide 13

Slide 13 text

スクラムマスター ⽀援と奉仕をする プロダクトオーナーと開発チームの会話を促す プロダクトオーナーと開発チームの⽣産性が⾼くなるように 変化を促す 教育、ファシリテート、コーチ、推進役 プロダクトオーナーや開発チームに アジャイル開発やスクラムについて説明し、理解してもらう 必要に応じて会議の進⾏を⾏う

Slide 14

Slide 14 text

プロダクトバックログ

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

プロダクトバックログ プロダクトへの要求（実現したいこと）を実現したい順番に並べ替えた プロダクトバックログ と呼ばれるリストを１つ作成 要求 ＝ ストーリー プロダクトオーナーが管理する 常にメンテナンスを⾏い最新に保つ

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

具体的なストーリーの書き⽅ ＜ユーザー / 顧客＞として ＜XXXを達成＞したい なぜなら＜理由＞だからだ ＜30代の求職者＞として ＜勤務地で仕事を探＞したい なぜなら＜地元に帰りたい＞から

Slide 19

Slide 19 text

ストーリーには How を書かない ユーザー(Who)の望みは、理由(Why)から出てきているため、 Why を実現する⼿段(How)はむしろ、 開発チーム(UI・UX デザイナー)の腕の⾒せどころ

Slide 20

Slide 20 text

ポイント ストーリーに対してつけるもの 開発チーム内のローカルな数値（規模感）

Slide 21

Slide 21 text

ベロシティ スプリントで開発チームが実現できたストーリーのポイント合計 ベロシティを元にスプリントプランニングでどの程度スプリントに ストーリーを⼊れる(スプリントバックログに載せる)か検討する ⼈を増やしても馴染むのに時間が掛かるため、 すぐにはベロシティは上がらない 周りからベロシティを上げてほしいと声が上がっても聞いてはいけない ベロシティが上がるように簡単なストーリーを消化するなど、 細⼯してしまいがちなため 安定したベロシティであれば、⾒積もりとして使⽤できる

Slide 22

Slide 22 text

スプリントプランニング

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

スプリントプランニング スプリントで開発をするためには計画が必要 プロダクトオーナーは何をほしいのか（第⼀部） 開発チームはどれくらいできそうか（第⼀部） 開発チームはどうやってそれを実現するか（第⼆部）

Slide 25

Slide 25 text

スプリント

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

スプリント 繰り返し開発を⾏う固定の期間のこと 週単位で期間が設定されることが多い 短ければ1週間、最⻑4週間 スプリントの最終⽇に作業が残っていてもスプリントは終了し、 延⻑はしない スプリントの期間はプロダクトの規模や開発チームの⼈数、成熟度、 ビジネスの状況などを踏まえて決定する

Slide 28

Slide 28 text

スプリントレビューと振返り

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

スプリントレビュー プロダクトオーナーが完了したストーリーの内容を確認する 開発チームが完了できなかったバックログの項⽬について説明する プロダクトオーナーがプロダクトの状況やビジネスの環境について説明する プロダクトバックログに追加すべき項⽬の有無について議論する プロジェクトを進める上で問題となる事項について関係者で議論する

Slide 31

Slide 31 text

振返り（スプリントレトロスペクティブ） プロセスやツールなどの観点で今回のスプリントを検査する うまくいったこと、今後改善すべき点を整理する 今後のアクションプランをつくる スクラムでは何か新しい試みや改善を⾏い失敗しても、 スプリントが短いため、⼩さい失敗になる 挑戦しやすい環境と⾔える

Slide 32

Slide 32 text

デイリースクラム

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

デイリースクラム 開発チームの状況を毎⽇確認する 内容 前回のデイリースクラムからやったこと 次回のデイリースクラムまでやること 困っていること

Slide 35

Slide 35 text

まとめ スクラムは改善のフレームワーク プロダクトオーナーが優先度をつけ、プロダクトバックログを管理する ストーリーは How を⼊れず、INVEST を意識して作成する 今回触れていないこと リファインメント インセプションデッキ プランニングポーカー etc

Slide 36

Slide 36 text

Appendix

Slide 37

Slide 37 text

参考 SCRUM BOOT CAMP