靠外包和借调搭建的新团队，效率却比成熟团队高2倍！

公司产品中的核心控制系统，其框架设计将近10年未变，维护难度极大，急需重构。然而在2014年，维护该系统的团队成员全部流失。

新组建的团队共15人（2名应届，11名外包，2名从其他团队借调的同事），重构被要求2个月完成。初步评估要达成该目标，人均生产率至少是成熟团队的2倍。

面对艰巨的挑战，该团队急需加速催化进入高效模式。为此，我在传统的敏捷实践中加入细节补充，效果极佳。核心控制系统以历史最优的质量按时交付。另外，人均加班时间只有过去的一半，效率之高令所有团队咋舌。

“让我们体验了另一种敏捷。”这是领导层的评价。

公司产品中的核心控制系统，几乎与产品中所有系统都有交互，流程极其复杂。随着业务规格的增长，该系统不堪重负，打补丁的代码非常多，导致维护该系统的团队的加班时间和离职率都是全公司最高的。

2014年，维护该系统的团队人员迅速流失，竟然无人看护。同年，我从A部门转入B部门，被授命组建团队维护该系统。我希望改变核心系统的命运，因此极力说服领导层同意我重构该系统。虽然领导层最终同意了我的重构请求，但是两重风险在时刻威胁着我们，工作随时会叫停：

• 面向过程转向面向对象的重构是否可行？

• 全部新人组成的团队是否能够超越成熟团队，奇迹般地在两个月内完成交付？

这两重巨大的风险，让领导层无时无刻不在担忧，并极有可能让重构中途夭折。要避免夭折，我们的团队需要每分每秒都在高效工作，不断快速地交付价值，每时每刻证明我们能够按时交付，而且还是最高质量的交付。而这个证明过程就是我们案例的启示要点：通过细节催化高效团队。

何为“高效”？在我们平常的标准中，约定时间内更高的交付率、更高的质量，或者约定的交付物在更短的时间内完成，都可以认为是高效的表现。

每个团队都期望高效的表现，但是如何证明团队是“高效”的？这个证明过程，有可能会让领导失去耐心而夭折，也有可能会让团队成员苦不堪言而抵制，还有可能因为方向错误而变成“低效”的代名词。

上述证明过程，其实也是我们在推行敏捷的过程中遇到的现象。我们一直在思考如何优化这个证明过程，我们期望每天都能证明团队在高效工作，让领导越来越有信心，让团队成员越来越有成就感，让团队在正确的方向上高歌猛进。

我们的高效之路从细节开始：做正确的事情、组建团队的自验证能力、培养高效的沟通，让每个人聚焦做一件事。

3.1 做正确的事情

“不完美的做正确的事情远比完美的做错误的事情更有意义。”对于团队而言，高效的第一优先级就是一直确保我们在“做正确的事情”

因此，我们思考的第一个催化剂是：“如何确定我们在做正确的事情？”

3.1.1 拆分故事，让价值假设更有把握

所有需求，在正式交付使用前，其价值都是假设的。 为了让价值假设更有把握，我们需要对交付的工作有清晰的认识，因此需要对需求进行分解。   

新的问题来了，“如何界定需求分解到合适的程度？” 这个问题并没有准确的答案。我个人的理解是分解的粒度和设计的粒度是一致，如果只进行概要设计，则交付层次应该是系统级别的。如果进行了详细设计，则交付层次可以细化到系统内部的事务级别。

回到我们的案例，为了保证价值假设的准确性，我的要求是能清晰的看到交付物的实现过程，也就是事务流程。基于这个要求，最终我们将需求拆分到5人天以内（大部分是2-3人天）。

拆分故事是常见的迭代计划会议的工作内容，然而这个实践却非常容易出现矛盾的现象。

• 为避免过度设计，只做了概要设计，却要求将故事拆分到系统内部的事务级别；

• 大量需要仔细分析需求场景的工作却要求一个迭代计划会议上完成；

• 统一的评估标准（交付标准、时间标准）却在参差不齐的团队中实行。

这些矛盾的现象源于团队对故事“范围”的理解存在不一致。如果不关注这些细节，主动解决这些矛盾，极容易产生摩擦（估算不准，重要场景遗漏，无法按承诺交付）。摩擦会让团队的前进产生阻力，进而对团队的能力产生怀疑。

通过分析团队的能力和系统的特点，我提前一周对迭代工作内容做了详细设计，并和相关角色人员讨论好交付标准（测试，维护，设计）。经过细致的准备工作，在迭代计划会议上，我能快速引领团队认识到交付价值及假设过程，在半小时内就能结束会议。

事后证明，团队对交付内容的理解十分到位，交付率极佳。

3.1.2 分析依赖关系，无法交付的工作宁愿不做

