HackMD
エクストリーム プログラミング（第I部 XPの探究 第10章～第16章）
第10章 XPチーム全体
XPチーム全体とは、様々な人が相互に関連しながら一緒に仕事をして、プロジェクトをさらに効果的にするものである。
各自が成功するためにも、グループとして共に働かねばならない。
テスター
テスターはシステムレベルの自動テストの選択や記述について開発前に顧客を支援したり、プログラマーにテスト技法をコーチしたりする。
テストファーストプログラミングを浸透させ、週次サイクルの頭にシステムレベルの自動テストに変換するプロセスを挟む。
テスターは想定通り動く「ハッピーパス」を視野に入れつつ、そこから外れた部分についてコミュニケーションを通じて考えさせる役割を持つ。
インタラクションデザイナー
システム全体のメタファーの選択や、ストーリーの記述、新たなストーリーの機会の創出などを担う。システムに求められるものを特定したうえで、プログラマーへの橋渡しを行う。最終的なユーザーの課題に取り組む開発チームの顧客理解や分析に役立つ。
アーキテクト
ストーリーの実装や大規模なリファクタリングの調査・実施、システムレベルテストの構築などを担う。 システムの成長に合わせて適切な大きさのアーキテクチャを選択する。テストによってアーキテクチャの意図を伝えたり、システムの分割（統治分割）を担う。統治分割は、小さなチームで小さなシステムを作ってから、自然な切れ目を見つけて分割する。その分割の選択を担うのもアーキテクトである。
プロジェクトマネージャー
チーム内のコミュニケーションの円滑化や顧客やサプライヤーなどのチーム外の組織とのコミュニケーションの調整を行う。チームをまとめ上げるとともにその進捗に目を配り、外部へのクリエイティブなプレゼンを行う。プロジェクトに対する数多くの変更をうまく伝達するスキルが求められる。
チーム内外とのコミュニケーションを円滑にし、一体感や信頼関係を築く必要がある。
プロダクトマネージャー
ストーリーを書き、四半期サイクルのテーマや週次サイクルのストーリーを決める役割を担う。
主に四半期や週次でのチーム計画を主導する役割であるが、チーム計画は起こり得るものが何かを示したものであり、計画して終わりではない。チームの実情に応じてストーリーやテーマを適応させる役割も担う。
週が終わればシステムは「完全」である必要がある。そのための必要ストーリーを選択し、実践させる力が求められる。
経営幹部
XPチームに勇気、自信、説明責任を提供する役割を担う。 会社のゴールという大きなゴールの明確化と維持が、チームの監督として経営幹部に求められる役割である。
経営幹部はチームに対し、筋の通った明確な説明の提供を求める。その情報は、意思決定の重要な判断材料となる。
XPチームの健全性を判断する指標として、開発後に発見された欠陥数とアイデアに投資してから収益が生まれるまでのタイムラグがある。これらの結果が優秀なほど、優秀なチームである。
チームが組織の期待に添わない場合は、組織へのチームのプレゼンも重要な役割である。
テクニカルライター
フィーチャー（機能）のフィードバックの早期提供や、ユーザーとの密接な関係構築を担う。フィーチャーを一番最初に目にすることになるため、そこからフィードバックを真っ先に提供する。
また、ユーザーとの橋渡し役として、発表資料の作成やデモの実演などを行う。
フィーチャーが完成すると同時に出来上がり、簡単に更新でき、コストのかからないドキュメント作成を行う。現状から理想に進むための重要な役割を担う。
ユーザー
開発中のストーリーをの記述や選択の支援を行ったり、専門領域の意思決定を行う。ユーザーはコミュニティの代表者であり、コミュニティの人と会話するまでは、影響範囲の大きな意思決定は遅らせるべきである。
プログラマー
ストーリーやタスクの見積もり、ストーリーのタスク分解、テストやフィーチャーのコードの記述、自動化や設計カイゼンなど多岐にわたる。技術的に密接に協力しながら一緒に働く。
人事
人事評価の問題：チームのパフォーマンスに集中しているにもかかわらず、評価は個人の目標度や達成度であること。
XPにおける重要性の高い従業員の指標としては、
- リスペクトを持つ。
- 他人と上手くやっていける。
- イニシアティブをとれる。
- 約束したものをデリバリーできる。
個人目標の評価で行くのか、チーム目標の評価に変えるのかは時々次第ではあるが、両者の方法をミックスするのも一つの手である。
雇用の問題：既存の方法とは異なる可能性がある。チームワークとソーシャルスキルを持ったメンバーを雇用する。
役割
役割は固定化された不変のものではない。全員がチームの成功に最善を尽くして貢献することが目的である。 また、役割と人数の関係も特に制限はない。
大事なのは権限と責任のバランスを保つことである。
第11章 制約理論
XPのスコープ外である営業やマネジメントといった分野なども含めて、ソフトウェア開発の全体像を見定める必要がある。
制約理論では、あらゆるシステムに1つの制約が存在すると考える。この制約を見つけ出し、最大限に稼働しているかどうかを確認する。そして、制約のキャパシティーを増やすか、それ以外の負荷を下げるか、制約を完全に排除するのかの検討に移る。
開発のプッシュモデルとプルモデル
ウォーターフォール型等のプッシュモデルは開発段階が進むにつれて山積みになっていくため、インテグレーション（統合）プロセスがボトルネックになりやすい。
一方、XPはプルモデルを採用している。 ストーリーは採用直前に仕様化する。テストは仕様からプルする。コードはテストやインターフェスにあわせて書く。これによって次に仕様化するストーリーが決まる。
制約を理論はこうした全体的なスループットへの集中を行える半面、モデルであり、人間のプロセスとは異なるという弱点がある。それでも制約理論はそのプロセスを認識する優れた方法である。
外側に制約を移す
XPによる最適化が行われると、制約理論上のボトルネックは徐々に外側へと押し出される。ボトルネック解消にはその外側の最適化が行われる必要がある。
但し、XPによる急速な最適化は、ボトルネック側の反感を買い、排除されてしまう恐れもある。経営幹部の支援がない場合は、たとえ評価や保護が得られなくても、自分自身でより良い仕事をする覚悟が必要である。
第12章 計画：スコープの管理
お互いの合意の上に成り立ち、現実の変化を反映して調整された計画は、リスペクトに満ちた相互に重要な人間関係を表す。 逆に現実離れした計画は、不明確で不安定な人間関係を表す。
計画づくりはあらゆる可能性の中から次に何を行うかを決定することである。意思決定に使う情報は日々変化するため、フィートバックを用いて見積もりをカイゼンさせたり、意思決定をできるだけ遅らせたりする。
計画は明日起こりそうなことについて、今日知っていることを表したものである。不確実性は計画の重要性を否定するものではない。
スコープを明確にする
スコープを明確にすると、以下のメリットがある。
- 状況に合わせて適応する安全な方法が得られる。
- 協議の方法が得られる。
- 非常識で不必要な要望を制限できる。
実施には以下の4ステップを用いる。
- 完成させる必要がありそうな作業項目を一覧にする。
- 項目を見積もる。
- 計画サイクルの予算を設定する。
- 予算内で完成させる作業に合意する。協議の時には見積もりや予算は変更しない。
その他計画づくりで重要なポイント
- チーム全員で話し合う：計画づくりは共同作業である。
- ストーリーの選択時は複数の方法で並び変える。：価値の高い順、パフォーマンスの高い順など。
- ストーリーの見積もり：「完成」：すなわちすべてのテストを完了し、デプロイ可能となるまでの日数や大変さの相対値を見積もる。見積もりは最初は大幅に間違っていることも多いため、経験に基づいた見積もりの方が正確である。
- 見積もりと日数：正確な日数（あるいは相対的なポイント）の情報は、フィードバックを繰り返すことで最適化できる。現実と計画が合わない場合、修正を行う。
- サイクルの途中で計画よりも遅れた場合、計画を再調整する。バランスが回復できない場合や、最初に完成させたいストーリーを顧客に選んでもらうようにする。ウソをついて責任逃れするよりもよっぽどマシである。
- 物事がうまくいかない時ほど、価値と原則を忠実に守り、プラクティスを修正して、有効性をできるだけ維持する必要がある。
第13章 テスト：早めに、こまめに、自動化
欠陥は信頼をぶち壊す
欠陥は効果的なソフトウェア開発に必要な 「信頼」をぶち壊す。 信頼できないと、誰かが間違いを犯す可能性からの保守に必死になり、効率的な仕事ではなくなる。
だが、全てのバグを取り除くのは不可能である。欠陥はコストになるが、欠陥を無くすのにもまたコストがかかる。但し、欠陥のコストのほうが、対策コストを上回る。 なぜなら欠陥修正のコスト+信頼を失うコストの両方がかかるためである。
XPは、明確なコミュニケーションにより、最初から欠陥を発生しないようにする。発生した時は逆にそれを利用して回避方法をチーム全体で学ぶ。
欠陥の水準とチームの信頼
欠陥の許容レベルはシステムにより様々で、通常のサイト等、経済的に持続可能なレベル（99.99%以上等）で良いこともあれば、宇宙船の打ち上げシステム等、一切の欠陥が許されないレベルが求められることもある。
この 「経済的に持続可能」な水準 は、開発の一つの目的となる。
また、もう一つの目的は、チーム内の信頼がある程度成熟するまで欠陥を抑えることである。互いに信頼を失い、チーム内の効率的なやりとりができなくなっては生産的な仕事はできない。
XPにおける取り組み
XPでは欠陥に直接対処して欠陥を減らす取り組みを行う。
- ダブルチェック
テストコードで行いたい処理結果を書き、本番コードで行いたい処理内容を書く。テスト駆動開発やテストファーストプログラミングでは、コードとテストが調和して正しくなる可能性が高い。 - 欠陥コスト増加(Defect Cost Increase)
欠陥コスト増加（DCI）は、欠陥を早く見つければ見つけるほどコストは安くなる。 逆に遅くなるとコストは増加していくことを表す。フィードバックループが長いとコストも増加する。逆に短いと早く発見でき、コストが小さくなる可能性が高まる。XPでは自動テストが週次で組み込まれているため、フィードバックループを小さく保ちかつ容易にバグを発見できる体制を整える。
こまめなテストの意味
- 間違える可能性がある本人がテストを書かなければならない。：テスターや他メンバーに任せると、その相違は大きなコストになりうる。
- 一つの視点でしかテストできていない。：プログラマー視点でコードやテストを書いてOKでも、ユーザー視点ではアウトなこともある。
XPでは、2セットのテスト（プログラマー視点でのテスト（コンポーネントレベル）と、ユーザー視点でのテスト（システム全体レベル）） をお互いにダブルチェックする。
テスト方法
- 自動テスト：手動テストに比べて素早くかつミスのないテストが可能となる。その結果、ストレスも無くせる。
- 静的検証：動的に検証するのが難しい部分における検証のこと。
テストの時期
テストを先に書くかコードを先に書くかは決まっていないが、XPではテストを先に書く。 インターフェースに左右されない他、確信が持てる、進捗を計測できる等のメリットがある。
第14章 設計：時間の重要性
インクリメンタルな設計の意義
インクリメンタルな設計を受け入れる理由を掘り下げる。
パーマカルチャーとは、バランスの取れたエコシステムにおける持続可能な生活の哲学及び実践のことである。このような「各要素が有益に関連したシステム」が設計であるとしている。
設計はソフトウェアの価値を高める。設計はコスト不要で無限に要素を複製できる。したがって、有益な関連は既存のすべての要素の関連に広げられる。
物理的な設計とソフトウェアの設計
物理的に不可能な既存システムを段階的に置き換えて完成させるような方法は、ソフトウェアではコストのかからない 普通の手段としてみなされる。したがって、漸進的なインクリメンタルな開発は、物理的に無理でもソフトウェアでは可能である。
段階的な変更と設計者のスキル
ソフトウェアの設計者が持つべきは能力は、まず十分なフィードバックが得られるまで「忍耐」のスキルを身につける必要がある。
ソフトウェアは建築のメタファーが良く使われる。建築の世界では段階的に変更するのは極めて難しいが、ソフトウェアでは可能である。
大事なのは誰がするかではなく、いつするかである。
藁人形論法
BDUF（Big Design Up Front：前もって大部分を設計）にとって代わるのは、なにも設計しないことではなく、LDUF（Little Design Up Front：前もって少しずつ設計）かEDUF（Enough Design Up Front：前もって十分に設計）である。
実装前の設計にとって代わるのは、実装後の設計である。
実装前の設計は以前のMVPを参考にできるだけ小さく実装する。最初は簡易な実装ができる部分だけで十分で、実装後に本当の制約が明らかになってから詳細を決定する。
XPの戦略は「何も設計しない」ではなく、「常に設計する」である。
設計時期
直感ですぐにでも設計して成功する場合、熟考する必要がある場合、経験に基づいた知識が必要な場合に分かれる。
経験が役に立たない場合は、熟考レベルですぐに設計に取り掛かるべきであり、逆に経験により大きな価値を生む場合は必要な分だけ取り掛かってあとから設計すると良い。
なお、設計は費やした時間分のコストがかかるため、後で間違っているとコストが膨らむ。経験に照らした確実な設計はコスト面でも役立つ。
Once and Only Once
データ、構造、ロジックなどは、1か所に固まっておくべきである。
全体処理を担うコントローラー、処理の材料となるモデル、ページを表現するビュー（MVCアーキテクチャ）といった、機能別に切り離して特化したコードが理想的となる。
こうしたコードの構造的最適化処理は、リファクタリングの一つである。
リファクタリングを繰り返すうちにたどり着くのが、重複がほぼ取り払われた「パターン」である。
長所として、1つの概念を変更した際に、変更するコードは1箇所で良くなる。
また、前提もできる限り局所化しておくことで、影響を限定的にとどめられる。
まとめ
- 設計は意思決定の時間をなるべく遅らせる。→経験を踏まえた確実な設計を行うため。
- こうした設計があればより早くデプロイできる。
- 確信をもって意思決定ができ、急な変更にも対応できる。
シンプリシティ
- 対象者に適している。：使うべき人たちが理解できることが最優先である。
- 情報が伝わりやすい。：伝えるべき全てのアイデアがシステムで表現されている。
- うまく分割されている。：重複を無くす効果的な分割がなされている。
- 最小限である。：システムの要素を最小限にしてコスト削減ができる。
第15章 XPのスケーリング
XPは人数だけではなく、様々な尺度でスケーリングを行う。
人数
小人数チームで行っていた規律を、大人数チームに適用してもうまくいかない。
まず大きな問題を小さな問題に分割する。 ここでは、まずチームの分割から始めてみる。
ここでうまくいかなければ、プログラミングの問題を小さく分割し、簡単な解決策から始めてみる。
例えば、統治分割戦略（自然な切れ目で分割し、複数チームで作業。こまめに統合）
こうした解決策が失敗した場合のみ、複雑な解決策に移る。
投資
XPプロジェクトの会計は開発費用？それとも資本投資？
開発費用扱いの場合：継続保守名目で正当化可能。
資本投資扱いの場合：全体のスコープを明確にはできないが、四半期単位・年単位で開発費として承認可能。
特に大規模プロジェクトの場合は、早めに財務担当者の協力者を見つけておくと良い。
組織の規模
大きな組織の一部でXPを取り入れる場合、これまでのやり方でやってきた人々が敵になる恐れがある。
そこで、月例会議等でスキルの高いプロジェクトマネージャーが、組織が受け入れられる形で情報提供を行う。
その一方で組織の要求には原則応える必要がある。
大変ではあるが、ありのままの現実を隠さず、組織の意向をリスペクトすることがうまくいくコツである。
期間
長期間のXPプロジェクトはうまくいく。 テストによる保守間違いを防ぎ、開発プロセスのストーリーがうまく伝わる。
さらに、自動テストやインクリメンタルな設計により、システムを維持しつつ、さらなる成長が可能となる。
プロジェクトが開始と停止を繰り返す場合は、「ロゼッタストーン」という将来の保守に向けたガイドを書くことが多い。
問題の複雑さ
XPは専門家同士の密な連携が必要な場合に最適である。
お互いに専門分野を学びつつ、全員を協力させることができれば、チーム力の劇的な向上につながる。
解決策の複雑さ
システムが複雑になり、問題を解決しても新たな問題を発生させるような状況では苦しい。
こういう時にXPは力を発揮する。
自動ビルドやストーリーマッピングなどのプラクティスを利用して、余計な無駄を排除しながら欠陥を修正すれば、大幅な改善が見込める。
継続的にデリバリーしながら少しずつ複雑さを削り取る。そして計画づくりの見える化で見積もりも受け入れられやすくなる。
失敗の重大さ
安全性やセキュリティが重要なプロジェクトの場合、たった一つの欠陥が命取りとなる。 このような場合XPだけでは不十分である。
セキュリティの原則に則り構築し、専門家による審査をパスするというプラクティスを日常業務に取り込む必要がある。
審査はプロジェクトの最後のフェーズにならないよう、フィードバックが得られるよう早めにこまめに行うべきである。
リファクタリング時も当然ながらセキュリティの担保が求められる。
審査官と継続的な関係を築けば審査の成功率も高まる。
なお、情報を記録する手順は決まっていないため、トレーサビリティの実現には物理的に記録するだけでよい。
第16章 インタビュー
Sabre Airine Solutions社の、ブラッド・ジェンセン航空製品開発シニアバイスプレジデントのインタビュー
