敏捷与完美需求开发：异同与实践

敏捷宣言所遵循的原则里面的很多条款与需求开发相关，具体如下。

●我们最优先要做的是通过尽早得、持续得交付最优价值的软件来使客户满意。

●即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

●经常性交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的间隔越短越好。

●在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

基于这样的原则，敏捷宣言提出了：可以工作的软件胜过面面俱到的文档，客户合作胜过合同谈判这样的宣言。

可以说敏捷的起点和我们上面所分析的基本一致。通俗一点讲是：既然变化永恒，且变化越来越频繁，既然用户只有在看到真正的软件后，才能进一步深化他的认识，那我们为什么要写几百页的文档来把自己伪装成已经理解了一切，接下来再不停地修改这些文档呢？为什么不首先就专注在软件上呢？(www.xing528.com)

然而我们在这里的观点毕竟与敏捷不同。形象来讲是敏捷走出了100m，而我们这里认为50m才是一个恰当的距离。文档自身不需要面面俱到，这点没错，但考虑到需求的变化来源之一与人相关，这里始终认为停在恰当的尺度上的文档是必要的。这主要植根于以下两个原因。

一是人始终是有遗忘、偏好等特质的。这类东西处理不好，会导致内耗大幅增加。而人的特质与历史文化等相关，恰恰是最不好把握的一环。考虑到“说话算数”，这一基本原则在各种文化背景下都可以获得共识，所以这里认为文档化可以不记录某些细节，但对外交流时的内容则不能缺失。很简单，如果没有这类文档，A可能认为B在某年某月某日说过X，但B不这么认为，这种事情只可能引起无限的纷争。尤其是牵涉到利益分割的事情，比如，某种表单的总结，是应该由需求提供方提供原始版本，还是由开发方自行总结。

二是只有对点上的信息进行归纳，才可能发现这些信息背后的东西。对软件项目而言，这些背后的信息往往价值很大。比如说，在做一个监视系统的时候，用户的需求中可能同时包含了用30个摄像头覆盖所有区域和每只摄像头的转角要有30°这样的要求，但当结合用户的场地进行分析时可能发现在转角为30°时，覆盖所有区域并不需要30个摄像头。这类细节的分析，没有文档做支撑是很难做到的。

发现原始需求背后的信息对某些生死攸关的选择非常有帮助。最简单的例子是对编程语言的选择，如果没有对目标软件一定程度上的分析和认知，而立刻专注于生成可工作的软件，那么编程语言的选择就可能变得很随意。

为了使上面的观点更加清晰，提供一组软件规模和文档规模的对比数据会更有意义，但很可惜，这类数据暂时还无法找到。