作为自管理团队的开发人员：好的长什么样，差的长什么样

2020年版Scrum指南表述清晰：开发人员负责为Sprint创建计划（Sprint Backlog）、通过遵守完成定义来植入质量、每天调整计划以朝向Sprint目标，并作为专业人士相互问责。换言之，自管理不是成熟Scrum团队的可选特性——它是基线期望。实践中，许多被称为Scrum团队的群体更接近任务分配小组：他们等待被告知做什么，按个人所有权划分工作，遇到问题向上传递而不是自行解决。以下对比列出了区分自管理团队与仅走流程团队的特征信号。

好的自管理长什么样

• 每位开发人员都理解Sprint目标，且这一目标驱动日常决策。当开发人员在Sprint中面临权衡时，他们问的是哪个选项最有利于Sprint目标——而不是哪个选项完成了自己分配的任务。

• 团队从Sprint Backlog中拉取工作，而不是接受分配。没有人单独拥有一个用户故事；团队拥有整个Sprint。开发人员根据当前产能和最佳贡献点来承接工作，而不仅仅依据职能专长。

• 障碍在每日Scrum中提出，并立即被承接。自管理团队不等Scrum Master注意到阻碍再去修复。团队识别问题，在团队内部分配解决责任，只有当障碍超出团队权限时才上报给Scrum Master。

• 团队在计划会上推回不现实的Sprint范围，只承诺实际能交付的内容。

• 质量由团队集体把控。当开发人员发现某个条目不满足完成定义时，他们会提出——无论是谁构建的。对质量的集体所有权，是团队自管理最显著的标志之一。

差的自管理长什么样

• Scrum Master或产品负责人在Sprint计划会或Sprint期间将任务分配给特定的开发人员。这是团队未实现自管理最清晰的单一信号。

• 开发人员在每日Scrum中向Scrum Master汇报状态，而不是相互协调。每日Scrum变成了向上级汇报的站立例会，而非同行之间的规划会议。

• 团队遇到意外情况时等待指引，即使是他们完全可以自己做的决定也立即上报。

• "那不是我的领域"这句话不应该出现在自管理的Scrum团队中。

• Sprint目标在Sprint计划会之后再未被提及。如果Sprint目标从对话中消失，直到Sprint评审会才重新出现，团队管理的是任务，而不是成果。

转型是一个教练问题

将团队从任务分配模式转变为真正的自管理，需要刻意的教练辅导。Scrum Master的角色是为自管理创造条件——这意味着，除其他事项外，克制回答团队本可自己回答的每个问题的冲动，主动升级组织层面的障碍而不是悄悄吸收，并确保产品负责人提供清晰的目标而非详细的指令。一个从未被允许自管理的团队，不会仅仅因为流程名叫Scrum就自然而然地实现自管理。

XNM协助公共部门及资本项目组织建立有效的敏捷交付团队，包括走向真正自管理的教练辅导和Scrum实施。欢迎联系XNM项目群与项目交付咨询团队，探讨结构化Scrum教练如何强化您的团队。