敏捷重构：Scrum角色

在自组织的敏捷团队中，不同的成员承担不同的职责，我们按照职责把团队成员分为Scrum Master角色、Product Owner角色和Team角色。

1．Scrum Master角色

Scrum Master为敏捷专家或者敏捷大师，是敏捷团队的组织者，即熟悉敏捷开发模式及敏捷实施流程的人员，一般可由敏捷团队中的开发负责人或者既懂技术又懂管理的产品经理担任。Master与Product Owner紧密合作，及时为团队成员提供帮助，保证敏捷团队按照Scrum方式运行。

Scrum Master的职责主要有：

●保证团队资源可用并具有较高的产出。

●保证各个角色及职责的良好协作。

●解决团队开发中的障碍。

●作为团队和外部的接口，屏蔽外界对团队成员的干扰。

●保证开发过程按计划进行，组织每日立会、迭代总结、迭代计划会议。

如果按照职责优先级别来排列的话，Scrum Master首先应该明确哪些任务已经完成，哪些任务正在实施，哪些任务即将实施，哪些任务可能发生变更，团队有没有偏离Scrum敏捷流程等。Scrum Master需要根据以上情况生成可视化产物，如绘制（或者通过敏捷工具生成）燃尽图、更新任务完成所需的工作量等。

其次，Scrum Master需要发现敏捷团队必需的依赖和遇到的障碍。如果团队任务的实施必需依赖于外部环境、设备或者人员，那么Scrum Master需要进行外部协调，必要时还应当寻求公司管理层的协助来解决所需的依赖。如果团队任务实施过程中遇到障碍，比如某个成员正在实施的任务经常受外部非敏捷任务干扰或被打断，那么Scrum Master需要及时屏蔽外部干扰，使敏捷团队能够专注内部任务的实施。

案例：某通信公司最近在媒体网关的语音业务组实施Scrum敏捷流程，Scrum Master在实施前的团队依赖评估中发现，该Scrum团队需要依赖通用平台组提供的运行环境、数据配置组提供的底层数据库，以及测试部门的测试人员。这些外部的依赖直接影响Scrum敏捷是否能够顺利实施，因此，Scrum Master需要按照优先级别对所有涉及的依赖进行梳理，并汇报上级管理层寻求尽可能多的支持和协助，以便Scrum团队任务的实施。

谁可以成为Scrum Master？

一般而言，敏捷项目团队中，项目经理、技术专家或者质量专家都可以成为优秀的Scrum Master，但在行使职责的时候可能侧重点有所不同。

●项目经理可能更注重流程管理，在团队内部技术方案所必需的依赖或者遇到的障碍方面可能有所欠缺。

●技术专家可能更注重技术问题，对流程控制和质量控制可能会执行不到位。

●质量专家可能更注重缺陷管理和质量保证，对技术和进度流程可能会有疏忽。

Scrum敏捷团队应该是一个自组织团队，所以，上述缺陷完全可以通过不断学习和尝试来弥补。从这个意义上来说，一开始可能由项目经理兼任Scrum Master角色，等团队达成默契后，由谁来担任Scrum Master并不是问题，谁都可以成为Scrum Master。

Scrum Master应当固定还是轮流担当？

不论是固定还是轮流担当都有利有弊。如果从长远的角度来看，轮流担当有助于自组织团队成员对Scrum敏捷流程的理解和创新，也有利于团队能力的整体提升。Scrum Master每隔一段时间更换不同的成员担当，每个成员至少有机会把敏捷流程熟悉一遍，可以与前任Master进行交流，找到适合本团队的最佳实践流程。当然如果着眼于眼前利益，那么轮流担当可能会导致过渡期的短暂空白，因为Scrum Master更换会带来工作风格的变化，团队成员需要短暂的适应时间；同时新任Scrum Master可能对某些流程还未达到熟练的程度，短期内可能会影响团队的工作效率。

2.Product Owner角色

Product Owner为产品负责人，熟悉与该产品所有业务相关的逻辑、流程和配置。客户把产品需求告知Product Owner，Product Owner把客户（团队外部）的需求转变为团队内部的产品需求清单（Product Backlog），并为清单中的每一项定义产品发布内容、优先级和交付时间（Deadline）。

Product Owner的职责主要有：

●确定客户需要的产品功能。

●确定发布内容和最后期限。

