玩转 Scrum 团队篇

Posted 2021-04-25 上海欣旋

原创：刘铮  编辑：蔡玉蕊

 来源：欣旋咨询（PMP2010）

通过之前的三次课程嘉宾刘老师为大家介绍了Scrum方法的一个流程和四个活动，但对于Scrum来说，最重要的还是团队，团队才是我们要特别关注的。所以，刘老师在本次的Scrum团队篇里将详细说明Scrum团队中三个角色所承担的职责以及角色间应该如何协作。希望通过本次的分享能让大家认识到敏捷Scrum团队与传统项目的团队的差别之处。

Scrum团队的核心价值

（Core Value）

任何团队的凝聚都需要向心力，这里所谓的向心力就是一个团队的核心价值。相对于团队比较通用的价值，例如，沟通、信任等就不一一说明了，以下所列出的是嘉宾在Scrum落地实践中认为Scrum团队独特的价值。

・承诺

Sprint kickoff时，会上承诺要交付的东西是一种承诺；每天站立会上，每个成员的发言也是一种承诺诺（昨天已完成的工作，今天计划的工作，之后剩余的工作）等等。这些都是所谓的承诺，而Scrum团队第一个核心价值就是要注重承诺。

・专注

Scrum方法的特点周期短、节奏快，大家必须专注于自己工作以及自己工作的进展。所以Scrum项目中一般不会出现镀金。

・公开

在前三次的课程中提到过很多关于信息公开的方法。例如，看板的运用，只要大家遵守鸡与猪的原则，团队的状况都是公开的。回顾会中开诚布公地表达自己的观点也是信息公开的一个表现。

・尊重

尊重团队中每一位成员，尊重他们表达的观点，尊重他们的做事方式方法。例如，在做评估时，由于成员的经验，阅历的差异造成大家的估算结果存在偏差，只是不能质疑成员的能力而是应该去真正理解成员偏差较大的原因，要从他们的角度去帮助他们如何缩短差距，尊重他们的想法，这样才是对团队有利的做法。

・勇气

Scrum/敏捷项目并不像传统项目计划需要事前做好完备的计划，各个阶段并不会规划到特别细节的程度，它规划的只是近期的工作。所以，对于个人来说，要有勇气在这种状态下往前走并以一种拥抱变化的心态来开展项目。有时在实际过程中，如果任务遇到问题要有勇气说出来寻求帮助。从团队角度来说，要能有勇气接受失败。例如，有些功能无法实现时，要有勇气直接说出我们无法实现，而不是拖到要上线了才告诉客户无法实现。这对团队和个人都没有好处。

Scrum团队的角色

一个Scrum团队中一般有三个角色：

• （Product Owner）：产品经理

• （Cross Function）Team：开发团队，也是实际干活的人

• Scrum Master：敏捷教练

注意：在Scrum团队中除了以上的三种角色就没有其他角色了！

接下来嘉宾将详细为大家介绍各个角色的必须具备的特质及其职责。

  ◆ PO   

・PO的职责

1. 提供愿景

PO要对产品的Roadmap&Backlog负责。这点非常重要！产品的Roadmap是指产品六个月后会达到一个什么样的状态或者说三个月后我们的产品与竞品相比有哪些优势或劣势。所以，这就要求PO能够将Backlog中的内容、需求的优先度整理地非常清楚、有条理。产品PO对Backlog负责这点也在前三期的课题中反复强调了。

2. 提供边界

PO要能够清晰的描述产品的限制条件。例如在国庆节或春节黄金周前，一般公司都会在之前发布一款产品，如果国庆节后或春节后上线就没有意义了。这就是一个比较清晰的产品边界了。那么问题来了，之前不是说上线时间应该有团队来定，怎么这个时候又变成PO决定了？其实这里的提供边界就是指PO要详细说明产品的限制条件，PO只是提出上线时间后再由团队来判断是否真的能上线，如果上不了就只能PO和团队相互协商，要么改变范围要么改变上线时间来进行调整。

3. 每个团队只需要一个PO

这个应该很好理解。在一个家庭里孩子的教育，一般父母总会有一方作为主导方，如果双方意见不一致时，孩子又要听爸爸的要求又要听妈妈的要求自己也会混乱，到底以哪一方为主。又或者孩子就是专门找父母意见不一致的地方来逃避作业或学习。所以对于一个Scrum团队来说，需求的出处只能有一个源头，避免冲突。当然一个PO可以是多个团队的PO。

・优秀PO所具备的品质

一个优秀的PO应该至少具备以下的特点：

1. 始终都在

团队在需要PO做决定时PO始终都在，对于团队来说是最重要的了!

