为什么Windows这么复杂的软件也可以“敏捷”？《微软的软件测试之道》的第三章提供了一些答案。作者Alan Page参与的大多数的微软产品都采用螺旋模式或其变体的开发模式。如下图所示，他们也用里程碑来组织一次发布。关键就在那些括号中的“Beta（对应内部测试）”和“业内预览”。“每一个里程碑发布的产品都是一个完整的产品，都可以用于大范围的使用。”——通过每一个里程碑的内部测试和业内预览，大型软件开发实现了有规律的“模拟发布”，并获得了“持续交付”所带来的收益。
写到这里，一个改善现有流程的方法已经自然浮现。弱化里程碑0（如果不是取消的话），构建初始功能列表。里程碑1选择一些功能开始迭代开发，迭代结束后发布 Beta1，请用户试用。里程碑2选择一些功能开始开发，某些功能可能来自用户对Beta1的反馈，迭代结束后发布Beta2，请用户试用。里程碑3选择少量功能开始开发，重点是处理Beta1和Beta2发现的缺陷和获得的反馈，迭代结束后发布正式版。随着开发流程的发展，逐渐实现“永远的Beta版”或“无版本”的软件。
然而，知行合一总是无比困难。实现上述转变已经超出我的能力范畴。不过，从注重实效的角度，仍旧可以完成一些力所能及的工作。例如，维护一个始终可用的、反映最新开发进展的测试系统；邀请用户代表参加Sprint演示，听取他们的意见。另一个好消息是，组织将逐渐把发布周期缩短到3个月（最终目标是1个月）。这显然是向敏捷迈出的重要一步。
版权声明：本文出自liangshi的51Testing软件测试博客：http://www.51testing.com/?298785
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