●根据市场价值确定功能优先级。

●每次Sprint迭代前，根据需要（如有功能变更）调整功能和优先级。

●参与Sprint计划会议（Scrum Planning Meetings）、Sprint评审会（Sprint Review Meeting）和Sprint回顾会（Sprint Retrospective Meeting）。

●接受或拒绝敏捷团队交付物。

●为产品的ROI负责。

什么是敏捷ROI

ROI为投入产出比。敏捷团队希望按照产品的市场价值来确定实施的优先级，最大限度地提高投入产出比，因此，敏捷团队更关注高价值功能，从而提高成本效益。敏捷团队更愿意在尽可能短的迭代周期结束后有可运行的软件版本作为交付物，短迭代周期缩短了反馈周期，提高了敏捷团队及早发现问题的可能性。

Product Owner准备什么？讲解什么？

会前准备：条目化的需求（用户故事），优先级排序，最近1～2个迭代最希望获得的功能。会前准备至关重要，可帮助Product Owner理清头绪，不至于在迭代期内频繁变更、增加或删除故事。

会上讲解：讲解难以用文字表述的内容，如游戏的文化背景，嵌入式设备的手感，OA系统背后的人事关系等。讲解过程中团队成员可以随时提问，Product Owner要予以解答。若Product Owner还没想清楚答案，可推迟用户故事的敏捷实施，或将用户故事分解为“已想清楚的”和“未想清楚的”，后者推迟到下一迭代或更晚。

两者关系：会前准备类似电影剧本编写，它解决了这是不是一个好的用户故事的基本问题；会上讲解类似导演说戏，它解决了用户故事能不能演好的基本问题。很多Scrum团队错误地认为已经有文档可读了，开会讲解太浪费时间，其实两者缺一不可。

谁可以成为Product Owner？

一般来说，产品经理、项目经理、团队中熟悉产品业务流程和逻辑的开发人员，都可以成为Product Owner。

●在初级团队中，Product Owner要确认客户需求，并确定需求价值和优先级。

●在中级团队中，Product Owner需要多方收集需求，与团队成员共同确定需求价值和优先级。

●在高级团队中，Product Owner和团队成员共同收集需求，共同对产品负责。

案例1：某移动互联网公司最近与客户达成一项基于手机端的酒店预订应用的开发意向书，客户要求实现的应用包括：酒店列表浏览、酒店预订、酒店取消、订单管理、用户评论、酒店导航、多国语言等功能。作为敏捷团队的Product Owner，前期应当与客户反复沟通每个需求，并与客户、团队成员一起讨论每个功能需求的市场价值以便确定其实施优先级和最后期限。在与客户沟通后，表3-3中客户原始需求中的酒店预订、酒店取消、订单管理变更为订单管理，同时新增支付管理功能。根据变更后的需求（Product Backlog），确定了各自的优先级和最后期限。

表3-3　Product Owner根据需求价值确定优先级和最后期限

案例2：某敏捷团队在计划会议中邀请Product Owner参加。但Product Owner因会议时间冲突未能参加，在讨论Sprint Backlog的时候，因客户需求有变动，团队未完全按照Product Backlog的优先级认领。在团队成员选好Sprint Backlog后，Scrum Master详细梳理了每一条Sprint Backlog的评估工时。(www.xing528.com)

在案例2中，存在以下问题：

问题1：Product Owner未参加计划会议。

应对方案：敏捷团队应提前与Product Owner协商时间，确保Product Owner参加会议。

问题2：未按已排定的优先级认领。

应对方案：敏捷团队需要和Product Owner再次确定优先级。

问题3：由Scrum Master一个人完成工时评估。

应对方案：工时的评估应当由团队成员共同参与，而不能由Scrum Master一个人说了算。

总结：在敏捷开发团队内部，Product Owner和Scrum Master角色是非常重要的，直接决定了团队是否能够很好地执行敏捷开发模式，因此这两个角色必须非常熟悉敏捷开发的整个运转流程，带领和引导团队成员一步一步地往敏捷的目标迈进。

Scrum Master和Product Owner可以由同一人担任么

《Scrum敏捷软件开发》的著者Mike Cohn认为，敏捷团队的Scrum Master不应该同时担任Product Owner的角色。Product Owner考虑得更多的是打造什么样的产品，不会考虑敏捷团队的能力和生产力；而Scrum Master考虑的正是团队的能力和生产力，因而Scrum Master退回Product Owner的需求是经常发生的事情。

