×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
モブワークっぽいのをやっている話 2020/01/28 DeLT 1
Slide 2
Slide 2 text
⾃⼰紹介 いもです クライアントエンジニアやってます 2020/01/28 DeLT 2
Slide 3
Slide 3 text
モブワークとは? その前に、ペアプロとモブプロについて話さないといけない 2020/01/28 DeLT 3
Slide 4
Slide 4 text
ペアプロ(ペアプログラミング)とは ⼆⼈で協⼒してコードを書く ドライバーとナビゲーターに役割を分ける ドライバーがコードを書き、ナビゲーターがサポート 適時休憩を挟み役割を交代する 2020/01/28 DeLT 4
Slide 5
Slide 5 text
モブプロ(モブプログラミング)とは 3⼈以上で⾏うプログラミング コードを書く⼈以外は「モブ」となる モブはコードを⾒たり実装⽅法とかをやいのやいの⾔う 書く⼈とモブを⼊れ替えてみんなでやる 2020/01/28 DeLT 5
Slide 6
Slide 6 text
モブワークとは モブの考えをエンジニア以外にも適⽤する働き⽅ 様々な職種が混ざりモブとなる ⼿を動かす⼈も時と場合で変化する プログラマーが書いてる後ろでプランナーがガヤガヤしたり デザイナが書いてる後ろでエンジニアがガヤガヤしたり つまりはみんなで集まって作る 2020/01/28 DeLT 6
Slide 7
Slide 7 text
チームの歴史 複数のスクラムチームからなる 11⽉くらいに今のチームに所属 チームは7,8⼈ クライアント、サーバ、デザイナ、ディレクター、QA (⾃分含め)エンジニア3⼈ 元々ペアプロをしていたっぽい 3⼈になったのでモブプロを開始 現在は2⼈ 2020/01/28 DeLT 7
Slide 8
Slide 8 text
チームのモブプロのやり⽅ やりたいことを⼩さい単位で付箋に書き出す ○○を表⽰する、データを更新するetc.. どうやって実装するか?をやいのやいの話す 既存で再利⽤できる仕組みはあるか? どこに気を付けるべきか? 1つずつ潰していく 実装したらユニットテストできるだけ書く 2020/01/28 DeLT 8
Slide 9
Slide 9 text
モブワークの発端 ふりかえりで出てきたProblem 「スクラムでQAの関わり⽅」 仕事がスプリント前半暇で後半忙しくなる問題 QAだけ1周ずらす作戦も考えたりした 2020/01/28 DeLT 9
Slide 10
Slide 10 text
「実装時から⼊ったらいいんじゃない?」 2020/01/28 DeLT 10
Slide 11
Slide 11 text
QAさんと⼀緒にモブワーク 基本はモブプロと⼀緒 付箋を書き出し、1つずつ潰す QAさんも混ぜて影響範囲、気を付けるべきところを考える Unityエディタ上で⼀緒に確認 実機でも確認する 参考資料:Agile開発に⼊り込むQAの⽅法 https://speakerdeck.com/nihonbuson/agile-qa-night 2020/01/28 DeLT 11
Slide 12
Slide 12 text
変化 専⾨職の凄さを思い知る QAさんの観点から⾒る「考慮すべきポイント」はエンジニアとはまた違う こちらが思いつかなかった懸念や検証項⽬を提案してくる 毎回「あーそういえば・・」的な感じになる 初期段階でだいぶ懸念を潰せる 2020/01/28 DeLT 12
Slide 13
Slide 13 text
変化 テスト駆動開発(TDD)しやすくなる 資料だとテストシナリオを書いてたので最初は真似してみた テストシナリオがそのままユニットテストになりそうだった QAさんと話した「Aの場合Bになる」がそのままテストコードになった ↑をコードを書く前に決めるので、⾃然とTDDになる 2020/01/28 DeLT 13
Slide 14
Slide 14 text
変化 共通⾔語を作ることを意識し始める 他職種とやる以上、エンジニア独⾃の⾔語だけで会話はできない 何をやりたいかは作っているもののドメインで会話をする Missionクラスではなく「宿題」機能の仕様を語る どうやるかの段階で詳細なコードを議論すればよい シームレスにディレクタやデザイナも会話に混ざれる 2020/01/28 DeLT 14
Slide 15
Slide 15 text
⽣産性いいの? 少なくとも悪くはない(体感) ⼀⼈だったらもっとヤバいことになってた的な事はあった ⼿戻りとかはほぼ起きていない TDD始めた当初に慣れてなくて作業が遅れるというのはあった ペアプロを⾏っても⽣産性が半分になることはない、という論⽂はある https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Pro gramming 2020/01/28 DeLT 15
Slide 16
Slide 16 text
常にモブワークすべき? 四六時中ではある必要はなさそう 本当にエンジニアだけで解決できる作業もある リファクタリングとか、設計を考えるときとか 「モブすっぞ!」と気軽に声かけできるようになってることは重要 2020/01/28 DeLT 16
Slide 17
Slide 17 text
モブワークおすすめ? やってみないと分からない 常に⼈とコミュニケーションを取るような働き⽅になる 個⼈の性格、相⼿との関係性はモロに出る 普段コミュニケーション取れてない状態で始めるのは多分つらい 疲労感はすごい みんなで作るのは楽しい でも、やってみないとわからないのは間違いない 2020/01/28 DeLT 17