8.7 コードレビューとレトロスペクティブのスケジュールを立てる 8.8 学習を増やし、知識を広げる 8.9 常にメンター、メンティーであれ 8.10.2 レトロスペクティブの７つの戦略 内容 ペアプロの本質の１つはリアルタイムなコードレビューが含まれているということ。しかし、チーム全体に共有する時間を持つと、尚良い。 また、ペアプロで上手くいったことや上手くいかなかったことの共有としてレトロスペクティブを行い、チームで共有することも良い。 今は、個がスペシャリストになればそれで良いという時代ではない。横断的に情報を展開し、さまざまなことができるチームになることに価値が置かれている。外部の人とも積極的に混ざり合い（機密情報はもちろん伏せる必要があるが）、楽しく知識を増やそう。 ときには孤立するかもしれない。しかし、目的にフォーカスする姿勢、教えることは教わることがという謙虚な姿勢と、新しいことを受け入れる勇気を持ち、協働して作る世界に入ることは自分にとって多くのメリットがあるはずだ。 レトロスペクティブの７つの戦略 小さな改善を探す組織（人）は変化を嫌う。特に、同時に多数な変化があることを嫌う。小さな改善を積み重ね、徐々に改善する。 プロセスを責めよ。人を責めるな誰かが原因で問題が発生した場合でも、その人の問題にフォーカスするのではなく、その人がそうなってしまった開発プロセス全体をフォーカスする。 なぜなぜ５回をやってみる問題がなぜ起こったかを自分たち自身で問う。４回目あたりから想像もしなかった真因が見える。 根本原因に取り組むそのまんま 全員の意見を聴く問題に対して全員の目線が揃っているかは重要。出揃っていない場合、偏った解決策になる可能性がある。 人に権限を改善行動に取り組む際には、必要なものを与える。特に、権限と責任を与え、勇気を持って取り組ませる。 進捗を測る改善は明確なゴール、指標で計測できる状態にすることで効果が図りやすく、さらなる改善につながる。 学び 学びを共有することにさらなる学びがある 学びを活かすアイディア・行動 まずペアプロの実践

8.5 スパイク、スウォーム、モブ 8.5.1 スパイク 8.5.2 スウォーム 8.5.3 モブ 8.6 タイムボックスの中で未知を研究する 内容 ペアプロ、バディプロの他に有効なプラクティスを紹介。 スパイク未知の課題解決のために１つのタスクに複数の開発者が取り組む。使う時間は限定し、課題が解決すればその会は解散する。 スウォーミングチーム全体（または複数のメンバー）で課題解決に取り組む。 モブ単一のストーリーを複数の開発者で進める。ペアプロの複数人版で、キーボードを打つのは常に１人、周りはディスカッションしながら指示をする。物によっては非常に有効。 また、これらの方法は、ソフトウェア開発だけでなく、通常の科学の研究者でも使えるプラクティスだということがわかった。そもそも未知なものを解決することに有効な手段ということだ。 学び 未知の問題は複数人で協力することで効果的なことが多い。 スパイクなんかは実際やってるね。 学びを活かすアイディア・行動 まずはペアプロをして徐々に取り入れていきたい。

