Scrum 敏捷实践中的三大角色

在我过去的近两年工作中,我们一直在应用 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 的故事。

如果大家想学习更完整的敏捷实践,可以 [查看视频格式] 。

原文地址:https://www.cnblogs.com/ramantic/p/12401995.html

时间: 2024-10-12 23:32:19

Scrum 敏捷实践中的三大角色的相关文章

菜鸟Scrum敏捷实践系列(二)用户故事验收

菜鸟Scrum敏捷实践系列索引 菜鸟Scrum敏捷实践系列(一)用户故事概念 菜鸟Scrum敏捷实践系列(二)用户故事验收(本篇) 菜鸟Scrum敏捷实践系列(三)用户故事的组织(即将到来) 一.用户故事的状态: 用户故事推荐定义五种状态,分别是“构思”.“已批准”.“开发中”.“已完成”.“已验收”. 只有符合项目组规定的验收标准,才能置为“已验收”状态. 二.用户故事验收标准  由团队决定验收标准. 该标准可包括: •已完成所有任务(开发.测试和记录) •正在运行和通过所有验收测试 •无开放

浅谈敏捷组织中PMO的角色

所谓的"敏捷组织"其实并没有标准的模式,而且PMO(项目管理办公室)并没有一个标准的角色定义.有一个非常普遍的误解,公司在选择"敏捷"或者"瀑布"的开发流程时只能做二元互斥的选择,导致的结果就是一些公司会试着让他们的业务和项目严格遵循这种模式到一种极致的状态.而正确的解决办法应当是让开放方式去适应业务需要,并且很多时候,两种开发方式应当兼而有之.一般来说,任何PMO都有责任去最大化组织内部项目组合的投资回报率,他们通过以下方式去达成: 通过选择对

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

菜鸟Scrum敏捷实践系列(三)用户故事的组织---功能架构的规划

采用Scrum敏捷项目管理方法进行产品开发,当碰到较大规模的产品开发,用户故事较多时,就必须采取一定的方法来组织.管理用户故事,使其分门别类的管理,条理才清楚.通常我们采用“功能架构”来分层分类别来管理用户故事. 一.规划层次 遵循Scrum敏捷项目管理理论,可把项目划分为三个大的层次,分别是顶层的产品层,支持多个产品同时开工:第二层是功能架构(Features)层,能够规划软件产品的整个骨架(功能蓝图):第三层是用户故事层,把用户故事分门别类的放在功能架构之下.项目管理者和开发者能够一目了然的

菜鸟Scrum敏捷实践系列(一)用户故事概念

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

Scrum敏捷实践之旅系列(一)用户故事概念

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

【项目管理】敏捷组织中PMO应遵循的准则

敏捷改变了人们的工作方式,不仅仅是开发部门,而且还包括其它的部门,例如HR.财务以及PMO等.在大多数组织中,PMO是一个控制体.它指导项目团队的规范.模板以及流程.目前,大多数的IT组织都敏捷化了. Nick Oostvogels,SkyCoach公司的项目经理及敏捷教练,最近发表了敏捷组织中PMO的新角色的文章.Nick说,组织敏捷带来了一些影响,例如业务单元有偏差.项目组合规划不满足敏捷的步调,以及项目管理办公室不知道如何支持敏捷团队. 一个经典的PMO突然必须处理敏捷项目时都会表现相同的

scrum敏捷开发的几款工具

做敏捷开发,如何敏捷?我们需要一系列成熟的工具帮助我们敏捷.敏捷开发工具的适合以及选用,对开发项目起着关键性的作用. 此篇介绍我们在scrum敏捷开发中发掘的几款工具,方便更多新加入的开发者上手. 1.  AxosoftOnTime Scrum AxosoftOnTime Scrum能够帮助开发团队管理待办事项.产品发布和模拟项目冲刺.这款基于HTML5特性的工具提供创建图表和管理仪表板的功能,随着工作时间的走动,它可以追踪代码特性并修复bug.除此之外,Html5也是AxosoftOnTime

敏捷团队中测试人员的角色

Karen Greaves和Sam Laing将会在Agile Testing Days 2015上发表主旨演讲,演讲题目为"测试人员正在消亡",Agile Testing Days 2015将于11月9日至12日德国Potsdam举行.小编将会覆盖本次会议报道. 小编对二人进行了采访,关于敏捷是如何影响测试人员角色的,为了缩短测试交付周期,测试人员可以采取哪些措施,敏捷团队中测试人员与其他团队成员之间的协作,敏捷团队中测试人员可以贡献的价值. 小编:我的经验是,敏捷更广泛的普及率正在