05-scrum的三个角色

Posted 2021-04-25 敏捷DevOps那些事儿

上一篇我们简单的介绍了scrum框架，这一篇我们聊一下scrum中规定的三个角色，prodcut owner 、Team和scrum master；

Prodcut owner

Prodcut owner（产品负责人）简称PO，是有且仅有的一位对产品价值负责的人，PO的职能可以简单概括为四个方面：描绘产品愿景、对需求进行优先级排序并体现价值、确保需求透明和干系人的理解、接受或拒绝团队交付。

1 描绘产品愿景 说到产品愿景，先了解下什么是愿景，愿景就是希望看到的情景，比如“替天行道”就是梁山好汉的愿景，即使我们不是产品负责人我们可能也听说过企业愿景，比如说国内几家大型互联网公司的愿景如下：

成为最懂用户，并能帮助人们成长的全球顶级高科技公司---百度
让客户相会、工作和生活在阿里巴巴，并持续发展最少102年---阿里巴巴
构建万物互联的智能世界---华为
最受尊敬的互联网企业---腾讯

这里面还有一个比较有意思的内容，阿里巴巴的愿景是要持续发展102年，为什么是102年呢？阿里巴巴集团创立于1999 年，持续发展最少102 年就意味着要跨越三个世纪，这是少有企业能够实现的成就。
      而对于淘宝这个产品来说，它的愿景“是为中国人上网购物及交易提供了一个优秀的平台，打造国内领先的网上个人交易市场和网商社区，为全球数百万会员提供网上商务服务”，这里能很明显的看到企业愿景和产品愿景涉及的范围是完全不一样的，但是愿景也都有一个共同点，愿景并不是一成不变的，愿景会随着企业、产品的发展，环境的变化而变化；回到我们今天的话题，产品负责人是要描绘产品愿景，这个看起来是很虚的内容，实则非常重要，它可以告诉所有相关方我们在为什么而努力，我们的目标是什么，我们要以此来把控方向。
     2 对需求进行优先级排序并体现价值 关于需求优先级排序的内容，在后续的需求管理文章中还会详细的说明，这里我们可以做个简单了解，需求优先级排序的根本目标是希望，能够尽快的满足客户价值，价值高的要先交付给客户，但是需求排序是要综合考虑各方面的影响，单纯只考虑价值可能会忽略很多重要的因素，比如需求紧迫性（窗口期）以及需求所夹杂的风险等。
      3 确保需求透明和干系人的理解 需求透明是敏捷所期望的需求管理状态，有的朋友说瀑布式开发写了详细的需求文档，不是也很透明了吗？其实所谓的需求透明不单纯是表面的需求可见性，还要满足需求的易获得、易沟通、易变更，而在敏捷中更加强调面对面沟通，作为产品负责人要把产品待办事项列表整理的足够清楚、详略得当，并在有需要时及时进行澄清，这样才能确保各相关方的信息对齐。
      4 接受或拒绝团队交付 虽然整个研发过程我们运用各种技术和实践做到资源协同、信息透明，但是仍不能确保产品增量一定是满足客户需求的，所以在迭代的最后产品负责人还是要明确团队交付的功能是不是能够接受，即使被拒绝掉也要明确的表述不符合的理由，以便在后续的迭代能够及时调整，而这个接受或拒绝的过程一般是在团队的迭代评审会上进行的。
      以上，是对产品负责人相关职责的简要描述，那大家可以简单思考一个问题，为什么产品负责人必须是一个人？道理其实很简单，就像开车的时候产品负责人就是司机，如果有两个司机能把车开好吗？出现了分歧听谁的？

Team

