昨日参加了一次小型民间敏捷聚会，心情很愉快。从09年开始间接参与敏捷，到领导敏捷项目，还从未写过一篇敏捷的体会总结文章。今天简短整理一下，不足之处和不正确之处还忘各位理解。

　　首先敏捷的核心思想是提升质量，而加快进度的效果通过三个维度实现：

　　1、遵循测试的原则之一尽早测试（不仅仅是代码级测试，还包括更充分的对需求、架构、设计文档的测试），减少了发现缺陷，修复缺陷的成本从而实现了一部分的加快进度的效果；

　　2、敏捷思想提倡“以客户为中心” 而非以“以技术为中心”，减少了需求开发的浪费从而实现了一部分的加快进度的效果；

　　3、敏捷活动中“关注人”，注重“方法论”的使用，又提升了每个人的工作效率和质量，从而实现了一部分的加快进度的效果。方法论的出现和应用无论是开发领域还是测试领域都是必然规律，这些方法论要么提升单位时间内的工作质量，要么提升工作效率，从而体现在项目中就是项目按时有质量交付。

　　其次对于大型复杂项目和小型项目的敏捷测试要所区分，没有统一的测试模式：

　　1、大型复杂项目除了测试人员在敏捷团队中为开发人员提供方法论开展早期测试外，测试人员还可以参与story的编写开发，写的好的story甚至可以直接作为功能测试用例的标题。测试人员还应该代表客户进行story之间依赖关系图的建立（以我经验开发人员更容易画出模块实现的关系依赖图），然后PO再从story之间的依赖关系图中梳理出story开发的先后顺序。这样的迭代计划才是有设计依据的，保障迭代计划的质量。你的迭代计划的质量有依据吗？

　　2、大型复杂项目的story测试更多还是功能级测试，对于很多系统级的测试还是需要有专门的系统级测试技术人员来实施更好。而小型项目的story测试就足够了，可以省却系统级测试活动。

　　3、在进行验收测试时，建议PO参与测试组一起测试，PO必须审查测试用例。我曾作为PO领导过2个软件的开发，由于测试组同事没有条件和资源像PO一样从全局对需求有了解，因此开发的验收测试用例还是有些不足，因此2次审核测试组的用例都提供了很多补充意见，从而提升了测试用例质量。

　　4、对于一些开发生命周期很短的项目或团队成员很少（2-3个人）的项目，不一定要搭建一个第三方CI环境才能开始敏捷。因为这时你自己都可以通过本地的开发环境编译器进行编译，当然每天要编译至少几次，每次新增点什么代码或修改点什么代码就要马上编译，开发人员本地自验——这就体现了敏捷的思想尽早测试了。

　　最后敏捷中的每日晨会不要流于形式， 要与风险管理结合起来：

　　1、每日晨会每人就三句话：昨天我做了什么？遇到什么困难？今天计划做什么？ 谁在混日子马上都能暴露了。PO也可以及时了解项目新产生的风险。

　　2、PO除了从成员反馈的困难中收集新风险，还应该凭借自己的经验提前分阶段去识别项目所存在的技术风险，质量风险，进度风险 用一个表从每个迭代一开始到结束都跟踪起来。把风险尽早第一时间管理好项目怎么能不成功。

　　在我领导的敏捷项目中实践了：结对编程（1人code 1人review）， 代码共享（我们两人轮流在同一个文件中写代码）、每日构建（有一个项目每日构建几次每日集成几次），开放办公，每日晨会、尽早测试、重构、简单设计等。但我认为对项目成功最关键的是：每次遇到开发人员提出要新增某个功能或改进某个实现时，我脑海中只有一个标准谁能马上证明这个要求是客户在迭代交付时间点需要的，如果找不到充分理由，我就会否定这样请求。在整个敏捷项目中每次决策时，我脑海中都是反复在问：会影响按时交付吗？会影响交付质量吗？会导致新增大量测试成本吗？

　　其实我认为衡量敏捷实践效果的标准不是单元测试覆盖率或自动化率，或是我用了哪些实践活动。而是通过深刻认知和运用敏捷的原则，最终保障了项目的每个迭代都是按时甚至提前完成了有质量保障的交付，那么无论团队的士气提升或敏捷的价值都会得到认可。我个人作为PO兼Master所带2个敏捷项目的所有迭代都是按时甚至提前交付，并无返工或重大质量问题反馈，因此我很认同也喜欢敏捷的这种工作模式（不是开发模式），喜欢敏捷的“以客户为中心”的思想。真“客户为中心”是以质量为前提，通过质量保障的方法论间接加大了测试投入；假“客户为中心”是以进度为前提，克扣质量保障的投入。 大部分敏捷的优秀实践本质都是质量提升的方法论，尽早测试尽早发现问题修复问题，减少返工才是敏捷的核心。

版权声明：本文出自 架构师Jack 的51Testing软件测试博客：http://www.51testing.com/?293557

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。