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

待办列表的份数和多面学习:2)职能团队和组件团队
2020年2月5日
待办列表的份数和多面学习:4)专业特性团队
2020年2月6日

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

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

本篇为系列之三:特性组

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

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

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

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

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

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

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

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

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

周期时间

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

R3回路:返工损害效率

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

专业化

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

当成员有自己的待办列表(B1回路)时,工作量的改变会导致:

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

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

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

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

特性团队

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

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

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

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

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

长按识别二维码撩客服小优小姐姐

评论关闭了。