如何带领传统软件团队走向成功（二）

大家好，今天继续来说一说：“如何带领传统软件团队走向成功”，这节的内容有很多软件开发中的专业术语，可能非软件开发专业的小伙伴一下子理解不了，造成阅读有点困难，这里要说声抱歉，不过还好问题不大，并不影响对于整体的理解以及中心思想的表达。

今天再来和大家分享一下：面对频繁需要返工的困境如何提高交付质量？

困局

当我团队建设工作告一段落，同时也要求公司给团队提供了一个相对来说安全的环境。那么，我们理所当然地要有产出，要交付出一个高质量的产品。

所以当时我们就引入敏捷开发，形成定期迭代，每两周发布一定的产品增量，让客户也好、业务部门也好，有一个预期。那问题也来了：在产品最初的几次迭代当中，交付的新功能非常的少且零碎，而且经常会因为要修复一些紧急的bug和缺陷给打乱节奏。并且因为之前遗留的一些历史问题，研发人员经常需要返工，偿还技术债及技术债带来的利息，这往往占用了他们大量的时间，还将整个迭代计划完全打乱。

而且当时还有一个很重要的问题暴露出来，团队里面一直缺少测试人员，真的很难想象一个软件开发团队居然没有一位测试人员。团队里面的每个开发人员互相不沟通交流，闷声只做自己的，然后就直接提交代码，不仅提交的时候经常互相覆盖代码，而且Bug非常多。很多时候做出来的东西和实际业务部门需求的是两个东西。

所以，当时产品虽然定期迭代，但质量特别差。差到什么程度？好多代码都是那种硬代码，直接写死了，比如说我给A客户的某个值写死成“123”，当b客户的这个值变成“234”的时候就不行了，就要把代码重新拿出来改成“234”后，再重新去发布一次。

还有最常见的就是功能的核心流程操作经常被打断，业务闭环走不通。还有很多体验方面的，比如点了一些按钮没有反应，跳出一堆乱七八糟字符等等，甚至很多客户都在不停的吐槽我们的系统界面太难看了，杂乱无章，风格不一。

破局

虽然质量问题不是由Scrum Master操刀负责的，但我既然作为领导者，我有能力也有义务来解决频繁返工，交付质量低下的难题。我当时是怎么解决的呢？

首先我还是要从研发人员的思想入手，让他们充分认识到外部失败成本对于组织、对于团队所造成的严重后果。后面，又该怎么解决？那就要求我们研发人员在开发阶段，就要达到高质量水平。这其实，就涉及到怎么建立，提升开发人员的质量意识。

我当时就还引入了精益开发的一个核心概念“质量内建”，也就是要求软件生命周期之间，参与的各个角色都需要实时的对软件的质量负责，也就是说，从我们产品经理开始，从产品到UI到开发到测试，我们每个职能都要去对这个产品负责，确保软件在交付到下一环节前已经有了基础的质量保证，这样才能减少因为质量问题导致的返工，避免浪费大量人力成本。

同样的，我一直在灌输“我即团队，团队即我”的思想。之前面对产品的质量问题，尤其是被客户投诉，被业务嘲讽时，团队成员的第一反应就是，“这个功能不是我开发的，这个锅我不背”，“这个跟我什么关系，当时是谁谁叫我这么做的”。

比如有一次，这个产品的人脸识别功能出现故障，用户使用时一直提示错误。其实这只是个小问题，很快就能修复好。但是为了避免以后出现类似的问题，所以我把团队成员聚在一起开会，讨论为什么会出现这个问题，以后也避免犯这种低级错误。但是大家都是一一副“这个锅是某某人的，你跟某某人说就行了，我不需要听你讲这些”的态度。

可把我气得厉害，我该怎样办呢？从思想层面来说，要让研发团队的成员们在工作中深刻贯彻“我即团队，团队即我”。团队要为质量负责，也就是每一个人都要为质量负责，而不是说这个功能不是我开发的就不关我的事。

如何落地

那具体如何去做呢？我首先就是要求增加测试岗并配备人员，通过迭代计划会保证PO、开发人员和测试同学对于用户故事和验收标准的认知是一致的，并且让测试同学提前介入测试，及早的发现缺陷并及时修复，或者在合适的时候采用TDD（测试驱动开发）的方法，来将Bug扼杀在在摇篮状态。但是这里需要特别说明的是，TDD会增加大量的工作量，所以说我们需要在合适的时机恰当使用。

