アート・オブ・アジャイルデベロップメント読書会 第2版 #1 ペアプログラミング
===
###### tags: `アートオブアジャイルデベロップメント読書会`

[読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view)

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/193498/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2021/xx/xx]()

# 自己紹介

- ファシリ役
-
- 読み上げ役
-

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

[アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu)

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はアジャイル非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:30- | - | もくもくタイム（hackmd書き込み） | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:45 | 70分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:45-21:50 | 5分 | [miro](https://miro.com/welcomeonboard/OW54WlJIZ3pKQlBwbUtTc0p3d1Y3UlJOWWgycGx4S2ZLZGpyUGtVeXRCOG1HUUs3QnJVREwzY29LOTJnSU1UeXwzMDc0NDU3MzQ3MDA4ODU5ODI5)を使ってふりかえり | |
| 21:50-21:55 | 5分 | 次回開催日と読む範囲決めてクローズ | |

* 流れ
* 10分ごとにトピックを区切って議論します
* 10分経った段階できりがよければ次の話題に、そうでなければ延長します
* 議論するトピックは最初に「いいね」がついた数の多い順です。
* 「疑問・参加者に聞いてみたいこと」→「感想・気づき」の順番で進めます
* その前に、議論するトピックを決めるための投票を行います
* ひとり1トピックには1票、全体では何票でもOKです

# 下に感想などを書いていって下さい。どんな些細なことでもOKです。

### 目安の時間

- 1トピックにつき10分を予定しています
- 盛り上がったら延長することもあります

## 疑問・参加者に聞いてみたいこと

- ここ以外に、みなさんがペアプロをする時に気をつけていることって何かありますか:+1:

- ペアプロってみなさんどのくらいやっていますか？ :+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/948182756502958091)
- 逆にやっていない場合は、ペアプロにどういう印象を持っている？

- ドライバー、ナビゲーターの交代ってどのくらいのインターバルでやっていますか？
- 1分以内
- よく、10~15分って聞きます。

- ペアの組み合わせ変更ってどのくらいの間隔でやっていますか？ :+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/948185916848099348)
- 参考文献だと、90分の無差別ペアリングとか出てますね。

- 第1版との違いってなにか見つかりました？ :+1:
- ペアステーションが手前に来たあたり、ペアプロのやり方の疑問が多かった？
- 基本的には変わってないように思いました。

- 「ペアより一人でやった方がいい」と信じている人(マネージャー層)に響くいい説明ありますか？
- リアルタイムでコードレビューができるので、工数が減るとか

- ペアプロを実施するときはどの様な単位で実施していますか（具体的なイメージは以下です） :+1: :+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/948188828022235156)
- 1つのプロダクトバックログを同じペアでやり切ったり
- 1つのスプリントバックログを同じペアでやったり

- なぜペアリングするのですか？（why pair?）　のところで、「ペアリングには、知識の共有以上のものがあります。ペアリングにより、結果の品質も向上します。ペアプログラミングはあなたの頭脳を倍増させるからです。」（訳）って書いてあるけど、「知識の共有以上」って何があるんだろう？
- その人の仕事に関する考え方とかが聞けた経験ありました。

- リモートペアプロでは、どんなツール（主にエディタ）つかっていますか？

### Alternatives and Experiments

- > Noise cancellation with situational awareness. Pair programming has another benefit that’s even less obvious. In a physical team room, pairing creates a low buzz of conversation. You might expect this to be distracting, but it actually recedes into the background as your brain focuses on your interaction with your partner. But the background conversation still enhances your situational awareness. It’s the cocktail-party effect: when somebody says something important to you, your subconscious picks it out of the background and brings it to your conscious attention.
- > 状況把握でノイズキャンセリング。ペアプログラミングにはもう一つ、あまり知られていない利点があります。物理的なチームルームでは、ペアリングによって会話のざわめきが生まれます。しかし、脳がパートナーとの対話に集中することで、このような雑音は背景へと消えていきます。しかし、バックグラウンドでの会話は、状況認識を高めることになります。これはカクテルパーティー効果で、誰かが自分にとって重要なことを言うと、潜在意識はそれを背景から拾い出し、意識的に注意を喚起するのです。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/948191927063425024)
- これはリモートワークのツールでは難しいけど、うまくやる方法ってあるんだろうか？ :+1::+1::heavy_check_mark:

---------------------------------------------------------------------

## 感想・気づき

- (モブプログラミングの章より)
- 新規チームだと、モブは効果的
- 確立されたチームだと、モブよりペアの方が効果的なことがある

