跨职能团队

自20世纪80年代开始，跨职能团队被应用于包括丰田、尼桑、本田、宝马、通用汽车、福特在内的大型企业中。团队由来自不同部门、不同层级，甚至不同组织的员工组成，目标是在短时间内完成重要的工作项目，例如新产品开发，提升产品或服务的质量，提升组织效率。

1986年两位学者Takeuchi和Nonaka在“哈佛商业评论”发表的论文《新的新产品开发游戏》中也介绍了“异花传粉”的团队，即由具有不同的专业技能、思维过程和行为模式的成员组成项目团队。例如富士施乐公司fx -3500的多功能团队包括计划、设计、生产、销售、分销和评估部门的成员，有助于信息共享、沟通理解，多角度思考和决策，并激发出更多的主动性。

这篇《新的新产品开发游戏》通常被认为是Scrum的起源。
原文链接 https://hbr.org/1986/01/the-new-new-product-development-game

稳定及跨职能团队是帮助Scrum团队取得成功和高效工作的关键因素之一。跨职能团队具有更大的灵活性，能够更快地响应不断变化的需求，并能更好地处理持续的支持和维护。

在敏捷实施过程中使用。

前几年流行的全栈工程师可以说是跨职能团队的一种理想形式，每个人都可以做前端，后端，测试，UED，十八班兵器样样拿得起放得下。但是理想是丰满的，现实是骨感的，因此Mike Cohn表示，“也许敏捷中最普遍和最持久的神话是，跨职能团队是每个人拥有完成工作所需的所有技能的团队。这根本不是真的......跨职能团队的成员具有各种技能，但这并不意味着每个成员都具备所有技能”。

不管现实和理想有多大的差距，敏捷团队要尽量往跨职能团队努力，而且要尽量保持团队的稳定，只有这样才能保证团队的绩效能够持续提升。下面讲一下在现实的场景中，敏捷团队在达不到完全跨职能的情况下，如何运作才能保证敏捷转型能够坚持进行下去。

1、UED是共享团队
即使在大的互联网企业，团队中也很少有配备独立的UED人员，往往是一个大部门有一个UED小组，承接各个开发团队的UED需求。

1）对于这种情况，敏捷团队需要提前和UED团队提出需求，双方定好计划，以便双方的开发节奏一致。刷脸，施展个人魅力，死缠烂打往往是比较实用的招数。有人可能会说，不是应该制定严格的规则，进行优先级排序吗？说这话的人通常是没有经受过社会的毒打。
2）有的同学可能会说，敏捷团队可以自己先按原型进行开发，等UED出来后再作替换。由于UED团队往往会对原型作较大的改动，因此这种方案会造成后期前端工作有较多返工，因此在现实中一般不会被采用，前端同学宁肯等UED的效果图出来后再进行前端工作的开发。
3）还有一种方案是，UED团队先出一版草稿，即只将样式和交互定下来，供敏捷团队开发使用，象颜色，位置，大小等细节后面再深加工。这个方案很符合敏捷原则，但在现实中往往不会被UED团队所采纳，因为这会增加UED团队的工作量。有人可能会说，同一个部门的各个子部门之间不是要互帮互助吗？只能说这是大家共同努力的方向，但是很少有公司或部门能达到这种完美协同的状态。没有这么好的协作，就不进行敏捷转型了吗？敏捷转型就是在挫折和妥协中不断前行。
4）在实践中有一种方法是可行的，我在带团队的时候也采用过。即培养团队内的UED设计能力。但是这并不是要代替UED团队，而是进行有效补充。比如说对于一些简单的确定的小页面，由内部UED人员完成，而复杂的UED设计工作仍采用1）的方法交由UED团队完成。UED设计是有很多创意在里面的，不是一个前端或后端开发人员所有取代的。对于这种情况，UED的标准化工作特别重要，从如按钮大小，页面字体，颜色，对齐等等。
5）UED设计，当前流行的工具是蓝湖，产品经理做原型设计的工具一般用Axure。

2、团队中前端人员不足
在敏捷团队中虽然常常没有UED人员，但是前端设计人员确是会配备的。现在都是采用前后端分离的方式，前端只负责显示和页面交互，而业务逻辑基本上都由后端实现，前端通过接口从后端取数。

在实际工作中，后端人员一般能够保证，但是前端人员往往不足，这样便面临着一个问题：一个迭代内的用户故事，后端同学的开发工作完成了，而前端还没有完成，存在后端等前端的情况。这时怎么办？难道后端同学空闲下来等着前端同学？这是部门领导或项目经理绝对不会允许的，不管敏捷教练或管理大师有多好的理由。对于这种情况，在实际工作中有以下方法可以参考：

