第5章 自组织：敏捷团队如何开展自组织？

上一章：第4章 启动：如何拥有敏捷思维？

经过上一章的学习，我们知道敏捷思维的培养要注重四个方面。本节课我们将学习敏捷实践中关键的一步——敏捷团队如何开展自组织。

敏捷宣言的原则中提到“最好的架构、需求和设计出于自组织团队”，所以在敏捷实践中需要构建自组织团队。

1.自组织团队

首先，我们要明确自组织是什么？

自组织团队也叫作自管理团队或者被授权的团队。管理层授权团队自己管理自己的工作过程和进度，并且团队通过自己的方式完成工作。也就是说，自组织团队并不是完全自组织的，自组织也是在一定的限制条件下的自组织，离开了这一限制，自组织也就无从谈起。

我举个例子，比如露营团队就是典型的自组织团队。大家一起去露营，需要有人搭灶生火、洗菜做饭及搭帐篷等，整个团队中每个人会的不尽相同，所以大家会根据自己的能力自发认领任务，或者帮忙打下手，这就是自组织的方式。在露营中，大家一般默认集体为重，每个人需要先完成集体的事情，再去做个人的，如果有人违反这个规定那么就自行退出，所以说自组织是有一定限制因素的。
关于自组织团队的详细介绍可参考：自组织团队：理念、实践与误区

1.1自组织团队应该做什么

还记得我们前面提到的跨职能团队吗？自组织团队往往就是跨职能团队，由拥有不同职能专业、思考方式和行为模式的成员组成，就像一个游戏团队，通常会有策划、美术、开发、测试、运营等。

对于自组织团队来说，他们需要做的是：

1. 自己分配任务，而不是等着管理层来给自己分配任务；
2. 团队自行考虑用怎么样的产品方案和技术手段来实现目标；
3. 团队自行制定需要遵循的行为准则。比如我们团队只有 3 条准则：开会自动交手机，迟到发红包，尽量不给别人“添麻烦”（即文档或代码自检）；
4. 团队需要向管理层随时报告进展和问题；
5. 团队成员自己管理自己工作内容，流转工作状态。

通常工具可以很好地帮助我们团队透明化，减少反馈的烦琐流程。比如在腾讯，通常使用敏捷项目管理工具 TAPD，它可以实时显示团队目前的工作状态，更方便自组织团队使用。

1.2传统团队：无变化，高效率

为了帮助你感知自组织的优势，我们再来看一下传统团队，这种团队一般是由经理领导。对于经理领导的团队来说，经理需要为团队成员分配任务，要根据任务合理分配有限的资源。团队成员只要关注自己的任务，按部就班地执行就好。另外，经理除了要确定目标、方向和组织结构，还需要监督和管理团队的过程和进度，这就要求经理的专业能力非常高。

这种团队的优点是，对分配任务和执行任务进行了专业化分工，资源能被最大化地合理运用。如果一直没有出现变化，那么这样做效率是最高的。

但现实中项目的推进往往伴随着变化，这就暴露了其缺点——应对变化的能力非常弱。如果人员变动比较大，例如请假或调动出项目组，或者是有大的变更需要占用现有的资源，那所有的资源就得重新安排；如果变动进一步变得频繁，那么这种分配的弊端就被无限放大，这就更能看出自组织的优越性。

回到我们的敏捷实践当中，在一个自组织开发团队内，产品负责人和敏捷教练为团队明确当下的工作目标，让其他成员清楚此次迭代要完成什么功能，自己要做些什么。团队在明确的分工下，每个人对自己的职责更加清晰并需要对自己的工作负责，也能保证完成的任务经过自检，从而不把质量问题留给下游。

总而言之，自组织团队和传统团队最大区别是管理者，即自组织团队中不会依靠某一个人决定所有的事情，团队要自己决定如何达成目标，而管理层只看最终的情况，不会事无巨细得关心团队推进的过程。

2.管理层如何组建自组织团队

根据前面的叙述，我们知道了自组织以团队为重，那么自组织团队就意味着不需要管理层吗？当然不是这样的。自组织团队不代表彻底的自由，而是在管理层的战略下，有约束的自由。在组建自组织团队时，管理层主要需要做以下这些事情。

1. 确定团队目标和愿景，让团队充分理解我们要做这件事情的目的和意义，比如我们斗地主项目就是让玩家畅快地对局游戏，所以我们需要让广大游戏玩家感受到这项游戏是好玩的，是畅快的，这是我们要做这个项目的意义。
2. 确定团队上下文，即组织结构、团队结构、团队组成，组织结构是服务于业务的，只有好的组织架构和绩效方式，才能让自组织团队保持高效。在腾讯，只要你是属于业务部门的，不管是产品、开发、测试和运营，都需要背负部分业绩 KPI，这样做的好处是让团队能有共同的驱动力，激励他们为了同一个目标而努力。
3. 提供环境和支持，主要是安全感、良好的团队空间、氛围和技能辅导等。我们给团队安排最近的位置，在晨会的地方竖立电子看板墙，必要的时候占会议室，把它改为“作战室”；不仅如此，我们从一开始就创建每个人都可以畅所欲言的开放氛围，并请外部教练帮助团队做敏捷转型。
4. 适当放权，给予团队自治权，让团队自我管理，比如每个人确定个人的工作任务、团队商议迭代周期等。管理层一般不插手团队的执行过程，只有当团队成员需要帮助时，才需要反馈给管理层，让其提供帮助。
5. 训练协作，管理层需要通过实操让团队“练兵”。给团队制造一些“意外”，让团队自行处理和总结经验，借此来锻炼团队应对“意外”的能力。阿里巴巴的 CTO，他会经常给系统来次“小惊喜”，比如叫人去机房拔网线，或制造大量的访问。通过这样不断地“练兵”，阿里团队面对各种突发情况也丝毫不慌。

