モブプログラミングの情報を噂に聞いて現場で取り組んでみて半年経過したので参考までにまとめておきます。
##モブプログラミングとは(以下モブプロ)
-
簡単にまとめると「チーム全員でペアプロする」みたいなことです。
2014年にWoody Zuill氏がAgile Allianceで発表されたMob Programming A Whole Team Approachが原著になると思います。
##モブプロを取り入れた経緯
- 設計の背景や意図を伝えるのに時間がかかる
- ドキュメントを作成してみたが作成に時間がかかり、かつ保守が大変
- コードレビューやレビューの取り込みにやたら時間がかかる
- スキルやナレッジが偏ることでタスク担当者に偏りがでる
- バス因子のようなもの…
- 開発チームで決定したことを顧客に合意を得るまでに時間がかかる
他にも挙げればキリがないのですが、特にプロジェクトでボトルネックになっていたのが上記の課題でした。
そこでコミュニケーションのムダやナレッジ共有に効果があると噂のモブプロを取り入れてみました。
##環境
- 人数：3～6人
- 場所：比較的大きなモニターがある部屋、スペースなど
- PC：作業用のPC1台
- 内容：要件定義、設計、開発(TDD)、運用手順定義 など
- ツール：
- mobster
- モブプロ用のタイマーです。(ペアプロでも効果あり)
- 一部動作しないPCもあったのでその場合は下記のサイトを利用していました。
- http://oss.jahed.io/agility/timer.html
- mobster
##結果
###設計編
- 全員で合意しながら設計が行えたので、その後の情報共有も不要になった
- 各システムや言語の有識者が集まっているので、より洗練された設計ができた
- チーム全員で設計を共有できているのでドキュメントコストを削減できた
###レビュー編
- そもそも全員でレビューを行いながら開発しているのでこれまでのレビューがなくなった
- gitのwork branchも使わなくなり、trunk base開発に移行
- マージもなくなり幸せになった
###スキル編
- 有識者：スキル共有することで理解を深める
- 初心者：スキル共有され且つ実際に手を動かしていくので理解を深める
- win-winな関係に
###合意を得るまでのリードタイム編
- その場で合意が得られるのでリードタイムは0です
##これからモブをやってみようという方へ課題共有
###モブプロでぶつかった課題と解決策
- ナレッジ差によって発言しなくなってしまう人が出る
- ドライバー、ナビゲーター、モバーの役割を明確に分けて徹底する
- ドライバー、ナビゲーターは発言せざるを得ないので意図的に割り当てる
- 議論がヒートアップしてムードが悪くなることがある
- 意見が分かれた場合、プランニングポーカーのような形式で方針を決定する
- ファシリテータを明確に立てて場をクールダウンさせるようにする
- 時間を決めて作業に取り組む(予定時間になったら一旦落ち着く)
- 参加者1人1人のゴールがばらばらになっていることがある
- ホワイトボードに書くなどして常に見えるところにゴールを配置する
- 定期的に現在の目的を再確認する
- 顧客へのレビューに時間がかかる
- 意思決定が必要な場合は、顧客に参加してもらいその場で決定する
- ファシリテータによって進行に差がある
- ファシリテータでない参加者も気づいた時点で積極的にファシリテーションする
###やっておいた方が良いこと
- 毎回ふりかえりを実施する(モブ開始前に前回の振り返りからtryを選んでもok)
- no blameの精神を…
- あまり否定的だと発言が消極的になるので
##総括
- 結果の部分からもわかるようにモブプロを取り入れて得られた効能は非常に大きなものでした。
特に心理的安全性が確立されたことから、これまで発言が消極的だったメンバーも積極的に発言するようになったので、より良い設計や実装ができるようになりました。 - 他にも新しい情報があれば積極的に試していこうと思います!