shinescrum.com

Scrum迭代开发、增量交付的开发方法建筑在Scrum团队之上，Scrum团队中的开发团队应当是特性团队，而不是组件团队。离开特性团队，Scrum就难以实现迭代开发、增量交付。深入了解组件团队的固有问题，准确理解什么是特性团队，对于指导组织转型至关重要。

什么是特性团队？按照Ken Rubin的定义，特性团队是一个跨职能、跨组件的团队，能够从产品待办列表中抽取并完成最终客户想要的特性。Ken Rubin的定义里谈到了“职能”、“组件”和“特性”三个名词，这三个名词分别是什么意思呢？

首先，应该准确理解“特性”。这个特性指从产品的最终用户的角度看，对最终用户有价值，最终用户能够感知到的东西。

第二、职能。比如UI设计、编程、测试，就是三种不同的职能。最终用户想要的某个特性往往需要多个职能协作，“跨职能”就是要求一个开发团队具备所有必备职能，而不需要依赖团队外部的职能部门。

第三、组件。当软件系统庞大、复杂时，通常把一个系统分解为多个组件。当这个复杂的软件系统由很多开发者共同开发时，传统组织通常把开发者按照组件分组。负责某个组件的这样一组开发者是这个组件的专家，他们熟练掌握自己负责的组件的相关知识，也只有这组人有权限修改、维护这个组件。

当一个最终用户想要的特性需要三个组件协同工作才能完成时，这个特性就是跨组件的。要开发这样一个跨组件的特性，就需要分别来自三个组件团队的开发者来协同工作。

举个极端的例子，Facebook的最初版本是扎克伯格一个人在大学宿舍里开发的。UI设计、编程和测试都是他做，他跨职能；网页界面和数据库都是他做，他跨组件。他一个人构成了一个最小的跨职能、跨组件开发团队，具备交付最终用户想要的特性的能力。当然我们不能期望每一位开发者都像扎克伯格一样是全才，但我们可以组建这样的团队，这个团队相对于某个产品，相对于从产品待办项中抽取的某个或某些特性，拥有必备的职能，拥有必备的知识和权限。这样的团队不需要依赖外部的力量就可以承诺并完成最终用户想要的特性。这样的团队就是特性团队。

以组件团队为主的组织难以实现迭代开发、增量交付。这是因为特性会因涉及到不同的组件而分散在不同团队中进行开发。每个组件团队对自己的待办列表有自己的优先级排序，多个待办项列表，优先级如何协调呢？众所周知，跨团队的协作比团队内部的协作更麻烦，需要更多的沟通成本。在传统开发方法中，只是在开发末期一次性集中交付，协调多个组件团队这个问题并不突出。但在Scrum中，每个冲刺都要协调，势必消耗大量沟通成本，而且难以保证及时交付。

以某传统组织为例，该组织按照职能划分组织结构，有UI部门、软件研发部门和测试部门。软件研发部门内部按照组件划分为多个团队，每个团队负责开发和维护一到多个组件。该组织每年平行开发的产品不下数十个。某产品采用Scrum开发方式，每3周一个冲刺，但团队结构仍然是传统的组件团队，于是经常出现这样的现象：软件研发团队把它放在最高优先级，UI设计团队把它放在最低优先级，在等待UI设计的时间里，开发者无事可做。等到UI终于设计完成，留给软件编码的时间就很紧张，程序员拼命加班还是无法完成。如果这个特性不仅依赖UI，还跨组件，问题就更多。各个组件团队有自己的开发任务优先级列表，有的组件更新好了，有的组件还没有更新好。临近发布截止日期，产品经理将当前的代码提交测试，测出很多缺陷也就无法避免。长期以来，这样的问题反复出现，严重困扰着软件研发团队，使他们面临极大压力。

管理层拷问，为什么还有这么多bug？要求分析bug产生的原因，提出预防措施。经过分析、总结，bug的主要原因来自两个方面：一是UI设计完成太晚，来不及编码；二是某些组件不稳定；提出的预防改进措施有2点：建议UI部门早点完成设计；建议其他组件团队提供稳定的组件。事实证明，这些建议从未起作用。

让我们从团队结构的角度重新审视这一问题。上述案例中的开发团队跨职能吗？跨组件吗？毫无疑问，答案是“否”。按照职能、组件划分的团队结构，容易导致各职能团队，各组件团队各自为政，协作较弱，难以按照特性对齐。所以，上述案例的问题，是团队结构的问题。

以特性团队为主的组织更容易实现迭代开发、增量交付。面对同样的情况，Ken Robin描述的跨职能特性团队应该这样开展工作：一名UI设计师，分别来自相关组件团队的几名软件开发者，一名软件测试者，结组形成一个7人左右的小团队。整个团队面对同一个产品待办列表，对于这个版本要发布某个特性，先完成UI设计，然后完成软件开发，最后完成软件测试。然后针对下一个特性，如此循环往复。特性团队，按照特性的维度协调工作，逐个特性开发，优先级自然向当前特性对齐。宁可一个冲刺少从产品待办列表中抽取几个低价值的特性，也要保证高质量地完成高价值的特性。这样就不会出现几个职能责任人的优先级对不齐，几个组件开发者的优先级对不齐的问题。对于大型产品，由很多人并行开发，则建立多个特性团队，并行开发多组特性。

全球已经有很多组织成功建立了跨职能、跨组件的特性团队，基于特性团队成功实施Scrum，为创新型产品的成长、成功提供了理想环境。以2012~2016年间的Facebook为例，他们的项目采用Scrum开发方法，开发团队的结构是：设计师加工程师。如果做一个简单的小功能，一般是一个设计师加两个工程师，比较大的项目，比如说改版、在新版开发两三个工，基本上两三个工程师一起做，也可能扩展到五到十位工程师。Facebook没有专职的测试员，工程师自己测。整个流程中，设计师和工程师互相合作，联系是非常紧密的。不同职能的人坐在一起讨论，有任何进展马上当面沟通。

综上所述，以特性团队为主的组织在实现“迭代开发、增量交付”方面有天然的优势，成功的Scrum组织应以特性团队为主。

一个组织的团队结构以特性团队为主，实现“迭代开发、增量交付”就会顺利。但同时，组件的维护、可复用性就会有问题。如果软件架构简单，这个矛盾或许并不突出。如果软件架构复杂，不同特性团队对组件的修改意见相互矛盾、期望完成修改的时间相互竞争，该怎么办呢？这就需要适当的混合组件团队，以协调维护组件的问题。一个组织的团队结构以组件团队为主，组件的开发、维护、可复用性就会顺利，但又难以实现增量交付，在不确定环境下的应变能力也不会那么强。所以，特性团队和组件团队到底哪种好，如果混合，以哪种为主，应视业务特点而定。强调业务不确定性强、灵活多变，需要增量交付，应以特性团队为主。强调业务基本稳定，组件、平台可复用，应以组件团队为主。