在我过去的近两年工作中，我们一直在应用 Scrum 敏捷项目管理方法来开展工作，今天，我先从它的角色划分来讲起，毕竟这可是它最鲜明的特征。

首先，为什么这种项目管理方法叫 Scrum ？Scrum 是一个引申词，原义是橄榄球场上的并列争球。橄榄球号称是美国的国球，受关注度最高，我们经常听到的超级碗 Super Bowl(/bəʊl/)就是它的年度冠军赛。

就像橄榄球运动极度强调团队协作一样，它是用于开发和交付软件产品的一个框架，且过程是增量和迭代的。

好，我们回到 Scrum 的角色划分。基于 Scrum 框架开展工作时，会涉及三个角色：产品负责人、ScrumMaster和开发团队。

产品负责人（PO）

第1个核心角色是产品负责人，Product Owner，简称 PO。

他负责两个层面，分别是 代言人 和 产品定性 。从经济层面来考量，他要考虑每一期迭代的资金投入是否合算，或者说投资回报率 ROI（Return on Investment）。最重要的是，与各内部干系人形成一个统一愿景，这些干系人一般会包括业务方、市场人员等等。

在产品定性上，他负责敲定要开发什么，以什么优先级顺序开发。

所以在 Scrum 这个框架体系里，产品负责人很明显地扮演了一个承上启下的代言人角色。

ScrumMaster

第2个核心角色是ScrumMaster，他会负责指导团队在通用的 Scrum 框架上遵循正确的敏捷过程，他也会帮助大家解决跨团队的沟通问题，让每个人理解、并乐于接受 Scrum 的价值观、原则和实践。

ScrumMaster 就像是前面所提到橄榄球运动的教练，他会观察整个实践过程，帮助大家达到更高级别的工作效能。

ScrumMaster 也是团队的服务型领导，他着重于为整个团队提供服务保障。他的领导力主要是体现在过程权威，帮大家定义和遵守流程，最终确保交付不延期。

开发团队（TO）

第3个核心角色是开发团队，就是在 TeamLeader 的带领下负责最终的交付。

对比而言，作为开发团队的 TeamLeader 也要擅长跨团队的沟通能力，甚至很多会议 ScrumMaster 和 TeamLeader 都是要一起参加的；

说起来的话只要是 ScrumMaster 在做的事情，我觉得 TeamLeader 都要会，这是沟通力的表现和保障，然后才是关注核心的开发技术，在敏捷中 TeamLeader 也叫 Technology Owner，简称是 TO，技术能力级别通常是高级工程师，或者是架构师。

开发团队，除了有形的人员，还需要良好的内建可视性，帮助落地的工具有很多，比如 Jira、禅道、Teambition。通过这些工具能获悉到每个人每天在做什么，进展如何，何时能完成。

在呈现方式上，我们采取了用户故事 + 子任务的一对多拆分模式。用户故事是产品负责人 PO 定义的，子任务通常是 TO 带领开发团队一起投个屏，逐个拆解的。所以，这些可视化工具也间接承载了工作的流转去向，以及结果状态。

开发团队其实是一个跨职能的综合体，有负责前端 HTML5 的、移动客户端 iOS 或 Andriod 的、有中、后台开发的（像 Java、Python、C#等等），还有测试小伙伴，这样整合在一起，团队整体的目标就比较容易统一。

如果上 OKR 的话，团队层面不同职能人员的 Objectives（目标）可以很迅速的达成。OKR 就是 Objectives and Key Results（目标与关键结果）。敏捷开发和 OKR 概念，在以后的分享中会再拎出来说一说。

团队的人数一般会控制在 10 个人以内，这样便于降低沟通成本嘛。

那敏捷的跨职能开发团队于企业来讲还是有代价的，简单地说就是资源问题，同一个角色被安排到某一个团队时，那他至少在最近的一到两个迭代都是跟着这个团队走的，别的团队如果需要人手那资源就不够，不够就得招人，而招人就会促使人力成本增加。

另外，在开发质量层面上，TeamLeader 会组织整个开发团队开展 CodeReview 代码评审会、新知识培训，以及与运维方一起完善 CI/CD，也就是持续集成和持续部署。

对待会议的态度

好，介绍完这三种角色，我们会发现敏捷实践中，开的会可是不少的。好处就是，在两周一个迭代的周期里，通过会议的交叉可以将需求吃得很透。要说会议多而浪费时间也可以这么讲，之所以要这么做，主要就是说它能克服开发人员的一个隐性问题，就是“都不太喜欢学习业务知识”，通过多频次需求的讲解和鞭策，在最终交付的时候，做出来的东西基本都是靠谱的。不然，十天半个月过去了，交付的东西要是无法向产品负责人 PO 交代，PO 就无法向业务部门交代，结果就是公司层面无法向最终用户提供服务，一环扣一环。因为会议的本质是共识的达成，这个也算是一点点的大局观吧。

好，今天先简单介绍了 Scrum 敏捷框架里的三大角色，下一次再和大家分享更多关于 Scrum 的故事。