Scrum框架的自组织团队

飞行在天空中的鸟群一会排成一个“一”字，一会排成一个“人”字，它们自由飞翔，又根据不同的风向排列不同的队形减少阻力，达到最高的飞行效率。人类社会中也如此，没有一种不需要调整的通用方法可以适用于所有的工作场景，且经久不衰。

当面对多人协作的工作任务时，我们有必要找到一种有条理的、相互协调的方法来实现人力、任务的协同工作，不然就会陷入无尽的混乱。这种方法和组织可能会很复杂，而为了降低复杂性，我们可以将它的架构和流程都标准化，再依据实际情况进行调整。这个标准化过程就可以通过最佳实践或者延续企业文化发展来实现。

这种最佳实践是在特定的情境中发展的，以达到特定的目标，这样它就可能不适合给定的组织。在任意一种复杂任务的执行过程中，几乎不可能预测哪些常见的基本配置是最佳解决方案。这个时候，我们只需要一个符合既定目标的合适的开始；从这里开始，遵循“紧急情况”的指导。在这一点上，组织可以在适当的时间和形势的紧急要求下开发自己的最佳实践框架和过程。这些最佳实践成为确定的实践方法。然而，即使这些实用的方法通常会奏效一段时间；随着时间的流逝，它们不会永远存在。随着管理方法的改进和科技的进步，商业形势也发生了变化。相应的，团队可能会进入一个新的发展停滞期。

当被领导明确告知需要做什么时，员工会感到轻松，但这样的引导和控制也会导致一些后果。当员工为控制型管理者工作时，他们的工作动机和一些职场因素，如员工离职率和工作满意度，都会受到损害。

此外，执行任务的员工才是了解如何将工作做得最好的合适人选。当员工失去对工作的控制时，他们也相应地失去了提高效率、效果和质量的宝贵机会。例如，工厂工人可能自发地采取行动来提高工作效率或安全性。这种改进可能不是由管理者发起的。因为管理者对具体工作情况并不了解，也就无法意识到改善的必要性，更谈不上考虑改进了。

Scrum框架的自组织团队

研发团队成员通常拥有专业技能。利用团队成员的优势和差异来高效工作是有益的。但如果团队成员只在自己的专业技能范围内工作，任务进度可能会有所延迟，而不是更均衡的分配和发展。

所以研发团队自我管理、自我组织，才能把工作“做好”，可以由研发团队全权负责如何开展工作。

研发团队掌控日常工作的所有细节，比如开每日Scrum会议，决定新的任务和相关的负责人、决定工作项的优先级、决定如何组织集群工作、决定团队将如何利用研发团队成员在相关领域的专业技能和专业知识——这个过程可以包括决定如何在团队中一起工作。

值得说明的是，自组织对团队成熟自律的要求比较高，有些人在自组织团队中可能感觉不舒服。这时候组织的利益相关者，比如产品负责人（PO）可以直接提供帮助，或者Scrum Master认为他们知道谁应该接手相关的任务（Scrum Master不可以直接指派人去完成任务或者告诉开发人员如何工作）。即使一开始会很难，但是研发团队以外的成员需要通过自组织让团队学习。

取消明确的监督角色的一个危险是，团队中的另一个人可能担任同样的角色，从而通过施展魅力、盛气凌人或主导对话等方式将个人意志强加于团队。这种行为会让团队保持和以前一样的驱动力，没有任何改变。Scrum Master需要明白可能会出现这种情况，并通过行为建模帮助团队提高意识，从而保证研发团队的每一个成员都能有所贡献。这个互动过程将帮助团队建立指导方针。如果这种类型、或者任何其他会抑制自组织的行为发生，Scrum Master有责任帮助团队识别和消除障碍。当然，小团队和同一个地方的团队自组织是最容易的，因为后勤工作相对简单容易。

自组织模式是Scrum的核心实践之一。它使Sprint中的工作能够以最有效的方式进行。自组织可以提高研发团队的士气，也有充分证据说明还提高了绩效。有了自组织，研发团队相当于拥有了自愈能力，可以有效识别并改正错误。这是敏捷组织需要掌握的最重要的模型之一。

当业务允许研发团队自组织时，团队获得自由和相应的责任，这是打造信任型社区的第一步。一个拥有如何打造产品话语权的团队，对自己和产品的荣誉感会更强。