8.3 ペアプログラミング 8.3.1 ペアプログラミングのメリット 8.3.2 どうやってペアを組むか 8.3.3 誰とペアを組むか 8.4 バディプログラミング 8.10.1 ペアプログラミングの７つの戦略 内容 ペアプログラミングへの誤解 まず、ペアプログラミングは非常にネガティブなイメージが、開発者でもマネージャーでも先行している。しかし、それはただ単にやり方が間違っているため。 うまくやれば、１人でやるより、はるかに早く、高品質に高いレベルでタスクを完了することができる。 ペアプログラミングのメリット メンバー間の高速な知識の共有。メンバー全員がある程度コードに親しんでいる状態は、ボトルネックになりにくいためチームにとっとかなり価値が高い。 ネーミングに有効。プログラミングでは至るところでネーミングするが、名が体をなしているネーミングが超重要で、しかも他の人とも共通で読めるものでなければならない。 コーディング標準がいらなくなる。コードに一貫性が生まれ、コード自体が標準化され、コーディング標準がいらなくなる。「コードはこうあるべき」というものを定義せずとも、チーム内で運用しやすいものが生まれやすい。 新規参画メンバーの成長にも良い。経験者メンバーと１〜２週間ペアプロ（最初のうちはシャドーイング）することで、新規参画メンバーのスピードがつく。 １人でやるよりも見られている緊張感のために変なコードを書かなくなるし、お互いが監視することでしっかりとした一日を過ごす。 割り込み作業がほぼなくなる。２人で作業しているところに割って入りづらくなるため。 時間の観点でも、生産性が半分になるわけではない。約１５％増えるとされているが、高品質なコードとチーム全体がが総合的な運用コストをカバーする。 ペアプログラミングの注意点 ナビゲーター（指示する側）とドライバー（タイプする側）で分かれるが、両者の合意のもと進むことができるということをお互いが意識して、お互いが積極的に「そうやったのはなんで？こうやらないのはなぜ？」というような質問をして、それに対してしっかりと回答して、回答に対して耳を傾ける必要がある。 お互いが正直に意見を言えることが重要。 良いものは積極的に褒める。 休憩も両者のタイミングで取る。 片方が退屈しているようであれば、退屈している方は機能していないため、役割を交代してみたりする。 おすすめの方法は、テストファースト開発で、片方がテストを書き、片方がテストを通すコードを書きCleanにする。 役割の交換のタイミングは遅くて３０分。忘れそうならタイマーを使うと良い。 ペアリングの方法 ペアプログラミングが本質的に期待するところとして「それぞれ違ったものが合わさり、新しいものが生まれる」「お互いに無いところを補いあう」というような考え方がある。同じような人とペアをしても学びは少ない。その考えに乗っ取り、 性格が違う人同士（強い性格、社交的な性格の人と、内向的な静かな人など）をペアにする。 経験の豊富な人と浅い人をペアにする。教える側と教わる側という関係になることが多いが、結果的に教える側は教えながら自分も多くを学ぶことになる。 ランダムにペアする。知らなかった自分の一面が引き出され、新たな可能性が広がる。すべてのパターンでペアリングしてみよう。 その他の有効な手法 自分の考えは他人の手でコンピュータに伝えなければならないという原則に則る。これによって当人たちの頭の中の問題解決空間が共有され始め、ペアフロー状態という桁違いに生産性の高い状態に入れる。 バディプログラミング ペアリングが苦手なチームや、１人で作業したほうが効率が良いタスクの場合に有効な方法。１日の最後に、やったことのレビューをお互いで行い、質問、回答、議論を行う。ペアプロよりもエクストリームではないが、ペアプロの導入としては取り入れやすい。 進捗を追跡する ペアリングが上手くいき始めたら、その効果、生産性を計測し、マネージャーに提示することで、さらにペアリングの運用が確固たるものになる。 学び ペアプロを新人の教育の場合のみに使われることを見てきたが、ペアプロの目的はチーム全体のフロー効率を上げるためにあり、知識の共有はその１つの効果でしかない。その認識をまず持つことが重要。 ユダヤ学習方式でもペアで教え合うこと・議論しあうことをしているが、この人に教えるという行為は記憶の定着率が一番高い。（読書、プレゼン、体験、人に教える、の中で）ペアプログラミングにはそのエッセンスが入っている。 ペアプログラミングをトレーニングしたくなった。 学びを活かすアイディア・行動 現場でペアプロの実践、バディプログラミングの実践。特にバディはやりやすい。

プラクティス８ 協力しあう 8.1 エクストリーム・プログラミング 8.2 コミュニケーションと協働 内容 すべてのスキルに方法論、テクニック、プラクティス、原則があるように、協働も１つのスキル。 協働をすることで、お互いに学び合い、ともに学べるようになる。しかし、ある日突然それができるようにはならない。チームの一員になって、ただ隣にいるだけでは足りない。 チームの文化を受け入れ、チームメンバーと相互理解を深めて「本当の一員」になる必要がある。 そうしてこそ、互いに質問しあい、議論し合うことができ、高い生産性を出すことができる。 ソフトウェア開発は多くのコミュニケーションが必要で、人と人との調整が極めて重要。成功させるために、ゴールの定義、品質の意味、完成の意味の共有から始め、設計のための共通言語を共有していく必要がある。部屋のパーティションがコミュニケーションを阻害するのであれば排除する必要がある。そしてオープンな空間の中で、人と人がどのように相互作用するかが一番重要なポイント。 学び すばやいコミュニケーションをとるスキルがソフトウェア開発において超重要。 そのために、日頃のチームビルディング（メンバー間の相互理解、様々な共通認識合わせ）も重要。 学びを活かすアイディア・行動 現場でのペアプログラミング導入

7.7.2 リスクを減らす７つの戦略 内容 継続的に統合する未知のリスクを最後に入れないため ブランチを避ける未知のリスクを最後に入れないため。フィーチャーフラグを使っておいて、マージは先にする 自動テストに投資する開発のコストを抑えることにつながるため。 リスクのある場所を特定する未知の場所、コントロール不可の場所を特定し依存関係を切り離す。 未知の中で働く未知のものを発見したら短時間でそれだけに取り組み、記録しながら進捗を確認する。 価値のわかる最小のものからつくる２割で８割の効果を得られるなら２割のものから作る。 頻繁に検証する顧客は実際に見てみなければ欲しい物がわからないかも知れない。完成品でなくても早い段階で作って、見てもらう。 学び そのまま 学びを活かすアイディア・行動 いまのところ特になし

