有或没有共享组件团队

在许多组织里，有专门的团队来负责共享组件（平台和中台都属于共享组件）。同时会有多个业务/产品团队，他们都向共享组件团队提要求。下图显示了一种典型的情况。

与共享组件团队关联的最大痛苦是等待，由此导致更长的端到端周期时间。我们可以通过更好的优先级排序和/或进一步导入特性团队来改善这一情况。

优先级排序工作（有共享组件团队）

共享组件的工作通常没有独立的客户价值；它需要和使用这些共享组件的业务/产品中的特性工作集成在一起。因此，当优先级排序共享组件的工作时，我们自然会考虑业务/产品中相关特性的优先级。

实际上，来自更重要的业务/产品的请求通常都能得到优先级，因此他们遭遇到不得不等待的情况比较少。对他们来说，尽管有跨团队依赖，相关的工作还是能大致同步地被完成。然而，那些没那么重要的业务/产品就会遭遇到更多等待，有时感觉根本没有希望得到优先级。这合理吗？

假设有一份整体的待办列表包含了所有业务/产品，某个时候可能根本就没有来自于一些业务/产品的高优先级工作，因此他们在共享组件上相应地得不到优先级是合理的。但是现实情况是每个业务/产品都有自己的待办列表和人员。即使某些业务/产品没那么重要，他们自己还是会往前走。在这种情况下，不能从共享组件中得到任何优先级就会阻碍他们完成特性，从而造成在制品和浪费。那么，有什么更好的优先级排序共享组件工作的方式呢？

当业务/产品有着不同的重要程度但同时又有各自的待办列表时，他们之间不同的重要程度是如何反映的？实际上它是在显示了每个业务/产品人数的饼状图里。我们在优先级排序共享组件的工作时应当考虑这一信息。我们可以基于饼状图中的分布为每个业务/产品固定工作量，但这样就忽略了共享组件的特征 - 他们被多个业务/产品所使用。还能怎么做？

“购买特性”是Luke Hohmann设计的一个创新游戏，它放在这里很适用。我们基于饼状图中的分布为多个业务/产品分配虚拟预算；我们对备选需求估算成本。然后我们决定将哪些需求放入下个迭代。“在Solarwinds的增量LeSS导入”案例中有一个例子 - 参见“尝试……购买特性游戏，当你有许多利益相关方时”章节。如果玩这个游戏，业务/产品会有代表来协作决策。即使不玩这个游戏，我们还是可以在为共享组件优先级排序中使用这个模型。这个模型旨在对齐全局范围 - 也就是各个业务/产品和共享组件之间 - 的优先级，从而减少由于不同优先级造成的等待。

导入特性团队（没有共享组件团队）

尽管通过对共享组件进行更好的优先级排序有助于减少等待时间，等待的深层次原因则是技能和需要之间的不匹配。只要我们假设技能是静态的 - 人员被固定在专业领域，而需要是动态的 - 各专业领域的工作量会变动，等待就不可避免。根本的解决方案是导入更多的特性团队，由团队成员多面学习各种技能来匹配持续变化的需要。

需要注意的是采用特性团队的情况下仍然有共享组件。新的共享组件会涌现，已有的共享组件会演进。特性团队之间协作来让它发生。顺便说一下，这是Bas Vodde所提倡的关于最大化团队间的依赖；我也曾在一篇相关文章中写过这个方面。那么，我们如何摆脱共享组件团队并转向特性团队呢？

第一步是简单地把共享组件团队的人员分布到各个业务/产品团队。数量还是可以基于饼状图中的分布。假设在各个业务/产品已经有了部分（不包含共享组件的工作）特性团队，我们实质上是在扩展那些团队的范围。那些共享组件人员仍继续之前的协作，无论他们的团队身份发生什么变化 - 他们过去是在共享组件团队内协作，而现在则是跨特性团队协作。

然后，随着真正的集成在特性团队内进行，业务/产品成员和共享组件成员之间的边界变得模糊。与此同时，工作在共享组件上的人员也不再限于那些老的共享组件人员。

最终，我们不再需要在共享组件的层面考虑饼状图。只是特性团队作为正常生活的一部分来适应变化而已 - 随着优先级改变他们可能移到不同的业务/产品。

结论

在LeSS组织里，大多数团队都是特性团队，而特性团队会共享组件，却没有专门的共享组件团队。但是，因为大多数不意味着全部，而且特性团队导入是个渐进的过程，共享组件团队即使在LeSS组织里也可能存在。

当有共享组件团队时，我们还是可以改善它的优先级排序并逐渐缩小它的规模。饼状图提供了一个关于全局优先级的有用视角；它能帮助到优先级排序和特性团队导入。