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