敏捷开发模式下的质量管理

恭喜发财dife

前几天，笔者与一位在大型互联网公司从事质量保证的朋友交谈，作为互联网产品质量和测试的负责人，他
最近负责的质量管理方面遇到了很多困难。主要有：1）测试团队在敏捷开发模式下的价值非常有限；2）
开发人员只顾自已写代码，没有任何文档，测试人员无从下手，3）由于进度的原因，测试人员测试的时间
非常有限，上线后出现很多问题；4）由于测试人员得不到开发团队的认可，离职率非常高；5）质量部门
无法收集到数据，不能进行质量度量；6）测试团队也有一批自动化测试专家，但派不上用场…..这些问题
可能很多开发团队都会遇到，总结一下，大致是这几个方面：



}        越来越多的企业希望采用，但没有把握
}        习惯于传统的瀑布式产品开发流程已不满足快速发展需要，但大规模改动不现实
}        缺少敏捷软件开发专家和人才
}        技术人员需要观念的转变和方法培训
}        缺乏相应的质量控制方法
}        需要经常的和及时的质量度量、测试、决策
}        自动化测试不能落到实处，每日构建仍是纸上谈兵
在现在行业中，需求变化太快，不管我们怎么努力去做，发现还是不能满足客户的需要，不管需求搞得多
么细，到交付产品给客户的事情，总是有这样那样的问题，这个时候就不得不去修改我们的软件，这是目
前很多企业尤其是互联网公司面临的一个挑战，如何解决这个问题？
笔者先后在华为、阿里巴巴软件质量部门任职，最近也深入研究了腾讯敏捷开发平台TAPD（腾讯敏捷产
品开发）和IGD（集成游戏开发）一些资料，对国内敏捷项目的质量管理有很多独到的见解，结合共创力
咨询公司多年的项目经验，总结如下：
1）QA角色的转变
QA要从警察的角色转变到一个教练的角色。在以前，团队实施CMM的时候，QA更多的是一个警察的角色，
他整天拿着一个checklist、报告什么的到处去团队里面看，你是否ok，不ok就要怎么怎么样，整天就干这
个活，但是引入敏捷之后，QA就觉得有点失落，都敏捷了，我都不知道该怎么下手了，在著名的通信企
业华为的做法是将QA转变了一下，将QA更多的充当教练的角色，充当SCRUM Master的角色，他去指导项
目团队该如何去开这个站立式会议，该怎么去做迭代的计划等等指导性的工作，这样QA也觉得挺好，这
样他能参与到在不同的团队中去，QA的角色更多的偏向于全过程的敏捷活动指导，以提高产品开发效率
和质量。QA在这个过程中也能得到一些数据，如代码缺陷率，版本的不良率，上线遗留问题数，团队成
员配合度等等。
      2）要使敏捷团队整体参与

   QA和测试人员也是敏捷团队的一部分，作为敏捷教练，要向他提供支持和训练，以使作们适应开发的快
节奏。比如，如果你是敏捷团队中的测试人员，并且计划会议和设计讨论没有邀请你，或者业务用户正在
独立定义故事和需求，那你应该主动站出来和团队的其他成员交流，并偿试“三方协作”，即测试人员、开
发人员和业务专家。腾讯公司把业务专家称为BA，即
   Bussiness Analyst, BA和开发人员DE、测试人员TE组成了敏捷开发团队，这些成员不仅仅把都在忙着最
终的交付而努力，他们还乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自已的
需求，从而得到他们的需要的功能，同时向所有人提供项目进展的反馈。
3）              自动化回归测试。敏捷团队没有自动化会成功吗？可能也会成功，但我们所知道的成功团队都
依赖于自动化回归测试，如腾讯和支付宝公司的Selenium框架，阿里巴巴和淘宝网的QTP框架。汉捷咨询
认为，敏捷开发利用测试来指导开发，为了编写的代码使测试通过，需要快速而简单地运行测试，没有短
期反馈周期和安全的回归测试，团队将很快陷入技术债务，缺陷不断增加，速度越来越慢。
4）            提供并获取反馈
反馈是敏捷的核心价值，敏捷的短期迭代可以提供持续的反馈以帮助团队正常运转，测试人员则通过自动
化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供支馈。如你怎么知道客户手里
拿到了预期行为的正确示例？你怎么知道编写的测试用例正确地反映了这些示例？开发人员通过查看测试
用例能够理解应该编写什么代码吗？QA和测试人员应该询问开发人员是否得到了足够的信息以理解需求
并是否能够指导编码，询问客户是否理解质量标准，应花时间参与迭代计划会议和回顾会议以讨论这些问
题并提出改进方案。把反馈的结构可表示为如下：


5）            构造核心的敏捷实践活动
软件行业有一名老话是：软件质量是设计出来的。对于敏捷开发也是如此，汉捷咨询认为没有一些基础的实
践活动，无法产生出高质量的软件。
①持续集成。持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天
至少集成一次，每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决，
降低缺陷修改成本；将集成工作分散在平时，通过每天生成可部署的软件；避免产品最终集成时爆发大量
问题。

②灰度发布。这是互联网产品的一个特点，说白了，就是对用户一个逐步放量的一个过程，而且不要求团
队要尽早 的将产品包发布出来，也就是不要求马上发布给所有用户，而是会分批的去发布，比如按号段发
布，比如在公司内部先体验。发布的时候也有策略，比如发布时如何放量，对用户有些什么样的实验，技
术上怎样做一些后台开关，运营上怎样跟进，怎样保证4小时人员的留守，发布完后怎样收集用户反馈等
等都会有一些统一的规则。比方实验室某WEB产品的发布，可以同时有多个版本，1.1版可能会有100%的
用户在用，1.2版可能只有1%的用户在用，它们是一个交叉升级的过程，目前腾讯采用了该活动。

③每日晨会：每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个
人今天计划做些什么工作（特点：是站着开会）。笔者在阿里巴巴工作时，就经历过每日晨会，一般主持
人由敏捷团队的成员轮流担任，这个时候可以了解每天发生的问题。

④结对编程：两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码
；操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；领航员检视的
同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。有助于提升代码设计质量；研
究表明结对生产率比两个单人总和低15%，但缺陷数少15%，考虑修改缺陷工作量和时间都比初始编程大
几倍，所以结对编程总体效率更高，同时结对编程能够大幅促进团队能力提升和知识传播。

⑤用户故事。用户故事是站在用户角度描述需求的一种方式；每个用户故事须有对应的验收测试用例；用
户故事是分层分级的，在使用过程中逐步分解细化；典型的描述句式为：作为一个XXX客户角色，我需要X
XX功能，带来XXX好处。用户故事的好处是：用户故事站在用户视角便于和客户交流，准确描述客户需求
；用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈；用户故事强调编写验收测试
用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。

⑥迭代回顾会议。在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；
围绕如下三个问题：本次迭代有哪些做得好？本次迭代我们哪些方面还能做得更好？我们在下次迭代准备在
哪些方面改进？会议需要Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；
会议关注重点是Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；会议结论要跟
踪闭环。

总之，共创力咨询认为，测试和质量是整个敏捷团队的职责，团队中的每一个人都应该关注手边的一个任
务或者故事，敏捷模式下的质量管理更具有挑战性，但与传统瀑布模式相比，其在应对需求变化、提升产
品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具
有明显优势。敏捷的焦点在于持交付有价值的软件让一直到客户满意为止。在这个“快鱼吃慢鱼”时代，要
想交付好而快的产品，不防用敏捷模式试试。

macco123

大受启发  多谢