- リモートの話は第二版で新しく追加されたところですね。
- リモートでのやり方を紹介しているこの記事はかなり有用:+1:
- https://langrsoft.com/2020/06/02/git-handover/

- > As a coach, one of my favorite techniques is to remind people to go home on time. Tired people make mistakes and take shortcuts. The resulting errors end up costing more than the work is worth. This is particularly true when someone comes to work sick; in addition to doing poor work, they could infect other people.
- > コーチとしての私のお気に入りのテクニックの1つは、時間通りに家に帰るように人々に思い出させることです。疲れた人は間違いを犯し、近道をします。結果として生じるエラーは、作業の価値よりも多くのコストがかかることになります。これは、誰かが病気で働くようになったときに特に当てはまります。貧弱な仕事をすることに加えて、彼らは他の人々に感染する可能性があります。
- ペアプロで行き詰まった時に休憩を入れて、その後ペアチェンジをすることはやっている :+1::+1::+1:

### Why Pair?

- > There’s more to pairing than sharing knowledge. Pairing also improves the quality of your results. That’s because pair programming doubles your brainpower.
> ペアリングには、知識の共有以上のものがあります。ペアリングにより、結果の品質も向上します。ペアプログラミングはあなたの頭脳を倍増させるからです。
- 先日、本を読んでいて、「個人が持つ複数の人格は、個人が任意で引き出すことができない」という話が書いて　あった。Aさんの振る舞いは、一人の時、Bさんと一緒にいる時、Cさんと一緒にいる時で異なり、無理やりBさんの前にいる時の振る舞いをCさんの前ですることはできないということ。ペアを組むこと、ペアをローテーションすることで、より高いアウトプットを出せるのだなと。:+1::+1::+1::heavy_check_mark:
- どの本だろう。気になる
- [私とは何か――「個人」から「分人」へ](https://www.amazon.co.jp/dp/4062881721)

### Pairing Stations

- 二番目の節に「ペアリングステーション」を置いてるのが、時代の変化の影響を感じる？まず環境を用意するところから。以前は 5.1.4 だった。

- > If your team is remote, you’ll need a collaborative code editor and a videoconference. Make sure you have multiple screens, so you can see each other and the code at the same time.
- > チームがリモートの場合は、共同コードエディタとビデオ会議が必要になります。複数の画面があることを確認してください。そうすれば、お互いとコードを同時に見ることができます。
- 常に相手の顔を移せるディスプレイと、作業用のモニター2枚といった構成でやっていると、ペアの表情とかがわかるので結構いいと思っている :+1::+1::+1:

### How to Pair

- > As you pair, switch the driver and navigator roles frequently—at least every half hour, and possibly every few minutes. If you’re navigating and find yourself telling the driver which keys to press, ask for the keyboard. If you’re driving and need a break, pass the keyboard off to your navigator.
- > ペアリングするときは、ドライバーとナビゲーターの役割を頻繁に切り替えます。少なくとも30分ごと、場合によっては数分ごとに切り替えます。ナビゲートしていて、どのキーを押すかをドライバーに指示していることに気付いた場合は、キーボードを要求してください。運転中に休憩が必要な場合は、キーボードをナビゲーターに渡してください。
- こういうのをやるのがナビゲーターの仕事って思われてそうだけど、ナビゲーターはもっと先を俯瞰してみてどういうリファクタリングができそうとか、設計的に問題がないかを考える役割なんだなっていうのがわかる :+1::+1:

- >Take a moment to check in with your partner about each other’s preferences, too.
- チェックインするのこれまでやったことなかったので、興味深かったです

### Effective Navigation

- > As navigator, your role is to help your driver be more productive. Think about what’s going to happen next and be prepared with suggestions. When I’m navigating, I like to keep an index card in front of me. Rather than interrupting the driver when I think of something, I write my ideas on the index card and wait for a break in the action to bring them up. At the end of the pairing session, I tear up the card and throw it away.
- > ナビゲーターとしてのあなたの役割は、ドライバーの生産性を高めることです。次に何が起こるかを考え、提案を準備します。ナビゲートするときは、目の前にインデックスカードを置いておくのが好きです。何かを考えたときにドライバーの邪魔をするのではなく、自分の考えをインデックスカードに書いて、アクションが中断してそれを持ち出すのを待ちます。ペアリングセッションの終わりに、私はカードを引き裂いて捨てます。
- これは大事。生産性を高めるということを意識していないと、相手のコードを指摘したり、質問をしたりするという行為も、これが根底にあることを意識したい :+1: :+1: :+1::+1:

### Teaching Through Pairing

- > Although pairing works best as a peer collaboration, sometimes people with different levels of experience will work together.
- > ペアリングはピアコラボレーションとして最適に機能しますが、経験のレベルが異なる人々が一緒に作業する場合があります。
- こういった状況になりやすいチームで適用したら、ペアプロ、ペアワークは教育用の方法という認識が広まってしまった。:+1:

- > If you need to bring your partner up to speed on some part of the code, remember to be patient. Teaching your pair partner how the code works slows you down, but the goal isn’t to maximize your performance…it’s to maximize the team’s performance. A good developer works quickly and well, but the best developers help everyone do so.
- > コードの一部でパートナーをスピードアップする必要がある場合は、辛抱強く待つことを忘れないでください。ペアパートナーにコードの動作を教えると速度が低下しますが、目標はあなたのパフォーマンスを最大化することではなく、チームのパフォーマンスを最大化することです。優れた開発者は迅速かつうまく機能しますが、最高の開発者は誰もがそうするのを助けます。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/948194825373638706)
- めっちゃ大事にしたい。目的はそのときの短期的なパフォーマンスを最適化するのではなく、チームのパフォーマンスを最適化すること :+1::+1::+1::+1::+1::heavy_check_mark:
- 直近のペアプロがTeachingになっていて、引用の点をとにかく意識したらややワークした感じあります。ただ、教える側ばっかりなのは個人的には心からやりたいことではないんですが、「こう考えたら」みたいなアドバイスあれば聞きたいです:+1:

