原題は『The Object Primer』。 スコット・アンブラーのフルライフサイクルオブジェクト指向テスト (FLOOT: Full Lifecycle Object-Oriented Testing) から、アジャイルな要求やアーキテクチャまでが、1 つにまとめられています。 実践 eXtreme プログラミングの共著者である Granville Miller は、「アジャイルになるとは、チームや自分自身に対する制約を取り払うこと」だと述べています。 本書ではその方法の神髄を学ぶことができます。
下記、重要そうなところや、個人的にビビッと来たところのメモです。
第1章: 最先端のソフトウェア開発
- 下記がアジャイルアライアンスのマニフェストであり、そこに集まった異なる方法論者全員に受け入れられたものである。
- Individuals and interactions over processes and tools
プロセスやツールよりも個人や相互作用- すばらしいプロセスやツールは重要だが、結局は人の協力関係がすべて。
- Working software over comprehensive documentation
わかりやすいドキュメントよりも動作するソフトウェア- ドキュメントはシステムがなぜ、どのように構築されたか、どう使えばよいかを理解するためには重要。
- Customer collaboration over contract negotiation
契約上の駆け引きよりも顧客との協調- 契約は重要だが、契約を結んだからといってコミュニケーションが必要なくなるわけではない。
- Responding to change over following a plan
計画を硬直的に守ることよりも変化への対応- プロジェクト計画は必要だが、柔軟でなければならない。ガントチャートを何枚も作成する必要はなく、非常に単純なものでよい。
- Individuals and interactions over processes and tools
- 自己組織化されたチームとは、チームのリーダーが開発メンバーの各自の役割や作業範囲を決めるのではなく、目標を共有するメンバーが共同作業を行う過程でチームの能力が最大限発揮されるようにメンバーの役割が自然に決まっていくようなチーム形態のこと。
- 成功を収めている組織は、大抵アジャイルなソフトウェア開発アプローチをとっているか、RUP または EUP を採用しているかのどちらかだ。RUP をアジャイルに使おうとしても現実には非常に困難（素材が多すぎてアジャイルなレベルまで切り詰められない）。アジャイルプロセスを取り入れたいなら、XP や FDD などを採用すべき。
- MDA よりも、アジャイルモデル駆動開発 (AMDD: Agile Model-Driven Development) アプローチの方が、お絵かき式のモデリング方法に近く、現実的に大多数の開発者が採用できるアプローチである。
第2章: オブジェクト指向概念の基本
この章にはオブジェクト指向を知らない人のために、その概念について書かれています。
第3章: フルライフサイクルオブジェクト指向テスト (FLOOT)
FLOOT とは
ソフトウェア開発中に作成するさまざまな成果物を検証するためのテスト手法が必要である。 フルライフサイクルオブジェクト指向テスト (FLOOT: full lifecycle object-oriented testing) 方法論とは、オブジェクト指向ソフトウェアの検証および妥当性確認を行うためのテスト、および検証手法を集めたもの。 FLOOT のさまざまな手法は、モデルやドキュメント、ソースコードなど、広範なプロジェクトの成果物をテストするためのものである。
ただし、この一覧にはすべての手法が網羅されているわけではなく、利用できる選択肢には様々なものがあるということが重要。 また、それぞれの手法は必ずしも逐次的に行う必要はない。
エラーの検出が開発ライフサイクルの後期になればなるほど、それを修正するためのコストは指数関数的に増えるので、早い段階から何度もテストをした方がよいことは明らかである。
レビューについて
アジャイル開発手法のインクリメンタルな反復型アプローチでは、開発サイクルが短縮されているため、たいていのモデルレビュー作業をとりやめて、代わりにユーザ受け入れテストを行うことができる。
アプリケーション開発において品質が上がるのは、ソフトウェアの適切な作り方を理解した開発者、経験から学んだ開発者、教育やトレーニングによってスキルを身につけた開発者のおかげである。 レビューを行えば品質の欠けている箇所は見つかるが、それがアプリケーションの品質向上に直結するわけではない。
モデルのレビュー時にコミュニケーションをとるよりも、モデリング時に協力して作成してしまった方が効率的である。 この考え方により、アジャイルな開発では、公式のレビューを避ける傾向がある。 つまり、レビューが不要になる体制を作るのが理想的ということになる。 これは、コードインスペクション（コードレビュー）に関しても同じことが言える。 ペアプログラミングで開発しているのであれば、コードレビューは必要なくなるからである。