zoukankan      html  css  js  c++  java
  • Scrum 敏捷实践中的三大角色

    SuperBowl

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

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

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

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

    产品负责人(PO)

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

    PO

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

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

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

    ScrumMaster

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

    ScrumMaster

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

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

    开发团队(TO)

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

    TO

    对比而言,作为开发团队的 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 概念,在以后的分享中会再拎出来说一说。

    OKR

    团队的人数一般会控制在 10 个人以内,这样便于降低沟通成本嘛。

    那敏捷的跨职能开发团队于企业来讲还是有代价的,简单地说就是资源问题,同一个角色被安排到某一个团队时,那他至少在最近的一到两个迭代都是跟着这个团队走的,别的团队如果需要人手那资源就不够,不够就得招人,而招人就会促使人力成本增加。

    另外,在开发质量层面上,TeamLeader 会组织整个开发团队开展 CodeReview 代码评审会、新知识培训,以及与运维方一起完善 CI/CD,也就是持续集成和持续部署。

    对待会议的态度

    好,介绍完这三种角色,我们会发现敏捷实践中,开的会可是不少的。
    好处就是,在两周一个迭代的周期里,通过会议的交叉可以将需求吃得很透。要说会议多而浪费时间也可以这么讲,之所以要这么做,主要就是说它能克服开发人员的一个隐性问题,就是“都不太喜欢学习业务知识”,通过多频次需求的讲解和鞭策,在最终交付的时候,做出来的东西基本都是靠谱的。
    不然,十天半个月过去了,交付的东西要是无法向产品负责人 PO 交代,PO 就无法向业务部门交代,结果就是公司层面无法向最终用户提供服务,一环扣一环。
    因为会议的本质是共识的达成,这个也算是一点点的大局观吧。

    共识

    好,今天先简单介绍了 Scrum 敏捷框架里的三大角色,下一次再和大家分享更多关于 Scrum 的故事。

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

  • 相关阅读:
    vim配置----YouCompleteMe配置
    Linux之configure make make install
    zookeeper原理与实践(一)----zookeeper的基本功能
    RPC原理与实践(二)----Thrift分层模型
    RPC原理与实践(一)----RPC原理与实现(Thrift版)
    mysql由浅入深探究(四)----mysql事务详解
    mysql由浅入深探究(三)----mysql增删改查
    mysql由浅入深探究(二)----mysql用户操作
    Django
    7.1
  • 原文地址:https://www.cnblogs.com/ramantic/p/12401995.html
Copyright © 2011-2022 走看看