スクラム開発ドキュメンタリー~なぜなぜ、落ちるスクラム開発速度~
by
suger4
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. ©2020 RAKUS Co., Ltd. スクラム開発ドキュメンタリー ~なぜなぜ、落ちるスクラム開発速度~ 開発統括部 第一開発部 楽楽明細開発課 柴田 知詩
Slide 2
Slide 2 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 自己紹介 • 柴田 知詩 • 楽楽明細の開発担当 • 機能開発・運用保守・サポート etc… • 経歴 • 2017~: 運用/保守T • 2019~: 開発Tへ • 趣味 • ギター、模型製作(ガンプラ)、 ダイビング etc…
Slide 3
Slide 3 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 本日のお話し 1. 楽楽明細Tのスクラム 2. 起きてしまった認識ズレ&手戻り 3. 現在の開発スタイルの紹介
Slide 4
Slide 4 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 概要
Slide 5
Slide 5 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd.
Slide 6
Slide 6 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 1. 楽楽明細Tでのスクラム
Slide 7
Slide 7 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. スクラム開発って? アジャイル開発の手法の一つ • 「スプリント」と呼ばれる短い期間で開発を行う • スプリント単位で 機能の実装 と 評価/FB を経て開発を進めていく メリット • スプリント単位の計画を行うため、正確な見積もりがしやすい • スプリント単位でFBを得られるため、仕様変更に対応しやすい
Slide 8
Slide 8 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. スクラム開発って? アジャイル開発の手法の一つ • 「スプリント」と呼ばれる短い期間で開発を行う • スプリント単位で 機能の実装 と 評価/FB を経て開発を進めていく メリット • スプリント単位の計画を行うため、正確な見積もりがしやすい • スプリント単位でFBを得られるため、仕様変更に対応しやすい
Slide 9
Slide 9 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 開発スタイル
Slide 10
Slide 10 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 開発スタイル 企画チーム(PO) 開発チーム ユーザーストーリー スクラムマスター
Slide 11
Slide 11 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 2. 起きてしまった認識ズレ& 手戻り
Slide 12
Slide 12 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 実装を終え、迎えたデモの日・・・
Slide 13
Slide 13 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 実装を終え、迎えたデモの日・・・ この機能って、A機能が有効でないと使えな いってこと?
Slide 14
Slide 14 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 実装を終え、迎えたデモの日・・・ この機能って、A機能が有効でないと使えな いってこと? ユーザ操作の中で○○のように やりたいというニーズもあって~
Slide 15
Slide 15 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 実装を終え、迎えたデモの日・・・ この機能って、A機能が有効でないと使えな いってこと? ユーザ操作の中で○○のように やりたいというニーズもあって~ この画面イメージなら○○みたいな操作も あり得そうだよね~
Slide 16
Slide 16 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 認識ズレ&手戻りが発生…
Slide 17
Slide 17 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. どこがマズかったのか? I. 自明だと思いこんで確認を怠った II. ユースケースの確認不足 ⇒結果的にデモで見つかることに…
Slide 18
Slide 18 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. どこがマズかったのか? I. 自明だと思いこんで確認を怠った II. ユースケースの確認不足 ⇒結果的にデモの時に見つかることに… ※ デモで見せていたものは結構作りこんだ後…
Slide 19
Slide 19 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. I. 自明だと思いこんで確認を怠った • 前バージョンで生んだ制約を取っ払う案件 • 以前確認したことは自明という思い • 操作イメージやユースケースを確認せずに開発を進めた • 過去に確認したことでも、 利用している中で操作イメージやユースケースは変化し ていた
Slide 20
Slide 20 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. I. 自明だと思いこんで確認を怠った • 前バージョンで生んだ制約を取っ払う案件 • 以前確認したことは自明という思い • 操作イメージやユースケースを確認せずに開発を進めた • 過去に確認したことでも、 利用している中で操作イメージやユースケースは変化し ていた
Slide 21
Slide 21 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. II. ユースケースの確認不足 •開発に渡ってきたユーザーストーリー • ユースケースは揃っているものと認識していた。 •実は幅広い利用シーンがあって、その要件に合致し ていない。 • ユースケースの洗い出しができていなかった
Slide 22
Slide 22 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. II. ユースケースの確認不足 •開発に渡ってきたユーザーストーリー • ユースケースは揃っているものと認識していた。 •実は幅広い利用シーンがあって、その要件に合致し ていない。 • 要求/ユースケースの洗い出しができていない
Slide 23
Slide 23 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 確認する手間を怠ったんじゃない?
Slide 24
Slide 24 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. スクラムに対しての勘違い(過信) •イテレーションを回すタイミングで都度確認で きるから、認識齟齬は生まれにくい •素早く作って、デモで見せて問題を刈り取って いけばよい
Slide 25
Slide 25 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. スクラムに対しての勘違い(過信) •イテレーションを回すタイミングで都度確認で きるから、認識齟齬は生まれにくい •素早く作って、デモで見せて問題を刈り取って いけばよい
Slide 26
Slide 26 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 「早い段階で要求を出し切る」営みが必要
Slide 27
Slide 27 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 3. 現在の開発スタイル
Slide 28
Slide 28 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 問題への対応策 I. 自明だと思いこんで確認を怠った • ⇒小さなことでも自明であるとは思わない II. ユースケースの確認不足 • ⇒ユーザストーリーに表現されていないものを 事前に洗う必要がある。
Slide 29
Slide 29 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 現在の開発スタイル a. 要求分析はウォーターフォールっぽく b. 決まった要件をもとに、アジャイルに開発 ※ すべての案件がこのルートを通るわけではありません
Slide 30
Slide 30 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. a. 要求分析はウォーターフォールっぽく • 出てきていない要件や、ユースケースの洗い出し • ⇒ こまめに確認 • 確認用のドキュメントは作りこまない、永続的に メンテナンスしない • 調整に時間をかけすぎない • 認識合わせで決まったことを随時反映する形。 ※ すべての案件がこのルートを通るわけではありません
Slide 31
Slide 31 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. a. 要求分析はウォーターフォールっぽく • 出てきていない要件や、ユースケースの洗い出し • ⇒ こまめに確認 • 確認用のドキュメントは作りこまない、永続的に メンテナンスしない • 調整に時間をかけすぎない • 認識合わせで決まったことを随時反映する形。 ※ すべての案件がこのルートを通るわけではありません
Slide 32
Slide 32 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. b. 決まった要件をもとに、アジャイルに開発 •開発を進めて小さな単位でデモ、 そしてブラッシュアップ ※ すべての案件がこのルートを通るわけではありません
Slide 33
Slide 33 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 現在の開発スタイル ウォーターフォールとアジャイル のいいとこどりを目指す! ※ すべての案件がこのルートを通るわけではありません a. 要件決める部分はウォーターフォールっぽく b. 決まった要件をもとに、アジャイルに開発
Slide 34
Slide 34 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. うまくいってる?
Slide 35
Slide 35 text
#RAKUSMeetup ©2020 RAKUS Co., Ltd. 現在進行形のため、またの機会に…