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

スキル差があるペア_モブプロで効果的な_ドライバーナビゲータ以外のロールの分...

Yatakeke
September 20, 2023

 スキル差があるペア_モブプロで効果的な_ドライバーナビゲータ以外のロールの分け方.pdf

スクラムフェス三河2023の発表資料

Yatakeke

September 20, 2023
Tweet

More Decks by Yatakeke

Other Decks in Programming

Transcript

  1. このセッションのゴール • プレゼンのターゲット ◦ ペアプロやモブプロをやったことがある人 ◦ スキル差があるなかでのペアプロやモブプロの進め方に悩んでいる人 • アウトカム ◦

    チームやプロダクトの状況に合わせて、ペアプロやモブプロでの進め方を柔軟に扱える、も しくはそのきっかけがもらえる ◦ 教育と開発スピードのバランスがうまく取りながら進められるようになることでメンバー間 のスキル差が緩和されていく 2
  2. そのときのペア・モブプロの進め方 • 新卒の子1人 + ジュニアレベル1人 + 自分のペアプロ・モブプロ • ドライバー ◦

    キーボードを持ってコードを書いていく人、自分だけの考えで実装を進めない • ナビゲーター・モブ ◦ ドライバーが書いたコードをレビューしながらドライバーに対して適切な指示をする人 ◦ 自ずと自分がなることが多かった • 1セッションが25分タイマーで交代する 15
  3. そのとき起こった失敗談②:スピード優先の伝言ゲーム • 新卒1年目の子にドライバーをやってもらった時のこと ◦ 実装を論理的に考えて構文まで落とし込むのに少し苦労する人 • 曖昧な指示を出すと、構文を調べたりするのに時間がかかってしまう • 開発が遅れすぎるのもよくないし、できるだけ具体的な指示をしよう! •

    whyをいいながら進めようと試行錯誤をしながら結局whatを指示する日々 • 結果として、あまり考えることなく言われたことをただコードにうつすドラ イバーになる ◦ 知識差が緩和されることもなく、ただただナビゲータの自分が疲れてしまう 19
  4. 大きく3つの問題があった気がする • 自分の問題 ◦ 自分の説明スキルは高い方ではない • チームの問題 ◦ 教育とスピードのバランスについて合意が取れていなかった ◦

    実装スキルに差がありすぎて、コードに対する意識があっていなかった • プロセスの問題 ◦ ドライバー・ナビゲーターがあっていない ◦ 25分交代が逆にリズムを作れなかった 28 失敗した状況を振り返ってみると・・・
  5. 自分や人を変えるのは大変なのでプロセスを変える 29 人を変えられない 認識はズレやすい プロセスは変えられる • 自分の問題 ◦ 自分の説明スキルは高い方ではない •

    チームの問題 ◦ 教育とスピードのバランスについて合意が取れていなかった ◦ 実装スキルに差がありすぎて、コードに対する意識があっていなかった • プロセスの問題 ◦ ドライバー・ナビゲーターがあっていない ◦ 25分交代が逆にリズムを作れなかった
  6. 守破離 from レガシーコードからの脱却 • アジャイルを、やって良いこと、やって悪いことのルールとして学ぶ人は多 い。(中略)ルールを学ぶのは学習の最初のステージにすぎない • ソフトウェア開発のような複雑な活動はルールだけで捉えることは難しい。 ~(中略)~ ある状況では最良のアプローチが別の状況では最悪のアプロー

    チになることもある • 守から始める理由は、プラクティスの背後にある理論が簡単には理解しにく いからだ。~(中略)~ 成功するには、プラクティスを上手に使いこなせる ように、プラクティスの背後にある原則を学ばなければならない。 35 『レガシーコードからの脱却』 David Scott Bernstein, pp. 50 (4.2 守破離)
  7. XP白本の記述 • ペアプログラミングとは、2人でプログラミング(および、分析・設計・テ スト)とプログラムの改良を同時に行うやりとりのこと • 以下のようなことをする ◦ お互いにタスクに集中する ◦ システムの改良について意見を出し合う

    ◦ アイデアを明確にする ◦ パートナーがはまったら主導権をにぎり、相手の失望感を軽減させる ◦ お互いにチームのプラクティスの説明責任をはたせるようにする 38 ※ 太字は発表者独自の視点 『エクストリームプログラミング』Kent Beck, Cynthia Andres, pp. 40 (主要プラクティス)
  8. まとめ 意図 交流の仕方 XP白本 2人でプログラミングとプログラムの 改良を同時に行うやりとりのこと 改良のアイデアを出し合って、パート ナーがはまったら主導権を握る クラフトマンシップ 2人以上の人が、同じコードで、一緒

    に作業をする規律 キーボードを触っているのは 1-2人 クリーンアジャイル 二人が一緒に同じプログラミング課題 に取り組む 明確な役割分担はない モブプロ 1台のコンピューターの前に座って協 力しながら問題を解決していく キーボードの前に座っているタイピス ト、それ以外 ペア・プログラミング 同じタスクに対して1台のコンピュー ターで一緒に作業する 目的に合わせたさまざまな種類のペア が存在する 43
  9. 意図は交流から生まれる相互作用にある 意図 交流の仕方 XP白本 2人でプログラミングとプログラムの 改良を同時に行うやりとりのこと 改良のアイデアを出し合って、パート ナーがはまったら主導権を握る クラフトマンシップ 2人以上の人が、同じコードで、一緒

    に作業をする規律 キーボードを触っているのは 1-2人 クリーンアジャイル 二人が一緒に同じプログラミング課題 に取り組む 明確な役割分担はない モブプロ 1台のコンピューターの前に座って協 力しながら問題を解決していく キーボードの前に座っているタイピス ト、それ以外 ペア・プログラミング 同じタスクに対して1台のコンピュー ターで一緒に作業する 目的に合わせたさまざまな種類のペア が存在する 44
  10. 交流のやりかたについては原則はない 意図 交流の仕方 XP白本 2人でプログラミングとプログラムの 改良を同時に行うやりとりのこと 改良のアイデアを出し合って、パート ナーがはまったら主導権を握る クラフトマンシップ 2人以上の人が、同じコードで、一緒

    に作業をする規律 キーボードを触っているのは 1-2人 クリーンアジャイル 二人が一緒に同じプログラミング課題 に取り組む 明確な役割分担はない モブプロ 1台のコンピューターの前に座って協 力しながら問題を解決していく キーボードの前に座っているタイピス ト、それ以外 ペア・プログラミング 同じタスクに対して1台のコンピュー ターで一緒に作業する 目的に合わせたさまざまな種類のペア が存在する 45
  11. パターンの書き方(Alexander + fearless change + α) • パターン名 • このパターンが使える状況:問題が発生する状況の定義

    • このパターンが解決できる問題 • 役割の分け方:解決策としてのそれぞれの役割での動き方や関わり方 • 実施方法:解決策としての役割の分け方を踏まえた実施方法 • 例:自分が実際にこのパターンを見出した場合の例 • 気をつけることや注意すること 53 初めてパターンを言語化してみたので優しく見守ってください
  12. パターン:五十六先生 • このパターンの要約 ◦ 自分の実装風景を相手に観察してもらうことでその実装概念に対しての価値を実業務を通し て実感してもらい、イメージをつける。 • このパターンが使える状況 ◦ あなた自身は暗黙的に使いこなしている実装技術ではあるが、相手にとっては新しい概念と

    なるものがたくさんある • このパターンが解決できる問題 ◦ 初学者に対して教育の時間が充分に取れないなかで実際の開発タスクが山積みである ◦ 初学者にとっては、さまざまな実装技術のアイデアを活性化してくれる存在が必要である 55
  13. • 役割の分け方 ◦ 師匠(主体的に実装)= インストラクター ▪ 通常通りに実装を行い、言語化できる部分は説明をする ◦ 弟子 =

    オブザーバー ▪ 「師匠」を観察しながら暗黙的に概念を記憶する • 実施方法 ◦ 「師匠」は言葉のみの説明に注力せずに背中を見せながら実装を進めていく ◦ 「弟子」は「師匠」の実装を共体験することで、暗黙知を獲得する パターン:五十六先生 56
  14. 例:新人にテストファーストな実装を教える • テストとは?の説明はせずに実装から見せるところから始める ◦ こういう感じでテストってのを書いていくんだよ • テストメソッドで日本語で入力と出力を書いてみせる ◦ 書いた後に以下のメリットだけ伝える ▪

    日本語で書くとコードが読めない人でもわかる ▪ 具体的に書いて、グルーピングすると仕様の理解が深まる • テストコードが失敗するところを見せる • テストがパスするように変更する • リファクタリングする • 最後に追加で説明する ◦ テストの実行は何回でもしていい ◦ テストを通したまま変更すればよりよいコードになる 57 TDDとまでは言わないが
  15. 例:新人にテストファーストな実装を教える • テストとは?の説明はせずに実装から見せるところから始める ◦ こういう感じでテストってのを書いていくんだよ • テストメソッドで日本語で入力と出力を書いてみせる ◦ 書いた後に以下のメリットだけ伝える ▪

    日本語で書くとコードが読めない人でもわかる ▪ 具体的に書いて、グルーピングすると仕様の理解が深まる • テストコードが失敗するところを見せる • テストがパスするように変更する • リファクタリングする • 最後に追加で説明する ◦ テストの実行は何回でもしていい ◦ テストを通したまま変更すればよりよいコードになる 58 TDDとまでは言わないが それ以上のことは、説明すると自分の説明がうまくできないのとスピードが変わるのであとに回す
  16. パターン:赤ペン先生 • 役割 ◦ 弟子(主体的に実装) ▪ 実験に近い形で実装をする ◦ 師匠 ▪

    実装されたものに対してブラッシュアップ(orリファクタリング)する • 実施方法 ◦ 「弟子」は「師匠」からリアルタイムでレビューを受けながら実装を行うことでよりよい コードへの差分や勘所を頻繁に知ることができる ◦ 「師匠」は「弟子」の書いたコードをもとに直接書き直すことで新しい概念を伝える 62
  17. 例:可読性の高い実装 by モブプロ(新卒+2年目+自分) • とあるコンポーネントに関して新卒が書いてみる ◦ 新卒の子はとりあえずできるところまでをやってみる ◦ 実装ができたらそれでよし ◦

    詰まるなら2年目に渡す • 2年目が実装/リファクタリングしてそのコードをよりよくしていく ◦ 2年目は新卒の子が書いたコードをその場で引き継いでよりよいコードを実装していく ◦ 新卒の子は自分のコードが変更されていく様を見ることで実装パターンのイメージが活性化 されていく • 自分が最後にリファクタリングをしてよりよい実装を作る ◦ ふたりとも実装がほとんど終わらなかった場合は五十六先生パターンになる 63
  18. パターン:ライオン先生 • このパターンの要約 ◦ 単独練習を通して、それぞれの実装概念の背後にある原則を深く理解する ◦ ライオンが谷底に落として育てるようなイメージ • このパターンが使える状況 ◦

    経験の浅い開発者は熟練者とのペア・モブプロであれば実装ができるとき • このパターンが解決できる問題 ◦ 開発者がペア・モブプロのフィードバックループに過剰最適されている ◦ 開発者はペア・モブプロでないときに実装への自信がなくなる 66
  19. パターン:ライオン先生 • 役割 ◦ 弟子(主体的に実装)= ソロプログラマー ▪ 覚えたことや実践してみることで実践知を増やし、自分の中で知識を昇華させていく ◦ 師匠

    = レビュワー ▪ タイポなどの明らかに間違っているところだけ指摘する(エディターの機能に近い) • 実施方法 ◦ 画面は一緒に見ているがプログラマーができるだけ単独で実装を行う ◦ ただし、バグは防ぎたいので、レビュワーは監視をしながらバグを発見したら報告する 67