周金根:个人敏捷的创立与详解Scrum会议

原创
开发 项目管理
在敏捷实践中,Scrum可以说是用于运行项目的框架,它基于敏捷的原则和价值。对于管理严格的项目团队,Scrum会议也会每天都在同一时间进行。通过每日Scrum 会议,团队成员之间可以彼此相互熟悉工作内容,充分了解项目进度,相互帮助解决问题。那么,在Scrum中的Sprint计划会议应当如何进行?记者采访了敏捷个人创立者,周金根老师跟网友们谈谈Scrum的实施与Sprint计划会议。

【51CTO专稿】在敏捷实践中,Scrum可以说是用于运行项目的框架,它基于敏捷的原则和价值。对于管理严格的项目团队,Scrum会议也会每天都在同一时间进行。通过每日Scrum 会议,团队成员之间可以彼此相互熟悉工作内容,充分了解项目进度,相互帮助解决问题。那么,在Scrum中的Sprint计划会议应当如何进行?记者采访了敏捷个人创立者,周金根老师跟网友们谈谈Scrum的实施与Sprint计划会议。

[[68705]] 

个人简介:周金根,个人成长教练,软件产品架构师,培训师,敏捷个人创立者和推广者。

以下内容为采访实录:

记者:请问你是如何接触到敏捷开发的?敏捷个人的创立是出于什么样的想法?

周金根:最早我们是采用RUP开发的(可以看看从IT方法论来谈RUP),我记得在一个产品设计阶段,我们使用Rose画了很多图,但是最终开发的时候其实没有人去看;更为重要的是,产品交付之后需求变更很多。这之后,我就开始关注软件全生命周期的方法、技术和工具,于是了解了敏捷。最早是XP,然后是Scrum。08年我去了一个新的项目组,这个组没有开发流程方法,也不知道如何做需求,于是我在这个组实践了一些新的方法,其中包括Scrum。在Scrum的实施过程中,我发现并不像最初想象的简单。看似简单的流程和角色,真正要发挥功效并不容易,除了技术能力之外,我还需要让自己学习更多管理方法,更需要自己深入领悟敏捷管理背后的东西。对Scrum的深入思考,我越发觉得团队中每个人的成长是敏捷发生效果的动力,这让我对个人管理这个话题有了更加浓厚的兴趣,于是把自己在个人管理和个人成长方面的思考写下来,并在团队中学习和实践。团队中的成员有自发打印出来给家属学习的,也有主动参与讨论的,以及后期社区对敏捷个人的认可,这都鼓励和激发我慢慢系统化的思考个人成长,并提出了敏捷个人。 经过两年多的思考,目前敏捷个人已经是一个较为体系的个人成长框架,它可以帮助个人成长,并促进敏捷团队的形成。

记者:请问敏捷开发是否真的能解决传统开发的一些问题?如何去认识敏捷的根本?

周金根:从瀑布到敏捷,我们已经发现产品更适合用户、质量越高、上市时间也越短,敏捷顺应不断变化的时代,是否能解决传统开发已经不是一个问题。对于敏捷,我认为其根本在于学习和适应,这也是拥抱变化需要具备的两项最重要的能力。

记者:团队的敏捷实践与管理是分不开的,您是怎么看目前国内的管理?

周金根:在没有敏捷之前我们就在管理,但在敏捷盛行的时候,有些管理者就分不清敏捷和管理了。其实我不太在意某种***实践出自哪种敏捷方法,我认为只要有利于当前团队的实践都是管理的一种工具,也就是说,作为管理者,我们仍需保持更大的视角,敏捷仅是管理的一种工具,我们还要学习目标设定、流程优化、团队建设、个人成长等更多管理方法。

记者:有些人认为敏捷开发并不适用于水平一般的程序员或团队,您是怎么认为的?

周金根:任何方法都不是银弹,也说明了没有一种方法是***的。既然没有***的方法,那自然也不必是***的人去执行了。水平高的程序员在技术实践领域的敏捷固然可以做得更好,但一个产品的失败大多数都不是因为你是否采用了测试驱动、结对编程等***实践,而是开发管理上的问题。Scrum作为一种敏捷方法,背后具有很多管理思想,只要管理者和团队对Scrum有进一步的思考和认识,也可以很大程度上去提高技术水平一般的程序员团队。

周金根:敏捷方法在国内实施起会导致项目管理原有模式的改变,而很多公司都没有达到敏捷的目的。以致公司往往不愿意引进这样的开发模式。您怎么看待这个问题呢?

