在互联网时代，交付速度是当今软件开发的主题。十年前，项目通常要持续好几年，并且项目阶段是以月来衡量的。如今，多数团队的项目周期是按月来衡量的，而项目阶段则减少到几周甚至几天。任何需要长远规划的东西都将被抛弃，比如大量的前期软件设计和详细的需求分析。超过项目阶段平均周期的任务将不复存在。跟代码冻结（Code Freeze）以及数周的手动回归测试说再见吧！

　　变化频率如此之高，文档很快会过时。不断更新详细需求说明和测试计划（Test Plan）需要投入大量精力，相当浪费。那些以往在日常工作中依赖于此的人们，如业务分析师或者测试人员，在这个每周迭代的新环境中经常会无所适从。开发人员原本以为不会受到纸质文档缺失的影响，现在却要把时间浪费在不必要的返工与功能维护上。他们不是花时间去制订宏伟的计划，而是要浪费数周的时间去修正有问题的产品。

　　在过去的十年里，软件开发社区致力于使用“正确”的方式来构建软件，关注使用技术实践和思想来确保质量。但是，正确地构建产品和构建正确的产品是两码事。我们要二者兼顾才能取得成功。

图1-1

　　实例化需求说明可以帮助团队构建正确的软件产品，而技术实践 可以确保正确地构建产品

　　想要有效地构建正确的产品，软件开发实践必须满足以下几点。

　　● 保证所有项目干系人和交付团队的成员都对需要交付哪些东西有一致的理解。

　　● 有准确的需求说明，这样交付团队才能避免由模棱两可和功能缺失造成的无谓返工。

　　● 有用来衡量某项工作是否已经完成的客观标准。

　　● 具有引导软件功能或团队结构变更的文档。

　　传统意义上，构建正确的产品需要庞大的功能需求说明、文档以及漫长的测试阶段。如今，软件每周都要有交付，这一套已经行不通了。我们寻求的方案要能带来如下好处。

　　避免过度说明需求从而产生浪费，避免花时间在开发前会发生改变的细节上。

　　有一种可靠的文档，可以解释系统的行为，据此我们能容易修改系统行为。