アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

全章を通じて具体的な技術にはあまり触れずに、客観的な視点からアジャイル開発者の「あり方（心構えや思考）」を導いてくれます。

アジャイルとう言葉を全く知らない人も含めて、この本はソフトウェア開発に関わる全ての人に読んでいただきたい。まさに教科書です。

私は仲間にもこの本を自信を持って紹介しています。

色々と他のアジャイル本を読みましたが、この本が一番、アジャイルソフトウェア開発をプロジェクトにどのように適用すればよいか具体的で分かりやすかったです。

全体の構成も各項目が短くまとめられていて読みやすかったです。
200ページの専門書ですが３日ほどで読めてしまいました。

プロジェクトが上手くいかないと嘆いている暇があったら、読む価値は絶対にあります。
ブタであるプログラマ（読んでもらうと意味が分かります）の生き残るためのバイブルです。

面白かったのは「コードレビューのパターン」で、３つの模様を紹介している。コード見直し模様。

オールナイタ
　お奨めしないそうだけど、年に１回はやりたい。ちょうど、昔のJUSE、今のSWESTみたい。徹夜とすればよかったかも。
ピックアップゲーム
　SHIP ITを参照せよとのこと。日本語版の書名は「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」。読んでみます。
ペアプログラミング
　ドライバとナビゲータだそうです。運転者と道案内とすればよかったかも。

アジャイル開発のプラクティスを紹介した本です。
ソフトウェア開発の進め方、チームのあり方、プロジェクトの運営
等の分野で、約50個のプラクティスが紹介されています。

各プラクティスは、解説、間違った考え方、
どんな状態となると良いか、、などで、1つのプラクティスについて
5〜6ページで紹介されています。

テクニカルな部分は少なく、ソフトウェア開発の進め方、
チームのコミュニケーション、人間関係などに関連する
部分が多かったです。
ですので、「アジャイル」と構えなくても、
一般のソフトウェア開発でも利用できるプラクティスも多かった
印象です。

　本書によれば、「アジャイル」という名前が付けられた開発手法は、2001年2月に発表された「アジャイルマニフェスト」に端を発している。よりよいソフトウェア開発方法を解明しようとして議論した結果、次のような価値観が根底に据えられたのである。
　- プロセスやツールよりも、人と人との交流を（重視する）
　- 包括的なドキュメントよりも、動作するソフトウェアを（重視する）
　- 契約上の交渉よりも、顧客との協調を（重視する）
　- 計画に従うことよりも、変化に対応することを（重視する）

　この「アジャイルマニフェスト」を実現するための具体的手法を、本書は９つの章立てで述べている。
　それぞれ章はいくつかの節に分かれているが、その節の構成がおもしろい。
　まず最初に「悪魔のささやき」が登場し、アジャイルでない方向へ読者を誘い込もうとする。悪魔に負けない解説文を駆使してアジャイルの方向に読者を向けたあと、正反対の結論をこんどは「天使」が高らかに宣言するというベタな展開。秀逸なのがその後の「こんな気分」というセクションで、２〜３行でアジャイルな考え方を的確にまとめてくれる。最後に必ず「バランスが肝心」というセクションで行き過ぎにブレーキをかけているのが、いかにも「アジャイル」だ。

　ドキッとさせられたり、感心したりする指摘が多かった中で、特に身につまされたのが、第６章の次の一節。

　呼び出す側が、呼び出されるオブジェクトの状態に基づいて判断して、呼び出される側のオブジェクトの状態を変更すべきではない。（中略）オブジェクトの外側での判断や状態変更を許してしまうと、オブジェクトのカプセル化を破ることになる。これはバグの温床になりかねない。

　今担当しているプログラムがしっちゃかめっちゃかになってきたのは、そういうことだったのか!!　なあ〜るほど。