リズムをつくる開発サイクルと会議のペース
先日発売されたこちらで取材された内容なのですが、せっかくなのでもう少し詳しく書いてみようと思います。スクラムの実践方法というよりも、円滑に回すために会議や意思決定のタイミングを工夫した内容です。
前提条件
以下が実施した条件です。
会議のリスト
イテレーションは２週間で切っていて、その中で以下の会議を実施しています。
開発者全員が参加するもの
- 朝会
- スプリント計画
- 振り返り
- プロダクトチェック会
- 仕様レビュー会
プロダクトオーナーが参加するもの
会議の実施内容とタイミング
Daily - 朝会
これは毎朝実施されます。デイリースクラムも呼び、その日のやることや問題となっていることなどを共有する場として使っています。
Day1 - スプリント計画
これは開発期間の開始日に実施します。その時点で決まっているプロダクトバックログをベースに個々のタスクに落としてアサインしていきます。
最終的にはカンバン化して物理的にホワイトボード上で管理をするようにしています。
実施するものはプロダクトバックログの単位でGithub上にisuue化しておきます。milestoneはリリース日にして、以降のその機能に関する議論はisuue上で行います。
Day1 - プロジェクト運営MTG
プロダクト開発そのものよりも、チームとしての問題やその他環境問題などについて話す場です。マネージャー陣中心になる会議でかつ頻繁に問題がでるものでもないので、終わり次第すぐに切り上げます。
Day6 - プロダクトバックログMTG
開発するものの一覧の整理と、優先順位を見直す場です。こちらもマネージャー陣のみの参加です。新しい要件などの追加もこちらで話すようにしています。
ここにはデザイナーであるプロダクトオーナーが参加をしていて、次のイテレーションで実施されるだろうもののラフなデザインを作り始めます。
Day9 - プロダクトチェック
今のイテレーションで実装された内容が動作しているかチーム全員で動作確認をします。ここででた不具合や実装のモレなどを可視化してリリースまでに修正をします。
Day9 - 仕様レビュー
次のイテレーションで実施する内容をチームに共有します。この時点でプロダクトオーナーが作ったラフなデザインが共有されます。チーム全体に共有されるため、仕様的な問題点などはここでクリアするようになっています。
問題がなければ、ここで共有された内容が機能一覧としてisuue化されて、リリース時のチェックリストとして使います。
Day11 - リリース
今のイテレーションで実装されたプロダクトの最終チェックをプロダクトオーナーが実施し、チェックリストが全てチェックされた時点でリリースとなります。
なお、iOSは申請のことをリリースと呼んでいます。審査が通り次第、Androidとタイミングを揃えてAppStoreに出すようにしています。
振り返り - Day 11
この２週間のイテレーションを振り返ります。出来る限り次のイテレーションに振り返りを活かせるように、可能なものはタスク化し個々にアサインをするようにしています。
また、この直後に Day1 のスプリント計画を実施していて直前の振り返りを活かせるようにしています。
上記を実施する上でのポイント
いろいろ試行錯誤した上でこのペースになったのですが、考える上でのポイントは以下の点でした。
- イテレーションの期間は２週間とし、できるかぎりその単位で出せるアウトプットを意識する
- 会議の日は出来る限りまとめて、分散しないようにする
- 祝日などがあって営業日が少ない時も同じペースで実施する（長期の休暇が入る場合は要調整）
最後に
この会議のペースや内容なども全て振り返りを中心にいろいろ実施していって生まれた実施ペースです。自分のチームとしてはかなりワークしているという実感はありますが、これはあくまで一つの実施方法です。
そのためにも振り返りをしっかりとやり、そこから改善につなげていくといったアクションが大事ですね。
