ソフトウェア開発現場のマニュアル本のように感じました。
少しでもより良い環境作りを、少しでもより良いソフトウェアの提供を、、、そう思うなら読んでみるべきかと。

内容が、充実しすぎて抜粋して紹介するのが難しいですが、『インセプションデッキ』は実践したくなりました。
あと、この本と関係ありませんが、『人月』管理から逃れる方法を日々模索中です。
ベロシティの考え方を広めるにはどうすべきだろうか。。。

自分への備忘録として再度おさらい。

『アジャイルソフトウェア開発宣言』
[quote]私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。

[b]プロセスやツールよりも個人と対話を、[/b]
[b]包括的なドキュメントよりも動くソフトウェアを、[/b]
[b]契約交渉よりも顧客との協調を、[/b]
[b]計画に従うことよりも変化への対応を、[/b]

価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。[/quote]

『アジャイルソフトウェアの12の原則』
[quote]顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。[/quote]

よくありがちなのが、「アジャイル開発ではドキュメントを作成しない」とか「要件変更はいつまでもOK」とか。
そんなことは無いと思います。
言葉の意味を誤認すると、変な方向に進みがちですが、この本を読めば理解できます。

合わせて、読みたい・・・。
http://xp.miyacomp.net/modules/d3diary/details.php?bid=80
http://agilemanifesto.org/iso/ja/
http://agilemanifesto.org/iso/ja/principles.html