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

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

    （1）对迭代周期作出安排

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

    （2）制定版本发行规划和安排

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

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

    （3）控制小版本的开发粒度

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

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

    （4）明确小版本的交付管理制度

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

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