> 原文出处：http://www.infoq.com/cn/articles/full-function-team-about-data > 作者： 吴少博 在《[建设全功能团队](http://www.infoq.com/cn/articles/hk-build-full-function-team)》和《[建设全功能团队——实践篇](http://www.infoq.com/cn/articles/hk-build-full-function-team-practice)》两篇文章中，我的同事[胡凯](http://www.iamhukai.com/)曾介绍过建设全功能团队的必要性和良好实践，此后在围绕这一话题的讨论中，很多人都分享了自己的理解，或看好，或看淡。在[ThoughtWorks](http://www.thoughtworks.com/cn/)有许多团队一直在建设全功能团队方面实践着，在这篇文章中我希望与大家分享我从这些团队收集到的过去一年来的数据，以及更切身的理解。 [TOC] ## 简短回顾 ### 全功能团队 它不仅是由一专多能的多面手成员组成的软件开发团队，而且是所有成员共同分担职责的团队。团队中的各项职责不再与具体的人员耦合，每一个人都有可能做并且有能力做超过一种传统角色所做的事：例如在某个时刻，开发人员在做测试，测试人员在做业务分析，业务分析人员在做部署；前端开发、后端开发、数据库维护被开发人员一视同仁；所有的人都能与客户沟通，也承担着只有传统的项目经理才闹心的项目风险。 ### 来自软件开发业界的质疑 在关于全功能团队的讨论中，最激烈的质疑集中在能力和效率两个方面： * 从效率上看，除非团队小得可怜，分工是必然的：团队成员频繁地转换工作职能，就意味着要不时地做点不是特别熟练的事，这是否降低了效率呢？比如，重复性高的测试工作虽然入门简单，但一个传统开发人员也需要一些时间的经验积累，才能替代专职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](http://www.thoughtworks.com/cn/)西安办公室做的一次关于各人所担任过的团队职责的调查结果。来自包括我所在的团队在内的几个团队共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](https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd), Nov 2008 3. 通过招聘网站估算出的数字，如果需求是基本平衡的，市场所提供的职位数量比例与相关从业者的比例应当基本一致。对某主流招聘网站IT板块进行搜索得到：35000开发职位，14000测试职位，12000分析职位。

