导读：本文向开发者分享敏捷测试实践经验，文中阐述了敏捷测试的实现方法，对比敏捷模式和非敏捷模式的区别以及它的适用范围。

1.什么是敏捷模式：

敏捷模式是一种应对快速变化的需求的一种软件开发模式，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。敏捷的模式并不是一个方法论，而是一个世界观。

甚至敏捷不是一个方法论，顶多也是一种世界观。当在做一件事而又不确定哪种方法正确时，就可以参考一下原则，看看是否与原则相违背。

2.敏捷模式的实现方法

采用敏捷的开发模式不是说前期的需求什么的都不需要讨论，系统设计不需要了。在项目的前期，PD需要完成PRD，召开PRD评审会议，或者出原型之类的，务必使项目的成员都了解项目的需求。

对于没有使用过敏捷模式的团队，还需要召开Scrum计划会议，介绍项目的整体管理（流程，方法，工具和团队组建）等。

另外在流程开始之前，我们需要介绍一个名词UserStory。用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：角色 ——谁要使用这个功能；活动——需要完成什么样的功能；商业价值——为什么需要这个功能，这个功能带来什么样的价值。指定UserStory并没有统一的标准，项目组N个人可能有N种粒度的UserStory；从测试的角度来讲，我们需要保证没有遗漏。

迭代计划：迭代的划分设定UserStroy

• 任务的分解
• 工作量的评估和认领
• 对整个迭代的整体计划进行确认；

任务执行：开发和测试按照迭代计划执行

• 每日站立会议：沟通已经完成的进度，当前计划和当前问题
• 提前进行部分功能交付测试
• 全部功能测试
• 团队回顾：评审会议
• 产品交付验收

3.敏捷模式和非敏捷模式的区别：

使用敏捷的模式开发项目，更多的是要求项目成员之间能够彼此信任，互相协作，同心协作，相互沟通。使用需要项目组的成员发挥自己的主观能动性。

对比瀑布模型：

• 个体和交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划

对比迭代模型：

迭代模型是以模块为最小划分单位，每个迭代采用的可能是小规模的瀑布模型；而敏捷模式，是以一段时间为止，我们尽可能多的实现UserStory，；

4.敏捷的适用范围

敏捷的是在充分了解项目的基础上进行的一种类似于手工作坊的开发模式。因此在所有的项目中都可以使用敏捷的思想，但是如果完全使用敏捷的开发模式，个人觉得以下类型的项目比较适用：

对实践型需求变更较频繁的项目比较适用：对于那些需要严格按照PRD进行开发的项目不合适，比如微软需要开发一个win9的系统是不可能采用这种敏捷模式的。

对逻辑简单的项目比较适用：对项目逻辑复杂，关键性高，可靠性安全性等方面有较高的要求的项目需要在开发的每个过程中，都需要多方认证，适用敏捷模式不合适。比如需要淘宝的登陆系统，就不可能使用敏捷的模式。

对团队成员少而精的项目比较适用：如果一个项目中，人数越多，面对面的沟通的代价就呈几何级往上增加。

对模块独立的项目比较适用：如果项目中，模块和模块之间的耦合度较高，相互之间依赖严重，整个项目只有很少的UserStory，使用敏捷模式会造成项目敏而不捷。

5.敏捷实践的经验和教训

避免无计划性：在以往的开发模式中，测试计划是绝对时间，而敏捷模式中，测试计划是相对时间。以往的开发模式在某段时间中，任务比较明确，而在敏捷模式中，容易造成无计划没目标。对于这种情况，除了有任务计划之外，能够自己指定一份计划，给任务计划确定具体的完成时间点。

避免无纪律性：敏捷的模式是支持需求变更的，但是我们不能够无谓的变更。所有的开发和测试同学都不希望自己的项目中存在不确定因素，但是使用敏捷模式，我们需要接受这种变更；

任务划分思考不足：从下面的图中（最开始并行上升段）我们可以看到，预计的总的开发时间（蓝色的线）是上升的，表示项目的考虑不够充分！在实际开发的过程中发现了不足之处，然后进行改进，导致整个工作量的增加，例如我们项目使用的是WebX3，结果hecla不支持Webx3，目前仅支持从Webbx2 升级到Webx3的兼容模式

任务填写不准确：不是项目组中的每个同学都能坚持每天都在XPLANNER中填写时间的，如果时间填写不准确，则无法准确表达当前的项目情况（资源投入情况，项目质量等）。