SCRUM角色介绍

Posted 2021-04-25 项目管理锦集

    在前面的文章中我们了解到SCRUM团队是一个自组织，跨职能的团队。什么是自组织呢，顾名思义，就是团队成员自我管理，自我分配和安排工作内容。在现实团队中，我们往往会觉得这种团队是不存在的。但是很多敏捷团队确实是自组织团队。为什么敏捷强调自组织团队。在敏捷的12种原则中有一条“最好的架构，设计和需求出自自组织团队”。意思就是自组织团队往往会产出好的架构，设计以及需求。在这里需要强调，自组织团队并不是敏捷实施的前提条件，而应该是实施敏捷之后的结果。在推行敏捷的时候我们不能要求团队是自组织的团队，但是成功实施敏捷之后，我们会发现大部分团队都会打造成自组织的团队。

      同时，SCRUM团队通常会控制在7+/-2人（5-9）之间，通常称为“两个披萨团队”。意思就是2块披萨就可以让整个团队吃饱，从而表明其团队的规模。

      SCRUM团队包含3类：Scrum master(SM)，Product owner(PO),以及Dev Team。

     Scrum master，常常被称为敏捷教练，而不是敏捷领导。因为SM在团队中扮演的角色并不是一个领导者的角色，而是教练。SM是连接PO和Dev Team的桥梁，与Product Owner紧密合作，及时为团队成员提供帮助。他的工作职责就是让团队理解敏捷并按照其规则开展工作。SM扮演的角色通常被称为“牧羊犬”。牧羊犬的作用就是让羊有序前进，不掉队。SM就是让团队在迭代过程中不受外部干扰。

1. Scrum Master 服务于产品负责人，包括:

(1)找到有效管理产品代办事项列表的技巧

(2)清晰地和开发团队沟通愿景、目标和产品代表事项列表条目

(3)教导开发团队创建清晰简明的产品代表事项列表条目

(4)在经验主义环境中理解长期的产品规划

(5)理解并实践敏捷

(6)按需推动Scrum活动

 2.Scrum Master 服务于开发团队，包括:

(1)指导开发团队自组织和跨职能

(2)教导并领导开发团队创造高价值的产品

(3)移除开发团队进展过程中的障碍 

(4)按需推动Scrum活动

(5)在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队

3.Scrum Master 服务于组织,包括:

(1)领导并指导组织采用 Scrum

(2)在组织范围内计划 Scrum 的实施

(3)帮助员工及干系人理解并实施 Scrum 和经验性产品开发

(4)发起能提升Scrum 团队生产力的变革

(5)与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum

   PO是产品负责人，负责定义项目愿景，需求和优先级，负责最大化产品以及开发团队工作的价值。产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

(1)清晰地表达产品代办事项列表条目

(2)对产品代办事项列表中的条目进行排序,最好地实现目标和使命

(3)确保开发团队所执行工作的价值

(4)确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作

(5)确保开发团队对产品代办事项列表中的条目达到一定程度的理解

     产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负 责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发 团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

      Dev Team就是开发团队。敏捷开发团队建议是多面手，问题在团队内可以解决，较少需要外部的支援。开发团队负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点:

 (1)他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。

 (2)开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

 (3)Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。

 (4)开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

 (5)开发团队不包含如测试或业务分析等负责特定领域的子团队。

    开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。少于 3 人的开发 团队没有足够的交互,因而所获得的生产力增长也不会很大。小团队在 Sprint 中可能会 受到技能限制,从而导致无法交付可发布的产品增量。大于 9 人的团队需要过多的协调沟 通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人和 Scrum Master 的角色不包含在此数字中,除非他们也参与执行 Sprint 代表事项列表中的工作。

    以上是对Scrum 团队角色的深入介绍。当在团队中的每一个人都对自己的角色有深入了解的话，敏捷开发才能以敏捷的效率快速推进。