回答:从公司角度来说,你能把软件越快越好的做出来就可以了,至于采用的是敏捷还是瀑布并不重要。与其说是公司不愿意引进这种模式,不如说是软件开发负责人不愿意或者没有能力引进新的方法。敏捷开发相对来说已经比较成熟,我认为现在不是讨论是否愿不愿意引进这种开发模式的时候,反而是思考如何引进的问题,这不仅仅是技术实践,还有管理,甚至是个人成长方面的改变。

记者:团队的人数对于敏捷开发有何影响?如何进行拆分?

周金根:人数的规模会带来团队的复杂性,随着人数增加,管理、沟通等都会越来越困难。而保持7±2人左右的小团队,可以更利于团队的形成。在这样的团队中,人与人之间都更为熟悉,协作起来就更容易。那这样的小团队由哪些人组成呢?这也需要根据产品的规模来定。对于一个小型产品,这个团队将由市场、需求、开发、测试等人员组成全功能性团队;如果产品属于中大型,那有可能会形成单一功能性团队,再由多个这样的团队组成一个大的敏捷团队,由这个大的团队来实现对客户的交付。

记者:敏捷实践过程中Scrum实施整个过程怎样规划。

周金根:实施Scrum,我们可以采用类似学习一样的过程,首先完全按照Scrum流程执行;然后再根据执行后的效果进行自我裁剪和补充;***淡化Scrum的概念,与更大范围的软件产品周期过程融合起来。

记者:敏捷开发的方法内有很多不同的程度,而几乎每个敏捷开发团队都有scrum会议,在您们的团队中是如何进行的?

周金根:沟通在任何团队都是必不可少的,而会议是其中一种。我认为Scrum中的Sprint计划会议是最重要的事件,这确定了每次迭代的目标。回顾会议是第二重要的事件,因为这是团队做改进的***时机,如果没有回顾,就会发现团队在重犯相同的错误。如何进行可以看看我之前写的几篇blog:

1、Scrum之 Sprint计划会议(以下内容摘自周金根博客)

在sprint***天召开sprint计划会议,这个会议分为两部分,计划会议1由PO、SM和Team参加,主要是从产品backlog中挑选出需要放到当前sprint下的既定产品backlog,然后由SM、Team参加计划会议2,把既定产品backlog的故事拆分成任务进行估算,PO也可以一起参加这个部分来了解具体的开发细节。以下我将把会议主要内容罗列一下。

会议内容

sprint计划会议1

产品负责人和团队一起,在先前评估的成果基础上,定出 Sprint 目标和既定产品Backlog。

目标

定出 Sprint 目标和既定产品 Backlog

会议准备

  • 邀请与会者:产品负责人、Scrum Master、团队所有成员
  • 已按优先级排列产品 Backlog 中各项问题
  • 已评估 Backlog 中的各项问题
  • 把产品 Backlog 公开给会议中的每个人,保证其可被获取
  • 预期团队中有哪些人已明确会缺席(如度假)
  • 保证房间环境适合小组讨论
  • 每个人都可以获取上次 Sprint 评审会议和 Sprint 回顾会议的结果
  1. Sprint 时间表已经安排
  2. Sprint 计划会议 1 的时间安排
  3. Sprint 计划会议 2 的时间安排
  4. Sprint 的***天已确定
  5. Sprint 的***一天已确定
  6. Scrum 每日例会的时间安排
  7. Sprint 评审会议的时间安排
  8. Sprint 回顾会议的时间安排
  • (可选)为既定 Backlog 准备图钉板:一个至少 2x2 米的图钉板、卡片和贴纸、荧光笔
  • (可选)用作计划纸牌的卡片

会议进程(4 小时)

  • 把 Sprint 时间表公开给所有人
  • 把 Sprint 评审会议的结果公开给所有人
  • 把 Sprint 回顾会议的结果公开给所有人
  • 产品负责人向团队产品阐述产品远景
  • 产品负责人和团队一起确定 Sprint 目标
  • 如果 Backlog 里有问题遗漏:产品负责人有权限往 Backlog 里添加问题
  • 如果产品 Backlog 完全未被评估:选择 Backlog 中您认为是最小用例的问题,并指派其工作量为 2 个Story Point。以这个最小用例的工作量标准,分配 Backlog 中其他问题的 Story Point
  • 如果 Backlog 中的一些问题尚未被评估:根据其他问题工作量,评估这些问题的 Story Point 量
  • 如果产品 Backlog 中的各项还没能合理地按优先级排序:产品负责人对产品 Backlog 中的各项按优先级排序
  • 产品负责人和小组成员相互认可这 Sprint 目标和既定产品 Backlog

