目前软件开发除了强调产品质量,同时对产品能够快速发布并且迅速适应市场变化的要求也日益强烈。为适应这种开发环境和市场需求,传统的软件开发模式已被敏捷开发模式所替代。本文介绍敏捷软件开发中的Scrum方法,并结合实际问题,分析Scrum方法在实践中的运用。
产品质量和开发效率一直是软件产品开发的关键。随着科技和经济的发展,软件的市场环境和用户需求不断发生变化,这对软件产品的快速发布提出很高的要求。传统的瀑布模型、螺旋模型、原型模型等已不能适应越来越复杂和不断变化的需求和市场环境。近年来,敏捷软件开发逐步流行,并被广泛认识、研究和使用。敏捷开发具有应对快速变化的市场和需求的能力,因此,它被越来越多的公司企业采用。用于敏捷软件开发的方法有很多,其中Scrum方法是被广泛应用的方法之一。
1.Scrum简介
Scrum是一个增量的、迭代的开发过程,名称来自英式橄榄球的争球。Scrum的整个开发周期包括若干个小的迭代周期,每个小的迭代周期称为一个冲刺(SPrint),每个冲刺的长度一般为2到4周。在Scrum中,使用产品订单来管理产品或项目的需求,产品订单是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。开发团队总是先开发的是对客户具有较高价值的需求。在每个冲刺中,开发团队从产品订单中挑选最有价值的需求进行开发。冲刺中挑选的需求经过计划会议上的分析、讨论和估算得到一个冲刺的任务列表,我们称它为冲刺订单。在每个迭代结束时,开发团队将交付潜在可交付的产品增量。
Scrum的主要角色有:产品负责人、Scrum主管、开发团队。Scrum的会议包括:计划会议、评审会议、回顾会议、每日站立例会。Scrum的文档有:产品订单、冲刺订单、燃尽图。Scrum方法的运作过程就是产品负责人、Scrum主管、开发团队依据Scrum必需的文档,通过Scrum定义的会议方式展开的一轮一轮产品开发的迭代过程。
2.Scrum方法的实际运用
Scrum方法给出的是一个框架,各角色人员如何根据这个框架来实践Scrum,尤其如何利用好每日站立例会、评审会议、回顾会议,是影响敏捷开发效果的关键因素。在Scrum方法的实际运用中,会遇到或多或少的一些具体问题。笔者根据以往自身敏捷开发项目的经验,对这些问题作简要的分析,并给出有效的解决办法。
2.1每日站立例会
每日站立例会是Scrum主管和开发团队成员必须参加的会议。它是除了面对面沟通之外,开发团队成员的另一个有效的沟通交流方式。Scrum倡导的每日站立例会平均时间不超过巧分钟,开发团队的每个成员需要向Scrum主管回答三个问题:今天完成了哪些工作?明天打算做什么?完成目标是否存在什么障碍?
每日站立例会需要Scrum主管的有效组织。每日站立例会最常见的问题是,团队成员之间陷入了具体技术问题的讨论中,导致会议时间严重拖长,影响了会议的效率。还有一种情况是,一个成员汇报所遇到的障碍的时候,其他成员没有认真聆听,对一些共有的障碍或者有依赖性的问题没有引起足够的重视,导致大家都卡在同样的问题里,影响了开发的进度。
为使每日站立例会更加有效率,开发团队的每个成员需要控制好自己的发言时间,一般在3分钟左右。发言突出要点,简明扼要,不要详细论述具体技术问题。一旦发现团队成员开始讨论具体技术问题,Scrum主管应及时给与提醒,这样可以有效地控制会议时间。为了使每个成员都清楚目前项目的状况,尤其对可能影响完成目标的障碍有所了解,Scrum主管在每次例会结束之前把记录下来的障碍向开发团队总结一遍,让大家心中有数,确保第二天的开发工作不受广泛影响。这样做也有助于Scrum主管在接下来的工作中有效地为团队去除这些障碍。
2.2评审会议
在每一个冲刺的尾声需要进行一次评审会议,产品负责人、Scrum主管、开发团队必须参加评审会议。评审会议的目的是让开发团队向产品负责人展示在该冲刺完成的功能,回答与会人员对展示的疑问并记录所期望的修改。评审会议进程一般不超过4个小时,开发团队准备的评审展示内容一般不超过1个小时。评审会议包含阶段性验收的意味,如何才能在有限的展示时间内,得到产品负责人的积极认可和有效反馈,是在会议准备阶段和会议进行过程中必须注意的问题。
在会议准备阶段,开发团队应该按照本次冲刺的冲刺订单,组织产品功能的展示点,形成清晰简要的PPT文档。在会议现场最好能进行在线实际的功能展示,所以会议前开发团队要准备好工作站和设备等。同时开发团队还需要把能展现产品功能效果的图、表、日志等数据提前保存下来,以防突发情况导致现场展示失败时无内容可展示。在会议开始时,Scrum主管和开发团队需要确保所有人员对产品和该冲刺的目标有所了解,如果有人对此不清楚,则先用几分钟进行描述。然后,开发团队按照准备好的PPT文档,逐个介绍这次冲刺实现的结果,并且展示其功能效果。在展示的过程中,开发团队应该把重点放在“我们做了什么”,而不是“我们怎么做的”。这样可以让产品负责人对产品目前的功能状况有直观的了解,而不是陷入到技术细节之中。如果产品负责人想改变某些功能,Scrum主管把这个需求添加到产品订单中,留待以后的冲刺解决。
2.3回顾会议
回顾会议是在每个冲刺结束之后进行的,通常在评审会议后进行,它通过总结本次冲刺的实践经验,为团队指出日后改进的方面,避免团队重犯相同的错误。Scrum主管、开发团队必须参加回顾会议。回顾会议是Scrum方法中很重要的会议,利用好回顾会议,可以有效地提高团队的生产力。回顾会议需要鼓励团队成员积极参与,集思广益,否则,这个会议就会流于形式,达不到预期的效果。
在实际应用中,回顾会议的形式可以采取头脑风暴法模式。会议开始时,Scrum主管先给团队成员总结上次冲刺的回顾会议确定的改进内容的执行结果。然后,Scrum主管给每个成员发一张即时贴便签,让他们自己思考,回顾本次冲刺中团队做得好和做得不好且需要改进的地方，各选三点意见写在便签上,然后把便签贴在白板上。等所有成员都把写好的便签贴在白板上后,Scrum主管和团队成员一起逐条讨论便签上的意见,充分理解团队成员的想法。讨论过程中,Scrum主管对相似的意见进行合并,对有依赖相关性的问题进行梳理。回顾会议结束后,Scrum主管就可以得到本次冲刺做得好的地方和需要改进的内容。那些需要改进的内容供下次冲刺的回顾会议进行效果跟踪。
3.小结
Scrum方法是敏捷开发的一个框架,它并没有规定具体的实践方法。Scrum提倡灵活,遵循敏捷开发以人为本的原则,这需要软件项目管理人员根据企业文化、管理模式、开发团队的经验等因素,选择合适的方案。