记得曾经有过一个项目，我们业务产品和华为平台合作。由于华为平台刚启动，还不具备持续集成的能力。我们业务产品的进度超前了两个月，当然这两个月的工作内容都无法交付。当平台交付第一个版本之后，领先的两个月的交付物联调在不断干扰后续的需求，整个项目苦不堪言，最终放弃所有工作。重新从最核心的价值开始，确认交付后再开始新的价值。结果项目最终延期半年。

这次血的教训也在不断提醒我们要注意需求的依赖关系，无法交付的工作宁愿不做。

回到我们的案例，核心控制系统与产品中所有系统都有交互，因此其需求的依赖关系是十分复杂的。通过拆分故事，我们梳理清依赖关系，通过依赖关系来判断故事的优先级，聚焦能够交付的工作，才能高效交付价值。

另外，很多重要的事情，是无法等待依赖关系解除的，我们需要主动出击，这里我们思考通过合理的设计来解除依赖关系。

我们为对外部依赖的接口设置一个隔离层，业务模型是建立在隔离层之上的，外部依赖的条件变化由隔离层消化，避免影响到业务模型。

3.1.3  解除交付约束，快速交付价值

拆分故事是为了快速交付价值，我们希望能够在交付后立刻收集反馈，由用户来评价工作是否正确。

但是，“迭代未结束，而且故事也无法演示，我如何收集反馈？” 在思考如何快速交付时，质量管理部门给了我一个提示，交付的工作同时也需要演示给QM（代码检视、自动化覆盖率、问题缺陷率）。我开始思考：我们是否可以在某个环节快速收集到反馈？ 

思考：代码检视是否可以作为交付演示？  

备注：自动化测试例也是交付内容之一，在代码检视的同时，也会单步演示其中一个测试例的执行过程。这个主要是自动化的内容，不在此处展开。

代码检视作为交付演示有以下优点：

• 主持人讲解代码的过程，就是在向大家演示需求是如何实现需求的；

• 会议检视是一个沟通的过程，可以第一时间收集到交付物的反馈；

• 代码检视可以随时发起，真正做到快交付（上午完成后发个通知，下午检视）；

• 还有一点是促进团队成员互相学习、备份，每个成员的知识储备都是一个水平线，这点对我们的新人团队非常重要，不要让技术债务拖累整个团队的进度。

最初代码检视都是我一个人在不断反馈。一周过后，团队其他成员开始反馈。一个月过后，我基本上都不用说话。最初我反馈意见后，团队成员问我“怎么改？”过了一个月后，团队成员问我“咱们是不是可以这么改？”

为了让代码检视达到交付演示的效果，我们做了以下细节补充：

• 代码检视尽量邀请需求和设计人员参加，确认交付物是否正确、合格。（这里我作为PO角色代替了需求和设计人员，另外我们也在不断完善详细设计，也可以通过详细设计来确认交付物是否正确。）

• 时间不超过1小时，检视一个交付内容，代码100-300行。多个交付内容的检视需要间隔10分钟，避免太累。

• 一旦团队确认可以交付，则团队接手该交付物的责任。例如，我的交付物通过代码检视了，后续该交付物的测试、变更、问题解决都不再是我个人问题，团队的每个人都能接手。这样要求的目的是交付后，每个人可以全心投入新的工作，不再受已交付的工作的干扰。

3.2 组建团队自主验证能力

持续集成加自动化测试，这两者的珠联璧合对现代软件工程质量体系的重要性是无需置疑。

在鼎桥，这项工作一直在和华为交流，应该说做的非常好，持续集成一天可以发布3次版本（完成冒烟测试），本地构建则保证上传的代码绝对不会存在低级错误。这些优秀的实践一直在为项目的高质量交付保驾护航。

然而不可忽视的一个细节是，这些构建工作都是基于已交付特性的验证工作。对于正在开发中的特性，特别是将特性拆分成许多更小粒度的交付物时，利用自动化验证的难度很大。持续集成验证特性，粒度太大，周期长。单元测试验证函数，粒度太小，无法构建交付物验证。

因此，我们思考的第二个催化剂是：“如何利用自动化工具组建团队的自验证能力？”

3.2.1 降低自动化门槛，每个人从一开始就自验证

我们需要组建的是团队的自验证能力，而不是某个人的自验证能力。对于参差不齐的团队或者全部新人的初创团队而言，降低自动化门槛对组建团队自验证能力极为重要。

为此，在工作开展前，我特意邀请公司的专家，基于华为的DTCenter（类似于Cunit的工具），设计了一个非常简单的基于事务级别的验证框架（大约200行代码）。经过一小时的培训，基本上所有人都能使用。而且随着对验证框架越来越熟悉，有想法的同事还会对该框架主动改进，测试例的编写越来越倾向于脚本化，门槛进一步降低。

