400-888-5228

Scrum Master 认证是针对 Scrum Master(敏捷项目管理中的角色)的专业认证。Scrum 是一种敏捷开发方法,Scrum Master 则是负责指导和推动 Scrum 团队的角色。获得 Scrum Master 认证可以证明个人在敏捷项目管理方面具备一定的知识和技能,并且对Scrum方法有深入的理解和实践经验。这对于在敏捷环境中工作的项目经理、团队领导或相关专业人士来说,可能有助于提升他们在职场上的竞争力和专业认可度。

  • 中文名Scrum Master敏捷专家认证(CSM)
  • 英文名Certified Scrum Master
  • 英文简称CSM
  • 颁证机构Scrum Alliance(Scrum敏捷联盟)
  • 证书类别敏捷
  • 同类认证ACPITIL4 HVITDevOps

在当今的高速发展的商业环境中,敏捷,既能成为提升团队的灵药,也可能变成摧毁团队的毒药。它究竟是何种面貌,取决于我们如何运用它。

01_是“灵药”还是“毒药”?你们眼中的敏捷,到底是什么样子的?

普通程序员眼中的敏捷是什么样子的?曾经有学员跟小艾老师这样分(tu)析(cao)过:

1、很多公司老板之所以用敏捷,就是想让产品早点上线。以前瀑布式开发模式,一个项目起码一个季度,可敏捷模式一般 2 周就1个迭代。有时产品还没什么头绪,就要先做出能交付的_小版本。这就导致产品上线/产品迭代的节奏太快,程序员像是一直被上紧了发条。

2、对于程序员来说,如果完不成当天的工作,就只能加班。因为敏捷的站会是要当着同事们的面,说为什么没有完成,这很“丢人”,也很“不好受”。他推断现在一些互联网公司推行的996工作模式,敏捷可能也是一个重要的原因。

小艾老师觉得,不管怎么说,关于敏捷有三个事实,似乎不用争议:

  • 作为一个标签,敏捷是胜利者,因为没有人希望被称为“非敏捷”。
  • 但在实践上,虽然大家都说自己“敏捷”,其实可能并不是。团队容易陷入“假敏捷”的陷阱。
  • 虽然我们极力提倡敏捷(尤其是很多公司的老板...),但敏捷并不是_的,敏捷也有不适用的情况。

“敏捷开发”因为顶着“敏捷”两个字,常被作为解决“效率”问题的“灵药”,其实呢,敏捷开发中的敏捷,更多是“灵活”“灵敏”之意。指的是对“变化”能快速响应,而不是针对“效率”的。客观上来说,当你的团队拥抱敏捷,使用那些敏捷方法之后,你的团队的工作效率可能会提升,但也可能被降低。

敏捷的精髓在于拥抱变化以及快速响应的能力,它真正的核心是敏捷思想及原则,而不是啥工具、方法或者流程,更不是看板或者每日站会啥的。敏捷的价值在于把不确定的产品需求给落地,帮着用户搞清楚产品价值,交付_小能用的产品,然后在这个基础上小步快跑,快速迭代。所以,敏捷_适合那种“还不确定、还不完善、还没想清楚的产品需求”。要是那些目标、商业模式、需求都非常明确的项目,可能就不太适合敏捷了。

02_“真敏捷”还是“假敏捷”?如何用敏捷“搞垮”一个团队?

你们眼中的敏捷:是“灵药”还是“毒药”?如何用敏捷提升/搞垮一个团队? -- 第1张

真敏捷,意味着团队能够快速适应变化,不断交付价值,提高客户满意度。它强调的是灵活性、协作和持续改进。真敏捷的团队具有以下特点:

  • 紧密的协作:成员之间沟通顺畅,能够高效地合作。
  • 快速决策:能够迅速做出决策,避免繁琐的流程。
  • 持续学习:不断学习新的知识和技能,以更好地应对变化。
  • 客户导向:始终以满足客户需求为首要任务。

然而,有些团队可能只是表面上采用了敏捷的形式,而并未真正理解其内涵,这就是假敏捷。假敏捷的表现包括:

  • 形式主义:仅仅遵循敏捷的流程,而忽略了其精神。
  • 缺乏沟通:团队成员之间沟通不畅,导致信息传递延误。
  • 不注重质量:为了追求速度而牺牲了质量。
  • 无法适应变化:面对变化时反应迟钝。