随着大家对于质量意识的提升，我继续在产品的更新迭代中引入单元测试、集成测试和回归测试。我当时设想得很完美，单元测试、集成测试不仅可以提升代码质量，还能提升开发人员的代码设计能力、质量主人翁意识，让开发阶段的交付质量有所提高。但我没有料到，如果在一个没有测试文化的团队里面引入这些，阻力会这么大，团队的成员都跑来问我这提出异议：

“单元测试仅仅是证明这些代码做了什么，我觉得太浪费时间了。”

“我是很棒的程序员，技术能力这么强，我是不是可以不进行单元测试？”

“后面的集成测试将会抓住所有的bug，单元测试的成本效率不高，我把测试都写了，那么测试人员做什么呢？”

“公司请我来是写代码，而不是写测试。测试代码的正确性，不是我的工作啊”

……

对此，我只能不厌其烦地跟大伙解释，单元测试虽然是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节，也是唯一一次有保证能够代码覆盖率达到100%的测试。我也拿出数据说明，之前我们产品大部分的错误，是在软件设计阶段引入的，我们为了修正一个错误所需的费用，将随着产品生命期的进展而上升。我们错误发现得越晚，修复它的费用就越高。

我们作为编码人员，是唯一能够做到生产出无缺陷程序这一点的人，其他任何人都无法做到这一点。最后我也小小吓唬了他们，“如果你能百分百确定在开发后期，不会因为bug过多而失控，那你就可以别做，后果自己负责。”好在团队的小伙伴都明白我讲的是有道理，也都认真执行了。

如果说单元测试、集成测试是开发人员来做，那回归测试，通常由团队一起来完成。因为回归测试重复枯燥，我们通常都是借助一些工具自动完成。如果是带页面的项目，那么也会要求测试人员进行UI测试，帮助团队提高回归测试的效率。

当然，我们也会设立CI服务器，将以上测试定期运行，并且生成可视化报告，让所有团队成员都看到，并且要求团队第一时间修复CI。

我们使用Git管理代码，并建立Git的规范和分支策略，并且充分利用GIT的一些高级功能和规范流程帮助我们提升代码质量，同时解决一些疑难杂症。我们也鼓励开发人员设计更好的部署架构和技术架构，帮助团队做更好的决策。

夯实成果

除了以上这些测试工作，还有一个我认为也是非常重要的工作，那就是代码回顾。对于代码回顾的重要性，想来也不需要我再做过多的说明，代码回顾的好处几乎不存在争议。代码回顾既是质量的一道门槛，也是知识分享的一个很好途径。

那么如何保证代码回顾本身的质量呢？首先我们要在团队的技术能力的不同阶段，采用不同的代码回顾策略。比如团队稳定，编码规范掌握的比较好，使用的语言也是熟悉的语言，那么可能代码回顾的重点就会放到业务逻辑方面；如果团队新成立，还在磨合，可能编码规范就需要多注意；如果是团队新换了一门编程语言，那么语法本身可能也会是代码回顾的重点。

在公司业务发展的不同阶段也需要采用不同的回顾策略。比如To B的业务在稳定推进，那么代码回顾可能需要更加仔细严格，保证质量和代码的可读性、可维护性；但是如果是在互联网行业，业务发展初期，在快速试错阶段，那么代码回顾需要Leader去平衡回顾力度和业务交付的要求。    这些我们做到了，代码回顾就没问题了吗？当然不是。当时团队在开始代码回顾这块也出现问题了。具体咋回事？听我来说说。

一开始我们进行代码回顾时，我会发现，做代码回顾的成员交付出来的东西很差，乱七八糟的。有一次我终于忍不住指出他的问题，没想到他直接说，“这代码回顾我能力不够，做不了，老大你换人吧”。我当时真的挺惊讶的，没想到他这么排斥这项工作，我立刻态度缓和，真诚的问他是遇到什么困难，稳住他的情绪。他这才说，平时工作量也不少，现在做这个代码回顾，很难一下子挤出很多时间来做，而且还经常是一次性提交大量的代码来回顾，他很难抓住重点。

