【IT168 专稿】    随着软件规模及复杂程度日趋复杂化，软件开发模式也从早期的单兵作战式或手工作坊式渐转变为流水线式的团队协作开发方式。在这种开发模式中会遇到一些非常棘手的问题：就是客户需求会经常发生变化。如何有效的解决需求频繁变更造成的种种问题，成为每一位项目主管极为头痛的问题。

    近期，我在公司委派我负责的一个项目里遇到了不少麻烦。在已完成的三个阶段性周期里，虽然我一直是忙得焦头烂额，但是每个周期还是不能按时的完成计划任务。原因是每次将要完成一个阶段性任务的时候总会有新的需求要变更，结果是每个周期的任务总是要被拖延。在饱受痛苦的折磨后，我向资深的前辈请教，后来问题终于得到有效的解决。在这里我和大家分享巧借敏捷开发小版本技巧，破解需求频繁变更困局的实践经验。

需求变更之痛导致敏捷开发产生

    目前多数软件开发有一种所谓的"正规方法"，这种方法对开发过程有着严格而详尽的规定，以期望使软件开发有着可预设性和提高效率。这种开发方法是通过详细的计划、度量和控制来进行管理的，因此在开发过程会过分强调文档的完整，重视与客户的谈判与签订合同。例如第一件事情就是冻结需求规格说明书，双方签字确定需求。若要更改，必须经过非常严格的需求变更流程和需求变更委员会审批。

    但现实总是残酷的，需求总是会变化。有一句经典的话说得好："在软件开发领域中，唯一的不变就是变化。"软件需求变化的原因有许多，例如客户业务发生了变化，客户对业务的理解发生了变化，需求分析人员对需求的理解出现了偏差需要修正。对于第一点，或许还能够根据合同与客户讨价还价，而对于后两点尤其是第三点，开发团队显然是不可拒绝的。因此，这种"正规方法"虽然已存在了很长的时间，但是并没有取得令人瞩目的成功，甚至最常听见的是批评它们官僚繁琐。要是严格的按照它的要求来做，不但有太多的事情需要做，而且会大大的延缓整个开发进程。所以，它们通常被认为是"繁琐的重型"方法。

    作为对这种"重型"方法的反叛，出现了一种被称为"敏捷型"的新方法。这种方法的吸引之处在于对繁文缛节的官僚过程的反叛。它在"无过程"和"过于繁琐的过程"中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。例如，"敏捷型"与"重型"方法有一个明显的区别，是敏捷型通常要求尽可能少的文档。事实上，文档减少仅仅是个表象，它其实反映的是更深层的特点。"重型"方法是试图对项目在一个很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化，而敏捷型方法则欢迎变化。因为软件开发过程中充满了变数，需求会变、环境会变、资源会变，一切都会影响最终的结果。

    为了应对频繁的变化，敏捷开发的首要理念是：迭代式开发。因为有时用户也无法讲出完整的需求，甚至用户亲口告诉的需求也可能并不是他们想要的东西，只是他们无法描述出来。在这个时候，敏捷开发是先抓住用户需求里面最关键的要点，重要性低的需求点往后放。迭代开发会把时间分为开发周期和交付周期。每个交付周期的结束，向客户展示已经完成的部分，每一次迭代拿出的都是一个稳定可用的系统，但是功能可能尚未完整。当用户看到眼前的东西，就会想到更清楚的需求，就可能会推翻其中某些已完成的功能，或修改某些功能，或放弃某些尚未完成的功能。然后再给下一次迭代确定更加明确的需求。

    因此，敏捷开发与传统开发最大的不同点在于"敏捷"二字。传统开发是用户提出了需求后，开发团队闷头开发一两年，发布一个很大、很全但可能是不合用户本意的系统。而敏捷开发的发布周期通常是两周到两个月，它不要求每次都要发布很多的内容，但它要求向最终用户频繁发布最新版本。用户拿到新版本的周期由一两年大大缩短到了两周到两个月。

什么是敏捷开发的小版本发布？

    （1）什么是敏捷开发的小版本发布？

    敏捷开发(Agile Development)是一种以迭代为核心、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目。但是敏捷开发并不是为了盲目进行加速或出于速度考虑才选择敏捷的版本发布。相反，它是一种符合标准的规划方法并且融入许多实践经验的开发模式。

    敏捷开发其最本质的含义是：对用户需求的快速响应，要让慢如蜗牛的开发变成快速的产品交付。在敏捷开发中不会拿到需求后就闭门造车，直到最后才将产品交付给客户。而是尽量多的产品发布，一般以周、月为单位。这样客户每隔一段时间就会拿到发布的产品进行试用，而开发人员也可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动时，也能很快的适应。因此，敏捷开发强调小周期、小版本、快速重构。

    （2）敏捷开发小版本发布有哪些优势？

    从本质上说，敏捷开发小版本发布是一种非常务实的开发方式。因为小版本的目的是要分解复杂度、降低风险，改善和提高对需求变更的能力。表现为两个方面：一是它强调对用户不断变化的需求一定要尽快的快速响应，虽然用户需求频繁更改是最让人恼火的。二是用户的很多需求，在很多的情况下是无法事先全部预先想好的，是要在开发过程中不断完善起来的。

    小版本发布有众多优势，具体有以下几个方面：

    ①总体风险比较少：小版本总是在上一个版本基础上局部调整和增加，变化小使到技术复杂度低；由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布。②提升需求接纳能力：由于小版本快速实现并发布测试，然后就进入下一个小版本的周期，这样新需求一旦提出就能快速进入开发视野和尽快实现。而且在变更大的时候，小版本控制能随时将程序回复到以前某一时间点状态。③测试和开发高效协作：小版本能将开发环境与测试环境进行有效的隔离，使到开发和测试可以并行工作。例如，当开发实现第一个版本后，开发人员就进入下一个版本周期；测试人员测试新发布的版本并提交Bug，开发人员就可以在下一个版本结束时修正所有上一轮发现的Bug，然后发布新版本。如此循环往复，开发和测试实现高效协作。④频繁的小版本发布可让项目主管控制软件开发的进度。因为通过小版本发布能使项目主管对整个项目的进度、程序的编写、修改情况有一个整体的了解。