Product Owner往往决定要做什么，而Scrum Master将促进团队协作以实现需求。因此，Scrum Master和Product Owner基本上是需要全职或接近全职，让一个人同时担任两个角色在一定程度上会削减其中一个角色需要的时间。

产品管理的专家Roman Pichler认为，Product Owner和Scrum Master是两个互补的不同角色，如果一方执行得不好，另一方就会很痛苦。Product Owner负责产品的成功，而Scrum Master则负责流程上的成功，帮助Product Owner和团队用正确的流程创建成功的产品，为推进组织变革和建立敏捷工作模式提供帮助。

3．Team角色

理想情况下，Scrum Team应该由项目实施类成员与项目决策／应用类成员共同组成。项目实施类成员可以来自不同的职能部门，可以侧重自身的业务特长或技术强项进行Scrum项目实施。项目决策／应用类成员包括软件产品的客户和用户，客户是软件产品的决策者，对软件产品的用户需求理解得非常到位，是决定项目是否立项的关键成员；用户是软件产品的直接使用者，有对软件产品功能需求的通俗解释和极其敏感的用户体验，对项目实施过程中的人机交互体验的改善具有充分的话语权。

图3-4展示了理想情况下的Scrum Team人员构成。

图3-4　Scrum Team人员构成

决策／应用类成员：确保整个团队对用户需求的准确理解和把握。

实施类成员：确保整个团队高质量地实现用户故事并交付客户。

实施类成员长期从事产品设计与开发，往往不能很好地站在用户立场考虑产品需求，也未必能真正理解用户的真实需求。因此，实施类成员与决策／应用类成员坐在圆桌前一起交流并确认需求是非常必要的。

由此可见，决策／应用类成员和实施类成员共同实施Scrum敏捷过程是高质量交付软件产品的前提之一。但实际实施过程中，受诸多客观因素影响，决策／应用类成员未必会成为Scrum Team的成员，也就是说，产品的客户／用户未必会长期参与Scrum实施过程，也未必会与实施工程师进行频繁的需求确认和再理解。因此，不可避免地，由于对用户故事理解得不够准确或不够到位，导致交付的产品质量不如客户所预期的。

譬如，Scrum Team一般由4～8名成员构成，其中1名为客户／用户，其余为Scrum实施成员。需要特别强调的是，Scrum Team采用矩阵式的组织结构，与不同职能部门构成了矩阵式组织结构的两个维度。譬如，敏捷团队由6名成员组成，其中1名为客户，3名来自软件开发设计部门，另外2名分别来自软件测试部门和系统规划部门。

矩阵式组织结构

在公司职能部门单一组织结构的基础上，为解决不同的任务专门成立了不同的团队，形成“职能部门-任务团队”的矩阵式组织结构，如图3-5所示，该矩阵结构中横向为任务团队，纵向为职能部门，每个任务团队由不同职能部门的成员组成，打破了原有单一职能部门的架构，解除了各职能部门之间的限制，以达到资源优化配置的目标。

图3-5　矩阵式组织结构图

在矩阵式组织结构中，员工既隶属于纵向职能部门，也隶属于横向任务团队。尤其对于软件服务外包公司而言，矩阵式组织结构既有助于公司降低人力成本，也有利于高效完成开发任务，使公司在时间、成本和绩效上保持平衡。

Team的职责主要有：

●团队应当自组织、自管理。

●团队成员对认领的任务负责。

●团队成员之间应当相互协作，必要时应当结对开发和走查代码。

●团队遇到障碍时应当主动寻求Product Owner或Scrum Master协助。

图3-6为Scrum角色的职责和现实定位。表3-4总结了不同角色在敏捷软件开发生命周期中需要做的事。

图3-6　Scrum角色的职责和现实定位

表3-4　不同角色需要做的事

Scrum敏捷办公环境

开放的办公环境是Scrum敏捷开发的标志之一。与传统的开发环境——背对背地躲在格子间不同的是，Scrum敏捷开发提倡沟通与互动，除了每日立会以外，随时沟通也是不可或缺的。另外，一块随时可以涂鸦的白板也是团队的最爱。一个Scrum团队的办公环境如表3-5所示。

表3-5　一个Scrum团队的办公环境