> 原文出处：http://www.infoq.com/cn/articles/hk-build-full-function-team-practice > 作者：胡凯 在[上篇文章](http://www.infoq.com/cn/articles/hk-build-full-function-team)中我们一起回顾了分工历史，对于技术团队影响以及建设全功能团队的必要性 ，在实践篇中我将详细分享一些实践以及我们团队的经验数据。 [TOC] ## 吃自己的狗粮 当开发人员坐在测试工作站前，你将会诧异于多少开发人员因为繁琐的步骤而不会安装/升级自己参与制作的软件，多少人认为自己设计的复杂配置是荒唐的。在很多情况下，这都不是安装、配置的问题，而是设计问题，将开发和测试过程分离把痛苦转嫁给了另一个团体（测试、用服、用户），开发人员丧失了亲身使用软件的机会，从而无法发现问题的存在。暴露并修正这些问题，是将开发人员和测试人员进行轮换的主要价值之一。从我们的经验数据看，开发人员可以在一周内掌握大多数的测试技巧，个人的建议是从经验丰富的开发人员开始轮换，一方面他们更能认识到测试的必要性，便于交流，也便于形成表率。另一方面丰富的经验更容易帮助他们察觉到问题的存在。其它的一些要点是： * 一对一的充分交流，让开发人员认识到进行测试工作的价值和目的。 * 引导开发对痛点进行思考、改进。改变测试简单、重复的工作面貌，要对开发人员形成挑战。 * 一周轮换2天持续数周或连续轮换2星期为宜。 ## 睁开眼睛看大象 开发人员习惯于正确性驱动，然而正确的返回结果却不一定是必须的，有时甚至是一种浪费。我们项目所需要处理形如1001的期货时间戳，10代表2010年，01代表一月份。开发人员自然想到了如何区分1910年、2010年、2110年的问题。于是复杂的内部表达被设计出来，用于推断正确年份。这是必须的么？如果我们能了解到客户最大的压力在于半年后项目能否成功上线替换掉现有无人能够维护的应用，而不是100年后才可能出现的问题，我们是否能在类似的技术决策中，做出更聪明的选择呢？帮助开发/测试角色获取更多的信息，让他们了解到制定需求的上下文，而不仅仅是需求是什么；让他们更高的层面认清各个故事之间的关联，能够分辨可以给客户带来最大价值的任务，这是将开发角色/测试角色与分析角色对换的主要价值。一些要点是： * 在进行分析工作前，开发人员需要完成多个模块的开发，而测试人员最好完成开发轮岗，否则收效甚微。 * 分析工作可以兼职进行，我们认为比较有效的方法是每天下午花40分钟让开发/测试人员在教练的带领有重点的分析一、两个故事。 * 重点放在提供一套思考框架帮助新手梳理分析思路，我们发现一个有效的方法是结对工作、独立思考、演讲并点评。（参见结对工作，不止与结对一节） 根据我们的经验，两周全程跟踪式的结对分析足够帮助新手初步掌握分析思路，教练可以考虑逐渐减少在新手思考过程中的侵入，再经过大概2个月的练习，新手基本可以独立工作。 ## 和客户对话 在进行过分析角色的轮换后，可以进一步利用需求管理作为主线让团队成员参与到客户交流中，慢慢削弱项目经理的客户联系人角色，其主要价值在于： * 提升交流质量，一线人员常常比项目经理更了解产品。 * 展示开发人员的能力，增强客户信心。 * 弱化项目经理在客户眼中的重要性，为未来平滑的取代项目管理者，减少开销作准备。 * 帮助技术人员掌握交流技巧、提升团队能力。 个人建议是： * 从例行的功能展示会（showcase）开始，让每个成员练习从客户的角度进行思考（客户想看什么？），锻炼语言能力，消除与客户交流的恐惧感，并且让客户熟悉开发团队的每个成员，习惯开发团队的交流方式。 * 由多人分别准备客户进行电话会议中需要讨论的议题，每人深入思考的一、两个问题，通过充分思考弥补经验、技巧上的不足。 * 结对完成发给客户的邮件，让另一双眼睛检查有没有把该说的问题点到，表达方式、方法是否得当。 * 提供一套与客户交流的思考框架，并在与客户的交流中不断强化它。我们采用的框架是“客户，交付，流程，员工”，团队成员在思考问题时，首先从这四个点出发再逐层展开。 这项练习需要贯穿项目始终，对于团队成员无差别的进行，我们的经验数据是经过5个月左右的练习，项目经理就不需要出现在与客户的例行电话交流中了。 ## 写程序，我行么？ 测试人员普遍编程技术能力欠缺，同时有常常对编程这一未知的经验产生恐惧。从经验看，如果测试人员不能编写、维护自动化测试，测试工作将很快成为交付瓶颈。通过编程，让测试人员掌握技术，避免瓶颈的出现是测试到开发角色转换的主要价值。我们所采取的步骤是： * 与测试人员结对完成简单的编码任务，不断树立信心。在这个团队中，我们从设计与实现自动测试框架开始，亲手设计的框架让测试人员更有能力来编写、维护测试，同时增强了编程的信心。 * 在测试人员消除了编程恐惧、具备编程基础后，安排测试人员与开发人员结对进行功能开发。 在这个过程中，必须首先要帮助测试人员正视编写程序的必要性以及消除恐惧，同时针对每天的工作内容留一些家庭作业效果也非常好。必须承认的事实是即便在完成轮换后，测试人员较开发人员还有一定距离，然而我们得到了一个意外的收获：进行过轮换后，再讨论需求时，测试人员越来越熟练的使用开发术语与团队交流，越来越多得参与讨论，甚至主导讨论，她开始直接引用核心组件的设计思想来推导测试用例，不断质疑和挑战开发人员，极大的提升了交流的效率和功能实现的质量。从经验数据看，大致需要3个月的时间测试人员可以达到在辅导下完成功能的程度。 ## 订最后一颗纽扣 前端开发有其独特的知识领域，但这并不意味着任何界面工作都要由前端开发工程师来完成。前后端的分离增加了开发过程中的瓶颈以及人员认知领域中”[Unknown Unknown](http://en.wikipedia.org/wiki/Unknown_unknown)”的区域，降低了找到更优解决方案的可能性。前端开发能力的培养特别适合在全团队中无差别的展开：让后端开发人员进行前端开发可以减少瓶颈，积累知识，构造“T”型知识区。测试人员需要测试界面，所以了解界面是如何工作，可以帮助她们设计出更高质量的用例，对于需求分析人员来说，高保真原型可以用作高效的交流工具。一个有效的方法是全面铺开，引入专家，重点培养，我们所采取的步骤是： * 要求全团队在业余时间完成一组界面练习，在全团队普及Html, Css和Javascript知识。 * 引入界面开发专家重点培养一名有兴趣进行界面开发的团队成员，对系统的界面结对进行改进，优化。 * 在界面开发专家的带领下，全员重新完成之前的界面练习，专家每天用一个小时讲解对应的前端技术并点评作业。 从全面普及知识到引入界面专家再到培养出新人，总共花费3周时间。值得一提的是，在整个过程中，由于之前团队建设的铺垫，其它成员有能力完全分担工作，团队重点培养的开发人员可以不受任何干扰，全职投入到前端开发中，最大程度的利用了界面开发专家的价值，提升了学习效果。 ## 上同一艘船 项目经理是和技术领袖是作为现场管理者存在的，他们必须能够理解现场，能够通过现场的痕迹找到团队的不足和改进方向。那么，没有什么比卷起袖子参与到一线的工作中更能帮助这些角色理解现场。形成对产品质量和进度的亲身体验。理解现场，有效的管理现场而不是管理数据，是这些角色轮换到开发，测试或者分析工作的主要价值所在。现场管理人员常常有太多的职责，既要对内负责也得对外负责，一个自然而然的问题是：”没有时间投入一线工作“。我认为现场管理人员的工作主要是两个部分：首先是职位责所赋予的管理性事务，譬如状态的汇报，客户的管理等；其次是能力所赋予的工作，作为团队中最有经验的成员，他们需要参与到需求分析、架构设计、决策的制定、培训等活动中。基层管理者应当有意识的主动的卸下身上的工作职责，完成到一线角色的转换，从另一个角度看，这个过程就是整个团队能力提升的过程，个人经验是： * 对职位责所赋予的工作，首先做到对团队的状态、开发的进度等尽量的做到自动化、透明化、可视化，让所有人都能获得这些信息，其次通过知识传递，把不涉及敏感内容的工作下放，重点培养一、两名团队成员参与管理。 * 对能力所赋予的工作，一是针对团队急需提升的能力组织培训，二是通过结对工作（参见结对工作，不止于结对）传递知识，提升能力，让团队习惯于自行决策，有意识的逐步弱化自己在团队中的重要程度。 我们的的经验数据是大约需要4个星期，新人可以在指导下正确的进行管理实践（正确的做事），这已经可以保证基层管理角色一定的参与一线工作的时间；而让新人具备辨别团队目前需要什么帮助（作正确的事），进一步将原有的管理角色基本弱化为开发角色，则需要6个月左右的引导和练习。 ## 结对工作，不止于结对 我完全认可结对工作在知识传递、提升工作正确性方面的作用。我们几乎结对作所有的事情，某种程度上结对工作成为一种文化，成为了思维惯性和一种必然。长期的结对工作让我发现目前的结对方式对于培养新人还不够友好，这里，新人所指代的是广义的新人概念，不仅仅指毕业生，刚刚从事测试工作的开发达人也算是测试新人。目前结对方式的的缺点在于： * 培养了思维惰性，心理上依赖于别人的带领。 * 无法从失败中学习。有经验的人常常会跳过很多陷阱，新人的工作经历全是各种成功，一旦独立工作就被这些陷阱打的措不及防。 * 只见树木不见森林。譬如在TDD的过程中，新手可以看到一个个的方法是如何被设计的，如何从测试中被驱动出来，但很难从他的搭档那里学会如何想到要设计这些方法？从下向上驱动还是从上向下，各有什么分别？为什么这个方法要被放在这个类，而不是那个？ 我认为结对工作其中一个被忽略的要点在于让新人在可控的状态下经历失败，获取经验，并且在工作中学会思考问题的方式（如何发现问题？从何处着手？怎么在不同的方案中取舍？从哪里开从哪里开始分析？），而不仅仅是思考问题本身（写什么测试？如何让测试通过？）。从我的观察看，培养新人比较有效的途径是从全程结对工作开始，通过对细节的指导让新人了解工作的主要方式和职责，进行必要的知识贮备，学会如何正确的做事。接下来应当让新人逐渐学会什么是正确的事情。我们的做法是： 1. 新人接到任务后，自行思考。 2. 在白板上写下完成任务的主要步骤 3. 向教练讲解主要思路和考虑点，教练通过提问引导他（输入特殊字符会怎样？） 4. 自行完善方案 5. 和教练一起确认方案 6. 教练对整个思考过程进行点评，告诉新人这类问题的思考要点 整个过程大致耗时半个小时，这种方式的优点是新人对方案非常了解，执行起来不容易跑偏；有机会在可控范围内犯错，成长更快； 新人可以通过不断的练习有能力通过多个任务逐渐总结出一套思维方式。教练利用这种方法可以通过代码检视和有选择的结对（譬如针对任务中的难度部分结对）同时帮助多人，更有效率。 ## 结局 在咨询的过程中，我见过太多的团队把目标放在交付上，冀希望于工具，外部力量能够快速的解决问题，往往对小步前进不够耐心，不关心团队的成员。在我们这个 90%以上成员没有.Net经验，50%是毕业生的团队中，那些微不足道的改进，一点点的提升，最终造就了这个9个月中没有一天加班，几乎没有缺陷，提前交付的项目，客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话：把项目目标放在人员能力提升，让项目成功成为能力提升的副产物。

