今天是CSM培训的第二天,看得出大家经过一天的培训今天稍许有些疲惫。。。
1. 首先,吕老师回顾了一下昨天的讲课内容,并对大家提出的问题进行了一定的解答。有一个问题吕老师说在今天讲课之后会提到,就是SCRUM中并未提及绩效管理,采用scrum后绩效管理应该如何进行。
后来到课程的最后吕老师提到,有一本书曾经说过,考评并不能带来任何效益,但我们现实中却无法避免考评。他作为SCRUM团队的Mgr,他是这样做的:
a. 由于SCRUM团队应该是自管理,自问责,不区分角色的,所以团队整体的表现应该占50%
b. 30%来自团队成员,PO, SM的评价
c. 由于SCRUM强调 Generalizing Specialist , 20%来自考察该成员除了自己主要的职能外,对团队其他成员的职能是还也掌握了相关基本水平。
2. PO 和 Product Backlog.
PO 应该主要考虑ROI,也就是两个主要的维度:价值和成本。在做版本计划时,对时间,成本,范围进行权衡。传统模式是先确定范围,然后根据范围确定时间和成本,但在SCRUM中,一般是先确定时间与成本,然后据此决定范围。
Product Backlog中每一项叫PBI(product backlog item),而User Story/Use Case 只是PBI的描述形式。每一个PBI都应该估计他的价值与成本。根据价值排序。在product backlog中一般情况下自上而下为已经完成的,细粒度的,粗粒度的,下一版本的PBI。
好的Product Backlog应该满足:D(Detailed Appropriately)E(Emergent)E(Estimated)P(Prioritized)
PO应以 高价值低成本,高风险高价值的PBI优先。团队可以贡献和讨论PBI,但优先级最终应由PO决定,哪怕是错误的,可以让问题及早暴露。
PO 在做release 计划时,先和团队估算版本中的所有PBI的点数,然后根据版本时间,及以往的经验速率,可以得到期望的版本燃尽图。如果没有经验速率就先做两个sprint再得到实际速率。 Release plan 不是team对PO的commitment,也不能以实际版本燃尽图作绩效考核。
在发现实际版本燃尽图中完成速率与期望差太大时应及时调整。由于Release不是timebox,我们可以:
1) 延长版本时间
2) 减少PBI
3) 增加团队 (最好是在早期加入,后来发现多作可以撤走,但如果加入太晚反而成为累赘)
4) 改进办公条件,开发环境等,从而提高速率。
在Sprint中间,应预留相应的时间(2周的sprint, 大概半天),进行product backlog梳理。主要是对近期将要做的项目进行需求分析,进一步分解,重排优先级,重估故事点。最好是放在一个sprint中间某周的开始和结束。这样不会干扰团队,PO也有时间进一点和客户沟通。
分解PBI时就根据以下原则:
1)按功能分解(instead of module) ,关键能否交付
2) 分解后的PBI工作量比较平均
3) 分解后的PBI优先级分明
打牌确定PBI的故事点数。
1)故事点数为Fibonacci数列,这是为了做故事点数越大,不同点数之间的差距越大,区别更明显
2)先择倒数第二小的PBI作为2
3)大家估计很不一致时,让最大最小者发言分析,再重出牌
4)大家估计差不多时取较大者。 (注意,task的估值一般取平均)
写User Story 时应遵循的原则:
1) Card : As ( XXX role ) , I'd like to (XXX function), the value is XXX
2) Conversation: PO & Team的对话, PO & Customer的对话
3) Confirmation : 怎么算做完了(AC)
3. Scrum Master ---- Facilitator
不是管理者,不是决策者而是促进者。Facilitate 整个团队做好SCRUM,协助团队提高工作效率,增进合作。
多问团队,少做决定。
4. Scrum 团队
自管理,自问责,跨职能
5. 讲了一些工程实践,主要是ATDD和CI
6. Scrum Master的秘密~~~ 左手,顶脚,woof~
今天的时间有点紧,主要是由于中午上菜过慢浪费了半小时。无论怎样还是觉得收获颇丰,能认识挺多人,有机会走入SCRUM community,很值啊:)
分享到:
相关推荐
Scrum Master Training的课程内容涉及了Scrum框架的核心概念以及Scrum Master在团队中的工作方式。Scrum是一种敏捷开发方法,它通过短周期的迭代开发来提高产品或项目的交付效率。Scrum团队通常由跨功能的成员组成,...
* Inadequate Training:Scrum Master 和团队成员缺乏足够的培训和经验,导致 Scrum 框架的实施不成功。 * Insufficient Top-Down Support:组织高层领导不支持 Scrum 框架的实施,导致 Scrum 框架的实施不成功。 ...
Scrum会议共有四种,分别是Sprint计划会议、每日站立会议、Sprint回顾会议和Sprint复盘会议。Sprint计划会议用于规划下一个Sprint的工作;每日站立会议是团队每天简短的会议,用于报告进度和协调工作;Sprint回顾...
检查列表通常包括各个角色(如产品负责人、Scrum Master和开发团队)的任务和责任,以及Scrum的各个事件(如冲刺计划会议、每日Scrum、冲刺评审和回顾会议)的执行步骤。这些清单可以帮助团队保持对过程的专注,并...
### Scrum Master 认证考试知识点解析 #### 标题:Scrum Master 认证考试原题 **解析**:本题目集旨在帮助考生通过Scrum Master (CSM) 认证考试,该考试评估考生对Scrum框架、原则及实践的理解与应用能力。 #### ...
#### 二、Scrum的核心价值观与原则 Scrum的核心价值观体现在《敏捷宣言》中,即重视个体和互动胜过流程和工具;重视工作的软件胜过详尽的文档;重视客户合作胜过合同谈判;重视响应变化胜过遵循计划。这些价值观...
3. 每日Scrum站会:每天举行,团队成员相互同步进度,提出当前遇到的问题,计划接下来的一天要做的工作。 4. Sprint评审会议:在Sprint结束时举行,用来演示完成的工作项,获取反馈,并且讨论产品的未来方向。 5. ...
Scrum是一种敏捷开发框架,由Ken Schwaber和Jeff Sutherland在1990年代初创立,主要用于应对复杂的项目管理问题,特别是在软件开发领域。2010年,他们发布了首版Scrum指南,以帮助全球用户理解和应用Scrum。随着时间...
在Sprint期间,团队将执行所有的Scrum活动,如计划会议、每日站会、回顾会议和Sprint演示。 Scrum框架的关键角色包括: - 产品负责人:负责维护产品待办事项列表(Product Backlog),明确产品愿景,并确定待办...
#### 二、Scrum 的企业级应用 ##### 1. 实施背景 - **当前状况**:企业内部可能存在一些部门或团队已经在使用 Scrum,并且这些团队相较于其他部门表现得更为高效。 - **目标**:希望通过在整个企业范围内推广 ...
scrum及常见问题 ,scrum及常见问题处理解决办法等等
在实践中,团队成员需要对Scrum有深入的理解,包括角色(如产品负责人、Scrum Master、开发团队)、事件(如冲刺计划会议、每日Scrum、冲刺评审和回顾)以及工件(如产品待办事项列表、冲刺待办事项列表、增量)。...
Scrum中的会议主要包括Sprint计划会议、每日站立会议、评审会议和回顾会议。Sprint计划会议发生在每个Sprint的开始,用于确定冲刺的目标和需要完成的任务。每日站立会议是团队每日进行的简短会议,用于报告进度和...
"Scrum专业Scrum Master II题库" Scrum是一种敏捷项目管理方法,旨在帮助团队更好地协作、更快速地交付价值。Scrum Master扮演着关键角色,是Scrum团队的 facilitator、 coach和servant leader。Scrum Master负责...
#### 二、Scrum基本概念 1. **Sprint**:Scrum中的一个短周期迭代,通常持续1至6周。在此期间,团队致力于完成一系列预定义的工作项目。 2. **Product Backlog**:产品待办事项列表,包含了所有已知的工作项,按照...
3. **事件**:Scrum有四个关键事件或仪式:Sprint计划会议、每日Scrum站会、Sprint评审会议和Sprint回顾会议。这些会议促进团队间的沟通、协作和自我改进。 4. **透明度**:Scrum强调信息透明,通过信息看板(如...
每日站立会议是Scrum团队每天进行的短会议,用来检查前一天的工作进度,计划当天的工作。这是为了保持团队成员之间的沟通和同步。 Sprint评审会议在Sprint结束时举行,目的是向利益相关者展示在Sprint期间完成的...