敏捷开发模式下测试经理没有了话语权？
本文首发于【林子的空间】
“转敏捷后，测试经理的话语权没有了，团队更加关注交付速度而不重视质量怎么办？”
在跟某转型中的团队进行交流时，一位测试经理表达了这样的担忧。
我理解这里的困惑在于两个方面：
- 传统模式下测试是一个独立的部门，测试经理可以在测试这个阶段严格把关质量，有很强的话语权；在敏捷模式下，测试需要融入开发团队，都由开发团队PM来统一管理，很有可能会更关注交付速度，这种情况下，测试经理的话语权似乎减弱了，该如何发挥价值、捍卫产品的质量？
- 其实，测试经理对自己的工作职责比较迷茫，不是很清楚敏捷模式下他该如何开展工作，似乎传统模式他所做的事情不能再继续了？
下面跟大家一起探讨该如何解决。
质量的重要性毋容置疑
不管是传统还是敏捷开发模式下，质量都很重要。
两个管理三角
传统项目管理三角把质量放在中心，体现了质量的重要性。但是，现实情况下，项目管理在保持铁三角不变的情况下，很容易从质量方面去妥协。
Jim Highsmith提出了敏捷项目管理三角，价值和质量是目标，各占一角，传统三角组合变成“约束”占据第三角。敏捷管理三角不仅进一步强调了质量的重要性，更是强调了质量的不可妥协性。这就表明如果因为某些因素影响到了交付需要提速的情况下，也不能以牺牲质量来实现，应该调整的是范围。
业务方往往有上线时间要求，交付速度显得很重要，但速速交付一款质量不好的产品，一定会给业务带来更大的损失。如果有项目经理一味要求团队保障交付速度，而不重视质量，团队测试人员需要站出来，指出质量面临的风险，同时还需要引导团队不同角色增强质量意识，一起来为质量负责。作为更加资深的测试经理，更是需要关注整体质量状况和潜在质量风险，承担起守护质量的职责。
不能只追求系统质量
类似功能的两款产品A和B：
-
产品A几乎没有什么缺陷，系统功能性和非功能性质量都很好，但是用户用起来却不爽，有些关键业务流程设计不合理，不仅不能帮助用户提高业务处理的效率，甚至手工操作效率会更高。基本没人愿意为这款产品买单。
-
产品B有一些质量问题，这些问题不涉及关键业务流程，只是一些平常较少用到的功能存在一些缺陷，这些缺陷也不会阻塞任何功能的使用。用户都特别喜欢产品B，原因是它的设计非常好，能够帮助用户工作大量提效，减轻工作压力的同时还提高了工作的质量。这么好用的产品，用户对它有着很高的容忍度，有些小问题是完全可以接受的。
显然，产品A光有质量没有价值，而产品B的质量没那么完美，但是带来很大的价值。
敏捷三角在强调质量重要性的同时，突出了价值的重要性，而且价值要高于质量。从前面两个产品的对此，我们不难理解价值和质量的这层关系。
作为测试人员，需要因此调整关注重点，不再把重点放在发现多少缺陷上，尤其不能无休止地抠那些并不是很严重的缺陷，测试要以业务价值驱动，从业务优先级的角度考虑测试关注点，确保关键业务的高质量交付。
测试经理则需要从业务价值的传递、关键业务的识别、业务优先级的定义等维度去做工作，帮助测试人员确定测试关注点和优先级。
测试经理的转型
真正实现敏捷的组织，测试经理的存在没有多大的必要，团队为质量负责，所有的测试工作都应该有敏捷团队的测试人员和团队其他角色一起来完成。当然，从传统转型为敏捷的过程中，有可能测试经理还会存在一段时间，但数量也会少很多，而且，组织要继续设置测试经理职位，一定要想清楚这个角色到底需要履行什么职责。
对于处在敏捷转型期的测试经理，需要明白此时所从事的工作跟传统模式下的工作有着本质性的不同：
- 不再需要编写长篇大论的测试和计划文档，或者制定测试时间表、给测试人员分配测试任务，也不应该是盯着测试人员的工作、负责他们工作的检查等。
- 一般跨多个团队工作，主要对测试进行支持、协助和辅导，从策略、技术、实践、工具应用等方面探索新的方式，并帮助团队实现改进。关键是在组织内建立良好的测试文化，对团队人员进行质量赋能，并且倡导团队探索更好地支持敏捷的测试实践。
写在最后
转型必然会带来多个方面的变化，对曾经的那种舒适感将会是个很大的挑战。如果转型势不可挡，也无需过多焦虑，而是应该以成长型的心态面对，积极地学习和了解新的模式，勇敢而坚定地探索新模式下赖以生存的新方式。
推荐阅读
敏捷是怎样改变测试管理的？
测试要以业务价值驱动
团队整体为质量负责
一页纸测试策略
敏捷团队的质量保障赋能
从技术趋势看赋能
软件测试人员该何去何从