降低门槛的效果十分显著，从项目开始的第一天，团队的每个人就能使用自动化工具覆盖自己的工作。

3.2.2 交付条件中，必须有自动化用例演示

“百闻不如一见”，在我们交付工作内容时，要求的是代码检视+自动化单步演示，然而代码讲解的多么动听，可能都不如演示一遍过程让人印象深刻。

我们可能会非常关注自动化覆盖对质量的作用，却很可能忽视一个很重要的细节：通过单步演示流程，可以让团队体验一遍事务演变过程，这对团队接受交付物起着非常重要的作用，这个作用完全不亚于覆盖率对质量的作用。

另外随着自动化门槛降低，团队成员倾向于交付时多加几个用例来单步验证，自身能力不断提高。有部分同事自发开始先写用例，再写程序。因为用例比程序好写，先易后难，类似TDD。这些我之前并没有给他们任何指示。

3.2.3 培养大家对自动化覆盖的重视

门槛的降低，交付条件的要求，这两项工作的逐步深入，已经让团队越来越适应使用自动化工具进行快速验证，但是我还想进一步挖掘，让大家对自动化更加重视。奖励或许是一个不错的方法，可惜物质奖励需要特性交付后才能由质量部门评定，而我只能苦命一点，口头激励吧。

• 对于优秀的用例设计方法，在代码检视过程中，不厌其烦的复述该方法，一定要让所有人都用上；

• 对于重点或难点的函数，在代码检视过程中，要求补上单元测试用例，并作为交付条件；

• 记录每个人的自动化用例数，每周周报中顺带提一下（抄送全员），用数据说话，最后质量部门的评定更有的放矢。

3.3 培养高效的沟通习惯

现实工作中，组织沟通的时间往往数倍于实际工作时间。

这里面的原因有可能是研发人员不善于组织、有可能沟通对象无法安排时间、有可能根本没找到关键的沟通对象。

这些无形的因素在不断的蚕食团队的工作时间，我们如何找回这些“失去的时间”，对提升团队的效率非常重要。

3.3.1 组建第一沟通对象，TL(Team Leader)

记得我入职面试,当时的技术总监问过我一个问题:"如果工作中遇到紧急的问题,你会如何处理?" 我的答案是"找经理帮忙!"

在案例中，我们希望培养团队成员养成习惯,遇到困难或重要的问题,优先找团队的TL.

这么做的好处有以下几点:

首先， TL是有较高影响力的人员，其组织沟通的效率远高于其他人员；

其次，影响力高意味着见识面广，很多问题TL就可以直接解决；

最后，重要或关键问题（成员遇到的困难一般也是重要的问题），能够及早反馈到关键人员，避免遗漏或者传递延迟带来的风险。

3.3.2 让团队的沟通距离为1

我们不希望的沟通场景是A要解决一个问题,先找B,B让找C,C又让找D,如此拖延导致问题无法快速解决.因此建立了"第一个沟通对象"的机制。

然而这还不够,我们更希望团队成员乐于将自己认为重要的知识主动分享出来，从而整个团队的知识储备都是一条水平线，每个人都是“全栈工程师”。

在案例中,我们通过以下实践来“组建团队沟通氛围”：

• 组建一个通信群，让知识分享可以方便快速通知到每一个成员（沟通距离为1）。

• 培养分享的文化，我们鼓励在群里提出问题（讨论可以私底下，起码每个人都知道你遇到过这类型问题），如果某个问题一段时间无人回答，我会提醒TL回答，主要是营造有问有答的氛围，培养习惯。对于比较好的分享，在早站会上我会提出来，甚至鼓励归纳成文档或博客。（没经费，只能精神鼓励了，囧）

• 频繁的代码检视，在加强质量意识的同时，激发大家讨论的热情。

3.3.3  建立跟踪沟通效果的机制

“我希望能一眼看到所有问题闭环跟踪了” 2011年我担当beta局问题接口人，当时的DM对我提出了这个要求。

思考我们沟通效果的跟踪需求：

• 可以跟踪沟通效果在整个沟通过程中的变化；

• 可以方便通知到关键人员；

• 这个效果最终是可以归档的；

• 可以追溯的。

日常工作中，八成以上的沟通和遇到的问题相关，而我们常见的记录沟通效果的方法是邮件，文档等。但是这类方法无法起到流动闭环的效果，或者实现的代价较大。 

因此我们鼓励通过问题单的方式来跟踪沟通效果。我们希望通过鼓励提单的方式，来释放每个人需要闭环跟踪的精力，闭环跟踪主要由TL负责。

在案例中，研发阶段提单的缺陷值高达408（有不少未必是问题，可能只是为了跟踪不确定的需求），而它带来的效果不仅是研发过程的效率提升（无需自己跟踪），在交付之后，有很多问题，研发，测试，维护，市场都很容易在问题单库里找到记录，并基于记录讨论（可追溯，易沟通）

