2012年10月3日,星期三07:10

让我们结束关于Scrum Master与Project Manager的辩论

Written by

10月3日在过去的几年中,由于大多数组织都在进行敏捷转换,因此对于项目经理的角色一直存在很多争论和困惑。实际上,行业数据表明,大约有53%的组织正在将敏捷方法与Waterfall融合在一起。[1] 

这种巨大变化的结果是项目经理离开了组织。 PMO已被解散-全部归功于引入了敏捷开发方法。项目经理并不孤单。敏捷的引入也极大地影响了产品经理的角色。组织同时努力理解产品所有者的角色。

我无法告诉您我已经阅读了多少篇文章以及关于这些主题的LinkedIn帖子。最好的材料是项目经理不是Scrum Master,反之亦然。尽管在这些讨论中对Scrum Master角色的描述通常很清楚,但是没有人能很好地说明两个角色(Scrum Master和Project Manager)如何共存,或者这种角色混淆是如何开始的。 。

老实说,我真的从不理解这场辩论。我早在2001年就开始使用XP(极限编程)执行项目,而团队成员在项目执行期间的角色混淆方面从未遇到任何问题。敏捷不是邪恶的-敏捷行之有效。好吧,快进到2012年了,争论还在继续。我终于厌倦了观看不断的辩论,并决定采取行动。我参加了课程,通过了测试,并成为了认证的Scrum Master。在花掉所有的金钱和时间之后,我可以肯定地说,我不是Scrum管理员,而是项目经理! 

从根本上讲,我认为辩论的根本原因不是基于Scrum主管还是项目经理,而是基于我们对项目的基本定​​义。在具有最低限度可销售功能(MMF),产品积压和持续集成的敏捷世界中,传统项目的界限现在变得模糊了。我发现Scrum团队对产品负责人和Scrum负责人的职责没有任何问题,但是由于某种原因,整个项目团队都不会对项目经理负责。

我写这篇文章的目的是一劳永逸地结束混乱和辩论。为此,我需要提醒您什么是项目经理,以及两个角色应如何共存。让我在表格上获得一些快速定义,以帮助构建我们的对话:

Scrum Master-Scrum Master专注于开发过程并指导Scrum团队。 Scrum管理员的主要职责是:

  • 维护并消除障碍
  • 管理Scrum流程,使流程正常运行
  • 计划发布
  • 计划冲刺
  • 将团队与外部接口隔离
  • 根据要求促进Scrum会议
  • 确保参与项目的每个人之间的沟通清晰
Scrum Master通常是团队负责人。理想情况下,Scrum Master应该具有以下技能的良好平衡:
  • 技术专长
  • 了解产品负责人的意图
  • 优秀的团队合作者和指导者
  • 了解团队能力
  • 一个很好的动力
  • 问题解决

现在,通过定义一个项目和一个程序,来进一步了解该程序以及项目管理的角色和职责。

项目:为创建独特的产品,服务或结果而进行的临时性工作。在大多数组织中,我们的“临时工作”的界限是通过我们的业务案例来定义的。

计划:旨在实现特定结果的一系列相关项目。

简而言之,项目经理的角色是管理项目的所有方面(启动后支持的想法),以实现在既定业务案例(投资)中确定的预期结果,而不仅仅是Scrum团队。业务案例的规模,范围和复杂性将决定项目的规模。要实现投资中要求的结果,可能需要执行一系列相关项目,称为计划。此时,程序经理现在负责管理程序的各个方面,而项目经理和其他负责人员则负责管理较小的项目部分。

目前,“临时”有三种,可能是四种基本类别:

    1. 产品线执行–相对于1年计划周期的临时执行。基本上涵盖对现有产品线的较小增量增强。
    2. 大型定制项目/新产品开发
    3. 在产品线内–特定的临时计划/项目。例如,SQL Server升级。
    4. 跨组织计划-想到的例子包括品牌重塑,ICD-10(医疗保健),数据中心迁移等。

大多数组织的这些项目/临时工作通常是这样的:

starkeoct3rd1

看起来像这样……

starkeoct3rd2
看起来像这样……

starkeoct3rd3

如果这是一个项目,那么项目经理必须是负责所有工作的负责人(或负责理解和管理我们如何在每个圈子中获得上述问题的答案)–他们是不负责回答问题!

简而言之,项目经理负责将所有设备组合在一起以实现期望的结果。他们可能负责也可能不负责管理单个盒子。各个邮箱的责任通常由主题专家来完成。

如您所见,敏捷开发和Scrum团队只是一个盒子!

具体来说,项目经理负责:

  • 了解项目的预期结果并确保结果是现实的和可衡量的。他们需要了解业务案例的预期结果!
  • 与团队合作定义工作范围(例如,在上方每个彩色框下,其中的内容,预期的结果是什么),负责人以及何时将其交付。特别:
    • 完成所有项目工作所需的可交付成果
    • 跨职能资源分配
    • 估计完成工作以及工作项之间的依赖关系
  • 了解与工作相关联的每个职能团队的负责人(每个彩色框)以及如何分配他们来管理他们的工作。如果存在分配带宽问题,那么此人将负责简化和最终解决资源问题。
  • 项目经理的工作是通过清楚地将活动与时间相关的预期结果进行规划,消除角色和职责上的歧义。预先确定可交付成果和职能团队之间的相互依存关系,可以更好地确定相对于整个产品开发过程,应该更整合哪些团队以及何时进行整合。 