7.7.1 アジャイルインフラストラクチャーの７つの戦略 内容 すべてをバージョン管理するコード、ドキュメントなどビルドに関連するすべてをバージョン管理し、ワンクリックでEnd to Endのビルドをできるようにする 継続的に統合する最後に問題を入れ込まないため タスクの受け入れ基準を定義する？ テスト可能なコードを書くビルドも早くなるし、高品質なコードになる傾向にあるため 必要な箇所のテストカバレッジを維持する難しい箇所はテストカバレッジをを維持してテスト漏れがないように。 壊れたビルドをすぐ直す壊したならすぐに直すか、できなければロールバック。 学び バージョン管理の仕方が重要だと思った。ロールバックできるようにするためにも。 始めは難易度が高いところの必要最低限の箇所でもいいかと思う。 学びを活かすアイディア・行動 難易度が高い箇所の洗い出し ブランチモデルの再考

７ プラクティス３ 継続的に統合する 7.1 プロジェクトの鼓動を確立する 7.2 完了と、完了の完了と、完了の完了の完了の違いを知る 7.3 継続的にデプロイする 7.4 ビルドを自動化する 7.5 ビルドは頻繁にする 7.6 最初の一歩を踏み出す 内容 問題を後回しにすることは、リスクと努力が必要な状況を作り出している。継続的インテグレーション（CI）とは、統合＆ビルドをリリース直前にするのではなく、こまめに行っていくこと。開発で最も重要な環境で、作るのも簡単。 CIはビルドサーバーを作って（クラウドサービスでも可）、そこにバージョン管理システムで随時統合し、統合したらビルドと自動テストを実行するようにする。 「完了」と「完了の完了」と「完了の完了の完了」の３つの状態を知り「完了の完了の完了」を目指そう。 完了・・・ローカルでビルド、テストが通る 完了の完了・・・ローカルで通ったものが統合される 完了の完了の完了・・・さらに、保守可能な状態にリファクタリングされている ３つ目を目指すことで、保守可能なコードになり、テストも高速に実行できるコードになっていることが多い。 ビルドサーバーにはコードの他にも、ビルドスクリプトやDBレイアウト、必要なドキュメントなど、リリースに関連するものはすべて一元管理をし、ビルドの整合性を保つようにしよう。 頻度は最低１日１回、一日の最後ではなく最後にビルド失敗しても修正可能なタイミングで行おう。多ければ多いほど良い。 この癖をつけるのは最初は大変かもしれないが、この価値を知り、軌道に乗れば、今までの方法には戻れなくなる。 学び CI環境は高速フィードバックのために超重要 学びを活かすアイディア・行動 現場で作る

6.13.2 ストーリーを分割する７つの戦略 内容 複数のサブストーリーを要素に分解する複数のサブストーリーで構成されている場合、分けることでモジュール化しやすくなる 複雑なストーリーは既知と未知で分ける分けることで既知の部分が効率的に進む 未知のことをわかるまで繰り返す未知の課題を解決する。そのまま 受け入れ基準をもとに分解するストーリーの受け入れ基準と整合性を保つ必要があるので、受け入れ基準をベースに分解する 依存関係を最小限にするストーリー同士の依存関係を少なくし、それぞれが独立してリリース可能にする 意図を１つにするそのまま ストーリーをテスト可能に保つそのまま 学び そのまま 学びを活かすアイディア・行動 これらをチェックリストに、バックログを見る・分解する

6.13.1 ソフトウェア開発を設計するための７つの戦略 価値実現までの時間を計測する価値実現までの全体プロセスの時間を知ることで全体像に注目できるため コーディングに使った時間を計測する品質改善に使える時間が少なすぎないかチェックできる 欠陥密度を調べるコード1000行あたりのバグの数は品質改善のための指標となる 欠陥検出までの時間を計測する欠陥発生から時間が経てば経つほど修正コストは上がる 機能ごとの顧客価値を計測する価値の高いものから時間を費やすことができるため 機能を提供しない場合のコストを計測するその機能がないとどのようなコストが発生するかが、機能を作る理由になる場合がある フィードバックループの効率を計測する失敗から改善までどれくらいかかっているかを知り、プロセスが改善されているかを知ることができる 学び そのまま 学びを活かすアイディア・行動 まだ具体的な行動は思いつかない