これはなに
Agile Japan 2018 基調講演でモブプロの講演があって聞いた。
モブプロってよく聞くようになったけど、なにがいいんだろうと思っていたので、とても良質なインプットになった。
ホットなウチに自分の中でざっとまとめておく。
自分のなかでの勝手な超訳
- 俺たちは必要なものと作るのに、必要なスキルと知識をもったメンバーを別々の部屋に閉じ込めて個別のアウトプットをして組み合わせているが、それがうまくいくとおもうのかい？ 俺たちは実際、筋の良くない物を大量につくっている。
- ゆっくりでも正しいものを作るほうが価値がある
- モブプロ
- 割り込みなし、シングルタスク、待ち時間なし、1つのことに集中するという最強のフロー
- チームメンバー感の知識、スキルもリアルタイム同期
Agile Japan 2018基調講演 1『モブプログラミングと”フロー”の力』のメモ
- モブプログラミングは、同じ仕事を同じ時間に同じ場所で同じコンピューターですること。
- 知識もスキルもバラバラのメンバーがあつまって
- 典型的なプラクティス
- ドライバーナビゲーター
- ドライバー
- インプットするひと
- ナビゲーター
- 考える人
- チームがプログラミングする
- 周りが考え、アイディアをシェアして、コードとしてインプットしていく
- どこでもできる
- リモートでも
- 生産性はあがるのか？
- しらんけど、うまくいんだって。
- モブプログラミング
- ばらばらで作業してもアウトプット量は増える。だけどはゴミみたいなアウトプットがふえる。本来一緒に仕事するべき人たちがバラバラに仕事している。
- もっと役立つ物ができる。
- 品質が高い物ができる
- モブプログラミングはチームの頭の中をインテグレーションする
- 一個のことに集中すればいろんな問題は解消する
- キューイングの問題が最大の問題
- 質問がかえってくるまでの時間
- 返ってくるまでにほかのことをやる。マルチタスクになる。コンテクストスイッチが発生する。
- 「在庫」（しかかり中のタスク）は少ないほどよい
- 質問がかえってくるまでの時間
- モブプロでキューがなく、待ちもなく、割り込みがなく、マルチタスクがない理想の状態に近づくことができる
- モブプログラミングは強制しないほうがよい。モブプログラミングしたくなるように
- QA
- メトリックスある？
- 個人でとれることとおなじようにとれる
- リードタイムが典型的。一つのタスクの開始から終了までの時間をはかる
- 安易なメジャメントには抵抗すべき。計測することが目的になってしまう。
- メトリックスある？
よくわかってないこと
- プログラミング以外のタスクは？
- 設計はモブでできそうだけど、テストとかドキュメントとか、リリース、デプロイとかなんでもモブがいい
- ビジネスサイドに白い目でみられたときに、定量的に計れるなにかで効果を提示するのとか、モブプロの意欲なくなるんだけど。