待办列表的份数和多面学习：2）职能团队和组件团队

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

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

本篇为系列之二：职能团队和组件团队

在这篇文章中，我们将来看职能团队和组件团队的结构，探索它们待办列表的相关动态，以分析其对敏捷性的影响并找到优化敏捷性的杠杆。

职能团队负责诸如分析、设计、实现和测试之类的职能工作。组件团队负责各个不同组件（比如组件A、B和C）的实现。每个团队有自己的工作和优先级，也就是有自己的待办列表。交付价值需要多个待办列表里的工作，而且这些工作是相互依赖的。

为效率增加待办列表

让我们退后一步先来问这个问题 – 为什么会有更多的待办列表，答案是在基于效率的思考方式。

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

存在一个显式或者隐式的效率目标，由此产生效率差距，导致待办列表的增加。待办列表越多，专业化程度越高，效率越高，从而缩小效率差距。
相关地，更高的效率会带来更短的单元处理时间（用于处理本单元 – 某个职能或者组件 – 工作的时间），进而得到更短的周期时间。然而我们需要理解单元处理时间占到整个端到端周期时间的比重，以看到全局。

对周期时间的“意外”影响让我们来看更多影响周期时间的因素。

在上半部分，待办列表越多，集成件数越多，集成时间越长，进而端到端周期时间也越长。

在下半部分，待办列表越多，同步程度越低（不同的部件在不同时间被做到），因此：1）返工量越多，返工花费的时间越长；2）等待时间越长。两者都进而导致更长的端到端周期时间。

尽管多份待办列表也许会带来更短的单元处理时间，许多别的因素却对整体周期时间产生负面影响。在整体周期时间里，单元处理时间经常不是最为显著的部分，而等待和集成时间占据了更大比重。这样一来，多份待办列表将导致更长的端到端周期时间。

对效率的“意外”影响让我们回到效率。根据我们之前的分析，是效率目标驱使我们有更多的待办列表。现在我们来看由此产生的对效率的意外影响。

协作水平是一个常被忽略的因素。那些单元 – 职能或者组件 – 并不是独立存在，而是需要相互集成。集成要求与其它团队协作，因此协作水平既影响时间又影响效率。让我们来看几个对协作产生负面影响的动态。

R1回路：过度专业化损害协作

更高的专业化程度导致知识广度变窄。知识广度对于协作起到重要的作用。事实上，协作者之间知识上的重叠有利于相互理解。狭窄的知识广度一方面降低了效率，从而形成R1回路；另一方面对集成时间产生负面影响，进一步拉长端到端周期时间。

R2回路：本地标签损害协作

更多的待办列表导致本地标签变强，本地标签意味着我们组只做这个职能或者组件的工作，而且也不允许其他组触碰这块工作。这些就是职能和组件的竖井，损害到协作。它既降低效率，从而形成R2回路；又使集成时间变得更糟，进一步拉长端到端周期时间。

另一个动态来自于返工，它对效率产生负面影响。

R3回路：返工损害效率

不同的待办列表导致低的同步程度，而异步的情况会带来更多返工，从而降低效率。这样就形成R3回路。
整体而言，B1回路的目标是增加效率，但它在协作和返工上造成了意外的后果。B1回路和R1-R3回路一起形成了“饮鸩止渴”系统基模的动态。同时，这些影响也损害到端到端周期时间。

多面学习以减少待办列表让我们接着来看如何驱动待办列表的减少。

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

待办列表越多，专业化程度越高，知识广度越窄。然后狭窄的知识广度又成了需要更多待办列表的原因，这样就形成增强的R4回路。这个回路很容易工作在往更多待办列表的方向，我们如何能将它反转？

还是一样的增强回路，但是让它这样工作 – 待办列表越少，专业化程度越低，知识广度越宽，然后就可以有更少的待办列表。。。这里的挑战是降低专业化程度并不会自动带来更宽的知识广度。我们需要多面学习以增加知识广度。

更少的待办列表会驱动多面学习；而多面学习又让我们可以有更少的待办列表。它们之间互为促进。因此，待办列表的份数本身就是一个重要的杠杆 – 通过创建一个真正的跨职能和跨组件的特性团队来拥有一份待办列表。
我们多面学习些什么？这里的待办列表是基于职能和组件的，因此我们需要跨职能和跨组件学习。

都有哪些技术可以让我们跨职能和跨组件学习？以下是一些广为所知的技术列表，其中不少也被定义为LeSS指南。

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

总结起来，职能团队和组件团队相关的待办列表是为了效率，但是它们对端到端周期时间造成了意外的影响，更糟的是，它们也损害到效率本身。多面学习能减少待办列表，而更少的待办列表又能驱动多面学习。