Scrum 敏捷实践中的三大角色

Posted DotNet那些事

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Scrum 敏捷实践中的三大角色相关的知识,希望对你有一定的参考价值。

Scrum 敏捷实践中的三大角色

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

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

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

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

产品负责人(PO)

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

Scrum 敏捷实践中的三大角色

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

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

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

ScrumMaster

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

Scrum 敏捷实践中的三大角色

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

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

开发团队(TO)

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

Scrum 敏捷实践中的三大角色

对比而言,作为开发团队的 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 的故事。


以上是关于Scrum 敏捷实践中的三大角色的主要内容,如果未能解决你的问题,请参考以下文章

敏捷开发实践

唯品会敏捷Scrum实践系列1:团队组成和人员配比

唯品会敏捷Scrum实践2:产品开发路线图与需求管理

干货|企业敏捷转型的工具——Scrum

敏捷测试模式之Scrum及其实践

敏捷开发实践之Scrum方法运用