2. 懂业务

PO要理解业务，不懂业务做出来的产品是无法支持业务开展，那就是没有价值的。

3. 善于沟通

PO不仅要能与业务方沟通，也必须能与团队（研发）沟通，不能单纯分割业务与技术。认为业务是业务，技术是技术，要能够将业务与技术融合起来。也就是说不能只听业务方的意见，也要倾听团队的心声。

4. 果断

Sprint节奏很快，周期很短，所以决策一定要果断，特别在澄清需求时更不能是犹豫不决，模棱两可的样子。这样也可以给团队信心。

5. 得到授权的

PO要会拍板，但更重要的是能拍板，有权利拍板。

 

 ◆（Cross Function）Team

・（Cross Function）Team所具备的特点

1. 团队的人员相对固定，一般5～9人为宜。

当然，大家不要纠结于这个数字，有时候会有少量增减。但是人员要相对固定。

2. 具备专才和通才

Scrum奠定者之一的Mike Cohn说过，全世界快餐店都知道怎样处理专才和通才的问题，但唯独软件行业不知道！Mike Cohn曾经在墨西哥的快餐店打工，他说他与其他Waiter不一样的地方是当后方厨师忙不过来时，他可以去帮忙。虽然不如厨师做得快但是做出来的味道是一样很棒的。当前端Waiter忙不过来时也可以帮忙做。但是唯独打发票的机器坏了，他没办法修。这个例子就说明团队中不是每个人都是专才，一般在专才周围一定会配备通才，能让团队技术能力更丰富，当专才忙不过来时，可以让通才顶上去，让Sprint能够继续转下去。

 

3. 注重质量

传统很多研发团队很多时候为了赶进度被迫牺牲质量，因为相对时间（上线时间）和范围（功能）少了不太容易明显被发现。但是Scrum团队的特点就是不以牺牲质量为代价，而是以保证质量为前提，团队有自己的权利选择能够完成的时间和范围。

◆Scrum Master

・Scrum Master的职责

1. 确保团队成员实施/使用Scrum

2. 帮助团队获得成功

Scrum Master作为一个不对项目结果直接负责的角色，应该至少做到以下几件事：

1） 如果有人违反Ground Rules要毫不留情地指出

2） 始终提醒团队提升效率去完成工作，帮助团队寻找是否有更高效的方法

3） 当团队有做得好的地方要及时给予肯定

4） 让有独特个性的成员能够融入团队，让他们能够共同关注团队的利益，遵守团队的要求

5） 当有人或组织对团队造成伤害时，应该毫不犹豫地挺身而出

Scrum Master最终的目的还是让团队能够获得成功。

・优秀Scrum Master所具备的品质

1.负责

对团队能够最大化的产出负责，但不是对Sprint的成功与否负责，Sprint的成功与否还是有团队负责。

2.谦逊

Scrum Master没有实质上的行政权力，不同于强矩阵的PM，所以Scrum Master一定要谦逊。

3.协作

相互合作、共同进步，最终使项目成功，如同下图所示意的。

 

4.投入

一般一个Scrum Master是为多个团队共享的，无论多忙每个Scrum Master都要对自己负责的团队有投入。

5.有影响力

利用自己软技巧来影响团队成员，影响PO甚至影响团队以外对团队造成阻碍的人或组织。最终帮助团队有所提升。

Scrum团队的协作

三个角色的特质及职责到这里就介绍完了，那么这三个角色该如何相互协作来提升Sprint的效率，最终使Sprint能够成功呢？估计这也是大家最关心的！那么接下来由嘉宾给大家分享他在敏捷落地实践中的经验。

一个好的协作团队应该做到以下四点：

1. 要面对现实

对于不同角色应该怎样面对现实呢？PO，Team，Scrum Master在项目开始时团队每个人都是希望能够按质按量按时完成任务的，希望Sprint是成功的。但为什么最终与期望有差异呢？就是因为Sprint过程中情况发生变化了。所以，所有人应该能够面对并接受现实。

▪对于PO来说，需要面对的现实是需求总是存在的，但不是每个需求都必须马上实现的。

为了便于理解给大家举个例子，大家都有挤公交车或地铁的经验吧，他们的差别在哪里呢？如果是公交车挤不上，但后续公交什么时候来不确定，此时你的决定很可能就是想办法挤上去。但是如果是地铁呢？你很有可能就会等下一班地铁，因为几分钟后就会来下一班了。同样，在我们PO提出需求时，不用急着全部都要实现。每个Sprint能完成的点数就那么多，这次挤不上就放到下个Sprint，正好有更多的时间思考需求真正的价值。

▪对于Team来说，需要面对两个现实：