敏捷方法,既能成为提升团队的利器,也可能成为搞垮团队的隐患。如何运用敏捷,是决定团队成败的关键。用之得当,即真敏捷,它可提升团队的协作、创新与响应能力;反之,若误解或错误应用,可能导致混乱、冲突和效率低下。

小艾老师整理了几种“用敏捷搞垮一个团队”的例子:

1、老板和团队都不了解敏捷

很多公司老板/领导为了产品早点上线,光想着“更快、更好、更省成本”, 但他们没明白,敏捷开发中的敏捷两字,更多是指对“变化”能快速响应,敏捷并不是“高效”的同义词。

2、只有技术团队敏捷,其他人不敏捷

技术开发团队可以实现快速迭代和反馈,但其他团队的工作节奏和沟通方式与之不匹配,导致协作困难和项目推进缓慢。

3、团队将敏捷视为一种潮流或时尚,而不是真正理解其原则和目的。

团队可能会随意选择敏捷实践并试图快速实施,而不考虑其是否适用于团队的具体情况。这种表面上的敏捷实践可能会导致混乱和不良结果。

4、团队试图用敏捷解决技术上的困难或挑战,而不是将其用于项目管理和团队协作。

团队可能会误解敏捷方法的适用范围,试图通过迭代开发来解决技术架构或设计上的问题,而忽视了团队协作、客户反馈等方面的重要性。

5、团队错误地认为敏捷不需要文档,导致沟通和知识共享的困难。

团队可能会忽视编写文档,导致项目信息不透明,沟通困难。缺乏文档也会使得新成员加入团队时难以理解项目和历史决策,影响团队的可持续性和成长。

6、团队技术能力较弱,无法有效地执行敏捷

团队可能会遇到频繁的技术障碍,无法按时交付工作成果。缺乏技术能力的团队成员也会导致无法有效地进行团队内部的知识共享和技术支持。

03_重新认识敏捷与Scrum,如何用敏捷“提升”一个团队?

敏捷方法有很多,比如:极限编程XP、Scrum、DSDM、自适应软件开发、Crystal、FDD、SAFe等等。很多其他体系也都融入了自己的敏捷,比如PMP(敏捷项目管理)、比如ITIL(高速IT)、比如TOGAF(敏捷架构)、比如CBAP(敏捷业务分析)等等…

但_重要的敏捷方法,莫过于Scrum。Scrum是目前_为成功的敏捷方法。

Scrum是用于开发、交付和持续支持复杂产品的一个框架,是一个增量的、迭代的开发过程。

你们眼中的敏捷:是“灵药”还是“毒药”?如何用敏捷提升/搞垮一个团队? -- 第2张 你们眼中的敏捷:是“灵药”还是“毒药”?如何用敏捷提升/搞垮一个团队? -- 第3张

图:Scrum框架

Scrum敏捷方法论展开来看,核心要素为“3355”方法论,即3个角色、3种工件、5个活动和5个价值观。

3个核心角色

1、产品负责人(PO)

负责_大化投资回报率(ROI),通过确定产品特性,把它们翻译成一个有优先级的列表,为下一个Sprint决定在这个列表中哪些应当优先级_高,并且不断地重新调整优先级和梳理这个列表。

PO的职责是定义需求,定义需求优先级,定义需求的验收标准,定义产品发布内容与日期。

2、Scrum Master/敏捷教练

帮助产品开发团队学习并应用Scrum来达成商业价值,为大家服务,会做任何力所能及的事情来帮助团队、产品负责人和组织取得成功。

对应敏捷团队中的项目经理,但并非是一个项目经理。职责是促进团队的工作,帮助团队熟悉和掌握敏捷的价值观与框架,帮助排除影响生产力障碍,确保团队不受打扰。

3、开发团队

建造产品负责人所指定的产品。对交付结果负责。

团队是“跨职能”的,它包含了所有专业能力,如开发、测试、需求分析等,并且它是“自组织”[自管理]的,被给予很高程度的自治和责任。

3个工件

1、产品代办列表(Product Backlog)

  • 产品代办事项,即产品视角的需求清单。
  • 由Product Owner 负责维护,包括增删及优先级排序
  • 用户故事是其中一种_佳实践
  • 每项需求都需要描述其外部价值

2、Sprint迭代代办列表

  • Sprint迭代代办清单,即此次冲刺周期内规划要完成的内容。
  • 来源于Product Backlog
  • 由团队评估和选择Product BackIog中哪些放入Sprint Backlog
  • 团队需要一起定义“完成”标准

