Scrum的三大主要角色

Posted 2021-04-25 專案管理生活思維

之前写了一篇关于Scrum精神的说明。 发现还确实有些朋友对此方法有兴趣，所以接下来继续分几个篇幅来多介绍一下这方法的一些细节吧。

但我也要再次提醒，世界上没有「圣杯」。 并非你学了这方法，专案就能避免一切问题。 所有方法都有「适用性」的问题。 适用性「并非跟产业相关」，更跟专案规模、类型、组织、人员能力、还有文化相关。 如果在不合适的环境中尝试不合适的方法，最后就会得到不对的结果。 所以请别误以为你是做软体开发或是游戏开发，这方法就一定适合你。

但在继续讨论Scrum的方法细节前，我想先解释一下Scrum中几个「管理角色」的界定。 因为这方法很仰赖每个人能正确扮演好自身角色。 如果只是在传统组织中套用Scrum的方法论，那其实是不会有任何效果的。(换言之，想导入Scrum的，请先确保你能先改造「组织结构与工作职责」。)

那这角色定位是如何的呢？ 基本上，Scrum把专案中的成员分成三个角色： 
- Product Owner 
- Scrum Master 
- Team Member

Product Owner

是所有利害关系人(Stakeholder)的代表。 他负责整合不同的利害关系人，并协助专案来定义Vision。 换言之，他决定专案到底最后要做成甚么样子，确保投资的回报能最符合组织(其他利害关系人)的需求。 最后尤其重要的，他得定义专案的完成日期。

也因为他肩负这样的责任，他在专案开始前，必须要了解各利害关系人的考量，并根据这考量定义出这个专案的需求/功能清单(Scrum的术语称之为Product Backlog)，以及各需求的优先顺序。 甚至在专案的每个循环(Scrum术语称为Sprint)，他得定义各循环的需求、调整需求的优先顺序、甚至根据成果来删减或增加Product Backlog的内容。

至于团队在做每个循环的计画(术语称为Sprint Planning Meeting)时，他也得全程参与，确保团队对于需求的认知无误，要走的方向与内容也都可被接受。

最后，在每个循环完成后，他得代表其他的利害关系人来检视本次循环的完成状态是否有符合认知。

所以大家可以看到。 要使用Scrum的第一个要项，就是你得要有一个有担当的Product Owner。 他得去整合不同的利害关系人，并把大家的需求界定清楚、并标出优先顺序。 再来，他得从头到尾参与专案的开发，在每次计画会议中确认大家没有偏离方向，在每次循环(Sprint)结束后检视结果，并根据团队执行的能力来调整后续范畴。

如果扮演这角色的人不瞭解需求、不能搞定其他利害关系人、不能分辨每次进度的状态，那这方法就注定不会成功。

从此我们其实已经可以先简单得到一个结论：几乎台湾99%外包为主的案子都别想用Scrum。 两个原因。 首先，客户通常不会有耐心这么陪你玩。 二来，要做甚么通常合约都写死了，不可能根据实际执行状况机动调整。 所以除非是内部的开发案，不然这方法论几乎没有适用空间。

Scrum Master

这角色跟一般人认为的PM其实有很大的差异。 与其说他是一般专案组织的管理负责人，他更像是一个「家教」。

Scrum Master其实并「不负责管理团队，而是负责教育团队」 - 确保大家以符合Scrum精神的方式做事情。 另一个主要的工作，是帮忙团队把问题挡在外面。

比方说，有人提出不在这循环定义要做的需求时，Scrum Master得出头帮忙阻挡。 或是把这人引导到Product Owner那边。 有人的电脑坏了，但是IT并没办法一下子提供新替换机器，他得出头去跟IT部门协调。

至于每次循环进行中，他还是得协助团队计画、监控进度，并在每日的会议中确保团队知道自己在干嘛、没有偏离方向，并在察觉万一有人偏离方向时出来「拨乱反正」。 并把一些改善的流程、沟通方法记录下来，确保团队的效率与效能能随着多次循环后能一直提升。 至于数据面，则得熟悉团队的能力上限，并在每次循环的计画会议中要定义工作上限时，能把资料提供给Product Owner。 避免Sprint Backlog中的内容太多或是太少。

光看这内容就会发现，这又是另一个在很多组织里头很难简单落实的要求。 因为大部分组织还是有很深的部门籓篱，但一个要执行Scrum的组织，你必须让部门变成专案的从属结构，仅负责支援专案。 这时候Scrum Master才有办法去为专案立刻争取到所需的资源。 Scrum要把变更阻挡并引导到Product Owner这点，也是很多人不习惯做的事情。 但这可是Scrum模式要成功非常重要的一个关键。

Team

在这里，Team指的则是剩下的所有人。 包含不同技术领域的团队成员，或是技术主管带领的工作人员都算。 而且他们通常是以整合的方式处理同一工作。

这方法中，团队本身要担负大半比例的管理工作。 在一般方法论中，技术人员通常是仅被PM指派工作，并被要求在一定的时间中完成。 但在Scrum中，主张要让Team更高的自主性，并希望跨专业(Cross Discipline)的团队能自发的根据Product Owner的需求来「设计与建构做事的方式」。

就这方法的概念是，团队若能充分理解需求内容时，比较能根据彼此专业合作设计出对的做事方法。 此外也比较能对这工作有所热情、以及Commitment。

也因为这概念，所以每个循环(Sprint)前，都要花最少四小时的时间，请Product Owner来说明需求的内容。 团队再根据这内容规划本次循环的Task(工作内容)，以及需要投入的时间。 等所有Team的成员都界定清楚本阶段的工作后，这次的循环才正式开始。

而一旦循环开始后，大家就根据原本规划的工作分派执行。 每天则另外要花约十五分钟的时间「全员」聚在一起讨论进度作微调；或是当有外部阻碍时，在这会议中告知阻碍让Scrum Master去解决。

那这也是这方法要採行前另一个要思考的点。 这方法因为很重视团队的自主管理能力( Self-organizing，以及Self-managing)。 这可不是口号喊喊就好。 而是真的很多部分得让团队须能合力规划，并自行解决专案内部的问题。 所以若团队实力差距太大，这方法未必会比听命办事的模式更有效率。

以上是这三个角色的基本责任定义。 下篇在来跟大家分享在这方法论下，整个专案执行流程的架构吧。