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

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

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

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

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

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

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

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

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

　　(1)什么是敏捷开发的小版本发布?

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

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

　　(2)敏捷开发小版本发布有哪些优势?

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

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

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

　　高效实现敏捷开发小版本发布的技巧

　　众所周知，软件开发绝对不能闭门造车，因为需求总是可能存在二义性，且需求总是处于不断的变化中。若能不断交付一个可以工作的小版本，一方面可以给与开发团队和客户以信心，另一方面也有助于及时获得客户的反馈。结合这次项目的实践经验，在这里我和大家分享高效实现敏捷开发小版本发布的几点技巧：

　　(1)对迭代周期作出安排

　　在迭代开发的初期，应该要先对开发需求划分优先级，这样开发团队就能够知道要开发的具体内容。然后，再从开发需求中选择所能承受的、尽可能多的高优先级内容项，并将这些内容添加到每个迭代周期计划中。常见的迭代周期的时间长度为2到4周。因为时间较短的迭代周期往往更容易进行规划，快速的修改意味着一定的紧急性。较长时间的迭代周期容易让人误认为有大量时间可供使用，这可能会导致进度拖延和滞后。同时，在迭代周期计划中，要确定迭代开发的演示和复审时间。因为迭代特性演示可以帮助所有人了解开发的进度，并能获得早期的反馈机会，从而能在迭代期间及时的实现调整。

　　(2)制定版本发行规划和安排

　　在敏捷开发过程中，人们总是担心没有精确的版本发行规划，这已成为推广敏捷方法的主要障碍。因为对许多人来说，缺乏精确的版本发行规划就等同于缺乏协同规划。因此，对版本发行制定规划和安排是敏捷开发的核心一步。敏捷开发版本规划包括长期规划和小版本规划。版本规划的首要目标是要最大程度地明确"已知"工作并且完全公开它们。

　　因为当开发人员了解了自己所需要做的工作后，就会对小版本划分优先级，并确保开发始终优先实现最重要的内容。否则，如果团队将大量时间浪费在不重要的内容上，那么项目就会陷入麻烦之中，因为时间已经所剩无几。这也是我在这次项目中得到的最大的经验教训。因此，确保用户需求内容在版本规划上适当显示是重要的一步。这样在小版本发行期间，就能跟踪团队的开发进度和能够更清晰地了解开发的工作量。

　　(3)控制小版本的开发粒度

　　如果仅从对一个项目的进度控制粒度上来说，我的经验认为是要保证对项目进度在更细的粒度上进行控制。一般来说，小版本的持续时间通常各不相同，小版本有时被称为"冲刺"，多次的"冲刺"能有效的控制项目进度。对于使用极限编程的团队，小版本的周期为1到2周;而使用 Scrum 的团队通常有为期4周的冲刺。

　　例如，把一个开发周期在12到18个月的完整产品，先分解成2-3个月的研发短周期，进而又把这2-3个月的时间再细化，划分成2周粒度的开发目标。再具体到每一天每个人的开发任务上，这不但让每个人明确自己今天和明天要作的事，同时大家也能明确知道未来两周自己的开发目标。而且，交付的时间间隔越短越好，因为大家能更有效地进行反省，然后相应地对自己的行为进行调整。

　　(4)明确小版本的交付管理制度

　　小版本是敏捷开发的一项关键活动。在小版本期间，团队通常需要分配用户需求、分配任务以及评估完成每项任务所需的时间。目的是为了当出现某个用户的最新需求时、或当发现某个任务的技术障碍时、或当某个团队成员变为不可用时，开发活动能及时在小版本发布过程中得到修正。因此，在管理活动上需要明确制定小版本的交付流程和管理制度。

　　总之，在敏捷开发中，控制和管理小版本发布是非常重要的工作，不仅能对需求变更作出及时的响应，而且还能够协调开发人员的工作，对整个软件开发过程进行有效的管理，大大提高软件开发效率，达到事半功倍的效果。