共计 6705 个字符，预计需要花费 17 分钟才能阅读完成。
一 引言
本文是京东到家自动化测试体系建设过程中的一些回顾和总结，删减了局部零碎设计与实际的章节，保留了组织与文化相干的内容，整顿成文，以飨读者。
上面就以 QA（Quality Assurance）的视角来探讨工作中常常面临的问题与挑战。
关于软件品质，不晓得你有没有以下困惑：
中医中“头疼医头，脚疼医脚”的思路在研发团队中往往不能见效。西医的整体辩证论治往往是解决问题的良方。其基本还是思考维度和察看视角的不同。举个例子来说，扭转人类出行形式的，并没有依照培养更加低劣强壮的马匹来演进，而是自行车，汽车的创造；还有被公众常常戏说的例子，抢占方便面市场的不是因为某一款方便面，可能是外卖的衰亡。这都通知咱们，从更高维度视角去扫视问题，问题往往更容易被定位解决。咱们先来看一下研发体系需要交付流程，波及到的人员单干及各个交互阶段，如下图：
举个例子，拿软件漏测率高，导致线上事变频发的景象来说。先从整个需要交付流程来看，整个产品迭代的节奏如下图：
那么导致漏测率高的起因是什么呢？
可能是产品设计问题，可能是研发施行问题，可能是用例验证问题，可能信息不对称的流程问题，可能是团队合作节奏呈现了问题，也有可能是技术储备的问题，总结起来能够演绎为：组织反对，技术实际，文化共识几个维度。上面咱们聚焦于组织反对和文化共识两个方向。
二 康威定律
2.1 定律解读
亚马逊 CEO 贝索斯对于如何进步散会效率这个问题有本人的解决办法。他称之为“两个披萨准则”，即与会人数不能多到两个披萨饼还不够他们吃的境地。
谈到组织架构就绕不开号称软件架构设计中的第一定律，康威定律：“设计零碎的架构受制于产生这些设计的组织的沟通构造”；
它们都体现了横向沟通老本是十分高的事实。技术层面，零碎各个模块间的接口也反映了它们之间的信息流动与单干形式，也是同样情理。
为了直观了解，咱们借用一张流传甚广的图来了解一下组织构造：
其实依据原文中康威定律，又有人将其拆解为以下四个定律：
第一定律 组织沟通形式会通过零碎设计表达出来。
组织的沟通和零碎的设计之间严密相连，特地是简单零碎，解决坏蛋与人的沟通能力有一个更好的零碎设计。
第二定律 工夫再多一件事件也不可能做的完满，但总有工夫做完一件事件。
“麻利开发”模式很好的诠释了这条定律，做到一直迭代、继续交付、疾速验证和反馈，并继续改良。一句话：实现比完满更重要！
在零碎真正地投入生产应用之前，再好的架构都只是假如，产品越晚被使用者应用，失败的老本和危险就越高，而小步前进，通过 MVP 疾速试验，获取客户反馈，迭代演变产品，能无效地缩小失败的老本和危险。防止适度设计问题的呈现。
第三定律 线型零碎和线型组织架构间有潜在的异质同态个性。
你想要什么样的零碎设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队天然的自治内聚，明确的业务边界会缩小和内部的沟通老本，每个小团队都对本人的模块的整个生命周期负责。这是对第一定律的场景具象化；
组织和零碎架构之间有一个映射关系（1 ~ 1 mapping），两者不对齐就会出各种各样的问题，一方面，如果你的组织构造和文化构造（专制单干式，集权式，丛林法令式，人才密度）不反对，你也无奈胜利建设高效的零碎架构，例如集中式和严格职能（业务，开发，测试，部署，运维）的企业，很难推广微服务和 DevOps，推广 Docker/PaaS 平台也会比拟艰难，这样的组织职能之间都偏向于局部优化，无奈造成无效的单干和闭环。
反过来也是成立的，如果你的零碎设计或者架构不反对，那么你就无奈胜利建设一个无效的组织；
第四定律 大的零碎组织总是比小零碎更偏向于合成。
零碎越简单，越须要减少人手，人手越多，沟通老本也呈指数增长。分而治之便是大多数公司抉择的解决方案。分不同的层级，分不同的小团队，让团队外部实现自治理，而后对立对外沟通。
其实康威定义的外围要义就是如何进步组织的合作效率。想更加具象化的去了解，咱们能够从大自然中寻找智慧，最典型的就是树的组织构造，树根 -> 树干 -> 树枝 -> 树叶，树根通过树皮向上提供水分和营养到树叶，树叶光合作用将碳水化合物通过树心从上向下传导，这种生命有机体的分工协作形式就是合乎康威定律的。另外树状构造在数据结构方面的效率体现也是最为平衡的。所以使用好树状架构，对于组织沟通合作乃至零碎架构都是大有裨益的。从新扫视一下咱们的组织架构吧，这可能是繁冗问题景象后的罪魁祸首之一。
2.2 实际案例
京东到家优惠券零碎进行过一次大的改版重构。过后的业务背景是 O2O 业务模式通过一段时间的摸索，咱们最终将超市生鲜定为业务的着力点，紧接着针对于超市生鲜业务门类的促销便接踵而至，仅仅在新人资格下面就有：平台新人，商家新人，首单新人等若干维度，而后在叠加渠道，城市，商家，门店，品牌，商品等各个维度的组合限度，玩法灵便，多变，需要池外面挤压了大量的促销需要。
过后团队有 3 集体在反对以后优惠券零碎的业务迭代，运作模式能够用竖烟囱的形式来形容。架构体系处于失控的状态。其运行逻辑是：为了疾速撑持业务需要，缩小对原有服务逻辑的影响，就只能重整旗鼓，从新设计，而越是这样，从底层的数据结构到两头的根底服务，以及下层的业务聚合，在组件数量和构造上无奈做到必要的内聚和收敛，导致局部业务很难撑持，同时线上破绽显著增多，最终到了难以为继的境地。于是咱们进行了零碎重构，当然咱们的测试人员由一个人从头到尾全程反对，撑持起了整个重构工作的测试工作。过后的组织架构如下图：
随着业务的疾速倒退，大量的拉新促活需要接踵而至，最重要的是促销的玩法多变，各个业务团队都有本人的要求，比方对于用户留存业务团队要求有下单返券 / 分享领券 / 砍价券等场景，而对于用户增长团队可能想要的是定向推送优惠券 / 地推扫码领券 / 新人红包等玩法。业务方是多线的，而咱们的研发团队以及零碎却是复线的，这就导致了我的项目沟通和协调的老本微小，因为研发资源的问题，很多需要长期处于需要池外面得不到及时响应，即便咱们试着将研发人员进步了一倍，但后果还是不能基本解决这个问题，需要交付效率成了业务痛点。
接下来咱们在组织架构上做了很大的调整，首先业务架构层面，咱们将用户增长部门和用户留存部门的业务和研发别离进行了闭环，即两个业务部门都成立本人独立的研发团队外部进行畛域闭环；其次咱们在技术架构层面，将现有的优惠券服务进行了零碎拆分，将处于优惠券外围生命周期的性能进行了中台化，为各个部门提供根底服务的能力，而非核心生命周期里的比方优惠券发放门槛，触达形式等促销业务玩法，交由各个业务团队外部消化就能够了。这样就打消了业务和技术的多对一的组织合作模式，在团队的沟通和合作效率上获得了显著的成果。
从业务到技术研发都做到了组织和零碎的拆分映射，但咱们的测试团队并没有在第一工夫及时的进行人员调整，展示进去的后果就是测试品质有所降落，同时测试效率明显降低。因为随着组织和零碎架构的重塑，业务和研发做到了沟通合作的外部闭环，但对于测试同学来说却并没有做到，接下来咱们将测试团队再次与研发团队的组织进行对应，实现了整个需要交付链路的架构调整。
三 组织文化
3.1 团队认知
成员克服个体差异性，默契配合，彼此信赖，造成真正有凝聚力的团队，是须要一些工夫的，可能须要 6 个月，甚至 1 年。凝聚力一旦真正造成，团队的成员会一起做打算，一起面对问题，一起搞定所有。一旦团队有了凝聚力，但却因为我的项目完结了便将这样的团队遣散，则是极为荒诞的。最好的做法是不拆散团队，让他们持续单干，只有一直地把新我的项目分派给他们就行。
一些新创建的软件外包公司试图围绕我的项目来构建团队。这是一种不明智的做法。依照这种做法，团队永远都不可能造成凝聚力。每个人都只在我的项目中短期停留，只有一部分工夫是在为我的项目工作，因而他们永远都学不会如何默契配合。
业余的开发组织会把我的项目调配给已造成凝聚力的团队，而不会围绕着我的项目来组建团队。一个有凝聚力的团队可能同时承接多个我的项目，依据成员各自的志愿、技能和能力来调配工作，会顺利完成我的项目。
团队比我的项目更难构建。因而，组建持重的团队，让团队在一个又一个我的项目中整体挪动独特工作是较好的做法。并且，团队也能够同时承接多个我的项目。在组建团队时，要给予团队短缺的工夫，让他们造成擬聚力，始终独特工作，成为一直交付我的项目的弱小引擎。
团队的离心力如何打造？肯定是联合业务场景，设定适合的价值导向。从一般的研发团队来看，有以下几方面可能是须要投入精力来保障的：
- 辨认团队瓶颈，优化木桶短板，进步资源利用率；
- 缩短交付周期，进步吞吐率；
- 周期预估精确，精准把控节奏；
如果咱们的团队产出达不到预期，那就要辨认出问题呈现的起因，是因为指标没对齐，流程不标准，还是技术储备少，基础设施单薄，最要害的是咱们要有良好的洞察力和执行力。发现问题，问题就解决了一半。
- 指标不对齐：让信息通明，明确度量指标;
- 流程不标准：对流程进行治理，比方采纳麻利开发模式；
- 技术储备少：解构 -> 观测 -> 对标 -> 学习 -> 重构
- 基础设施单薄：善用工具(CI/CD)/ 自研
最艰难的是做决策和执行。在执行的时候也要思考事实的环境和团队文化，这是自上而下疾速推动制度落地的原则和根据。比方咱们应该如何去进行需要立项，如何将我的项目落地？
这就须要找出咱们做决策的根据和贯彻执行的办法:
- 做正确的事件（价值驱动 - 决策依据）：关注 ROI/ 优先级；
- 正确的做事件（规定驱动 - 执行办法）：关注规定 / 办法 / 品质效率体系建设；
3.2 问题认知
我想进步软件交付品质，就须要抓住问题的实质。如何定位问题的实质呢？外围就是多问几个为什么。参照六度分隔（Six Degrees of Separation）实践，“你和任何一个陌生人之间所距离的人不会超六个，也就是说，最多通过六个人你就可能意识任何一个陌生人。”
什么样的状态才算是高质量的软件交付？
答复可能是：问题少，交付效率高。
进一步拆解，问题少，交付效率是通过什么来掂量的？
千行 bug 数，单位周期上线的故事点数量。
如何统计千行 bug 数，单位周期上线的故事点数量？
能够借助 Bug 跟踪管理软件，比方 Jira。
第三方软件不能很好的反对我的诉求，我想要的更多，怎么办？
能够研发自有的 CI/CD 工具 …
那么问题问到什么时候能力完结呢？
将问题被拆解到至多能够被度量的粒度。拿软件交付品质来讲，问题可能会被拆解到上面几个维度：
联合 PDCA 工具，咱们能够将整个度量体系形象为以下流程：
拆解实现的能够被执行的工作，如下：
1. 晋升代码品质：指标度量（千行 bug 率，圈复杂度）/ 工具辅助（扫描）/ 服务拆分 / 流程保障（技术评审）；
2. 增强流程把控：提测流程线上化 / 上线流程（品质门禁，灰度等）/ 指标度量（提测通过率）；进步测试覆盖率：指标度量（接口覆盖率 / 代码覆盖率 / 自动化覆盖率 / 缺点剖析）等；
最终依照软件交付流程，将产研测运等外围节点如法炮制，最终造成体系化的解决方案，如下图：
3.3 常识赋能
在一个领有战斗力的团队中，默契和共识是根底。而要造成某些共识，就须要领有一套良好的问题反馈和解决机制，借事练人。能够借用如何进行单元测试和如何进行预估排期两个工作当中常见的问题，来扫视一下团队的共识状况吧。
3.3.1 如何单元测试？
软件可测性和研发过程非亲非故的，然而事实场景是软件开发人员很不违心编写单元测试用例，起因有很多，比方：办法和分支太多，单元测试用例的编写甚至要比业务代码还要多，工夫基本不够用；好多办法依赖于上下文，须要做模仿（mock），只有这样能力跑起来；推广单元测试仿佛就困难重重。
很多公司程序代码正确性的验证就交由软件测试人员来实现，工作的转移必然产生了更多的沟通与合作老本，如果软件不常常迭代，问题还不大，如果软件是依照周期迭代的，每个周期都要进行全量测试，那么这个测试团队的人员必将会十分之大，这个问题就比较突出了，测试阶段极有可能成为需要交付的瓶颈，侵害软件产品的公布，影响业务的增长。
为了晋升测试效率，很多测试过程能够进行自动化，比方回归测试，性能测试等。当然还有另一种晋升测试效率的方法，就是让单元测试回归到开发人员的职责范畴内，当然单元测试也属于自动化测试的领域。
举个咱们日常 web 开发中常常遇到的一种场景，比如说我想依据给定的筛选条件，获取相应的数据信息：
示例中这个办法的测试有容器的依赖 HttpServletRequest，须要模仿进去才能够测试，否则就只有把服务器启动才可能运行这段代码，这就不属于单元测试了，而属于集成测试了。仅模仿容器还不够，还须要模仿底层的数据库能力跑起来，于是模仿就会变得越来越简单。测试代码明明不简单，单元测试的老本确十分之高，如何解决呢？
要晓得咱们真正要测试的是代码逻辑，代码执行所依赖的环境不是单元测试的目标，它只会让测试变得艰难。所以咱们要写可进行单元测试的代码，就是要测试代码的参数开发人员能够自在模仿，不须要依赖于环境。比方，上述示例咱们就以拆分革新一下：
咱们拆分进去的子办法是不须要依赖于容器环境的，这样咱们的单元测试就能够顺利进行了。可能还会有人提出疑难，拆分后难道原办法里的代码就不须要测试了吗？答案其实是必定的，因为原办法里的代码都是程序执行的，并没有逻辑，如果代码里没有逻辑，是不须要进行测试的。同样的还有底层的数据库操作也是如此，咱们进行单元测试的时候也不须要真正的做落库操作，落库动作对于验证业务逻辑自身也没有太大意义。
单元测试交给软件开发人员来编写，自身是没有问题的，有问题的其实是软件开发人员对单元测试的认知，以及开发进去的代码自身。测试驱动开发模式就是标准咱们进行单元测试用例编写的一种实际形式。
3.3.2 如何预估排期？
研发人员应该懂得如何为业务人员提供可信的预估后果，以便做出打算。一旦做了承诺. 就要提供确定的数字，按时兑现。然而大多数状况下，准确数字这很难做到。业余的做法是提供概率预估，来形容冀望的实现工夫及可能的变数。对预估后果，研发人员会与团队的其他人协商，以获得共识。
1957 年，为反对美国海军的潜艇极地航行打算，打算评审技术 (PERT，Program Evaluation and Review Technique) 诞生了。PERT 的一部分内容就是对预估的计算方法。这种技术蕴含了一个非常简单而无效的方法，把预估变成概率分布，让主管们看懂。
你能够依据 3 个数字预估某项工作。这就是三元分析法。
O：乐观预估。这是十分乐观的数字。如果所有都异样顺利，你能够在这个工夫内实现。实际上，为了保障乐观预估有意义，这个数字对应的产生概率该当小于 1%。举例：如果是 1 天。
N：标称预估。这是概率最大的数字。如果画一张柱状图，标称预估就是最高的那个。举例：如果 3 天。
P：乐观预估。这是最蹩脚的数字。它该当思考到各种意外，比方飓风、核战争、黑洞、其余劫难等。为保障乐观预估有意义，这个数字对应的产生概率也该当小于 1%。举例：如果 12 天。
有了以上三个预估，咱们能够这样形容概率分布：μ=(O+4N+P)/6
针对于例子，咱们能够的出预估值（1+4*3+12）/6=4.2 天
通常这个数字都有点水分，因为分布图的左边局部比右边局部长。所以咱们用 工作的概率分布的标准差来掂量不确定性：σ=(P-O)/6
σ 是这个工作的概率分布的标准差，如果这个数字很大，就示意十分不确定。对上文举例来说，它等于(12-1)/6，也就是大略 1.8 天。
当初咱们预估后果是 4.2 天 /1.8（标准差），给人传递的信息是，理论可能 5 天实现，但也可能要 6 天甚至 9 天。
理论状况可能会更简单一些，有时候咱们会多项工作并行，这时候的预估模型也会进行调整，总任务统计散布：μseq=∑μtask，总标准差就是标准差平方和的平方根。
把握一些根本的工夫预估模型的常识，对于我的项目布局和施行节奏的把控，是十分必要的，毕竟根据教训甚至是拍脑袋给出的排期往往是不能让人称心和服气的。
四 总结
本文介绍了软件与组织架构的关系 - 康威定律，并结合实际案例进行了解读。又从组织文化层面，形容了团队规模对软件交付的影响，给出应该围绕团队来承接我的项目，而不是根据我的项目来组建团队的观点。接下来又借助六度分隔（Six Degrees of Separation）实践，给出了剖析问题，解决问题的办法和思路。最初介绍了团队应该独特成长，将工作中常见的问题（比方：如何预估排期），给出迷信的领导和训练，从而打造出一支能战能胜的“特种部队”。
注：本文局部图片来自互联网
作者：京东批发 刘慧卿
起源：京东云开发者社区 转载请注明起源