会议结果

为Sprint计划会议2的进行准备好既定产品 Backlog

sprint计划会议2

在 Sprint 计划会议 2 中,团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。

目标

确定所有任务,生成 Sprint Backlog,确认 Sprint 目标

会议准备

  • 邀请与会者:Scrum Master、团队所有成员、产品负责人(可以有权得知所有问题)
  • 任务规划时可以参考既定产品 Backlog
  • (可选)为既定 Backlog 准备图钉板:一个至少 2x2 米的图钉板、卡片和贴纸、荧光笔

会议进程(4 小时)

  • 团队成员从 Backlog 的各项问题中分出相应的任务
  • 确保考虑到工作中所有的细节:编码、测试、代码评审、会议、学习新技术、编写文档
  • 如果任务需时超过一天:尝试把该任务分割成几个小任务
  • 如果团队认为 Sprint Backlog 中项过多:和产品负责人一起删减 Backlog 中的问题
  • 如果团队认为 Sprint Backlog 中的项过少:和产品负责人一起从产品 Backlog 中选出最重要问题,加入Sprint Backlog 中
  • 团队确认 Sprint 目标

会议结果

  • Sprint 目标和 Sprint Backlog 对于公司内的所有人都是公开的
  • 所有团队成员都可以获取 Sprint Backlog 中的任务

2、Scrum之 站立例会(以下内容摘自周金根博客)

在sprint期间,每天都会通过站立例会来进行沟通,以下我将把会议主要内容罗列一下。(以下会议内容来自于Scrum Checklists)

[[68706]] 

会议内容

目标

团队成员间工作进度的沟通和协调

会议准备

  • 邀请与会者:团队所有成员、Scrum Master、产品负责人(可选)、相关人员(可选)
  • 在Sprint Backlog 上的所有任务都是可以增删修改,可重排序的
  • 任务的状态可设为todo、doing、done(可以再加一个test表示需要验证)

会议进程(15 分钟内)

  • 上次会议时的任务哪些已经完成:把任务从“正在处理”状态转为“已完成”状态
  • 下一次会议之前,你计划完成什么任务? •如果任务状态为“待处理”:转为“正在处理”状态
  1. 如果任务不在 Sprint Backlog 上:添加这个任务
  2. 如果任务不能在一天内完成:把这任务细分成多个任务
  3. 如果任务可以在一天内完成:把任务状态设为“正在处理”
  4. 如果任务状态已经是“正在处理”:询问是否存在阻碍任务完成得问题
  • 有什么问题阻碍了你的开发:如果有阻碍你开发进度的问题,把该障碍加入到障碍 Backlog 中
  • 如果展开了一个问题的讨论:提醒团队的成员们注意把精力集中在回答关键问题上
  • 如果相关人员想发表些言论:礼貌地提醒他,该会议只允许让小组成员讨论

会议结果

  • 得到***的障碍 Backlog
  • 得到***的 Sprint Backlog
  • ***的工作进度图

其他

可以指定一个主持人(或轮流)。他来召集并控制会议时间,会议中注意引导话题,在会议结束时可以做个简短的总结,说出重点就行,做好每日规划。

3、Scrum 评审会议(以下内容摘自周金根博客)

在sprint周期***,需要进行一次评审会议,让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注,让其他人了解团队在做些什么,并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。

  • 小组准备好工作站和设备等等,用以展示产品的新功能
  • 团队准备sprint审核实践不应超过1小时

会议进程(4小时)

  • 确保所有人员都清晰目标,如果有人对产品不知道,则花几分钟来进行描述。
  • 团队按 Backlog 中的问题,逐个地介绍这次 Sprint 的结果,和演示新功能。
  • 如果产品负责人想要改变功能:添加一个新问题到产品 Backlog 中
  • 如果对功能有一个新的想法:添加一个新问题到产品 Backlog 中
  • 如果小组报告项目遇到阻碍现在还没能解决:把该障碍加入到障碍 Backlog
  • 会议结束时,ScrumMaster向产品负责人和全体利益相关者宣布下一次审核的地点和时间。

会议结果

  • 对这次 Sprint 的结果和整个产品的开发状态的共识

