谈自组织敏捷研团队下的质量管理作用

束 勉，杜 宇

（中国联合网络通信有限公司软件研究院，济南 250199）

1 存在问题

个人归属项目管理部，负责项目的质量管理工作，我会经常和公司的质保工作者谈话，也经常和项目经理聊天，在和他们的交谈中我发现，项目经理需要对软件的整个质量负责，但是，在实际的质量管理中，也存在着很多的问题和困难。因此，针对开发团队常常都会遇到这些问题，大体可以总结为以下：

技术人员需要观念的转变；缺乏敏捷项目管理创新方法和实践；缺少敏捷软件开发专家和人才；项目中缺乏相应的质量控制方法；自动化测试每日构建依然实现不了。

2 解决措施

2.1 各项任务需要全员参与

QA作为敏捷团队的重要部分，敏捷导师，要进行支持和训练，从而使其能够快速地适应到团队开发中。测试人员要经常和其他的成员就工作展开沟通和交流，做好“三方协作”，即测试人员和开发人员以及业务专家之间的合作。他们为了整个项目的最终交付而辛苦忙碌着，并且十分喜欢收集信息，并且分享给大家，和业务部门之间的合作，能够辅助他们，能够将自己的需求展示出来，以得到他们需要的功能，并且，能够给与其他人项目进展和项目的反馈说明。

2.2 QA角色的转变

QA要实现角色转变，从检查者逐渐变为导师形象。传统中，在团队开展CMM中，他的作用相当于检查者，就是带着checklist和检查单等等，到团队进行查看，检查他们是否满足计划、执行、结果，如不符合就会提出一些可能不符合实际情况的改进措施，基本整天就干这个活，但是引入敏捷之后，QA感觉开展工作困难，在我所参与的团队中，我们试着把QA作为导师来看待，让他去带领整个项目团队，教他们怎样开会，怎么组织例会，怎么进行高效的工作计划制定等，在这个过程中，QA是更多地为了知道整个项目而进行的，他们来知道团队建设，提高他们的质量，方便高效的开展工作，另外，在质量管理中，QA能够获得一些数据，比如代码缺陷率，上线出现问题数，人均产能，接收测试问题数等等。

2.3 自动化测试

基于敏捷开发，迭代模式造成了大量的代码量，迭代越靠后，就会造成我们的更大的整合压力，带来的测试任务就更重。敏捷测试要求测试人员，可以随意启动自动化回归测试，然后快速验证迭代代码。如果缺乏短期反馈，没有安全回归测试的话，就会使团队容易背上技术债务，从而不断扩大缺陷，造成速度更慢。

2.4 收集反馈，不断总结

敏捷的核心价值就是反馈，只有敏捷的短期迭代，才可以为团队的带来持久的反馈，从而促进团队的运作，测试人员需要利用自动化，进行结果的测试，并且用观察结果形式，对团队的工作提供支持。接收测试人员可以了解研发与测试的具体工作思路与需求方的真实差距，以便持续改进；QA等相关要对开发人员进行询问，看其是否有了充足的信息来理解需求，并是否可以指导编码，对业务部门进行询问，看其是否能够对质量标准进行理解，要参与到迭代计划会议中去，经常召开回顾会议，提出问题解决的方案。

2.5 敏捷实践活动构建方式

（1）灰度发布。对现有生产系统逐步上线的一个过程，一般采用分批的方式去发布，实现指定范围内的用户通过相同服务访问地址访问不同版本的服务。我们的系统为提高质量，降低问题发生范围，传统的方式每发布一个新版本应用，都需要外围系统配合业务验证；为降低版本发布风险、减少外围系统配合发版的工作量，通过灰度方式选取小范围营业试点账号将需要外围系统配合验证的业务场景按照实际的营业情况进行验证。

（2）持续集成。团队的成员需要经常集成测试他们的工作，每次集成通过自动化构建完成，通过实现自动化测试脚本，能够完成持续集成。在代码管理方面，对于那些服务端的代码，如果有变化，那么是都能够利用自动化测试的，不断是什么错误，也都可以随时告知研发人员。通过每天生成可部署的软件；避免功能最终集成时爆发大量问题。

（3）迭代回顾会议。在每次的迭代完成后，都要开展会议，主要是为了进行经验的分享，并且能够及时发现和改进缺点，从而使团队建设不断。

（4）每日站会：对于每个团队而言，需要在每天中，都能利用10-20分钟，进行之前的问题回顾和分析，同时，也做好当天的工作介绍。公司倡导的每日站会，在会议中，通常是轮流担任主持人，可以对每天发生的事进行了解，还可以利于人员培养。

总之，创新与创业已经是当今社会的主要，创新需求方法论和技术的支撑，敏捷的研发流程是企业持续交付信息化产品的非常有效的方法，质量管理也更要发挥积极有效的左右，对于敏捷团队而言，测试和质量是主要的职责，在团队中，所有人都要做好自己的研发任务，在敏捷模式下，和传统瀑布模式相比，质量管理挑战更高，而且它在需求应对上、产品质量上以及周期上，都具有很大优势。敏捷的焦点在于持交付有价值的软件直到业务部门满意为止。

[1] 徐永富.对日软件外包中关于敏捷开发的质量管理研究[D].南京邮电大学，2013.