全功能团队 - 数据篇

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

　　简短回顾

　　全功能团队

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

　　来自软件开发业界的质疑

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

　　从效率上看，除非团队小得可怜，分工是必然的：团队成员频繁地转换工作职能，就意味着要不时地做点不是特别熟练的事，这是否降低了效率呢?比如，重复性高的测试工作虽然入门简单，但一个传统开发人员也需要一些时间的经验积累，才能替代专职QA，做到快速且高效地测试;又是不是应该找专人来做部署呢?

　　从能力上看，分工似乎是必需的：让业务分析人员明白代码实现是不是有必要，会不会强人所难?开发人员有较强的代码和业务阅读能力，但是否同样具有同样水平的测试用例设计能力?即便是多面手团队具备的技能深度也是有限的。

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

　　我们怎么做到的

　　针对效率问题

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

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

　　我们这样做：

　　我们不为前端开发、后端开发和运维工作划分岗位，要求所有开发人员接触到所有层次的代码和环境。有了全面的了解之后，再没有人“因为没做过所以不敢碰“，所以接下来就是提升各自能力来把事情做得更好了。

　　我们每两周轮换做测试工作的成员。做测试人员期间，他会测试开发完成的功能以及回归测试各个组件，这有助于他了解系统的整体行为;同时他带去了自己的开发经验，不仅能在外部功能层次测试，还能深入代码挖掘，比专职的测试人员更能找到潜在的缺陷。

　　我们的业务分析人员要计划每次部署和安排部署前的回归测试，对待部署的功能须十分清晰;他们要为每个待开发功能准备全面的验收条件，甚至写出验收测试描述(Given/When/Then)2，这样的用户故事可读性非常好，因为验收测试可直接拿来与客户或开发人员交流。

　　我们没有固定的人与客户做接口沟通，所有的轮值测试人员都需要向客户展示完成的功能以确认验收，所有的人都有义务向客户询问疑难的需求，所有的人轮流做迭代报告或主持回顾会议。

　　所有项目上的信息都在团队内共享，结对编程也2、3天一轮换，这减少了团队成员的上下文盲点，便于各人迅速定位并正确处理问题。

　　针对能力问题

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

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

　　我们这样做：

　　将职责和个人去耦合之后，提炼出若干职责，如业务分析、测试、前端开发、数据库维护、部署等。

　　我们为每项职责找出领导者，称为教练。教练是某一职责上的专家，如测试教练，他是测试工作上能力最强又所知最多的人，由他来辅导测试技能尚需锻练的人，通过结对的方式面授机宜，帮助他适应“新角色”的工作。

　　“新人”成长后，教练会跟踪其工作的进展，并只在复杂情况下才伸手帮忙，如某些紧急应对。教练也担负者第一时间响应客户疑问的责任，他们是客户与开发团队关于某方面工作的接口，客户知道想要跟踪某项工作的进展情况，只要联系他即可。

　　某职责上的教练也常是其他职责上的“新人”，他也需要被帮助，需要同样努力胜任新职责。

　　从项目的可持续进展上看，全功能团队能够轻易地克服人员短板，并保持很高的团队凝聚力。因为团队里都是多面手成员，且大家保持了非常频繁交流和信息共享，各个人即便相互替换位置来做事情也很容易。

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

　　没有专职的测试人员和部署人员，所有人都有能力做开发、测试和向产品环境部署，即便是才加入团队半年的大学毕业生，也能独挑这副担子了。项目的缺陷和交付进度依旧保持平均数目，并未出现由于没有“专职”人员而导致的不“专业”。

　　从不因为某人的突然请假而阻碍某件工作。这得益于多面手成员们每天充分的信息共享和结对工作，任何一个人请假了立即有人能顶替他做好职责。

原文转自：http://kb.cnblogs.com/page/174631/