3.自组织团队实践

通过上面的方式我们就能够建立起自组织团队，只有建立起自组织团队后才能够继续推进敏捷实践。那么基于自组织的前提下，我们接着需要做什么呢？那就是待办事项，也就是汇总未开始安排的任务，由自组织团队共同创建并维护。

3.1创建待办事项列表

通常来说，待办事项列表可以让我们把控项目推进的过程。在创建时，我们应该从团队的角度出发，以团队为衡量。列表要详细得将任务展示出来，所以应该包括任务详情，它的价值以及所需要的预估工作量。除此之外，列表是用来帮助我们推进项目的，所以列表中要将具体的执行步骤写清楚。综合这些考量，一个待办事项列表应该包含 ID 、类型、名称、价值、优先级、工作量和执行计划这些内容。

其中类型是根据其来源来划分的，通常是这三种类型：

1. 用户故事，即站在用户角度写的需求，通常由产品经理撰写；
2. 外网 BUG，即外网曝出的 BUG，通常来自数据或用户反馈，需要测试人员确认；
3. 开发任务，即开发人员撰写的任务，如数据库设计、系统重构任务等。

分类型可以帮助我们根据当前的主要任务，更快地选择相应的待办事项来完成迭代的目标。如我们这次迭代目标是解决大量外网用户的投诉问题，那么我们就在外网 BUG 类型里面选择待办事项。

在实际的工作场景中，我们具体是这样来做的。

团队进行讨论，明确需求的背景、价值，以及是否有现成的解决方案，进而确定是否需要纳入待办事项列表。然后纳入待办事项，我们需要填写如上图的 ID 、Type 、Name 和 Value 。

根据优先级对待办事项排序，待办事项的提出者要给待办事项加入一个优先级，我们填写在 Priority 列中，通常为 high 、middle 或 low。

对需求通过增加、删除、分解或合并进行整合。如果需求较复杂，我们需要关注它的完整性，尽量用一个需求来覆盖多个用户场景。如果可以拆分，就把需求拆成更小的单元，以便于更灵活地进行排期处理。我们把这个细化结果添加在它的 How to demo 列下面。

自组织团队共同对需求所需要的工作量进行估算，也就是每个人都要进行估算并给出意见。敏捷一般按照估算扑克来估算，当给出的估算值之间差距大于可接受范围时，估算数值大的人和估算数值小的人要各自陈述自己的意见，说明是什么原因促使自己做了相应的估算。通过这种方法，可 以让所有人都有机会发言，分享自己的想法，然后汇总得出大家都认可的结果，我们把结果填在 Initial Estimate 下面。

最后我们要发布这个列表，保证团队内外信息同步。这样，我们就完成了一个待办事项列表。

在做表的过程中我们需要注意以下几点：

• Detailed Appropriate ，即适当的详细程度。待办事项的每一项描述清晰简洁，明确该事项是为解决哪类用户的问题、我们需要做什么以及做的价值即可。
• Estimated ，即估算。待办事项要有一个大概的工作量估算值。值得注意的是，他与迭代计划的估算不同的是，这里的估算是只是负责人对工作的初步估算；
• Emergent ，即涌现，指的是允许随时插入新需求，自组织团队可以积极应对变化；
• Prioritized ，即考量优先级，指需要对每一个待办事项都排优先级，这样有新需求时，可以根据优先级进行比对，来确定放到表中哪个位置。

这个也叫做作 DEEP 模型，在完成列表后，我们还可以据此来衡量列出来的待办事项是不是合理。

3.2维护待办事项列表

创建完待办事项列表之后，团队就可以高枕无忧了吗？当然不是。因为敏捷的拥抱变化，所以待办事项列表是动态更新的，这样可以随时让团队知道最优先的功能是什么，始终在推进开发优先级最高的需求，也就是对用户最有价值的需求，具体该怎么维护呢？

比如，我们要插入一个新的待办事项即微信支付。

1. 分析：产品经理分析新的需求，确定是否放入待办事项列表中。如果确认可以则在表中新增一行，ID为 FE006 ，Type为 Feature（用户故事），Name 为微信支付 ；
2. 排序：放入之后，产品经理需要评估需求的价值，并进行优先级排序，此时，我们评估此待办事项的 Value 为 75，Priority [praɪˈɔːrəti] 为 High；
3. 理解：团队共同理解需求的描述。它的 How to demo 就是在用户选择支付时，可以选择微信支付来支付货款；
4. 估算：团队估算该需求的工作量，微信支付的Initial Estimate [ɪˈnɪʃl ˈestɪmət] 为 2 。
5. 更新发布计划：我们在待办事项列表中添加了微信支付，完成了列表的更新，我们就要向团队内外发布更新后的计划，做好信息同步。

每当我们遇到新的任务就可以按照上述例子来更新待办事项列表，在推进过程中，我们按照列表推进就会更加高效。

4.总结

本章我们知道了什么是自组织团队，以及自组织团队的实践：创建并维护待办事项列表。下一章我们将要学习如何建立一份好的迭代计划。如果你有敏捷管理方面相关的疑问，欢迎你在留言区留言与我一起讨论，本系列文章会持续更新，请关注博主以待后续。

下一章：第6章 计划：如何制定敏捷开发计划

​