建设全功能团队

winston

作者: 胡凯  来源: InfoQ  发布时间: 2012-01-17 18:33  

　　简介

　　团队的开发人员撇开需求沉浸在想象中的“完美”程序中；测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能；设计师造出了没有尽头的楼梯，更糟的是，客户爱上了这个设计；团队领导四处救火，力有不逮。种种迹象表明，我们得打破分工带来的壁垒，建设全功能团队——大多数人能完成大多数种类工作的团队。

　　在一次闲聊中，女友的母亲说起实习大夫必须轮岗一年才会进行分科学习，我质疑道：“对于致力于心脏病治疗的医生来说，他岂不是在不相干的学习上浪费了一年时间么？”，她母亲笑着说：“不这么作，你怎么确信病人的确患有心脏病呢？”。不知道为什么，我眼前突然浮现出这样的场景?测试人员在怯生生的询问：“这是一个缺陷么（而不是操作系统/浏览器的限制）？”。

　　亚当与大头针工厂

　　亚当·斯密于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点，我希望这个例子能够引发大家对于均衡生产的思考。

　　软件的需求和实现可以被细化，但它毕竟不是大头针，需求和实现间往往呈现出关联与依赖，换言之，局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产（参考表三），即消除生产的波峰（过度生产）和波谷（生产不足），避免任务时松时紧，松时生产力浪费（周一时专职测试人员），紧时加班加点，粗制滥造。

　　我倾向于认为亚当·斯密对劳动分工论述的假设是：需求稳定，简单生产。对于IT领域来讲，这些假设还成立么？

　　拧螺丝的卓别林

　　不难发现，对分工以及个体效率的迷信已经深刻的影响着IT领域。分工的端倪在招聘时就已经显现，即便对于差异不大的毕业生们，雇主也会根据其极有限的技能，用不同的标准进行测试（Java, .Net, PHP等），并在入职后将其冠以前端工程师，后端工程师，测试工程师，支持工程师等不同的头衔，甚至可能在其可见的职业生涯中专门负责某个文件的维护。

　　整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。对于IT企业来说，变化从招聘时就必须开始。找到拥有学习热情、学习能力、学习习惯的人变成了当务之急，员工是否掌握了某种算法、语言或者工具应当从准入条件降格为对于其学习能力和热情的一种（不是唯一一种）证明。

　　整体效率的优化要求员工必须持续学习、成长，兴趣无疑是成长的催化剂，然而丧失意义的工作却在不断扼杀人的兴趣。丹·艾瑞里在怪诞行为学里著述到：

劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动，因此劳动者就无法对劳动产生认同或者领略到劳动的意义，而缺少了意义，专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色，一切都由工厂的齿轮控制，他们根本不会有全心全意工作的愿望 。

如果员工成长是必须的，那么，帮助员工认识到工作的全貌也是必须的。角色轮换是一个很好的解决方案。在项目内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。

　　在我看来，进行角色轮换的最大阻碍在于编程能力的普遍缺乏，大多数的测试、需求分析工作（鉴于大多数团队所处的地位，需求分析师实在言过其实，更精确的名字是需求整理师），迭代管理，简单的客户交流，学习曲线都非常低，任何成员都可以在师傅的带领下迅速掌握工作要点，然而编写程序却是个例外，即便对于基础良好的新人，在经验丰富的导师带领下，也需要2个月左右才可能写出比较体面的单元测试、较为面向对象的程序。在分工的体制下，用别的角色轮换开发人员几乎是个死局。

　　非常奇怪，IT领域如此的看重抽象能力和逻辑分析能力，可为佐证的是层出不穷的建模语言、模式、领域模型、架构。然而最能训练抽象能力和分析能力的一项活动，却仅仅有选择性的开展，这是不是意味着我们认为IT项目可以在大多数人无法（也没有能力）达成共识的情况下顺利展开并成功交付呢？在我看来，编写程序不仅仅是一项技能，一种思考方式，还承担着构造IT团队成员间共同经验区，提高交流效率的目的。

　　一个值得从其它行业借鉴的经验是首先展开基础素质培养，再进入领域培养专业素养，换言之，避免过早的分工，所有新人从编程开始职业生涯，在公司的体制层面促成每个新人都能经历力所能及的所有角色。在具有了一定的基本素质后，在员工对工作内容和自身兴趣有了充分的了解后，根据个人意愿进入领域发展专业技能，兴趣将成为员工成长的内在动力，而良好的基本素质将使员工有能力在专业岗位上施展自己的想法。

　　同时公司应当鼓励员工跨界工作，“应用Selenium和Ruby进行面向领域的Web测试”的作者是拥有卓越能力的开发人员，他曾经进行了相当长时间的测试工作，在其他人抱怨自动化界面测试难于维护时，他优秀的抽象能力、分析能力已经帮他提炼出测试模式，识别出缺陷，找到了优雅高效的工作方式并诞生了这篇优秀的文章。

　　丹·艾瑞所言于我心有戚戚焉。

　　知行合一

　　在过去9个月间我们在团队中进行了建设全功能团队的初步实践，在分享具体实践前，我希望下面的总结性数据能帮助你获得一些背景知识。

　　项目处理的是期货交易领域，使用的技术栈是C#, ASP.NET MVC。团队主要由八名开发人员以及两名测试人员组成（其中一名测试人员在项目中期加入），其中4位是毕业生，3位具备工作经验，但刚刚加入Thoughtworks，只有一位开发人员具备.Net开发经验。

　　下面是全部35周的燃尽图，黑色实线代表项目的范围，绿色实线代表开发完成的速度，蓝色实线代表测试完成的速度，每周为一个迭代。

　　在这张图的大部分区域内蓝色和绿色是重叠或者非常接近的，这意味着团队每迭代开发完成的功能恰好与测试人员的处理能力对齐。一方面，这归功于测试人员自行实现的自动化测试框架对效率的提升，另一方面，开发人员参与测试也起到了平衡开发和测试速度的作用。

　　让我们截取开发过程的一部分，观察每个迭代的速度，在下面这样图中，横轴代表第几个迭代，纵轴代表每迭代完成的功能点数。

　　从项目经理的角度看，团队的交付速度很稳定，从15周开始直到项目的结束，我们都可以放心的使用12点每周的经验数据进行估算、计划工作。事实上团队在后期所处理的工作种类越来越多，包括了正常的开发任务、公式转换、性能调优、验收测试、支持等。在这种情况下，每个人都具备跨角色，跨模块工作的能力才保证了可持续的交付节奏。

　　在这篇文章中我们一起回顾了分工历史，对于技术团队影响以及建设全功能团队的必要性 ，在下一篇文章中我将详细分享一些实践以及经验数据。

建设全功能团队——实践篇

http://www.acejoy.com/thread-4141-1-1.html