1）将部分用户故事进行横向切分，即分为两个子用户故事，一个前端用户故事，一个是后端用户故事。比如说一个迭代内规划要完成10个用户故事，当前的前端资源在本迭代内能够完成6个，而剩下的4个按上面所说有方案进行横向切分。当然这种切分方法是完全违背敏捷中的用户故事切分原则的，在实际工作中也是不得已而为之。
2）在团队内培养前端开发能力，即将部分人员往全栈方向发展，既会前端也会后端，这个是长久之计。一开始的时候可以制定一个培养计划，先从简单页面开始，将全栈能力逐渐建立起来。当然这个有一个前提，一是你所在的部门比较稳定，预计缺期内不会被公司裁掉。二是团队预计相对稳定，比如说半年到一年内不会被解散。
3）在大部门范围内协调前端资源：这一点听起来很好，但是在现实中执行起来很难，一是其它团队的前端资源往往也没有整块的时间可以投入到你的团队，只有一些零散的时间，二是临时加入的前端资源还要熟悉代码和业务，往往即使借调过来也很难起到很大作用。但是这不失为一个思路，可以尝试，在实际工作中大家也在这么做。
4）将尽可能多的工作往后端移，使前端尽可能的只是纯做展现工作，这样会减少前端工作量，缓解前端瓶颈。但是有时候会遇到性能问题，如果前端页面对于性能要求较高，有些显示逻辑在前端实现往往效率会更高。如何权衡，需要根据具体情况而定。
5）将前端同学的“杂事”尽可能分解出去，由别人承担。

3、团队中的各个成员只熟悉产品中的一两个模块
团队中各个成员只熟悉产品中的一两个模块，这个在大多数团队中都存在，造成这种情况最主要原因是团队迫于交付压力，往往会将需求交给最熟悉的人员去开发，这样效率无疑是最高的。

这个问题不解决，会造成敏捷团队内各人的工作不均衡，严重影响团队效率的提升，也会影响团队的工作氛围。在实际工作中可以采用以下方法：

1）还是往全栈方向发展，这个全栈不是指工作类型的全栈，而是指业务能力的全栈。一种方法是将产品的每个模块都设置A/B角，A,B两个人对这个模块都很熟悉，另一种方法是让团队中每个人对产品中的大部分模块都熟悉，做到一精多熟，即精通一个模块，对于其它模块也熟悉，也能承接开发工作。这个需要在团队内制定详细的能力提升计划，并在工作中安排学习时间，我在实际工作中往往在团队内每周安排一个小时进行业务和技术培训。
2）可以先从简单的需求开始，当然在安排工作时，要多给出一部分学习时间。例如张三同学熟悉A模块，现在有一个用户故事是B模块的，安排张三同学去做，如果正常时间是12个小时，则这次给张三同学16个小时，其中四个小时是学习时间。同时要给张三同学安排明确的导师，在开发中给予支持。
3）在实际工作中，我会在迭代计划中，让SM列出各个人在本迭代的工作量。对于工作量不饱和的同学，在会上引导说：“Scrum五大价值观中，有一个是勇气。现在希望有同学勇敢地挑战一下自已不熟悉模块的用户故事。“这时，往往会有人主动站出来，这个方法缕试不爽，可见每个人都有一颗骚动的心，只等着你去挑动。

4、敏捷团队成员经常变动

出现这种情况往往有两个原因：

1）团队成员中很多是外包人员，这个在制造业的IT部门存在较多。外包人员往往是按项目外包的，项目完成后则人员离场。对于这种情况，需要组织进行变革，将项目外包转为长包（象一些互联网企业，一些国企，一般采用年包制），这个变革是艰难的，需要敏捷转型人员付出持续艰苦的努力。如果组织短时间内无法进行变革，是需要将多个项目的外包拼接起来，使外包人员做完一个项目，然后进入另一个项目，形成一种事实上的长包，但这会花费产品经理很大精力。
2）团队是按项目组织的，项目结束后，团队人员就解散了。在实际工作中，敏捷教练需要推动组织由项目团队往特性团队转变，即敏捷团队是相对稳定的，可以承接来自各个方面的需求，这些需求有可有是来自于多个项目的，也可能是一些维护性小需求。对于团队而言，它不需要知道需求是从哪里来的，它所面对的是一个个的用户故事。当然由于团队可能同时在干两个项目的需求，还有一些线上Bug的修复以及维护性的小需求等，需要进行严格的代码分支管理，在此不扩展开讲，大家可以看一下代码分支方面的实践分享。

1、因为团队不具备跨职能特性，于是认为当前团队不具备敏捷转型的条件，又回到传统的瀑布模式；
2、由于团队资源不足，认为领导对敏捷不了解不支持，心存报怨，而不是面对问题解决问题。