> 原文出处：http://www.infoq.com/cn/articles/hk-build-full-function-team > 作者：胡凯 [TOC] ## 简介 团队的开发人员撇开需求沉浸在想象中的“完美”程序中；测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能；设计师造出了[没有尽头的楼梯](http://www.google.com/url?q=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FM._C._Escher&sa=D&sntz=1&usg=AFQjCNG7lGrcNeh9FRtAHJP4AEGmEB-2Dw)，更糟的是，客户爱上了这个设计；团队领导四处救火，力有不逮。种种迹象表明，我们得打破分工带来的壁垒，建设全功能团队——大多数人能完成大多数种类工作的团队。 在一次闲聊中，女友的母亲说起实习大夫必须轮岗一年才会进行分科学习，我质疑道：“对于致力于心脏病治疗的医生来说，他岂不是在不相干的学习上浪费了一年时间么？”，她母亲笑着说：“不这么作，你怎么确信病人的确患有心脏病呢？”。不知道为什么，我眼前突然浮现出这样的场景?测试人员在怯生生的询问：“这是一个缺陷么（而不是操作系统/浏览器的限制）？”。 ## 亚当与大头针工厂 亚当·斯密于1973年在描述大头针工厂的专业化生产时提出了社会分工的好处：提高熟练程度、减少任务切换时的开销、便于机器的应用。我们似乎可以非常自然得推导出重复设计、重复编码、重复测试可以增加相应岗位员工技术熟练度，提升效率，并由此提升企业的盈利能力。 然而市场的不断变化让重复生产的美梦不在，切换任务变得越来越频繁。IT公司不是大头针工厂，知识工作者毕竟有别与体力劳动者，在劳动主体发生变化的过程中有两件事情的差异被放大了：一是局部优化与整体优化的差异，二是正确的做事与做作正确的事情的差异。 有一道数学题，假设每个开发人员每天可以完成一个功能，测试人员每天可以测试2个功能，团队由3名开发人员和1名测试人员组成，那么一周内通过测试的功能最多为多少个？ 大多数人的第一反应是5（天）x2（功能/天）=10功能，下面的表格会告诉你，由于负载不均衡，测试人员在周一没有功能可测，团队其实无法在一周内交付10个功能。 | 人员  | 周一 | 周二 | 周三 | 周四 | 周五 | 总计 | |---|---|---|---|---|---|---| | 开发人员 | 3功能 | 3功能 | 3功能 | 3功能 | 3功能 | 15个功能 | | 测试人员 | 0功能 | 2功能 | 2功能 | 2功能 | 2功能 | 8个功能 | （表一） 那么我们改变一下条件，假设团队中有4个开发人员，并且开发人员可以参与测试，结果会怎样呢？ | 人员 | 周一 | 周二 | 周三 | 周四 | 周五 | 总计 | |---|---|---|---|---|---|---| | 开发人员 | 4功能 | 4功能 | 3功能 | 2功能 | 0功能 | 13个功能 | | 测试人员 | 0功能 | 0功能 | 2功能 | 4功能 | 8功能 | 14个功能 | （表二） 我们最终能够交付13点，产量提高了60%， 如果我们只留下三名全能人员： | 人员 | 周一 | 周二 | 周三 | 周四 | 周五 | 总计 | |---|---|---|---|---|---|---| | 开发人员 | 3功能| 3功能 | 3功能 | 1功能 | 0功能 | 10个功能 | | 测试人员 | 0功能| 0功能 | 0功能 | 4功能 | 6功能 | 10个功能 | （表三） 居然比3个开发人员和1个测试的人员组合还多交付两个功能！ 我们当然有理由质疑第二题的假设：“开发人员可以胜任测试人员的职位”。又或者继续讨论迭代二的数据变化。我对此的的回答是： 第一，以我的观察来看开发人员之所以不进行测试工作，不是能力不允许，而是主观上认为测试工作是简单、重复而枯燥的，不愿意作。客观上开发人员们比较贵也更难于培养，组织层面不允许这样的“浪费”。 对测试工作的偏见客观上促成了大量不具备技术能力的人选择测试工程师作为职业，而技能不足则一步导致了测试工作倾向于简单重复。测试人员在很大程度上无法判断什么是正确的事情（作正确的事），从而更倾向于熟练的按照脚本进行操作（正确的做事）。 第二，我的关注点不在交付8点还是10点，我希望这个例子能够引发大家对于[均衡生产](http://www.google.com/url?q=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduction_leveling&sa=D&sntz=1&usg=AFQjCNGOuESBwDz-XfPhqX3xRW-q49pwEQ)的思考。 软件的需求和实现可以被细化，但它毕竟不是大头针，需求和实现间往往呈现出关联与依赖，换言之，局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产（参考表三），即消除生产的波峰(过度生产)和波谷（生产不足），避免任务时松时紧，松时生产力浪费（周一时专职测试人员），紧时加班加点，粗制滥造。 我倾向于认为亚当·斯密对劳动分工论述的假设是：需求稳定，简单生产。对于IT领域来讲，这些假设还成立么？ ## 拧螺丝的卓别林 不难发现，对分工以及个体效率的迷信已经深刻的影响着IT领域。分工的端倪在招聘时就已经显现，即便对于差异不大的毕业生们，雇主也会根据其极有限的技能，用不同的标准进行测试(Java, .Net, PHP等)，并在入职后将其冠以前端工程师，后端工程师，测试工程师，支持工程师等不同的头衔，甚至可能在其可见的职业生涯中专门负责某个文件的维护。 整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。对于IT企业来说，变化从招聘时就必须开始。找到拥有学习热情、学习能力、学习习惯的人变成了当务之急，员工是否掌握了某种算法、语言或者工具应当从准入条件降格为对于其学习能力和热情的一种（不是唯一一种）证明。 整体效率的优化要求员工必须持续学习、成长，兴趣无疑是成长的催化剂，然而丧失意义的工作却在不断扼杀人的兴趣。丹?艾瑞里在怪诞行为学里著述到： 劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动，因此劳动者就无法对劳动产生认同或者领略到劳动的意义，而缺少了意义，专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色，一切都由工厂的齿轮控制，他们根本不会有全心全意工作的愿望 。 如果员工成长是必须的，那么，帮助员工认识到工作的全貌也是必须的。角色轮换是一个很好的解决方案。在项目内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。 在我看来，进行角色轮换的最大阻碍在于编程能力的普遍缺乏，大多数的测试、需求分析工作（鉴于大多数团队所处的地位，需求分析师实在言过其实，更精确的名字是需求整理师），迭代管理，简单的客户交流，学习曲线都非常低，任何成员都可以在师傅的带领下迅速掌握工作要点，然而编写程序却是个例外，即便对于基础良好的新人，在经验丰富的导师带领下，也需要2个月左右才可能写出比较体面的单元测试、较为面向对象的程序。在分工的体制下，用别的角色轮换开发人员几乎是个死局。 非常奇怪，IT领域如此的看重抽象能力和逻辑分析能力，可为佐证的是层出不穷的建模语言，模式，领域模型，架构。然而最能训练抽象能力和分析能力的一项活动，却仅仅有选择性的开展，这是不是意味着我们认为IT项目可以在大多数人无法（也没有能力）达成共识的情况下顺利展开并成功交付呢？在我看来，编写程序不仅仅是一项技能，一种思考方式，还承担着构造IT团队成员间共同经验区，提高交流效率的目的。 一个值得从其它行业借鉴的经验是首先展开基础素质培养，再进入领域培养专业素养，换言之，避免过早的分工，所有新人从编程开始职业生涯，在公司的体制层面促成每个新人都能经历力所能及的所有角色。在具有了一定的基本素质后，在员工对工作内容和自身兴趣有了充分的了解后，根据个人意愿进入领域发展专业技能，兴趣将成为员工成长的内在动力，而良好的基本素质将使员工有能力在专业岗位上施展自己的想法。 同时公司应当鼓励员工跨界工作，[《应用Selenium和Ruby进行面向领域的Web测试》](http://www.google.com/url?q=http%3A%2F%2Fwww.infoq.com%2Fcn%2Farticles%2Fdomain-web-testing&sa=D&sntz=1&usg=AFQjCNG2c_RNWLQPtk1Ft5i4sZVSdIq66Q)的作者是拥有卓越能力的开发人员，他曾经进行了相当长时间的测试工作，在其它人抱怨自动化界面测试难于维护时，他优秀的抽象能力、分析能力已经帮他提炼出测试模式，识别出缺陷，找到了优雅高效的工作方式并诞生了这篇优秀的文章。 丹·艾瑞所言于我心有戚戚焉。 ## 知行合一 在过去9个月间我们在团队中进行了建设全功能团队的初步实践，在分享具体实践前，我希望下面的总结性数据能帮助你获得一些背景知识。 项目处理的是期货交易领域，使用的技术栈是C#, ASP.NET MVC。团队主要由八名开发人员以及两名测试人员组成（其中一名测试人员在项目中期加入），其中4位是毕业生，3位具备工作经验，但刚刚加入Thoughtworks，只有一位开发人员具备.Net开发经验。 下面是全部35周的燃尽图，黑色实线代表项目的范围，绿色实线代表开发完成的速度，蓝色实线代表测试完成的速度，每周为一个迭代。  在这张图的大部分区域内蓝色和绿色是重叠或者非常接近的，这意味着团队每迭代开发完成的功能恰好与测试人员的处理能力对齐。一方面，这归功于测试人员自行实现的自动化测试框架对效率的提升，另一方面，开发人员参与测试也起到了平衡开发和测试速度的作用。 让我们截取开发过程的一部分，观察每个迭代的速度，在下面这样图中，横轴代表第几个迭代，纵轴代表每迭代完成的功能点数。  从项目经理的角度看，团队的交付速度很稳定，从15周开始直到项目的结束，我们都可以放心的使用12点每周的经验数据进行估算、计划工作。事实上团队在后期所处理的工作种类越来越多，包括了正常的开发任务、公式转换、性能调优、验收测试、支持等。在这种情况下，每个人都具备跨角色，跨模块工作的能力才保证了可持续的交付节奏。 在这篇文章中我们一起回顾了分工历史，对于技术团队影响以及建设全功能团队的必要性 ，在下一篇文章中我将详细分享一些实践以及经验数据。 **作者简介** [胡凯](http://www.google.com/url?q=http%3A%2F%2Fwww.infoq.com%2Fcn%2Fauthor%2F%E8%83%A1%E5%87%AF&sa=D&sntz=1&usg=AFQjCNFgmcGs8a_1lXcLYHZ7a-mDiaCBPw), [ThoughtWorks公司](http://www.google.com/url?q=http%3A%2F%2Fwww.thoughtworks.com%2F&sa=D&sntz=1&usg=AFQjCNHB9YewQuFGgdHhde6g02HyeQ6XtA)的敏捷咨询师，官方认证的Spring Framework讲师，近2年一直从事持续集成工具[Cruise](http://www.google.com/url?q=http%3A%2F%2Fstudios.thoughtworks.com%2Fcruise-continuous-integration&sa=D&sntz=1&usg=AFQjCNG-mKAJxtbeGyumDKE0BLSgwyorgQ)以 及[CruiseControl](http://www.google.com/url?q=http%3A%2F%2Fcruisecontrol.sourceforge.net%2F&sa=D&sntz=1&usg=AFQjCNFVB79oNtiSE5EO_cs1s0Ic9qXWaQ)的设计开发工作。 创造和参与了开源测试框架[junit-ext](http://code.google.com/p/junit-ext/)，以及用于分析[CruiseControl](http://www.google.com/url?q=http%3A%2F%2Fcruisecontrol.sourceforge.net%2F&sa=D&sntz=1&usg=AFQjCNFVB79oNtiSE5EO_cs1s0Ic9qXWaQ)构建的报表工具[iAnalyse](http://code.google.com/webstats/), 对于Web开发，敏捷实践，开源软件与社区活动有浓厚的兴趣，可以访问他的[个人博客](http://www.google.com/url?q=http%3A%2F%2Fiamhukai.com%2F&sa=D&sntz=1&usg=AFQjCNHGzWhZ4m205bSvCbmdPUlfYrvDVg)进行更多的了解。