qa与rd为什么不能一起合作
qa与rd为什么不能一起合作
谁对软件交付的质量负责？
肯定很多人顺口就说了：肯定谁写的软件谁负责嘛，开发人员对质量负责。
但是真正的情况是：在软件交付后，出现问题往往是测试人员背锅
大家诚恳一点面对现实，才能更好地看清问题。比如说，大家都在说开发人员要对质量负责，那你敢不敢把测试人员从软件交付的流程里拿掉？
不是开发已经负责了么，为啥后面还要跟个测试人员对着软件点点点？既然拿不掉跟在开发屁股后面的测试人员，有啥脸说开发对质量负责了？
测试是如何对质量负责的？建立在“开发对质量负不了责必须有测试在屁股后面跟着测”这个前提下
很显然测试负责的方式就是从开发写的软件里找出更多的bug对吧。所以，给定同样规模的一堆软件，找出bug越多，就说明这个测试对质量负的责越有效
测试拿到一个bug，会怎么做？
-
马上告诉开发有个bug
-
打开缺陷管理系统，录入bug的复现方式，配上截图，提交，等着开发解决
很多测试人员的选择是很自然的：他们会打开缺陷管理系统，录入bug的复现方式，配上截图，提交，等着开发解决。虽然这个过程通常会走个至少一天两天的时间，但是那有什么关系呢，这段时间又不是在闲着——测试继续在测别的功能，开发继续在开发别的功能，大家工作量都很饱和，完全没毛病 。
除了一件事：这个功能达到可用状态的时间被拖长了。虽然所有人都很忙，新功能就是迟迟上不了线。但是有谁关心呢。测试测出bug了，文档记录也齐全；开发已经996了，又不是没有在忙。至于业务负责人想要可工作的软件尽快上线，那很简单，开发和测试一起告诉他没办法再加快了，他能有什么办法的。
这个选择，就具体而微地体现《敏捷宣言》的前两句价值观：是马上开始个体之间的交互呢，还是按照流程和工具的要求一步步来；是尽快解决问题得到可工作的软件呢，还是先把详尽的文档保障了再说。
这些年所有的MBA课程都在讲，我们身处一个VUCA时代。组织要怎么应对动荡、不确定、复杂、模糊的外部世界呢？那就得快速低成本试错，就得把精益创业的“构建-度量-学习”循环跑起来。好，老板在外面上了MBA课程，觉得是这么个道理，回到组织内部来一看，组织里干的满不是这么回事。组织里的绩效，就算真的按照那个完美构思在运作，顶多也就是提高了开发（加测试）人员的产出效率。
组织的目标，是在什么时候就悄然消散的？问题的根子就在“开发”、“测试”这样的岗位设置上——或者更准确点说，是这些岗位背后的“开发部”、“测试部”这样的组织机构设置。这种把人按职能拢在一堆的组织机构，有个专门的术语，叫“silo”，翻译过来叫“竖井”或者“筒仓”。一个职能的人，只要给他塞进这个竖井里，用职能相关的KPI（比如说，开发写多少行代码，测试发现多少个bug）给他一套，他立马就能找到“我就是我的职位”的感觉，从此两耳不闻窗外事一心只搞KPI。什么叫组织的目标，哪个是业务的驱动，就再不用管了。
更神奇的是，只要有了竖井，装进竖井里的人就会自动地构造出一系列生理特征，让自己跟这个竖井严丝合缝。比如说吧，前两年我还管开发的时候，我跟一个前端开发的小伙子说，这个Java代码逻辑是如此这般，这哥们马上叫我打住：我是前端开发，这后端的代码我看不了。我就奇了怪了，十几年前我们做个软件都是一个人从数据库到Java到Web页面全做，十几年过去现在工具框架这么发达，反倒做不了啦？当然这都是竖井的效果，同样这个小伙子，回头你看他接私活，别说Java了，PHP他也给你搞出来。
竖井对人的塑造效应，往理论上总结的话，也算康威法则的一种体现。有多少竖井，就会有多少分工流程。具体到一个用户故事上，有多少职能竖井，这个故事就会分解成多少个任务。以前只有开发和测试的时候，用户故事就会分成开发任务和测试任务；现在有了前端开发后端开发，一个用户故事就会分成前端开发、后端开发、联调测试三个任务；有些地方比较先进，已经成立了DevOps团队，那么用户故事就会再拆分出一个“DevOps任务”——虽然我也不知道这个DevOps任务到底是要干啥，但是不用担心，只要有竖井，就一定会发明出这个竖井该干的事，不然绩效从哪儿来呢。
职能竖井不光会发明出这个职能的活动，还会生长出山头，小山头逐渐变成大山头，大山头上建起庙，庙里就供上了大佛爷——手下都有团队了，不升级成个部门么？都有部门了，不得搞个理论体系么？这几年流行的东西，中台、DevOps，据我观察，都是这么个路数。