迭代还是交付?(2)

　　写到这里，一个改善现有流程的方法已经自然浮现。弱化里程碑0(如果不是取消的话)，构建初始功能列表。里程碑1选择一些功能开始迭代开发，迭代结束后发布Beta1，请用户试用。里程碑2选择一些功能开始开发，某些功能可能来自用户对Beta1的反馈，迭代结束后发布Beta2，请用户试用。里程碑3选择少量功能开始开发，重点是处理Beta1和Beta2发现的缺陷和获得的反馈，迭代结束后发布正式版。随着开发流程的发展，逐渐实现“永远的Beta版”或“无版本”的软件。

　　然而，知行合一总是无比困难。实现上述转变已经超出我的能力范畴。不过，从注重实效的角度，仍旧可以完成一些力所能及的工作。例如，维护一个始终可用的、反映最新开发进展的测试系统;邀请用户代表参加Sprint演示，听取他们的意见。另一个好消息是，组织将逐渐把发布周期缩短到3个月(最终目标是1个月)。这显然是向敏捷迈出的重要一步。

原文转自：http://www.ltesting.net