こんなことがありました。
20xx年6月1日
PM「本日の進捗どうですか？」
ぼく「問題ありません」
20xx年6月2日
PM「本日の進捗どうですか？」
ぼく「(あかん。。思った以上に範囲大きすぎて、わからへん。。。まぁ多分終わるやろ)
ぼく「問題ありまへん！」
20xx年6月5日
PM「本日の進捗どうですか？」
ぼく「あかんで(^)(^) １週間ほど遅れそうやわ、原因は既存実装の複雑さが予想以上にあったことや、調査不足ですまんな〜＾q＾」
PM「」
なぜ起きたか
- タスクの粒度が大きすぎる（ざっくりと A機能の開発 みたいな）
- 実装箇所についての調査不足
- 進捗確認でどこまで終わったか？どのぐらい終わったか？の確認がない
- タスクの期限が不明瞭
なんちゃってプランニングはやっていた
- PMがやってほしいタスクを説明
- エンジニアチームにタスクを振る（期限は決まってはいるものの 6月に開始して 8月初旬には〜みたいなタスクもあった）
- ２週間ごとに再プランニング
30分ぐらいで終わっていた
問題点
- 期限が明確でないので進捗もよくわからない
- ２週間単位なので大きいタスクでも振れてしまう（タスクの細分化を意識しない
- やるべきこと ばかり多く、それが本当にサービスの価値につながるか？の議論は少なめだった
ちゃんとした スプリントプランニング とやらをやってみよう！
スプリントプランニングの流れ
スプリント期間の設定（今回は１週間とした）
- スプリントゴールの設定
- 実行するタスクの選定
- 選定したタスクの細分化
今まではゴールが明確ではなかったのと、タスクの細分化が行われていなかった。
例：
スプリントゴール
ユーザー数の増加とともにDAUを増やす。
実行するタスクの選定
登録中の離脱率が高いのでリマインドメールの実装
継続的にコンテンツを見れるようにスライダーの利用
選定したタスクの細分化
- リマインドメール機能
- 要件決め
- 設計
- 実装
- テスト実装
- 手動テスト
- スライダーの実装
- 利用するライブラリの選定
- 実装
- テスト
細分化したタスクをスプリント内で実施する。
細分化の基準は1日で終わるぐらいまでやったほうがいい。
例えば実装に２日かかるなら
XXまでを1日
YYまでを1日
といったように、更に細分化していく。
やった結果どうなったか
20xx年6月1日
PM「ぼく君、本日のA機能の調査について進捗どうですか？」
ぼく「はい！A機能についてですが、既存機能の修正がありそうなので実装のタスクが1日ほど伸びそうやで！」
PM「おけまる水産」
20xx年6月2日
PM「本日の実装の進捗どうですか？」
ぼく「実装のうちAPI開発については終わったで！既存の修正を明日やる感じや！」
PM「OK牧場」
20xx年6月5日
PM「本日のA機能のテストの進捗どうですか？」
ぼく「問題ないで！遅れもなく期限通り終わりそうや！」
結果: (^)(^) にっこり
機能を細分化したことで遅れが発生した際もカバーできる範囲になり、結果として全体の進捗への影響も少なくなった。
またプランニングの時点で価値提供を考え行ったことで無駄のない開発が行えた。