今年もDevelopers Summit 2020に参加してきたので参加したセッションのメモを備忘録的に残しておこうと思います。 event.shoeisha.jp
講演資料など全体的な情報はここでまとめてくれています。 codezine.jp
モブプロとは
- チーム全員で同じ画面を見ながら、同じ開発を行う
始める
モブプログラミングベストプラクティス
- 初めてやる人におすすめの本
気を付けていること
- 目的とゴールを定める
- おおきな方向の目的を合わせておく
- 目的はこれです。いいですかという進め方はだめ。本音はでない
- 進み方を表明する
- TODOリスト
- 作業の区切りをつける
- ドライバーが今やっていることをしゃべる
- 目的とゴールを定める
議論と実験のバランスをとる
- わからないことは議論することが大事
- とりあえず試してみるのが大事
- 最初は議論<<実験を優先
その場でフィードバックを得る
振り返りをする
- より良いプロダクトをめざすはなしとより良いモブプロを目指す話をしたほうがいい
- 個人のペースで復習する
Q.「モブプロを始めるときにネガティブな反応がでたらどうするか」
取り敢えず少しの時間でも始めたほうがいい。外部の人をチームに呼んで始めるのもいいかもしれない。
Q.「個人で作業したいと言われたら」
- 個人を拘束する必要はない。でもまずはやってみてから。
チームをブーストするモブプロ
チームの内側を強くする
スキルトランスファー
- 経験値が低い人をドライバーにするといい
- ガンガン進める人がドライバーだと、止めづらい。ガンガン進める人はナビゲーターに
- その場に参加している人全員に伝えることができる
暗黙知もまとめて伝える
- コードの組み立て方、ツールのコツ、問題解決方法
- 暗黙知を伝えるには一緒にやるしかない
モブプロとレビュー
- レビューおじさん問題
スキルアップすればするほどコードを書く時間が減ってくる - リアルタイムレビューなので、チーム全員が合意のコードが出来上がってくる
- レビューおじさん問題
教育面などで中長期的な目線で見ると効率がいい
Q.「レビューの中でどんな会話が出るのかケンカになったりすることはないのか」
A.実際にケンカになることもある。モブプロはコミュニケーションがよくなるわけではないのでもとから仲が悪いチームはケンカする。ケンカも一種の議論なのでいい.Q.「わからないと言えない人が出てくるのでは」
- そういうときは意図的にわからないことを復習する時間を作ってあげる
仕事をドライブするモブプロ
ソロワークよりも優れた成果を出せる
「優れた成果」とは
→単純な定量的な評価ではモブプロの成果は出せない単純作業や参加者みんなが知っている容易な内容ではモブプロのメリットが出なくなる
モブプロが生きる仕事
- 顧客も一緒だったり
- 会社の一部屋を選挙して部室化
- メンバー各々のスキルは高い
なぜモブプロを導入するのか
- チームに生かす
- 障害物が見つかりやすくなる
心理的安全
- チームの心理的安全とは、対人のリスクをとっても安全であるという、チーム全員の信念である
- 対人のリスクとは、これ聞いたら馬鹿にされるとか怒られるとかがない状態のこと
Q.「やっぱり仕事を分担して進めるようりも生産性落ちるんじゃないの」
単純作業なら生産性は落ちる。人数が多すぎるとさすがに生産性落ちる。短期的に見ると厳しいが、中期的に生産性が上がる。チームの教育につながる
Q.「ほどよい学習状態に見を置くために工夫していること」
- LearningSessionチームの外から技術を持ってきてチームで論じる
Q.「モブプロをうまく使えているチームの特徴は」
- 楽しそう。みんながみんな発言している。ドライバーがうまくローテーションしている
