全功能团队 - 数据篇

在《建设全功能团队》和《建设全功能团队——实践篇》两篇文章中，我的同事胡凯曾介绍过建设全功能团队的必要性和良好实践，此后在围绕这一话题的讨论中，很多人都分享了自己的理解，或看好，或看淡。在 ThoughtWorks 有许多团队一直在建设全功能团队方面实践着，在这篇文章中我希望与大家分享我从这些团队收集到的过去一年来的数据，以及更切身的理解。

简短回顾

全功能团队

它不仅是由一专多能的多面手成员组成的软件开发团队，而且是所有成员共同分担职责的团队。团队中的各项职责不再与具体的人员耦合，每一个人都有可能做并且有能力做超过一种传统角色所做的事：例如在某个时刻，开发人员在做测试，测试人员在做业务分析，业务分析人员在做部署；前端开发、后端开发、数据库维护被开发人员一视同仁；所有的人都能与客户沟通，也承担着只有传统的项目经理才闹心的项目风险。

来自软件开发业界的质疑

在关于全功能团队的讨论中，最激烈的质疑集中在能力和效率两个方面：

• 从效率上看，除非团队小得可怜，分工是必然的：团队成员频繁地转换工作职能，就意味着要不时地做点不是特别熟练的事，这是否降低了效率呢？比如，重复性高的测试工作虽然入门简单，但一个传统开发人员也需要一些时间的经验积累，才能替代专职 QA，做到快速且高效地测试；又是不是应该找专人来做部署呢？
• 从能力上看，分工似乎是必需的：让业务分析人员明白代码实现是不是有必要，会不会强人所难？开发人员有较强的代码和业务阅读能力，但是否同样具有同样水平的测试用例设计能力？即便是多面手团队具备的技能深度也是有限的。

带着这样的问题，我们在过去一年里用实践里证明了全功能团队的可行性，并在团队成员培养和项目可持续进展上都受益不少。

我们怎么做到的

针对效率问题

对效率的通常考虑方式源于工业化生产，认为分工后的重复性工作能提高劳动熟练度，从而提高生产效率。但是，知识工作不是流水线上拧螺丝，它的核心问题是效果 (Effectiveness) 而不是效率 (Efficient) 1。通俗地说，打字最快的不一定是好程序员，100 行代码也不一定比一行代码更有价值。所以，对有价值的软件开发者而言，真正重要的是知道要做什么、为什么、怎么正确地做到。

全功能团队中，我们让成员做不同角色的职责，就是要打破知识壁垒，让大家都站在不同的角度看我们的软件，传递知识、扩展认知；等再回过头看自己原来做的“本职”工作时，从其他角色的角度得到的知识会帮助我们用更正确方式地做对的事。同时，培养多面手团队成员的益处也在于，可以按需调整做某件事的人数或安排人员的替补，这对团队的人员利用率提升是很有帮助的。

我们这样做：

• 我们不为前端开发、后端开发和运维工作划分岗位，要求所有开发人员接触到所有层次的代码和环境。有了全面的了解之后，再没有人“因为没做过所以不敢碰“，所以接下来就是提升各自能力来把事情做得更好了。
• 我们每两周轮换做测试工作的成员。做测试人员期间，他会测试开发完成的功能以及回归测试各个组件，这有助于他了解系统的整体行为；同时他带去了自己的开发经验，不仅能在外部功能层次测试，还能深入代码挖掘，比专职的测试人员更能找到潜在的缺陷。
• 我们的业务分析人员要计划每次部署和安排部署前的回归测试，对待部署的功能须十分清晰；他们要为每个待开发功能准备全面的验收条件，甚至写出验收测试描述 (Given/When/Then)2，这样的用户故事可读性非常好，因为验收测试可直接拿来与客户或开发人员交流。
• 我们没有固定的人与客户做接口沟通，所有的轮值测试人员都需要向客户展示完成的功能以确认验收，所有的人都有义务向客户询问疑难的需求，所有的人轮流做迭代报告或主持回顾会议。
• 所有项目上的信息都在团队内共享，结对编程也 2、3 天一轮换，这减少了团队成员的上下文盲点，便于各人迅速定位并正确处理问题。

针对能力问题

对能力的担心是可以理解的：对不熟练的事甚至头一次做的事，谁都不能很有把握独立做到；每个人的技术能力是有限的，职责的切换意味着挑战来临。然而这是一个团队，没有人孤军奋战，也不会安排成员做登天的事。

全功能团队在能力问题上重视的是团队成员的成长和项目的可持续进展。培养成员逐渐胜任某项新职责是对他能力的拉伸，只要方法得当，团队就会平稳地在几个月后收获一批一专多能的多面手成员。而这种成长也不是以暂时牺牲项目进展为代价的，项目和人员成长不站在对立面。

我们这样做：

