エクストリームプログラミング

第1章 XPとは何か

XPは、私自身のソフトウェア開発の実践のなかで人間性と生産性を調和させ、その調和を共有しようとする試みである。自分や他人に思いやりのある接し方をすれば、生産性が高まることがわかってきた。成功の鍵は、個人の努力ではなく、「人と人」のビジネスに自分が携わっていることを受け入れることである。XPは、私自身のソフトウェア開発の実践のなかで人間性と生産性を調和させ、その調和を共有しようとする試みである。自分や他人に思いやりのある接し方をすれば、生産性が高まることがわかってきた。成功の鍵は、個人の努力ではなく、「人と人」のビジネスに自分が携わっていることを受け入れることである。

第3章 価値・原則・プラクティス

プラクティス、フォース、バリュー

value

ある状況における好き嫌いの根源にあるもの

価値がプラクティスに目的をもたらすように、プラクティスは価値の説明責任を果たしている

実行しているプラクティスは誰の目から見てもわかる（ex. 朝のMTGに必ず参加している）

価値とプラクティスのギャップを埋めるのが原則（principles）

第4章 価値

「トラブルに巻き込まれる原因は、何かを知らないことではない。よく知らないのに、知っていると勘違いすることである」。ソフトウェア開発の「勘違い」のなかで、私が最も大きな問題だと思うのは、個人の行動に集中してしまうことだ。本当に重要なのは、個人としてではなく、チームや組織の一員としてどのように振る舞うかである。

コミュニケーション

問題に遭遇したときは、それがコミュニケーションの欠如によるものかどうかを自問してみよう。今から問題に対応するには、どのようなコミュニケーションが必要だろうか？これからトラブルに巻き込まれないようにするには、どのようなコミュニケーションが必要だろうか？

シンプリシティ

現在地から目的地までの道筋をみつけだす

「最もシンプルで、うまくいきそうなものは何ですか？」

ムダな複雑性を排除するために、何ができるかを考える。

価値は、お互いにバランスをとり合ったり、サポートし合ったりするものである。 ... シンプリシティを達成すれば、必要なコミュニケーションも少なくなる。

フィードバック

経験する前に方向性を決めてしまうと、すぐにダメになってしまう。変化は避けられないものであり、変化がフィードバックを必要にするのである。

最初から正しくやれればそれはいいけど、以下の場合は難しいだろう。

これまでにない新しい問題を解決する場合

正しいやり方がわからない

今日正しいことが明日間違っている可能性がある場合

コントローラビリティが低い課題に正しさを求めるのは難しい

時間がかかりすぎる場合

正しくやろうとして時間がかかりすぎると、その間に解決策は無効化することがある。

フィードバックの形式

アイデアに対するあなたやチームメイトの意見

アイデアを実装したときのコードの状態

テストは書きやすいか

テストは実行できているか

実現したアイデアがうまく機能しているか

次のリリースまでに対応できないほどの不具合レポートが突然出てきたとする。そのようなときは、不具合レポートに対応しながら、新機能の開発ができるようになるまでリリースを遅らせるべきだ。十分な時間を作り、なぜそれほど不具合が多いのか、なぜ不具合の特定に時間がかかったのかを解明しよう。

勇気

勇気のみでは危険。他の価値と合わせると協力。

勇気をもって真実を語ればたとえそれが不愉快な事柄であっても信頼は強化されるはず。

勇気をもって新しい解決策をみつければシンプリシティが促進される。

勇気をもって具体的な答えを求めればフィードバックが生まれる。

リスペクト

チームメンバーがお互いに関心がなく、何をしているかを気にもとめないようであれば、XPはうまくいかない。 ... 私も重要であり、あなたも重要だ。

その他の価値

最も重要なのは、チームの振る舞いをチームの価値に合わせること

第5章 原則

大量のドキュメントはコミュニケーションを目的としたもの！

ドキュメントも会話と同じくコミュニケーションが目的である

ドキュメントによるコミュニケーションは一方向で、本質的に無駄が多い。

事実として受け入れられるか、否定されるか、になりやすくコミュニケーションの増加につながりにくい。

人間性

ソフトウェアは「人間」が開発するもの

人間の欲求をないがしろにすると、チームやビジネスにとってもよくないことが起こる。

仕事は人間がするもの、と言い換えてもそのまま通じると思う。

優れた開発者になるのに必要なもの

基本的な安全性

達成感

帰属意識

成長

親密な関係

ビジネスニーズ、個人のニーズ、チームのニーズ

経済性

貨幣のタイムバリュー

ソフトウェア開発では、早めにお金を稼ぎあとで使う方がバリューが高い

システムやチームのオプションバリュー

よくわからなかった

貨幣のタイムバリューに悪影響を与えない程度に、やりすぎない範囲で抽象化するとソフトウェアの再利用性が高まり、将来的に本来の目的以外でも収益をあげられる可能性が高まる、みたいな話？

相互利益

最も重要で、最も実行が難しいXPの原則

大量の内部ドキュメント

相互利益を破壊するプラクティス

将来誰かがコードを保守しやすいように現在の開発速度を下げろと言われているのと同じ

そこまで言うのか...

将来の人間にのみ利益があり、現在の人間には利益がないという点を強調しているのだとは思う

相互利益をもたらすプラクティス

自動テスト

リファクタリング

一貫性のある名づけ

XPの相互利益

現在の自分、将来の自分、顧客への利益をもとめるプラクティス

Win-Win-Win

自己相似性

解決策の構造を新しい文脈にコピーする

TDDの先に失敗するテストを書く→動かす、というリズムはあらゆる規模において作用する

四半期、週単位、時間単位...

自己相似性だけでうまくいくとは限らないけど、まずそこから始めるのはよいこと。

改善

「完璧」はソフトウェア開発においては動詞であり形容詞ではない。

「完璧」は存在しないが「完璧にやる」ことはできる。

多様性

みんなが似ているチームは居心地はよくても機能的ではない。

様々な視点や考え方から問題に取り組むためにはチームに多様性が必要

多様性には衝突がつきもの

解決するには2つの方法がある、と言う衝突。

憎み合って前に進まない、みたいな衝突ではない。

設計のアイディアが2つあるのは問題ではなく機会。どちらも評価されるべき。

リスペクトしあい、自分の言い分を主張する

ふりかえり

知力だけでなく、直感、感情からも学べる

否定的な感情も、自分の感情が仕事に何を訴えかけているのか耳を傾ける

流れ

改善のために小さなバリューを何度もデプロイする

流れから遠かったら、元に戻さなければいけない

機会

サバイバルだけでは不十分！

サバイバルではその場を切り抜ける問題解決しかできない。

問題を学習や改善の「機会」に変換する。

エクストリームになるというのは、問題を個人の成長、人間関係の深化、ソフトウェアの改善の機会に意識的に変換することでもある

冗長性

目的の達成のために必要な冗長性

欠陥を完全になくすことはできない。冗長性によって対処できるならコストがかかっていても惨事は回避できる。

失敗

何をすべきかわからない時は、失敗のリスクを受け入れることが成功につながる確実な道になる。

品質

品質を犠牲にするのは効果的なコントロール方法ではない

ベイビーステップ

重大な変更を一気に行うのは危険

あなたができる最も小さなことで、正しい方向がすぐにわかるもの

責任の引き受け

責任は引き受けることしかできない。割り当てることはできない。

責任をもつかどうか選ぶのは自分自身

責任には権限が伴わなければいけない。

たとえば結果に責任をとらないのに仕事のやり方を命令する専門家は、権限と責任のバランスが取れていない。