TDDモブプログラミングに参加した話

モブプログラミングは初めての経験で、いろいろと気づきがありました。

社内向けに共有していきたいので、そこに向けて考える為の資料としてもまとめたい。

参加したやつ

TDD+モブプログラミングでワイワイする会 その23【ラスト平成スペシャル】

connpassというイベント企画サイトで発見。
関東で開催される一覧で、一番興味があったやつを選びました。

イベント当日の雰囲気は?

開始15分前に入場。
主催者以外ほぼ来てなくて、ソロぼっちだったので最初の空気感に堪え切れずちょっと後悔しました。

開始してからはタイムテーブルに沿って進めていくので、滞りなく。
最終的には主催も含めて14人くらいの参加人数。
1チーム4人~5人の3チームに分かれてモブプロしていきました。

モブプロ中は結構忙しい感じ。
頭も使うし、その場で調べてコミュニケーションする必要があります。
慣れてない場合は意識しないとどんどん喋らなくなるので、ファシリテーター大事。
初対面なのもあり最初はよそよそしい感じがしますが、
サイクルが回れば回るほど発言の敷居が下がる感じがしてとても良かったです。

1セッション(1個のお題)終わって振り返り。
この時点で既にチームでプロダクトコードを書いたので、チームで意識が固まった感じ。
こういった団結感というか、チーム感がたった2時間程度で形成できるのは魅力だと思う。
あと、誰がどの程度スキル感があるのかが良くも悪くもバレます。
チーム序列的なのができるのもこの辺ですかね。

2セッション目では、得意言語で別のお題をクリアする方向にシフト。
FizzBuzzほど簡単ではない課題なので、実装コードの歩幅が迷子になる感じでした。
この辺は経験とTDDの知識が生きる場面だと思うので、数をこなしていく事で解決できそう。
ちなみに、時間が30分程度しかなくて全然終わりませんでした!

全セッション終わったあと総括。
全体的に他者を敬う空気感があって心地よかったです。
きっとこれは全員が参加者として、何かしら行動しているからなんだろうと思う。

次回は5/19(日)に函館開催らしいです。
ちょっと遠いので参加は厳しいかなぁ。

やってみての感想

かなり雑多に、いろいろ思ったことがあったので箇条書きで。

全体的に面白かったし、またやってみたい。

ホワイトボードは必須。仕様とかTODO整理できると楽なので、広めの環境が大事
結構疲れる。長くても1セッション1時間半くらいがよさそう
お菓子とか、ドリンクはあって良かった。
ファシリテーター力が試される。
参加者の発言、行動を極力否定しないことが大事だと思った。
成功したら暗黙ではなくて、声にだしたり拍手したりして認め合うのが大事
調べる用のPCと、実行用のPCは分けないと調べられない人が出てくる

やったあと気になったこと

レビューが同時に行える!やった!工数削減!
って思ったけど、その後に気づいたバグっぽい事をどうキャッチアップするのかが謎。

レビューしても同じことにはなるけど、それはそれとして別の切口で解決すべき?

モブプロをすることの利点・欠点

利点

実装コードが壊れにくい。
リファクタリングがほぼ必須なので、コードがきれいに保たれる。
自分にないロジック的な解法の共有があり、ロジック力がちょっと上がる。
問題vs全員という図式になるので、へたくそコーディングしても周りから責められない
コードレビューが同時に行われ、忖度しなくなる
新しい言語習得のとっかかりになる。

欠点

慣れるまではかなり疲れる
まとまった時間と広めの場所、機材が必要
コードレビュー記録がつけづらいので、大手現場などでは運用に調整が必要

実際の手順

チーム分け

単純かつランダムにチーム分け。
実際業務だと、仕様と実装に強い人が各チームに分散すると良いのかもしれません。

実施言語・実施環境(キーボードなど)を決める

実施言語は業務では固定かもしれないので省略してもOKな部分です。
環境はOSとキーボードを「US配列」・「日本語配列」で決めるだけですが、慣れている環境のほうが良いと思いました。

お題を決める

実際の業務では、すでにお題は決まっていることが多いかもしれません。
今回はほぼ初対面の人とコーディングするので、cyber-dojoのWEBサービスを使ってお題決めしました。
お題選びや言語選びは、こちらのスライドが参考になります。

今回は「知らない言語×知っているお題」の組み合わせで「Swift×FizzBuzz」を選択

仕様を決める

お題が決まったら、その仕様を決めていきます。
完成条件に近いイメージで、何ができたらそのお題が実装されたのかを定義します。
仕様とか、今後発生するTODOはホワイトボードで管理しました。

こんな感じのレイアウトで実施していきましたが、使いやすかったです。
書いておく事で、ドライバーの順番であったり仕様とTODOを再確認しやすくなります。
実装が複雑になりそうなら、TODOの部分は付箋を使ってタスクボード的にしてもよいかもしれません。
仕様とTODOなどはもちろん、ルールや順番なども書いておくと便利

TODOを抽出する

仕様で満たすべき条件をテストコードに表現します。
TODOは適宜見直しが必要で、不要なら削除してもよいし必要なら追加します。
なるべく、実装レベルで書いた方がテストコードを書くのが楽になります。

テストコードを書く

TODOで上がった中から、1つ選択してテストコードを書きます。
実施順は検討しつつ進めていく。
この時点ではプロダクトコードは未実装なので、テスト結果がREDになるのが期待値です。
REDになるテストコードを書いたら、次のドライバーに交代します。

TODOを倒す

皆で協力して通らないTODOケースを倒していきます。
REDコード最短でGREENにします。
GREENになるまで、何度でもテスト実行して良いので細かく確認します。

リファクタリングする

テストコード、プロダクトコードどちらも細かく直していく
関数化やテスト名修正、不要コードの削除などもこのタイミングで行います。

リファクタする規模は任意ですが、逐次テスト実行してプロダクトコードが壊れていないか確認します。

次のテストコードを書く

未完了TODOから、次に解消するTODOを選択してテストコードを書きます。
ここでもテスト結果がREDになるのが期待値です。

TODOがすべて終わり、仕様を満たすまで続ける

テストコードを書く
TODOを倒す
リファクタリングする
次のテストコードを書く

の一連の流れをTODOが完了するまで繰り返します。

完了

TODOがすべて倒し切って、仕様も満たしていることを全員で確認します。
問題なければこれで終了です。

お疲れさまでした。

関連書籍など

実際に会場に置いてあった本たち。

TDDは前からカートに入っていて放置気味だったので、これを機会に買いました。

モブプロ本も、なるべくこの記憶が温かいうちに読んでおきたいです。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする