初めてのモブプログラミング体験

モブプログラミングを初めてやってみたのでその感想。

進め方

• モブプロ構成: Driver一人 + Navigator数人
  • Driver: コードを書く人
  • Navigator: コードの方針を示す人、相談のる人、横から口出しする人
• 画面共有方法
  1. プロジェクターに投影する
  2. Slack使って画面共有する
• マシンは個々人の所有マシンを回す形とした

感想

• Slackの画面共有機能が良かった
  • モブプロ専用チャンネル作ってそこにモブプロメンバー突っ込んで画面共有で進めるかたち
  • リモートの場合やでかいディスプレイが準備できない場合は、このやり方が良さそう
  • 画面共有されている側もペン使って相手画面に干渉できるのがよかった
    • 「ここのコードがおかしい」ってときのここが図示できる
• ああでもないこうでもないと言いながらやるワイワイ感はなんだかんだ楽しさがある
  • 一人で開発していると得られないみんなでやっている感
  • 少なくとも孤独感とは対極にある開発手法
• 時間にして2時間くらいで休憩を挟んだほうが良さそう
  • 交代要員で区切るなら「n人Driverが回ったら休憩」みたいにするのも良さそう
  • 参加者は集中力を使うのでやりすぎ注意
    • ペアプロより人が多い分、そこまで疲れないと思いきや衆人環視の中作業を進めるのでなんだかんだ疲れる
• レビューが不要という開放感
  • ジュニアレベルの上げるPRはなんだかんだPR完成→レビュー→レビュー修正という打ち返しが複数回発生する
    • 結果としてレビュワーもレビュイーも疲弊してしまう
  • その場で指摘して直せる
  • 実装方針のコンセンサスをとってからコードを書き始めるので、あとから大幅な方針転換は発生しない
• Driverはきちんと自分が何を考え、何をしようとしているかをNavigatorに示すこと大事
  • 無言の時間をなるべく少なくする
  • NavigatorはDriverが間違った方向に行かないようにガイドする
• 技術検証・フィジビリ調査もみんなでやると情報共有になるし文殊の知恵理論で新たな実装アイディアも出てくるのが良い
  • Driverが実装、Navigatorがドキュメント読んで使い方をガイドって進め方もなかなか良かった
• 個々のマシンを回す形式はお互いの環境の違いを意識する必要がなくて楽だけど、この形式だとDriverスイッチコストが高すぎて気軽にDriver交代ができないので一長一短はありそう

参考書籍

現時点でペアプロ・モブプロについて一番よくまとまった本・特集だと思うので興味がある人は読んでみると良い。