3、增量(Increment)

  • 可交付产品增量(Increment),即冲刺结束后可对外发布的产品功能增量部分。
  • 需要关注其是可工作的软件功能增量
  • 需要在Scrum Review会议上进行展示

5个关键事件

1、冲刺(Sprint)

冲刺Sprint或迭代是一个特殊的事件,或者说其一个容器事件。后续四个事件包含在其中。

2~4周,固定周期,固定事件开始,固定事件结束。时间盒是其一个重要概念。

2、Sprint 计划会

Sprint规划会的核心议题是下一次冲刺要实现的目标和范围。

从Product Backlog中选取高优先级的需求,确定Sprint的目标,对产品backlog 中故事进行估算,以作为是否放入下期的参考。对于需求不清楚的故事,需要产品负责人进行说明。

会议中输入是Product backlog,输出是Sprint Backlog。

3、每日Scrum站会

站会的目标是促进信息在团队内共享与透明。每次15分钟左右,不对问题进行深入讨论,每天固定时间召开。

团队成员需要回答3个问题:

  • 昨天我做了哪些事情
  • 今天计划要做什么事情
  • 是否遇到问题,阻碍达成目标

4、Sprint 评审会

评审会在冲刺默契召开,检查本期的成果,需要团队全员参与,并邀请产品相关干系人对产品进行展示,若与产品负责人预想的不一样,产品负责人可以拒绝接收成果。

5、Sprint 回顾会

冲刺结束后,团队一起复盘本次冲刺的过程,总结经验与教训,并形成切实可行的改进清单。

5个价值观

1、开放 OPENNESS- Scrum把项目中的一切开放给每个人看

2、尊重 RESPECT- 每个人都有他独特的背景和经验

3、勇气 COURAGE- 有勇气做出承~诺,履行承~诺,接受别人的尊重

4、专注 FOCUS- 把你的心思和能力都用到你_的工作上去

5、承~诺 COMMITMENT- 愿意对目标做出承~诺,全身心投入去完成Scrum团队的目标,而不是必须按计划完成,两者之间是有区别的。

结束语

敏捷是数字经济时代人人必须具备的DNA,小艾老师建议大家都学一下敏捷。目前_为热门的、_为成功的敏捷方法(体系),莫过于Scrum,艾威常年都有开班,欢迎报名和咨询。

1、Scrum Master 敏捷专家CSM认证——适合程序员(Scrum团队中SM角色)

2、高级Scrum Master 敏捷专家(A-CSM)认证 —— 高阶版的Scrum

3、Scrum Product Ower敏捷产品负责人(CSPO)认证——适合Scrum团队中的PO角色

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

  • 2024-04-02 20:00
    数据治理工作:挑战与冲突、职责与目标以及谁做决定、谁向谁报告
  • 2024-04-10 20:00
    职场故事:敏捷,与时代同步的方法论
  • 2024-04-11 20:00
    从战略规划到执行的全生命周期
  • 2024-04-16 20:00
    职场故事:工作中,我是怎么用到PMP学到的知识的?vision/mission/hoshin/projects...
  • 2024-04-17 20:00
    管理你的IT团队:管什么,怎么管,IT部门的管理思路
  • 2024-04-18 20:00
    市场洞察方法:从孤立的数据到市场预测,产品研发前需要做哪些调研工作?
  • 2024-04-23 20:00
    职场故事:PMO项目经理避“坑”指南 我总结了一些项目沟通中“argue”的技巧...
  • 2024-04-24 20:00
    信息安全解密大拆解①:长治久安,信息安全治理
  • 2024-04-30 20:00
    开发说“这个需求做不了”,怎么破?需求分析的逻辑及关键技巧
  • 更多直播讲座
    小艾老师还在安排中…
查看全部 >

扫码一键预约全部

查看更多 > 查看更多 >

数字化转型8大核心认证

  1. PMP项目管理认证

    艾威最近一期班: 针对2024年08月考试
  2. CBAP业务分析认证

    艾威最近一期班·开课时间: 2024-05-25
  3. CBPP流程管理认证

    艾威最近一期班·开课时间: 2024-06-15
  4. ITIL4 IT管理认证

    艾威最近一期班·开课时间: 2024-05-25
  5. TOGAF企业架构认证

    艾威最近一期班·开课时间: 2024-05-25
  6. CDMP数据管理认证

    艾威最近一期班·开课时间: 2024-05-25
  7. CISA信息安全审计师认证

    艾威最近一期班·开课时间: 2024-05-12
  8. CISSP信息安全专家认证

    艾威最近一期班·开课时间: 2024-06-15
近期课程安排