### Challenges

- > Even if you don’t fall victim to the endless vi versus emacs editor war, you may find your coworkers’ tool preferences annoying.
> 無限のvi対emacsエディター戦争の犠牲にならない場合でも、同僚のツール設定が煩わしいと感じるかもしれません。
- vi も emacs も嫌、という人が多い。この辺り、リモート会議を使ってPC切り替えスタイルにしたことで解決した感じがある。
- IDE共有機能を使えばキーバインド問題も解決する（した）:+1:

### Questions

- > Do we really have to pair program all the time? Some code doesn’t need it.
Some production tasks are so repetitive, they don’t require the extra brainpower a pair provides. Before abandoning pairing, however, consider why your design requires so much repetition. It’s a common indication of a design flaw. Use the navigator’s extra time to think about design improvements and consider discussing it with your whole team.
- > 私たちは本当に常にプログラムをペアリングする必要がありますか?一部のコードでは、それを必要としません。
一部の生産タスクは非常に繰り返し、ペアが提供する余分な頭脳を必要としません。ただし、ペアリングを破棄する前に、設計に多くの繰り返しが必要な理由を検討してください。これは、設計上の欠陥を示す一般的な指標です。ナビゲーターの余分な時間を使用して、設計の改善について考え、チーム全体と話し合うことを検討してください。
- 「この作業でペアプロしてもね～」という事を言う人と会ったことがあるが、それが設計上の欠陥を示している可能性があるという発想はなかった。:+1::+1:

### Prerequisites

- > Pairing requires a comfortable work environment. Most offices just aren’t set up that way.
> ペアリングには快適な作業環境が必要です。ほとんどのオフィスはそのように設定されていません。
- 出社中心の時代、オフィス内ではできず、会議室の予約できた限られた時間でしかペアでできなかった。あまり効果が出なかった思い出。

### Indicators

### Alternatives and Experiments

- > When you look at alternatives, don’t make the mistake of thinking that pairing is just a fancy type of code review.
> 代替案を検討するときは、ペアリングは単なる派手なタイプのコードレビューであると誤解しないでください。
- ペアプロの効果説明でよく「レビューしながら作業できる分高品質」と話したりするので、この誤解を与えてる不安を常に持っている。
- リアルタイムのコードレビューは副次的な効果だと個人的には思っている。
- 基本はペア同士の相互作用・コラボレーションだと思う。コードレビューはそのうちの1つ、みたいな。:+1::+1:

### Further Reading

- > “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” [Belshee2005] is an intriguing look at the benefits of switching pairs at strict intervals.
> 「無差別ペアリングと初心者の心：経験不足を受け入れる」[Belshee2005]は、厳密な間隔でペアを切り替えることの利点についての興味深い見解です。
- 概要は、これっぽい。90分ごとにペアも変えるっていうのも面白いけれど、難しそう。
- https://medium.com/etermax-technology/promiscuous-pairing-and-beginners-mind-817dc152dfff