第一章 アジャイルは方法と手法の集合です 第三章 Big Requirements Up Front 事前に最大の要求をするのはよくない 価値を定期的に提供することで、変化はプロジェクトにとって良いことであり、ソフトウェアを定期的に提供することで、チームと顧客は調整しながら協力できます ソフトウェアが最初に設計されたものと異なる可能性がありますが、これはむしろ良いことです フィードバックを得る最良の方法は、早期に提供することです。提供されるものが 1 つの機能しかなくても、それは双方にとって利益です 早期の提供の欠点は、顧客に渡される最初のバージョンが完全なバージョンから非常に遠いことです。一部のユーザーや重要な関係者は適応するのが本当に難しいことがあります しばしば起こる状況の 1 つは、誰かが何かを明確に指示した後、変更するように告げることです 変更要求を歓迎する第一歩は、事柄を顧客の視点から考えてみることです。これは通常簡単ではありませんが、非常に示唆に富んでいます 詳細な文書とトレーサビリティマトリックスは、いくつかのチームの問題を潜在的に抱えており、それは「責任転嫁」(Cover Your Ass, CYA) の態度を助長しています 進捗レポート自体が最適な測定方法ではないため、進捗を測定する最良の方法は、利用可能なソフトウェアに頼ることです 未完成の作業量を最大化するとは、依存関係が少なく、無駄なコードのないシステムを構築することを意味します