Scrum中的团队由七个人左右（加上或减去两个人）组成，团队中的每个成员都只是“团队成员”。我们期望的状态是没有任何固定的专业头衔。不会有业务分析员，没有数据管理员，没有架构师，没有团队组长，没有交互/用户体验设计师，也没有程序员，他们在每个Sprint中以任何恰当的方式一起工作来达到他们为自己设置的目标。但是反观企业实践中的各种现状，这样的状态还是比较理想化的，需要个人具备较高能力和素质，也需要很好的组织文化。但是不管怎么说我们都在试着向这个方向努力，关于团队还是可以概括为如下几方面的特点：
      1 自组织 自组织意味着没有人(即使是 Scrum Master 以)告诉开发团队如何把产品待办事项列表中的条目变成潜在可发布的功能。所以自组织应该是自下而上的，不需要管理者施加影响，不需要强硬的命令约束，是自发的行为，就像大雁迁徙，作为80后的我对《秋天到了》的课文还是印象深刻，“大雁一会排成个人字，一会排成个一字”，大雁迁徙的队伍并没有固定的头雁，带头人是不停变换的，雁群靠着团队的力量前行，任何一支单飞的雁都无法完成迁徙，当有雁受伤时，会有其他的大雁自发的站出来提供帮助，整个过程都是自组织的，也是高效的，虽然没有领导的约束却是非常规范、整齐的。
      在《赋能》这本书中也有描述到，美军攻打阿富汗时遇到了基地组织的强烈反击，而战斗的过程中，美军也发现了基地组织的特点，他们没有固定的首领，他们每个人都是领导者，他们任何几个人都可以构成一个小的团队，靠着自组织可以在任何时间和地点发起反击，而这些团队体现出来的灵活性和应变能力正是我们企业中每个团队都需要的。

但是，还有一点需要提醒敏捷转型初期尝试建立自组织团队的企业，自组织做的不好可能会变成无组织，所以自组织不是把工作扔给团队即可，也不是无组织、无纪律的无序状态。自组织应该是管理的一种方式，在给团队充分的信任和空间的前提下，必要的管理制度和约束也是很关键的。

 2 稳定 稳定是敏捷团队所希望的，任何团队从组建到成为高效团队都是要经历很多阶段的，如果团队不够稳定那将一直处于磨合期，很难达到高效的状态，但是我们又不能希望团队一直是同样的一拨人，稳定的极致就是缺乏创造性，缺乏活力，所以最好的状态是团队在保持主体稳定的前提下，还可以不断的有新血液的加入，有不同性格、国籍、背景、爱好的人参与，这样你的团队才能在稳定的基础上还保持活力。

3 跨职能 跨职能是说团队作为一个整体拥有创造产品增量所需要的全部技能，这个看起来难度并没有那么大，但是要想做的更好还有很多方面可以考量，比如从每个个体的角度来说，我们期望团队的成员能够成为“T”型人才，T型人才是说个体应该有自己非常擅长的领域，能够做到精，但是在这个基础之上还应该在其他领域有所涉及，这样当每个个体都成为T型人才时，团队可以有更多的可能性，而从团队的角度来说，归根结底希望是一个特性团队，也就是团队是能够独立交付特性的，而不是特性中的某一部分组件，这样团队的好处就是与业务团队可以纵向打通，形成高效团队，也避免了一个业务需求要多个团队协作交付的状况，避免了过多的团队间沟通和浪费。其实，关于团队还有一个明显的特点没有细说，在开头也已经很明显的阐述了，敏捷团队是小的，5-9个人即可，那既然期望团队是小的，多个小的团队又该如何协作呢，这个话题我们放到后面再聊。

Scrum master

在上一篇文章中我们就对scrum master做了简单的阐述，首先，scrum master和传统的项目经理角色有着根本的区别，项目经理的关键词是一个字“管”，而scrum master的关键词是两个字“服务”，这一点区别充分的体现了两个职能的定位，ScrumMaster为团队服务。他帮助移除阻碍，保护团队免 受外部干扰，就像一只牧羊犬保护着羊群，而单纯的保护还不够，遇到困难时要能够帮助团队扫除障碍，并且具备能力为团队提供必要的指导和培训，所以我们在scrum的各种会议和实践中都会有scrum master对的身影，因为他要时刻关注团队状态，有需要时他就应该站出来，所以作为scrum master除了具备充足的敏捷知识之外，还要转变自己的管理方式，运用教练、引导、辅导等技术帮助团队，而下图的情境领导力模型是能够体现出不同情境下可以参考的管理方式的。

最后，再讲个故事吧

一只鸡和一头猪走在路上，
鸡对猪说：“你想不想和我一起开家餐馆？”
猪想了想答到：“我很乐意。那餐馆准备卖什么呢？”
鸡回答道：“火腿和鸡蛋！”
猪停住脚步，犹豫了一下，说：“我决定不和你开这家餐馆了。因为我得全身心付出，而你只是简单参与而已。”
这是在敏捷圈非常火的一个故事，希望我们scrum中的三个角色都能像猪一样全身心的投入，而那些属于鸡的角色，我们要做好充分的管理，充分利用他们的能力帮助团队成功，同时也要避免属于鸡的角色带来不好的干扰，所以为了不被干扰，这时候该谁站出来了？