• 将职责和个人去耦合之后，提炼出若干职责，如业务分析、测试、前端开发、数据库维护、部署等。
• 我们为每项职责找出领导者，称为教练。教练是某一职责上的专家，如测试教练，他是测试工作上能力最强又所知最多的人，由他来辅导测试技能尚需锻练的人，通过结对的方式面授机宜，帮助他适应“新角色”的工作。
• “新人”成长后，教练会跟踪其工作的进展，并只在复杂情况下才伸手帮忙，如某些紧急应对。教练也担负者第一时间响应客户疑问的责任，他们是客户与开发团队关于某方面工作的接口，客户知道想要跟踪某项工作的进展情况，只要联系他即可。
• 某职责上的教练也常是其他职责上的“新人”，他也需要被帮助，需要同样努力胜任新职责。
• 从项目的可持续进展上看，全功能团队能够轻易地克服人员短板，并保持很高的团队凝聚力。因为团队里都是多面手成员，且大家保持了非常频繁交流和信息共享，各个人即便相互替换位置来做事情也很容易。

我所在的团队里，有很多事都是其他非全功能团队无法想象的：

• 没有专职的测试人员和部署人员，所有人都有能力做开发、测试和向产品环境部署，即便是才加入团队半年的大学毕业生，也能独挑这副担子了。项目的缺陷和交付进度依旧保持平均数目，并未出现由于没有“专职”人员而导致的不“专业”。
• 从不因为某人的突然请假而阻碍某件工作。这得益于多面手成员们每天充分的信息共享和结对工作，任何一个人请假了立即有人能顶替他做好职责。
• 从项目中移出成员比较容易，不会因关键人物的离开导致项目遇险。四个月前，当时做业务分析兼项目经理的女同事突然得知怀孕需要休假，我们也只做了简单的交接，就完成了这次人员变更，并保持了平稳的项目交付能力；如今这项职责早已向另一成员成功交接。

用数据说话

问题 1： 没有了专职测试人员之后，系统新增功能的缺陷数目是否显著增加呢？

答案：没有。图 1 显示的是我所在的项目过去一年半内的缺陷数曲线。竖线标示的是自 2012 年 7 月 1 日起，团队取消了专职测试人员，以两周一轮换的频率让所有开发人员轮流做测试。由图可见，这个实践开始之后的缺陷并未较之前显著增加，7 月初和 10 月初两次重大发布仍然是影响缺陷曲线的最重要因素。

图1 取消专职测试人员前后的缺陷数曲线

问题2：全功能团队中的成员角色切换甚至人员变更较频繁，有没有对项目的交付进度产生严重影响？

答案：没有。图2 是我所在的项目近一年来的团队人员变更情况与交付速率曲线的对比，这里的交付速率数值仅包含具有业务价值的用户故事卡的点数，而其他的如技术卡和缺陷卡的工作量是单另进行统计的。在2012 年7 月到8 月这段时间内，团队的成员调整的较频繁，同时伴随成员调整，各人的角色也在调整，参照交付速率曲线来看，在这段变更时期以及之后的适应期里，团队仍然保持了如以往的交付节奏和速度；交付速率曲线上在1-4 月、4-7 月、7-10 月体现出的冲高而后渐落的变化模式，也与项目在4 月、7 月、10 月的三次重大新功能发布相契合。前文图1 也参证了在7 月到8 月这段时间里，项目的缺陷数目并未显著爆发。所以我们观察到的是项目交付进度未受影响。

图2 团队人员变更与交付速率按月对比

问题3：全功能团队强调一人多用，那它真的比普通团队的人才利用率高吗？

答案：是的。图3-1, 3-2 是在 ThoughtWorks 西安办公室做的一次关于各人所担任过的团队职责的调查结果。来自包括我所在的团队在内的几个团队共 38 人参与调查，他们自认为的本职角色大多为开发人员（78.9%），具体的本职角色统计如图 3-1 所示，角色比例与业界数据 3 相去甚远。但他们在团队中做过的职责都不止一个，如图 3-2 所示，以人数所占比例最高的开发人员为例，他们中 77% 的人做过测试工作，23% 的人做过项目管理，30％的人做过业务分析，40% 的人做过运维。从数据可见，全功能团队中不易出现因为某角色人员的缺席导致的交付阻塞，因为其他角色的人可以转换职责来代替缺席者。建设这样的团队对多个团队之间共享人才、提高公司整体人员利用率会有帮助。

图 3-1 所有参与调查者职位的分布比例

图 3-2 参与调查者所担任职责的调查结果

结论

从我观察到的 ThoughtWorks 全功能团队的实践以及收集到的数据来看，建设全功能团队在中小型项目里能顺利进行。我们按照良好实践所做的尝试和努力，让项目、个人以及公司都受益了。那些来自软件开发业界的忧虑，从本文谈及的实践以及数据来看也应该释然了。

注解与参考

1. Peter Druker,
2. Uncle Bob’s post , Nov 2008
3. 通过招聘网站估算出的数字，如果需求是基本平衡的，市场所提供的职位数量比例与相关从业者的比例应当基本一致。对某主流招聘网站 IT 板块进行搜索得到：35000 开发职位，14000 测试职位，12000 分析职位。

感谢张凯峰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。