我没想到，我认为理所当然的操作，也很好操作的代码回顾竟然给他带来这么大的困扰。作为Leader，我首先控制了每次需要回顾的代码量，避免对大量、无意义的代码进行回顾的现象存在。

同时，要求提交代码的人在commit note中应该写清楚提交代码的目的。例如：这个实现的是什么功能？做的是什么优化？修改的是什么bug？这样才方便负责代码回顾的人有的放矢，清楚代码改动的上下文。

解决了这个问题，你以为代码回顾就可以高枕无忧了吗？

当然不是。当时我们团队还陷入了成员互相挑错的陷阱当中去。例如当时我们在回顾一个页面设置的代码，有人指出了小张这个代码写得太啰嗦，还出错了，犯了低级错误。小张当下心里就不舒服了，“你居然当面这样说我，我不要面子的吗。你等着，我现在就要挑你的错处”。这样的事情再多发生几次就会造成恶性循环，面对代码回顾，大家都会将内心封闭起来，抗拒那些针对自己的批评意见，团队气氛越来越紧张。一说到又要开展代码回顾，大家都情绪低落，特别排斥。到了最后，不仅代码回顾工作没有做好，还严重地影响正常的开发工作。

到了这个时候，我意识到不能放任大家有这样的情绪存在。我开始遏制挑错现象的蔓延，改变用代码评审、代码走查等“审、查、评字眼”，跟成员强调代码回顾重点是在共同学习和建设性上面，而不是批评。

让大家以开放的心态来面对代码回顾，它不是设置障碍，或者挑毛病，而是一个必不可少的质量保证过程，同时也是一个互相学习的过程，只是需要对于编程规范有一个共识，避免因为编程习惯发生不必要的异议。

最后，还要提醒你一点，一定要让成员将代码回顾养成习惯，让它成为我们工作中的一部分，当然，对代码回顾者的时间要有所保证，每个人在一个迭代中有自己承诺的任务，只有在预留了代码回顾的时间的情况下，代码回顾才能作为一个日常任务被执行。可以把代码回顾作为DoD（完成标准）的一部分。

总结

这一部分的信息量有点大，我再简单陪你回顾一遍。之前研发团队交付的新功能非常的少且零碎，研发人员常常因为返工被占用了大量时间，迭代节奏、迭代计划经常被打乱。而且产品的质量常常被诟病，也成了业务部门攻击我们的重点。面对这些困局，我具体在团队内部做了什么举动来破局，减少团队的返工，提升交付质量呢？分为三步走：

第一步，要求团队各个角色都要实时对软件的质量负责，给他们传递“我即团队，团队即我”的思想，也就是提升大家的质量意识；

第二步，引入单元测试、集成测试和回归测试，提升开发人员的代码设计能力、提升代码质量，让开发阶段的交付质量有所提高；

第三步：开发人员要做好每日代码回顾，提高质量和团队整体效率。

这样一操作下来，我不仅获得了团队内外的肯定、还获得老板的赞赏，他觉得我作为一名空降领导，这一顿操作猛如虎，看到了我是如何发挥自己的敏捷领导力，用行动推动和促进了团队变革。

为什么这么说呢？因为我通过行动，提升了研发成员的质量意识，从而也提升了开发阶段的质量水平，尤其在经历了几个迭代后，效果非常的明显。不仅减少了之前返工带来的对迭代节奏的破坏，让迭代顺畅又有质量。产品的缺陷跟BUG率有了明显的降低，使得我们团队有更多的精力投入到新功能中。还能帮助开发人员写出更好的代码，培养他们开发处理复杂和疑难问题的能力，大伙也不再因为产品质量被人诟病，相互甩锅，而是想着如何一起处理缺陷，避免类似问题再次发生。

同时，也间接开阔了团队视野，让团队成员了解更多的技术，学习如何利用新技术提升自己效率，甚至大家面对代码回顾这种枯燥又繁琐的工作，都不会抗拒，浪费自己时间，能明白其中起到的重要作用。

正因为研发团队对产品控制度有了上升，公司内外部成本也明显降低，业务部门的抱怨也明显少了，并且关系也更加的融洽，客户好评率呢，也上升了不少。