其他

  • 让演示关注业务层次,不要关注技术细节。注意力放在“我们做了什么”,而不是“我们怎么做的”
  • 有的sprint可能会包含很多bug修复等功能,在评审会议中不要演示太多一大堆细碎的bug修复,除非这个很重要。

4、Scrum之 回顾会议(以下内容摘自周金根博客)

Scrum中Sprint计划会议是最重要的事件,第二重要的事件就是回顾会议,因为这是团队做改进的***时机。如果没有回顾,就会发现团队在重犯相同的错误。在sprint的评审会议后,团队需要进行一次回顾会议,以下我将把会议主要内容罗列一下。(以下会议内容来自于Scrum Checklists和scrum-and-xp)

会议内容

目标

通过总结以往的实践经验来提高团队生产力。

会议准备

  • 邀请与会者:  Scrum Master、团队所有成员 、产品负责人(可选)
  • 附属工具:为所有参与者准备的荧光笔、贴纸、白板磁吸、白板和挂纸板
  • 准备一个回顾白板,分三列。***列和第二列是回顾过去,第三列是展望将来。
  1. Good:如果重做同一个sprint,哪些做法可以保持
  2. Could have done better:如果重做同一个sprint,哪些做法需要改变
  3. Improvements:有关将来如何改进的具体想法

[[68707]]
 

会议进程(1-3小时)

  • 介绍会议目标和议程
  • 准备(setting the stage):制定和回顾团队价值观和约定(Team values and working agreements):(10-30分钟)
  1. 不管我们现在发现了什么问题,我们必须懂得并坚信每个人通过他们当时所知的,他所拥有的技能和可得到的资源,在限定的环境下,都尽其所能做出了***的成绩
  2. 每个人都参与
  3. 坦诚交流
  4. 多说I,少用You
  5. 不深究具体业务细节内部问题
  • 收集数据(Gather Data):收集硬数据:事件(events)、度量(metrics)、完成的故事等
  1. 事件:对团队每个人都重要的任何事件,包含会议、决策点、里程碑、采用新技术等,例如上期回顾会议中确定的改进项是否执行了
  2. 度量:包含燃烧图、速度、bug数、完成故事点数、代码重构数等
  • 产生见解(Generate Insights):多问“为什么”,从收集的数据中找出优点和问题
  1. 向与会者解说如何使用该贴纸进行工作:使用贴纸时,注意一张贴纸只记录一件事。
  2. 派发贴纸,通过头脑风暴分别得出回顾白板三列的所有想法。
  • 确定改进项(Decide What to Do)
  1. 每人三票,投票决定下一sprint着重进行哪些改进(2-5项左右)。
  • 结束回顾(Close the Retrospective)
  1. 给会议做个总结,表明下一个回顾会议需要跟踪哪些做法

会议结果

  • 回顾白板,以及下一sprint需要改进的做法,在下一个回顾中,会跟踪这些改进的执行情况把障碍增加到障碍 Backlog 中去 

记者: 对于未来几年敏捷开发的发展,您希望看到哪些新方向?有何建议?

周金根:敏捷只是一个代名词,我希望它不仅仅只包含开发,还能能够在基于敏捷思想下,把方法框架扩充到市场、业务、营销环节等软件产品开发全生命周期。

责任编辑:林师授 来源: 51CTO
相关推荐

2010-03-11 14:37:47

Visual StudScrum

2009-11-12 11:30:13

Scrum

2023-09-06 18:23:48

Scrum框架项目

2020-01-14 14:15:03

开发技能代码

2012-11-12 09:41:31

Scrum敏捷开发开发培训

2017-04-12 10:04:18

Scrum实践终结

2009-07-16 09:52:00

Scrum流程

2017-11-29 16:32:05

Scrum敏捷开发

2012-11-12 09:44:07

Scrum敏捷开发开发培训

2019-02-25 09:00:00

项目Scrum工具

2012-12-13 16:56:26

2012年度IT博客大IT博客大赛博客

2014-07-26 09:56:43

WOT2014敏捷开发PO

2012-01-06 09:45:59

敏捷开发

2012-11-15 10:19:56

IBMdw

2010-12-21 14:13:25

敏捷开发Scrum

2017-03-29 10:09:44

敏捷Scrum实践

2017-03-21 10:24:40

敏捷Scrum实践总结

2011-07-06 13:42:42

Scrum

2017-03-22 09:04:21

敏捷Scrum实践

2012-01-06 12:57:56

2011年度IT博客大IT博客大赛2011年度十大杰出I
点赞
收藏

51CTO技术栈公众号