另外，作为辅助，每个迭代结束前，我们会回溯一下问题单，作为下一个迭代工作安排的入口。

3.4 避免干扰，让每个人聚焦做一件事

大部分人最高效的状态就是集中精力做一件事，这点是毫无疑问的。当多事务并行处理时，人不是电脑，状态切换再集中精力处理新的事务，难免会浪费不少时间，有的时候还会影响心情。（老是被打断，这件事啥时候能做完？）

避免干扰绝对是一个很爽的工作模式，每个人都处于这种high模式下，工作才会越来越高效。

因此我们思考的第四个催化剂是“如何尽量保证每个人集中精力做一件事？”

3.4.1 研发和测试的同甘共苦

只要是两个人合作，就有可能存在干扰。一般来说，同一种角色间的合作算是比较容易的，因为理解的背景，描述的方法都比较接近，大部分情况下可能只是几句话就能结束沟通。对于不同角色间的合作呢？

设计、研发、测试三者的合作是非常频繁的，然而角色的立场，背景，沟通方法都会有自己的特色，他们之间的合作会有哪些困扰？

两个典型的场景：

[场景一]测试：有个问题请帮忙确认一下

研发：手里有点事，能等会不？ 

测试： 。。。

[场景二]研发：这个问题挺重要的，能借用一下测试线不？

测试：不行，我还有n个用例要测试，日志和问题单都给你了。 

研发： 。。。

上述场景中，研发或测试的工作被堵塞，要么等待，要么切换到新的工作中，无论哪种都是非常低效。

同一种角色间的干扰，不同角色间的干扰，这些因素频繁的打断我们的工作，不胜其烦，有什么方法能避免么？ 统一团队是否可以避免干扰？

3.4.2 上游团队主动协助下游团队，双赢

统一团队打破了角色间的隔阂，让所有角色有清晰统一的业务愿景，彼此之间的立场是一致的，这有效减少了角色间的摩擦。

然而不可忽视的一个细节是，隔阂的消除也让下游角色对上游角色的反馈更加频繁，不同角色间的沟通是相对比较耗时的，这种频繁的耗时会让我们难以进入状态。

对此，我们思考的解决方法是“安排一名需求设计师协助研发团队，安排一名研发人员协助测试团队”

在案例中，我安排一名TL（研发）组织测试团队工作。作为一名比较出色的组织沟通型研发人员，对于测试团队常提出的问题或咨询，都能完好的覆盖，同时该TL能对重要的问题快速给出意见或主动寻求帮助。

该实践的效果，研发人均编程效率翻倍（同时自动化覆盖率也远超平均水平），测试人均完成测试例翻倍（2个/天->5个/天），测试人均发现的有效问题缺陷值翻倍（大量无效问题直接和TL沟通就解决了，原来这些无效问题会浪费研发和测试大量沟通时间）。

3.5 总结

高效的团队,一般经验老到,对方向有敏锐的直觉。我们的团队经验不足,但是可以从小事做起,把小事情作对,积少成多,同样能保证大方向正确。

高效的团队,对代码驾轻就熟,保质保量。我们的团队半桶水,但是我们的代码从第一天就是用自动化工具覆盖,同样保质保量。

高效的团队,彼此知根知底,几句话就能把问题搞定。我们的团队全是新人,但是我们有一个固定的高效沟通同伴:TL,同样能让问题快速解决。

高效的团队,即便是再多事务并发,也能来回切换,游刃有余。我们的团队参差不齐,但是我们能创造一个优秀的环境,让每个人集中精力做一件事,状态爽才能效率高。

经过细节催化,我们新人团队同样是高效团队!

4、案例启示 

敏捷的推广经常会遇到思想的阻碍，组织架构的阻碍。当我们暴力破除，强行将各种角色组织在一起推行敏捷实践时，往往适得其反。角色人员无法到位，彼此之间干扰加大，此类种种让大家的体验极差，敏捷推广的效果也就越来越差。

体验是一个极其重要的因素。我们需要在敏捷实践和组织架构之间寻找平衡，在不对团队产生重大冲击的情况下，逐步提升团队的体验，让团队自发的破除思想的阻碍、组织架构的阻碍。

本案例主要启示如何让细节成为催化剂，从效率方面提升团队的体验。

而其要点是：

• 确保团队在正确方向上前进，让团队更加自信；

• 培养自动化意识，让团队自发验证；

• 高效沟通让团队更加凝聚；

• 避免干扰让团队心无旁骛。

当团队体验到效率迅速提升时，其自信心不断增强，对敏捷实践更有把握，角色间的障碍也在悄然消失。