重要说明:如果工作范围足够大,则可以将另一个项目经理/人员分配给特定项目(小方框)。该关系将是从另一个人到项目经理的虚线。

换句话说,如果上面每个较小的框都足够大,可以视为自己的项目,则该程序将由几个相关的较小项目组成,这些较小的项目汇总在该程序下。

    • 例如。硬件或软件的采购,安装和配置– Application Operation Project Manager
    • 例如。敏捷产品开发–产品所有者/ Scrum Master
  • 了解与业务案例中确定的结果相关的管理工作范围所需的过程和工具。了解指标以及实现这些指标/目标的过程。
    • 如果确定的度量标准是在一定的资本预算内完成项目,则项目经理负责理解预测和跟踪工作所需的工具和过程。他们不负责创建或建立这些流程-除非当然将创建确认为另一个项目!
  • 项目经理负责有关项目的整体沟通(而不仅仅是产品的开发部分)。它们是唯一的权威信息来源,可确保对所有参数有共同的理解:
    • 范围
    • 成本管理
    • 定时
    • 假设/约束
    • 风险/问题
    • 资源资源
    • 质量
    • 特殊注意事项/例外
    • 开发方法的考虑
    • 团队成员以及相关角色和职责
    • 政策和程序

因此,如果您同意以上所有条件,那么这两个角色之间是否真的存在争议?

无法通过Scrum Master培训,由我来负责项目经理的所有职责。它只是不可原谅的,并且会导致最终的项目失败。为了使记录更清晰,项目经理不是Scrum Master的代名词。 Scrum Master对于促进和执行Scrum团队至关重要。但是他们不负责产品开发项目的所有组件。如果有的话,作为报告结构的一部分,Scrum管理员应该是项目经理的虚线。 

但是,要使所有这些关系协同工作,我们还需要知道团队对项目经理的责任。

本质上,项目经理必须知道项目过程中发生的所有事情,才能确定针对任务和可交付成果是否正在采取正确的行动以及必要的进展。将每次会议和每项操作都纳入项目经理的日程安排是不现实的。但是,他们仍然需要知道正在举行什么会议,以及何时需要进行沟通和决策,以确保团队相对于项目的商定范围和成功标准而有效地开展工作。

项目经理与团队之间的这种关系并不是基于命令和控制,而是基于信任和优化协作。如果项目经理有机会管理这些职责,而又没有对大多数(如果不是全部)团队资源的授权,那么他们需要依靠那些团队负责人来获得基本和基本信息。以下是整个产品团队(包括项目经理)的特征:

  • 对诚实的任务和可交付的进展持开放态度
  • 经常不断的沟通
  • 致力于达到成功标准
  • 勇于说实话
  • 互相尊重
我将Scrum团队职责页面借给产品所有者和Scrum主管,我对职责进行了定制,以使它们反映整个项目团队相对于项目经理的作用:
  • 交流有关需求,MMF,冲刺积压项目和任务的优先级(和变更)的信息
  • 根据商定的里程碑对结果的承诺
  • 传达实现用户故事和任务以完成所有项目可交付成果的工作量估算
  • 任务与团队成员之间的依赖关系沟通
  • 识别障碍,并通知项目经理何时可能发生这些障碍以及何时发生。
  • 自组织–项目中的各个团队必须具有自组织能力,并且不能依赖指挥和控制风格的项目经理。但是,自组织意味着要告知项目经理团队如何自组织以及他们打算如何完成工作。项目经理需要对此有一个合理的了解。
  • 团队有权在项目准则范围内做所有事情以实现项目目标。

在产品开发领域,项目经理比以往任何时候都对成功执行和交付项目/产品至市场至关重要。角色明确和协作至关重要。项目经理和Scrum主管应相互协作,而不是相互对抗。如果我们能够正确地定义项目,并且可以将团队的职责重新落实到项目经理,那么我可以自信地说:“项目经理,无需担心工作安全性。您仍然是组织的重要成员。如果有的话,通过引入Scrum管理员和产品所有者角色,您的工作变得更加轻松。”  Happy delivery!

不要忘记在下面留下您的评论。


[1] 产品团队绩效研究,2012年,Actuation Consulting LLC和Enterprise Agility Inc. 

史蒂文·斯塔克

史蒂文·斯塔克 是S.T.O.P.的作者–项目管理生存计划。他目前是Starke Consulting的创始人和VP副总裁 他在Actuation Consulting致力于开发产品团队合作的培训材料并促进产品开发的职业。

©ProjectTimes.com 2021

麦格雷戈徽标白色网站