こんにちは、開発2部のTashです。
今回関わったプロジェクトでは、開発手法としてスクラム開発を取り入れていました。
本記事では、その中で行われていたイベントを、実際の現場の空気感とあわせて紹介します。
▼前回の記事はこちら。
【アジャイル開発 #1】 アジャイル開発の現場に入って、最初に感じた戸惑い
【アジャイル開発 #1】では、アジャイル開発の現場に入って最初に感じた戸惑いについて書きました。
今回は少し視点を変えて、アジャイルで行われる「イベント」全体を俯瞰してみたいと思います。
アジャイルと聞くと、「イベントが多い」という印象を持たれる方も多いかもしれません。
実際、私も最初はそう感じていました。
ただ、半年ほど関わってみて分かってきたのは、
これらのイベントは単発で存在しているのではなく、1スプリントの流れの中でつながっているということでした。
スプリントの前提
私が関わっていたプロジェクトでは、
1スプリントを2週間として開発を進めていました。
この2週間という区切りの中で、
- 準備する
- 決める
- 作る
- 振り返る
というサイクルを、繰り返していく形です。
イベントも、このスプリントの流れに沿って配置されています。
デイリースクラム
デイリースクラムは、スプリント期間中に毎日行われる短いミーティングです。
最初の頃は、どうしても進捗報告の場になってしまい、
「これを毎日やる意味は何だろう？」
と感じていました。
ただ、回数を重ねるうちに、
ここは状況を共有し、ズレや問題を早めに見つけるための時間なのだと捉えるようになりました。
問題が大きくなる前に気づける、という点では、
アジャイルらしさを一番実感しやすいイベントだったかもしれません。
プロダクトバックログリファインメント（PBR）
私が関わっていた現場では、
スプリントプランニングの前に、プロダクトバックログリファインメント（PBR）の時間が設けられていました。
PBRでは、
- 今後取り組む可能性のあるバックログを確認する
- PBIとして進められそうかを整理する
- ストーリーポイントの見積もりを行う
といったことを、事前に行っていました。
ここでの目的は、
プランニングの場で初めて見る状態を減らすこと、
そして「次回のスプリントで扱える状態（レディ）」に近づけておくことだったように思います。
運用としては比較的軽めで、
細かく詰め切るというよりも、認識を揃えるための準備という位置づけでした。
スプリントプランニング
スプリントプランニングは、そのスプリントで「何に取り組むか」をチームで決める場です。
PBRである程度整理されているとはいえ、
要件定義を担当する立場としては、
- どこまで決めておくべきか
- どの情報があれば進められるのか
と悩むことの多いイベントでした。
この場では、すべてを完璧に決め切るというよりも、
スプリントを進めるための前提を揃えることが重視されていたように感じています。
スプリントレビュー
スプリントレビューでは、そのスプリントで完成した成果物を関係者と一緒に確認します。
実際に動くものを見ることで、
- 想像していたものと違った
- ここはもう少しこうしたい
といった意見が自然に出てきます。
要件を文章だけで詰めるのではなく、
成果物を前に会話が生まれる点が印象的でした。
レトロスペクティブ
レトロスペクティブは、スプリントの最後に行う振り返りの場です。
「何がうまくいったか」
「どこが難しかったか」
をチームで共有し、次のスプリントにつなげていきます。
最初は少し抽象的に感じていましたが、
チームの進め方や雰囲気が、少しずつここで調整されていく感覚がありました。
イベントを通して見えてきたこと
こうしてスプリント全体を眺めてみると、
アジャイルのイベントは「報告のため」ではなく、
チームで考え続けるための仕組みなのだと感じています。
最初は多く感じたイベントも、
それぞれの役割が分かってくると、
2週間のスプリントを回すために必要なものだと捉えられるようになりました。
次回に向けて
次回の記事では、
スプリントプランニングやタイムボックスに焦点を当てて、
- 何を決めたのか
- 何を決めすぎなかったのか
- 要件定義の粒度をどう考えていたのか
といった点を、実務視点で掘り下げていく予定です。
プロダクトバックログリファインメントでの判断や、
現場での工夫についても、もう少し詳しく書いていきたいと思います。
