首页 > 代码库 > Scrum介绍——续

Scrum介绍——续

四、 Scrum过程

Scrum的过程如图4-1所示

技术分享

图4-1 Scrum过程

4.1 建立Product Backlog

Product Backlog是Product Owner把客户的商业需求按照优先级排出来的列表,整个项目存在一个唯一的Backlog,Backlog的内容由Product Owner随时按照客户的需求进行更新,并且做出粗略的工作量评估,供开发团队进行参考。一个典型的Product Backlog如图4-2所示。

技术分享

图4-2 Product Backlog

4.2 Sprint计划会议

Sprint会议用来确定Sprint backlog,Sprint会议计划会议是Scrum中最重要的一部分,在会议中,产品负责人告诉Scrum团队产品backlog中优先级较高的项,Scrum团队共同讨论产品backlog,一起决定接下来的一个Sprint中开发哪些功能,形成Sprint backlog,并估算Sprint backlog中每一项的开发时间。有一下事情在该会议中需要明确:

  1. Sprint的长度,Sprint的长度是一个trade-off的结果,Sprint越短,越"敏捷",越能更早的看到成果,但是过短的sprint会使团队处于频繁的sprint机会会议、演示,发布等压力之下,目前建议的sprint长度为"三个星期"。
  2. Sprint的目标,每一个Sprint都应该确定一个目标,如果目标没有价值,就不应该开始这个Sprint。
  3. Sprint要包含的故事(story),就是要确定讲那些story从Product Backlog中放入Sprint Backlog中。
  4. 对每个Story的时间估算,scrum使用"纸牌"的方式,让每一个团队成员都参与到每一个Story的时间评估当中,具体操作是:买个成员都在纸牌上写下自己对当前story的评估时间,牌面朝下,等大家都已经完成后,所有团队成员把纸牌翻开,显示出自己对story的评估时间,如果团队成员评估的时间差距非常大,就需要大家再次进行评估,使用纸牌的好处是团队成员都可以对story的工作量进行评估,且不会受到其他人的影响,这样子得出的数据会更加的准确。
  5. 明确故事内容,确保让Product Owner和团队对故事有同样的理解,可以尝试将大的Story分解成不同的task从而便于理解。

4.3编写Sprint Backlog

在完成Sprint会议的基础上,由Scrum Master编写Sprint Backlog,Sprint Backlog可以由多种方式进行保存,excel等,本文推荐通过任务板来保存Sprint Backlog(将其挂在墙壁上),一个任务板的例子如图4-3所示。

技术分享

图4-3 任务板Sprint Backlog

在每次例会后由Scrum Master更新该Backlog,可以看出,使用任务板的方式使得整个项目的进展情况一目了然,并且方便维护

4.3.1燃尽图(burndown chart)

燃尽图清楚的表示在当前sprint中已经完成的story point和剩余工作时间的关系,燃尽图由scrum master在每日例会后进行更新,一个典型的燃尽图如图4-4所示。

技术分享

图4-4燃尽图

4.4每日例会

每日例会在Scrum中叫"站立会议",一般都不会超过15分钟,在每日例会后由scrum master更新任务板(包括燃尽图),在例会中每个人都会描述昨天已经完成的事情和今天要做的事情,以及自己遇到的问题(Scrum将会记录问题,在后续会解决这些问题),每日例会的主要功能就是update整个团队以及进度,它是一个汇报会议,每日例会不需要讨论具体细节,如果有细节需要讨论,单独发起会议,一个典型的每日例会如图4-5所示。

技术分享

图4-5每日例会

4.5 Sprint演示

也叫Sprint评审,这只是简单的展示工作结果,所有与会人员可以提出问题和建议。会议可以持续10分钟,也可以是两个小时——会议目的只是对工作结果的展示和听取反馈在scrum中,所有的sprint都结束与演示,通过演示,团队的成果可以得到认可,其他人可以了解到团队在做什么事情,演示可以得到更多的反馈,通过演示会迫使团队真正完成一些工作。

4.6 Sprint回顾

在Sprint评审会议结束之后和下个Sprint计划会议之前,Scrum团队需要举行Sprint回顾会议。在回顾会议上,Scrum团队会一起讨论当前Sprint有哪些成功的经验,有什么地方去要改进。在回顾会议的最后,Scrum团队应该确定将要在下个Sprint中实现的改进方法。

回顾是scrum中非常重要的事情之一,因为这是改进的最佳时机,回顾主要做一下三件事情:

  1. Good 如果我们可以重做同一个Sprint,那些做法是可以保留的?
  2. Could have done better 如果我们可以重做同一个Sprint,哪些做法需要改变?
  3. Improvements 有关将来如何改进的具体想法?

五、 Scrum的挑战

Scrum不是流程-而是提供给团队可视性的框架,并且容许他们相应的"检验和适应"的技巧。Scrum试图让许多存在于开发团队中的问题显现出来。比如,大多数的开发团队并不擅长于估算在固定期间内完成的工作量,因此在第一个Sprint结束时不可能交付他们预计完成的工作。

对于开发团队来说,这个是工作的失败。事实上,这个经验正是能更好预计工作量所需的第一步,并促使其对承诺的任务更加负责。这种模式-Scrum可以使机能失调更易显现出来,让团队切实可以解决问题-是使用基础的技巧产生出最有意义的收益,是团队使用Scrum的经验之一。

一个开发团队普遍犯的错误是,当他们在Scrum实践中遇到挑战,他们会改变实践方法,而不是改变自身的问题。比如,开发团队有困难完成Sprint任务时,会延长Sprint的周期,这样他们就会有充足的时间完成任务——在流程中,确保自身不用提高工作预测的技能和更好的管理时间。这样,在没有经验丰富的Scrum培训师的指导下,开发团队只会将Scrum作为自身弱点和机能失调的映射,并破坏了Scrum真正的意义:使优点和缺点都显现出来,给开发团队自我的提高提供机会。

另一个普遍存在的错误是,人们以为某一实践方法是被禁止或不提倡的,只是因为Scrum没有明确的提出此方法。比如,Scrum并不特别要求产品所有者 (Product Owner)对于他或她的产品作出长远的目标计划;也没有要求工程师请教更有经验的人员关于比较复杂的技术问题。Scrum将这些问题留给个人作出正确的处理;在很多情况下,以上两个方法(和其他许多的方法)会被建议。做个正确的比喻:"因为Scrum没有提到早餐的问题,并不意味着你就得挨饿!"另一个需要留意的问题是有时经理会强制开发团队使用Scrum;Scrum是为开发团队提供自我组织的空间和工具,由上层强加于开发团队恐怕不是取得成功的良方。 比较好的方法是让开发团队从同事或经理处了解到Scrum,并通过专业系统的培训,在开发团队实验此方法(比如90天)后作出决定;在实验周期后,开发团队通过经验的总结来决定是否继续采用此方法。

 

参考文献:

[1] Henric Kniberg.硝烟中的Scrum和XP-我们如何实施Scrum.清华大学出版社,2011.1.

[2] Pete Deemer,Gabrielle Benefield.SCRUM 简介-使用Scrum的Agile(敏捷)项目管理介绍

Scrum介绍——续