Upgrade to Pro — share decks privately, control downloads, hide ads and more …

わかった気になるモブプログラミング

 わかった気になるモブプログラミング

とある場所でモブプロの説明をする際に作成した資料です

いも

June 01, 2020
Tweet

More Decks by いも

Other Decks in Technology

Transcript

  1. わかった気になるモブプログラミング
    いも
    1

    View full-size slide

  2. モブプログラミングとは?
    その前に、ペアプロについて話さないといけない
    2

    View full-size slide

  3. ペアプロ(ペアプログラミング)とは
    ⼆⼈で協⼒してコードを書く
    ドライバーとナビゲーターに役割を分ける
    ドライバーがコードを書き、ナビゲーターがサポート
    適時休憩を挟み役割を交代する
    3

    View full-size slide

  4. モブプロ(モブプログラミング)とは
    3⼈以上で⾏うプログラミング
    コードを書く⼈(ドライバー)以外はナビゲーターとなる
    モブだったりナビゲーターだったり⾔い⽅はばらけてるかも
    ドライバーとナビゲーターの役割はペアプロと⼀緒
    適時休憩を挟み役割を交代する
    4

    View full-size slide

  5. モブプロの効能
    属⼈性の排除
    チームとしての練度向上
    リードタイムの向上
    5

    View full-size slide

  6. モブプロの効能
    属⼈性の排除 ←
    チームとしての練度向上
    リードタイムの向上
    6

    View full-size slide

  7. 属⼈性は分担作業で起こりうる
    この部分はAさんがやったから・・
    実際に携わってないのだから本当にAさん以外わからない可能性はある
    得意領域はあっても完全に任せるのは⾟いことになる
    モブプロは全員でコードを書いていくので、全く知らない部分を排除できる
    7

    View full-size slide

  8. モブプロの効能
    属⼈性の排除
    チームとしての練度向上 ←
    リードタイムの向上
    8

    View full-size slide

  9. プロダクトの情報を共有できているチームは良い動きができる。
    何故これを作ったのか?
    どうやって作ったのか?
    どんな問題が発⽣したか?
    どんな学びがあったか?
    これ以外にも、成果物だけを⾒ても理解しにくい暗黙知が存在していることは多い。
    9

    View full-size slide

  10. 暗黙知は過程に存在する
    ⾔語化しにくい気づき、改善
    それぞれが持っている知識、強み
    これらを全員が体験できるような場が重要
    10

    View full-size slide

  11. imoがモブプロで実際に体験したもの
    「実はこういう経緯で作られていて〜」という裏情報を教えてもらう
    実装の影響範囲の洗い出しに⼀役買った
    ちょっと改修すれば動くデバッグ機能を教えてもらう
    VisualStudioの便利機能を教えてもらう
    Windowsのスクリーンショットのショートカットを教える
    どうテスト書いてくかという考え⽅を教える
    相⼿のコードを読むときの⼿順を知る
    ⼤⼩様々だが、作る過程を知らないと気づかない部分が多かった
    11

    View full-size slide

  12. モブプロの効能
    属⼈性の排除
    チームとしての練度向上
    リードタイムの向上 ←
    12

    View full-size slide

  13. Q.モブプログラミングって効率いいの?
    A.なんの効率のことでしょうか
    13

    View full-size slide

  14. 効率とはなんなのか
    リソース効率性
    フロー効率性
    14

    View full-size slide

  15. リソース効率とフロー効率の話
    複数の仕事がある場合に、どう⾏動するか?
    それぞれ15⼈⽇かかる機能A,B,Cがあったとする。
    並⾏か?
    -----------------------> 時間軸
    AAAAA AAAAA AAAAA
    BBBBB BBBBB BBBBB
    CCCCC CCCCC CCCCC
    集中か?
    -----------------------> 時間軸
    AAAAA BBBBB CCCCC
    AAAAA BBBBB CCCCC
    AAAAA BBBBB CCCCC
    15

    View full-size slide

  16. 並⾏して⾏う(リソース効率性を求める)場合
    複数の機能を同時に進めるパターン
    -----------------------> 時間軸
    AAAAA AAAAA AAAAA
    BBBBB BBBBB BBBBB
    CCCCC CCCCC CCCCC
    ↑の場合だと、どこかの作業が⽌まってもすぐに別機能にリソースを割ける。つまり「リソースの稼働率」が
    ⾼い(全員に常に仕事がある)
    しかし、機能開発に着⼿してからリリースされるまでが遅くなる。つまり「リードタイム」が⻑い。
    リソース稼働率が⾼いことを「リソース効率性が良い」と判断できる
    16

    View full-size slide

  17. 集中して⾏う(フロー効率性を求める)場合
    1機能ずつ確実に潰していくパターン
    -----------------------> 時間軸
    AAAAA BBBBB CCCCC
    AAAAA BBBBB CCCCC
    AAAAA BBBBB CCCCC
    機能開発に着⼿してからリリースされるまでが早くなる。つまり「リードタイム」が短い。
    しかし、全員だと⼀時的でもやることがなくなる⼈は発⽣しがち。つまり「リソースの稼働率」が下がる
    リードタイムが短いことを「フロー効率性が良い」と判断できる
    17

    View full-size slide

  18. 私たちはどちらを求めているのか?
    作るものの正解が決まっているなら、リソース効率性を求める⽅がよい
    リリースすれば確実に成功であるから
    作るものの正解が決まってないなら、フロー効率性を求める⽅がよい
    早く提供してフィードバックを得て学ぶ必要があるから
    学びから正解に近づいていかなければならない
    ゴールを⾒て話し合いましょう
    18

    View full-size slide

  19. 分担作業は同期が必要
    作業時間+悩んだときの質問
    質問へのレスポンスタイムはまちまち
    コードレビュー
    レビュータイミングでレビュアーは内容を理解する
    朝会、報告会etc...
    チームメンバーの状況を理解するフェーズが必ず必要になる。
    同期が遅いとここで⼿戻りなども割と起きうる
    19

    View full-size slide

  20. モブプロは常に同期する
    全員でやっているので常に状況は把握している
    報告会での「○○やってます」はみんな知っている
    悩んだときはナビゲーターが隣にいる
    みんなで書いたコードなのでレビューしやすい
    これらのおかげでやるべきことにフォーカスを当てられる。よってリードタイムが短くなる
    20

    View full-size slide

  21. Q.モブプログラミングって効率いいの?
    A.フロー効率性を⾼めます
    21

    View full-size slide

  22. やり⽅(1例)
    時間は60min
    やることとゴールを先に決める
    「機能Aを実装する」など
    タスクが切られているなら⼀番わかりやすい
    コード部分を参加者全員が観れるようにする
    Zoomで共有 or VS Live Share
    ドライバーを決める
    22

    View full-size slide

  23. モブプロ開始
    TODOリストを作る
    何をするのかという認識を合わせる
    段階踏んで完了できるようにした⽅が議論が発散しない
    TODOリストをこなしていく
    どうやってこなすか話し合う
    決まったらドライバーが書く
    これをTODOが終わるまでループ
    15min~20minくらいでドライバーを交代
    MobStarというモブプロ⽤のタイマーアプリ使うのもいいかも
    https://kakakakakku.hatenablog.com/entry/2018/07/01/170255
    23

    View full-size slide

  24. 話し合い
    基本的には細かいルールはない
    変数名はこれがいいんじゃないか?とかこういうオブジェクトの持ち⽅だとか何でも話してほし

    今やるべきことからフォーカスが外れないように注意
    議論の発散は起こりがち
    議論の結果⼤きめなやるべきことが増えたら、基本的にはTODOリストの最後尾に追加し
    ましょう
    ドライバーは話が決まってからコードを書くこと
    いいの思いついてすぐ書きたくなる気持ちはよくわかる
    思いついたやつをまず⾔葉にしてみんなに話しましょう
    24

    View full-size slide

  25. TDDとモブプロの組み合わせ
    TODOリストがそのままテストケースになりやすい
    完了したかどうかはテストが通ればよい
    なのでレッド -> グリーン -> リファクタのサイクルで1つのTODOを倒せるといい感じ
    25

    View full-size slide

  26. みんなでクエストやってる感じでやりましょう
    動き⽅は常に「問題 vs 私たち」
    オンゲでギルドでボス倒すとかそういうイメージ
    問題をみんなでボコボコにする
    倒したときは、みんなで喜びましょう
    26

    View full-size slide

  27. 上⼿くいくのか!
    やってみないと分からない
    常に⼈とコミュニケーションを取るような働き⽅になる
    個⼈の性格、相⼿との関係性はモロに出る
    普段コミュニケーション取れてない状態で始めるのは多分つらい
    疲労感はすごい
    みんなで作るのは楽しい
    でも、やってみないとわからないのは間違いない
    逐次フィードバックと改善を回していきましょう
    27

    View full-size slide

  28. 参考
    モブプログラミングという働き⽅ #DevLOVE
    https://speakerdeck.com/takaking22/mobupuroguramingutoiudong-kifang-number-
    devlove
    XP祭り2019 実践!モブプログラミング!!~導⼊編~/How to install mob programming to
    your organization
    https://speakerdeck.com/martin_lover/how-to-install-mob-programming-to-your-
    organization
    XP祭り2019 実践!モブプログラミング!!~躍進編~/Mob Programming in Practice
    https://speakerdeck.com/martin_lover/mob-programming-in-practice
    明⽇からできる働き⽅改⾰「モブプログラミング」 WHOLE TEAM APPROACH /
    mobprogramming as work style reform
    https://speakerdeck.com/takaking22/mobprogramming-as-work-style-reform
    29

    View full-size slide