① 没有所谓的完美的需求

大家都有装修的经验，你们在装修前一般会有2种方法选择自己房子应该装修成什么样子。一种是找装修公司让他们给套方案后，基于他们的方案我们再针对自己喜好或房子布局做定制化的调整。一般都是看到了才会有感觉，有想法；另一种方法就是看楼上或楼下，因为房型一样，所以再根据自己的喜好做调整。所以，有些需求都是涌现出来的，并不是一开始就那么清晰可见的。

② 债务总是要还的，不要牺牲当下的质量

在开发过程中经常会有以下的场景：

1）这次开发发现代码写得不够好，没有按规范写，开发人员想着以后再修改吧，先把功能实现了就好。

2）测试人员写的测试用例并不是那么详尽，但是时间不够以后再补全测试吧。

大家认为以上场景下的“以后”有机会吗？在Sprint中团队成员常常会欠下这种技术债务，一旦有了债务之后会让你用10倍、20倍的代价去偿还。所以，一定要在当下避免技术债务，这种“以后”永远不会来！

▪对于Scrum Master来说，也要面对两个现实

① 我们没有水晶球，无法预测未来，所以Scrum的开发周期就2～4周，能改变的就是需求范围；

② 传统项目都是实现分配任务，而Scrum不再以这样的方式。大家可以自己选择任务而Scrum Master就是把握好大局观，把控好风险。

2. 要有担当

每个角色遇到问题时都要在认清楚现实的前提下，以解决问题为出发点，而不是一有问题就相互甩锅。

3. 要紧密的沟通

这点不多做解释了，任何一个团队沟通是绝对必要的。

4. 拥有共同的梦想

三个角色要以“One Team，One Dream”为出发点，以开发出更高效的软件，服务更多的用户为目标。

  Q & A  

到这里为止，今天课程内容就基本结束了。接下来进入嘉宾的答疑环节，我们来看看，同学们在听完课程后都有些什么样的困惑，是不是你也有同样的疑问呢？

Q1：Scrum Team中项目经理去哪里了？

嘉宾回答：对于Scrum来说没有PM，但是PM要做的事情没有消失。看个人意愿，PM可以转成PO也可以转成Scrum Master。

Q2：Scrum Team区分designer/tester角色吗？

嘉宾回答：从严格意义上说，Scrum Team不会区分设计人员和测试人员的角色。开发人员可能会拿一些测试用例去测试，甚至PO有时也会承担测试的任务。一般只要是任务就是团队的任务，不会严格规定谁做什么，但是只有任务都完成了Sprint才算完成。所以任何人都有责任去完成任务，能力大小另当别论。

Q3：PO只关心业务怎么办？

嘉宾回答：在Sprint中做什么原则上是由团队说了算，但是PO只关心业务不关注效率改善性的任务时，团队可以用业务的语言给PO解释这类任务所能带来的价值。如果还是不行，可以通过升级的手段去影响PO。

 结 束 语 

《人件》中说过“全世界有四分之一的软件项目正在失败”，在软件行业中不缺乏聪明才智，也不缺乏勤奋努力。团队成员经常加班加点，为什么还有那么高的项目失败率呢？甚至有人说现在有百分之五十的项目都是失败的！

1970年温斯顿·罗伊斯（Winston Royce）在他的一篇论文中提出了著名的“瀑布模型”，同时也指出瀑布模型其本身也存在不足和需要改进的地方，并提出了改善的解决方案，如迭代式，螺旋式等。但是在当时的大工业时代，我们只记住了瀑布模型。

近几年开始盛行敏捷，这种方法更关注交付的价值，注重拥抱变化，特别注重软件开发过程中的内在规律。敏捷的理念及方法正逐渐被越来越多的企业接受并运用。所以，通过这几次的课程希望大家能在自己的工作和生活中尝试着运用敏捷或Scrum方法。

是不是四次的课程大家还意犹未尽？如果大家在运用敏捷理念或方法的过程中，遇到任何问题或收获，可以加入敏捷VIP群，和大家一起探讨。

• 本文是欣旋敏捷VIP会员群的第8篇原创文章

  
  

欣旋敏捷VIP会员群

敏捷VIP会员群，是为广大敏捷爱好者搭建一个实战交流的平台，从敏捷转型落地，到管理与工作实践，共享敏捷资源，打通职场人脉

学习时间：12个月

学习费用：RMB1,680元/人，PMP获得60 PDU

欣旋商城 想了解更多培训课程，请上欣旋商场 小程序

上海欣旋   项目管理培训专家

PMP * 软考 * ITIL * ACP * PBA *  NPDP * P2

抖音帐号：欣旋咨询