今天参加了吕毅老师的Scrum Master 培训的课程。吕老师是国内第一个Scrum Certified Trainer, 果然有大家风范,讲课相当生动,presentation skill 相当 sophisticated。虽然自己实践SCRUM已三年左右,期间也从事过SCRUM Master的工作但依然觉得受益颇深。现就讲课内容作一回顾:
1. 先对两天的课程作了大致的Agenda介绍
2. 就大家对SCRUM的熟练程度进行了一个自我管理的排队,熟悉的排前面,然后交叉分组,保证每组都有对SCRUM不同熟悉程度的队员。
3. 小组成员自我介绍,并提出对SCRUM的最大疑问
我个人提出的疑问是,作为Scrum Master但权利有限,如何控制sprint中被强行加入的task ?
后来在听课过程中得到了答案,scrum 不仅仅是R&D部门的事,而是整个公司的事,一个无法决定自己workload的team是无法适用scrum的。而作为PO应该承诺不干预sprint的内容,最多在极少数情况下异常中止sprint.
作为PO,关心的粒度应该比较组:
PBI(product backlog item ) instead of task
Sprint instead of day
Team instead of person
因此可以带多个团队。
4. 介绍SCRUM的历史与敏捷宣言。其中四个价值观:
a. 个体和交互 胜过 过程和工具
b. 可以工作的软件 胜过 面面俱到的文档
c. 客户全作 胜过 合同谈判
d. 响应变化 胜过 遵循计划
对于第二点我有些自己的体会。曾经听培训过SCRUM的同事回来跟老板changllenge不该写文档,因为SCRUM培训老师如是说。 当时就觉得不应该这样,但一直没找到“理论依据”反驳,现在想来应该是他误解了Agile的价值观,workable software是比文档重要,但不是说文档不需要。况且只是比面面俱到的文档重要,当然这里“面面俱到”翻得有些争议,原文是“comprehensive document"。
5. 以老板指挥员工走路和员工自己走路(在指定区域内一伙人一起走)看哪种方法在规定时间内走的步数多的游戏强调了在有约束条件下的自我管理的有效性。
6. 以野鹅南徒举例讲解了经验型(也就是inspect & adapt)的流程对复杂项目比较适用。并讲述了,检查,透明性与适应是SCRUM的三大支柱。
7. 讲述了美国FATBURGER将死松鼠肉做的汉堡卖给只出得起1.6美元的顾客的案例,试图说明我们不应该为顾客去决定风险。其实就是为了说明我们的项目需要有足够的透明性。
8. 讲述了SCRUM的整个work flow和role. PO --> Product Backlog --> Sprint Planning --> Sprint Backlog --> Sprint --> Daily Scrum --> Scrum review and retrospective meeting. 然后让大家列举出原来项目经理的职责,以用在SCRUM中应该由哪个role承担。从而将SCRUM中的三个role的职责阐明了。 PO focus在release上,以ROI为导向,要考虑版本的时间,收益,成本。
9. 提供一个具有一定风险性的案例,让大家扮演不同的竞标公司,而吕老师扮演招标公司老板。结果大家不约而同地为了夺得这个票,从而隐瞒了风险。讽刺的是大家的作法与FATBURGER卖汉堡的案例如出一徹。以此进一步说明透明性的重要性。
10. 以遗留代码的产生,及其维护代价说明其危害性。从而引出什么才是"done"的概念。
就这点来说个人还是蛮有体会的,很少有公司定义的”done"能真正包含软件部署前所要做的所有事的。
作为SM应该始终保证"done"不被破坏。
11. 详细讲解了sprint plan , sprint backlog, daily scrum, scrum review & retrospective meeting。
Sprint的长短视项目/产品需要适应变化的程度决定,一般互联网公司应该在2周左右。
Sprint Plan -- 需求层面 (what & why ) --> PO 定义 Acceptance Criteria
先分散,再合并。每组分别对不同的PBI写出:Question, Assumption, Scope以及AC,再合并。
-- 设计层面(how & how much) --> team
Done X AC --> 工作量。
2周的sprint --> 1天的 task。调整更快捷。任务不要在planning时分配而是在每天分配。
Burning down chart & task board. 期间可以根据进度调整PBI的出入。
Daily SCRUM: Done ? To do ? Problem ?
Scrum Master组织daily scrum 应避免任何人成为中心。强调team自管理。
SM小技巧: 1. 避免与汇报者眼神交流 2.围着task board开会 3. 录音,寻求feedback看哪些内容对大家有用
Review Meeting :
1. 总结。 根据 done 的定义来看,哪些完成哪些没完成。
2. Demo 对比AC, 并要求PO或客户给feedback。如果请不到客户可以请公司内部最接近客户的同事参加
3. 调整 release , 画release burning down chart.
Retrospective Meeting :
0. 看上次提到的问题有没有改进,如果没有,反思为什么。
1. Set the Stage --> 开场白,说明会议的目的,流程,时间
2. Gather date --> 时间线,大家按时间轴写出重要事件或有问题的事件。 心情曲线,大家画出自己心情在sprint中随时间的变化。 从而找出整个team的主要问题
3. Generate insight -->分析问题的原因
4. Decide what to do
课上大家问题很多,吕老师不厌其烦地讲解,导致课程时间不够用了,回家后看了看讲义,发现有很多内容都来不及讲。但不管怎么说吕老师还是非常nice的一个人。
分享到:
相关推荐
Development with Scrum, and take advantage of the many excellent Scrum training and coaching options that are available; full details are at scrumalliance.org. Our thanks go to Ken Schwaber, Dr. Jeff ...
Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要
《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间,把自己近...
Scrum 是一个轻量的框架,它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织 创造价值。 简而言之,Scrum 需要 Scrum Master 营造一个环境,从而: 1. 一名 Product Owner 将解决复杂问题所需的工作...
Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程.。在这个框架中,整个开发周期 包括若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的建议长度2到4周。 在Scrum中,使用产品Backlog来...
It talks about scrum framework and how Scrum master works with team
是关于开发框架模型Scrum的介绍,Scrum是一种新的不同于瀑布模型的开发模型,很适合现在开发人员进行开发!
scrum及常见问题 ,scrum及常见问题处理解决办法等等
5分钟了解Scrum 只需一点点时间了解scrum
INTRODUCTION TO SCRUM SCRUM THEORY SCRUM CONTENT
SCRUM敏捷开发规则一栏
Scrum 讲座讲解如何应用scrum的流程, Scrum 讲座讲解如何应用scrum的流程
Scrum 是一个轻量的框架,它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织 创造价值。 简而言之,Scrum 需要 Scrum Master 营造一个环境,从而: 1. 一名 Product Owner 将解决复杂问题所需的工作...
scrum书籍
SCRUM Professional Scrum Master II题.docx
Created by Scrum.org—the pioneering Scrum training and certification organization founded by Scrum co-creator Ken Schwaber—Nexus draws on decades of experience to address the unique challenges ...
Scrum XP Agile
很全面的介绍scrum的教材,难得的一本好书 1、Scrum起源 2、导入Scrum模型的先驱 3、Scrum框架 4、现状 5、为什么会失败
《Scrum敏捷项目管理》探索Scrum的每一方面,包括科学原理、全新的项目角色及责任、ScrumMaster、产品负责人、如何有效管理未知因素和不断变化的产品需求、如何结束混乱、如何计划和报告、及如何扩展项目团队规模等...