待办列表的份数和多面学习：3）特性组

待办列表的份数和多面学习系列的四篇文章包括：

1. 看见待办列表
2. 职能团队和组件团队
3. 特性组
4. 专业特性团队

本篇为系列之三：特性组

在这篇文章中，我们将来看职能团队和组件团队结构的一个变体 – 特性组。我们将重温职能团队和组件团队的动态，来看就对敏捷性的影响和杠杆而言特性组与之有什么相似和不同。

特性组也叫特性项目。它被创建用来交付客户价值，由来自各个职能和组件团队的人员组成。每个成员有自己的工作和优先级，也就是有自己的待办列表。与职能团队和组件团队结构一样，交付价值需要多个待办列表里的工作，而且这些工作是相互依赖的。两者之间的差别在于这些待办列表是由职能团队和组件团队负责，还是由特性组里的职能成员和组件成员负责。

特性组让我们从职能团队和组件团队结构的因果回路图出发，来理解它如何在特性组的上下文里工作。

个体责任
特性组成员承担对职能或者组件的个体责任，从而有多份待办列表。为什么这样做呢？

B1回路：专业化以获取效率

职能或组件的专业化对效率有利。特性组里的专业化是基于成员而非团队，但背后是同样的效率思考。

这减弱了特性组的共同目标，就可能会产生以下动态。

R2回路：本地标签损害协作
特性组成员仍然保留他们在职能或组件上很强的本地标签。这将损害到协作，从而导致：1）集成工作量增加，进而更低的效率；2）集成时间增加，进而更长的端到端周期时间。

特性组可能减少竖井的思考方式，因为特性组可以在本地标签之上形成一个共同身份，有点象这样 – “你属于这个’团队’（特性组），但是你仍然只做你专业里的工作”。

周期时间

在职能团队和组件团队结构中，相关的部分可能会在不同的迭代里完成，因此，端到端周期时间可以长达几个迭代。然而，特性组应该有在同一迭代里交付客户价值的目标。在这种情况下，各个部分的同步程度会得到改善，等待被限制在一个迭代之内，从而最长的端到端周期时间将会是一个迭代。这也减轻了以下问题。

R3回路：返工损害效率

异步带来的返工仍然存在，但是随着同步程度的改善，由此导致的返工量也会减少。

专业化

R1回路：过度专业化损害协作
过度专业化在成员有各自的待办列表（B1回路）的情况下无法得到缓解。由此导致各自狭窄的知识广度将继续损害协作，并产生对效率的意外影响。
除此之外，动态的需求会使在各个职能和组件上需要的工作量随之改变。这带来另外两个动态，在下面更新了的图中呈现为R5和R6回路。

当成员有自己的待办列表（B1回路）时，工作量的改变会导致：

1）部分分配
一些成员将工作于多个特性组，然后就有了多任务。

R5回路：多任务损害效率
待办列表份数越多，多任务越多，从而效率越低。多任务产生了另一个对效率的意外影响。

2）临时组
成员将动态改变，因此特性组就成了临时组。
R6回路：群组不稳定损害协作
更多的待办列表导致群组变得更不稳定。特性组由能够工作于各个待办列表上的人员组成。待办列表越多，群组的组成会经历越多变化。群组需要时间来磨合以达到高效，因此临时组会损害协作水平，并使改进难以持续。群组不稳定产生了另一个对效率的意外影响。

总结来说，职能团队和组件团队的主要动态和问题在特性组里依然存在，但是特性组可以有在同一个迭代里交付客户价值的共同目标，并作为一个组形成共同身份。因此，就敏捷性而言，特性组相比于根本没有组通常要更好。

特性团队

为了进一步改善敏捷性，在特性组里减少待办列表是一个关键的杠杆。事实上这是特性组和特性团队的主要区别。真正的特性团队只有一份待办列表，而团队成员为之承担共享责任。

R4回路：减少待办列表驱动广度学习

特性团队一开始因为技能限制也可能有多份隐性的待办列表，但是它通过只有一份显性的待办列表来驱动多面学习，以此逐步减少隐性的待办列表。相反地，特性组则选择接受现状，永远保持多份待办列表。
一份待办列表意味着消除部分分配和临时组的做法。动态的需求还是会使在各个职能和组件上需要的工作量随之改变，从而产生工作和技能的不匹配。当这种不匹配发生时，我们正好利用它来触发跨职能和跨组件学习。
还是同样的技术列表来帮助跨职能和跨组件学习：

• 实例化需求
• 集体拥有代码
• 结对/群体编程
• 实践社区（基于职能和组件）
• 组件导师/代码看护
• 现有架构工作坊
• 多团队设计工作坊

多面学习进一步减少待办列表，直到最终达到一份。到那时，特性组就变成了特性团队。