在大学期间，我就是敏捷软件开发的追捧者。像《XP Explained》、《XP Explained 2e》、《Agile Software Development》、《Pragmatic Programmer》、《Domain Driven Design》这样的书都读过两遍，颇似叶公好龙。后来参加工作，将敏捷理论与中国国情相结合，也有些感悟。于是，我打算以“测试杂感”为题，从测试者的角度写一批文章，对自己的工作进行回顾和反思。错漏浅薄之处，还请不吝赐教。
最近一年，我都在做一个企业内用系统。该系统由多个服务组成，以Web Application的形式提供给内部用户使用。系统每6个月发布（release）一次。一次发布一般由四个里程碑（milestone）组成。里程碑0用一个月左右的时间确定规格文档和特性列表。里程碑1和里程碑2开发新功能。我们实施敏捷软件开发，所使用的方法论是Scrum。于是，里程碑1和里程碑2是两个Sprint，每一个Sprint延续4~6周，总共的开发时间是10~12周。里程碑3延续8周左右，修正已发现的问题，并为部署做一些准备工作。
那么这种开发方法是敏捷的么？
在著名的雪鸟（Snowbird）会议上，敏捷宣言的缔造者们希望给宣言起一个好名字。他们最终选择了敏捷（agile），因为它是一个“广告”词汇。与会者Alistair Cockburn反对使用轻量（light）之类的词，因为轻量意味着不重要、意味着在拳台上被重量级的选手打得摇摇晃晃。相反，所有人都会宣称自己是“敏捷”的，因为它让人联想到彪悍的肉食捕猎者、联想到以闪电般的速度奔向胜利。这是一个人见人爱的标签。
于是，实施某种敏捷方法的开发发团队都会毫无例外地宣称：我们是敏捷的。那么敏捷的核心是什么？请看敏捷联盟所提出的首要原则（principle）：
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
我观察到，许多开发者认为迭代是敏捷开发的核心特征。实际上，纵观敏捷宣言和敏捷原则，大师们强调的是可工作的软件（working software）和交付（deliver），而不是迭代（你甚至找不到iteration这个词）。Cockburn在《水晶方法》中指出“迭代并不提供关于软件是否能满足商业用途的端到端反馈”，因此他将“经常交付”作为水晶方法的首要体系特征。在他看来，“经常交付”的作用有：
- 项目主办者根据团队的工作进展获得重要的反馈。
- 用户有机会发现他们原来的需求是否是他们真正想要的，也有机会将观察结果反馈到开发中。
- 开发人员打破未解决问题的死结，从而实现对重点的持续关注。
- 团队得以调整开发和配置的过程，并通过完成这些工作鼓舞团队的士气。
那么“经常交付”的节奏有多快？再看一条敏捷原则：
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 要不断交付可用的软件，周期从两三周到两三个月不等，且越短越好。
如果a couple of months是上限，那么我们的项目以6个月为周期交付，它会导致什么问题呢？在里程碑0确定整个发布的功能列表，意味着项目经理要预测6个月之后的商业需求，意味着开发者要预测未来5个月的工作量。这不是不可能任务，但准确度也不会很高。而Robert L. Glass认为不准确的需求和估算是软件项目的首要风险。
再考虑一个情景：大半年前发布了版本V1，刚刚发布了版本V2，现在是V3的里程碑0。由于部署的速度比较慢，用户刚刚接触到V2，但是本周末我们就要确定V3的功能列表。于是，V3的功能列表将更多地基于用户对V1的反馈。这样，用户从体验V1、到反馈意见、到获得更新（V3发布）需要一年的时间。是的，一年的时间，这对于Web Application是多么的漫长。
在里程碑1和2，我们会用Sprint来实施迭代开发。每一个Sprint结束，我们都会做演示（presentation）。遗憾的是，用户并不评审我们的演示，因此我们无法获得他们的反馈。在里程碑3，我们会组织Bug大扫除（Bug Bash），并邀请用户也来寻找系统的错误。这对于发现歧义和界面错误是很有帮助的。遗憾的是，用户使用系统的时间很短（通常只有1~2天），我们很难获得他们深层次的需求。即便获得，我们也很难做出响应，因为原则上里程碑3是不允许增加新功能的。然而，排在第2位的敏捷原则是：
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
与大多数人的直觉相反，即便是Windows 7，也有能力在项目开发的后期做出变更。2008年底，微软内部用户开始试用Windows 7，即所谓的吃狗食（dog food）；2009年1月，Windows 7 Beta发布；在2009年7月，Windows 7完成RTM。比较RTM版和Beta版，你会发现Windows 7在任务栏（Taskbar）等组件上增加了新功能。这表明，Windows开发团队根据Beta版获得的反馈，增加了新的代码以提供更好的用户体验。
为什么Windows这么复杂的软件也可以“敏捷”？《微软的软件测试之道》的第三章提供了一些答案。作者Alan Page参与的大多数的微软产品都采用螺旋模式或其变体的开发模式。如下图所示，他们也用里程碑来组织一次发布。关键就在那些括号中的“Beta（对应内部测试）”和“业内预览”。“每一个里程碑发布的产品都是一个完整的产品，都可以用于大范围的使用。”——通过每一个里程碑的内部测试和业内预览，大型软件开发实现了有规律的“模拟发布”，并获得了“持续交付”所带来的收益。
写到这里，一个改善现有流程的方法已经自然浮现。弱化里程碑0（如果不是取消的话），构建初始功能列表。里程碑1选择一些功能开始迭代开发，迭代结束后发布Beta1，请用户试用。里程碑2选择一些功能开始开发，某些功能可能来自用户对Beta1的反馈，迭代结束后发布Beta2，请用户试用。里程碑3选择少量功能开始开发，重点是处理Beta1和Beta2发现的缺陷和获得的反馈，迭代结束后发布正式版。随着开发流程的发展，逐渐实现“永远的Beta版”或“无版本”的软件。
然而，知行合一总是无比困难。实现上述转变已经超出我的能力范畴。不过，从注重实效的角度，仍旧可以完成一些力所能及的工作。例如，维护一个始终可用的、反映最新开发进展的测试系统；邀请用户代表参加Sprint演示，听取他们的意见。另一个好消息是，组织将逐渐把发布周期缩短到3个月（最终目标是1个月）。这显然是向敏捷迈出的重要一步。