チームメンバーで モブプロ + 2 時間スプリント をやろうという話になったのでその時の記録です。
経緯
チームメンバー全員退職という前代未聞の事態に陥った状況下で、残された時間を使って何かチームでできないかということで色々やってみることにしました。モブプロは前職でやったときに慣れないうちは時間がかかるという印象を持ちましたが、今回は時間に余裕があるため試験的に導入することに。また、短時間（1 日以内）のスプリントもやってみたいということで並行して回すことになりました。
チームメンバー
- バックエンド: 2 人
- フロントエンド: 1 人
モブプロ
一人のコードを書く人（ドライバー）とその他の指示出しをする（ナビゲーター）にわかれてプログラミングを行う手法です。ドメイン知識が共有されるので全員の知識の偏りが少なくなります。
今回のルールは以下の通り
- ナビゲーター同士で話し合って次に書く内容を決める
- ドライバーはナビゲーターの指示に必ず従う
- 時間を決めて役割を交代していく
- 将来の設計について議論しない（目の前のコードについて議論する）
- コードを書くときや調査をするときは宣言してからやる
2 時間スプリント
通常 1-2 週間程度で行うスクラムのスプリントを 2 時間単位で行います。 短時間の作業になるのでプランニングやレトロスペクティブも短時間で済ませます。
- 10min: プランニング
- 90min: スプリント
- 10min: レトロスペクティブ
- 10min: 休憩
うまく回すことができれば 1 日に 3 スプリントくらい回すことができそう。
良かった点
- 2 時間という決められた時間のなかで決められたことをやるので、以前のモブプロで発生した「だらだらやり続けていつ終わるかわからない」という現象が起こらない。
- モブプロの「共通認識を作るのに時間がかかる」「進捗が見えづらい」という点に対して 2 時間スプリントで短期間の目標を決めることによって、目前のやるべきことが明確化されて進んでいる/遅れているの認識が取りやすい。
- モブプロ自体が参加しているメンバーによってやり方を細かく調整していった方が良いのだが、2 時間ごとに振り返りがあるおかげで修正を行いやすい。
- 参加者の中で共通認識が作られるので作っているものの方向性がばらけることがない。
- 自分はバックエンドの言語やドメインに慣れていなかったが、バックエンドの方々がカバーしてくれたので安心感がある。
懸念点
- 慣れの問題なのかもしれないが、モブプロは本来レビューで行っていた認識合わせをコーディング中に行うので通常よりもはるかにコストがかかる。
- 2 時間という短時間でできる目標を作らなくてはいけないのでタスク分割が適切にされていないと辛い。
- 上記にも絡む問題だが、短時間スプリントだけでは全体の進捗がとれないのでストーリーに対しての進行度が見えづらい。短時間スプリントをやる場合は長期スパンでのセレモニーも併せてやるなど工夫が必要かもしれない。
- 環境構築のような個人作業はモブプロに向いていないので事前に済ませておいた方がよかった。構築中に発生した問題点に関してはモブプロで解決しても良いと思う。
感想
- その領域に知識や知見がない人でも気軽に参加してそれらを得ることができるので良い。
- みんなでワイワイしながらコードを書くのは楽しいが 2 時間集中し続けるので非常に疲れる。
- ドライバーを変えるたびに発生する画面共有の切り替えやコードの push/pull などのスイッチングコストを下げるのに VSCode live share が便利だった。
どういうケースに向いているか
新しくチームに参加する人に対するオンボーディングに適していると思いました。特にドメイン知識やリポジトリの構造などは聞いた方が早いケースが多く、慣れている人達がコーディングをしているところを見たり質問をしながら吸収することができる点が目的に合致していると思います。また、短時間スプリントを回すことによって（簡易的ではあるものの）スクラム開発に慣れてもらうこともできそうな気がしました。