0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

モブプロ始めてみました

Last updated at Posted at 2020-03-29

モブプロを始めて2週間が経ったので状況のふりかえりを。
スクラム開発を開始して約1年が経ち、満を持しての導入でしたが、結果的に導入して成功だったと思います!!

メンバーに展開した時の状況

前回の記事「モブプログラミング始めてみます」を元にメンバーにモブプロを共有。
リソース効率重視よりもフロー効率重視という認識を持ってもらえました。
スプリントゴールをフロー効率重視、そのためにモブプログラミングを取り入れる、とし1ストーリーだけ実験的に取り入れてみました。

やってみた感想は

1ストーリーを終えてみて、スプリントレトロスペクティブから最初はモブプロを疑っていたメンバーも続けたいと言ってくれたので良さを実感してもらえたと思います。
なかでもエキスパートのメンバーが率先して楽しんでくれたのがよかったです。(一人でやるほうが早いので、もどかしさはあったはず)
生産性について従来よりも落ちはしました(前回記事の通り生産性以上のメリットがある)が、そんなに悪くなく今日は何ステップ実装した!と日々ふりかえりの白い帽子(Thinking Hats)で共有できており、楽しく開発できています。

チームのモブプロルール

時間配分はチームメンバー5人なので、10分ごとにタイピスト交代を行い、1順した後15分休憩という流れにしています。(喫煙メンバーがいるので)
2時間予定としていたので、2順できたらいいなーといった感じ。

ドキュメントや調べ物を行う用にサブPCも用意しました。
あとは、今日やるタスクを意識合わせする、リファクタは後回しといったことも取り入れつつ行っています。

モブプロふりかえりとカイゼン

導入してすぐはやはりカイゼン点が盛りだくさんでした。

- 最後に合意形成
    - 1つだけ決める
        - 1度に多くのことを変えるのは得策でない。徐々に適応していくことが大事

1つだけカイゼンは全然守れなかった。。
まあ、カイゼンポイントがたくさんあることはいいことです。

主な課題とカイゼン内容を。

  • モブプロ用の場所が遠い
    近場の会議室に変更しました。(60インチ4Kモニターは最高によかったが移動に15分かかるのはツライ。。)

  • プロジェクターは文字が滲む、目がツライ、眠たくなる
    液晶モニターに変えましたが、遠い、見づらい、との意見が。
    最終的にはこのような形で落ち着きました。
    image.png

    下にいるメンバーはモブマシンの画面を、上にいるメンバーは液晶モニターを見つつ作業することで、遠いという課題をクリアしました。
    タイピストにはモブマシンにつないだキーボード、マウスを回しています。

  • 切り替え時間が分かりづらい
    kakku22さんのブログを参考に、モブタイマーを導入しました。
    最初tomato-timerを導入しましたが、音がならなかったり、時間がきているけどキリのいいところまで、となり初回は2時間で1巡しかできませんでした。

    その後、mobsterを取り入れてこれが劇的にカイゼン。
    モブマシンの最前面にタイマーが表示され、常に時間を意識することができ、作業にメリハリができました。
    時間がくるとアプリ画面にバンッと切り替わるので、強制的にタイピスト交換ができるようになりました。(いいところで時間がきたときは笑いが生まれます笑)
    サイコロでランダムにメンバーをシャッフルできるのもいいですね!

  • モブプロ後の個人タスクの生産性が落ちる
    午後イチから2時間、モブプロに時間を当てていたのですが、終わった後の疲労感がハンパない、個人タスクの時間が分断されてやりにくい、との意見から午前中にモブプロを実施するようにしました。

モブプロの品質の担保について

「モブプログラミング・ベストプラクティス」では、モブプロを行ったソースレビューについて、

  • 従来どおりのレビュープロセスと同じように扱う
  • モブ用のIDを発行し、モブコミット分はレビューから省く

という対策案が挙げられています。
当チームは、モブプロを始めて導入したことから、品質を担保しているという証明が難しく、従来どおりレビューを行う対策を採用しています。
本書でもモブがレビューしているのに、なぜモブコードも従来のレビューをしなければいけないのか、と書かれており、、これからの品証の意識カイゼンに期待ですね。。

今後の課題

まだ解決策が見えていない課題もあり。

  • 単純作業をモブプロでやるのはいかがなものか
    訳あってJunitに書いた単体テストコードをExcelに転記する作業があるのですが、みんな無言でタイピストの打鍵音だけが響くという状況に陥っていました笑
    全部が全部モブでやるのもツライという意見が。
    ソースレビューもそうですが、モブプロ後はメンバーを割り当てての残処理が必要ですね。。

  • より早いタイピストになるために
    最近Eclipse上ではマウス禁止ルールを掲げました。意外となんとかなるものですね!まだまだぎこちないですがキーボードのみだと無駄な動きがなくなるのでマスターしたいところです。

  • スケジュールが厳しい中のモブプロは可能か
    今回は比較的スケジュールに余裕がある中でのモププロ導入でしたが、今後モブプロを忙しいチームにも展開するとなったときに果たして受け入れられるかなぁと。
    やるやらないはチームの判断ですので、今回のように、やってよかった!って思ってもらえるように売り込んでいこうかと。

最後に

モブプロを始めてみて、やはり技術が共有できるというのがいいなと感じました。
フロントエンドに強い人、バックエンドに強い人、テストコードに強い人の様々な知識が共有できて日々得るものが大きいです。
なかでも、マウス禁止ルールは一人でやっているとなかなか踏み込めませんでしたが、モブプロだとモブが知っていることをフォローしてくれるので、慣れるスピードも早いと思います。

個人的には、テスト駆動開発(TDD)は「モブプログラミング・ベストプラクティス」でも取り入れていると書いてあり、信頼と実績ありの手法と再認識。
勉強しなければ。

では、ハッピーモビング!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?