淡定哥头像

技术文档

Scrum敏捷开发

Scrum敏捷开发

一、 什么是敏捷开发?

1. 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

2. 为什么说是以人为核心?

我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

3. 什么是迭代?

迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

4. 关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

5. 敏捷开发的4句宣言

1) 个体与交互 胜过 过程与工具

2) 可以工作的软件 胜过 面面俱到的文挡

3) 客户协作 胜过 合同谈判

4) 响应变化 胜过 遵循计划

二、 什么是Scrum?

Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种,在最近的一两年内逐渐流行起来。把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

Scrum的基本假设是:

开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,确保每天、每个阶段都朝向目标有明确的推进。

Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部分,开发团队必须尽力于 30 天后交付成果,团队每天用 15 分钟开会检查每个成员的进度与计划,了解所遭遇的困难并设法排除。

三、 Scrum较传统开发模型的优点

Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。

下图是Scrum模型和传统模型的对比:


四、 有关Scrum的几个名词

1. product backlog: 可以预知的所有任务, 包括功能性的和非功能性的所有任务。

2. sprint:一次跌代开发的时间周期,一般最多以30天为一个周期.在这段时间内,开发团队需要完成一个制定的backlog,并且最终成果是一个增量的,可以交付的产品。

3. sprint backlog:一个sprint周期内所需要完成的任务。

4. product owner: 产品负责人,主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果

5. scrum master: 流程管理员,负责监督整个Scrum进程,修订计划的一个团队成员。

6. scrum team: 开发团队,主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

7.time-box: 一个用于开会时间段。比如每个daily scrum meeting(每日站立会议) 的time-box为15分钟。

8. sprint planning meeting: 在启动每个sprint前召开。一般为一天时间(8小时)。该会议需要制定的任务是:产品Owner和团队成员将backlog分解成小的功能模块,  决定在即将进行的sprint里需要完成多少小功能模块,确定好这个Product Backlog的任务优先级。另外,该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

9. Daily Scrum meeting:开发团队成员召开,一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目:今天完成了什么? 是否遇到了障碍? 即将要做什么?通过该会议,团队成员可以相互了解项目进度。

10. Sprint review meeting:在每个Sprint结束后,这个Team将这个Sprint的工作成果演示给Product Owner,客户,老板和其他相关的人员。一般该会议为4小时。

11. Sprint retrospective meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。

12. Scrum开发流程中的三大角色:  

 1) 产品负责人(Product Owner)
 2) 流程管理员(Scrum Master) 
 3) 开发团队(Scrum Team)

五、如何进行Scrum开发?

1. 我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

2. Scrum Team根据Product Backlog列表,做工作量的预估和安排;

3. 有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

4. Sprint Backlog是由Scrum Team去完成的,这个Sprint Backlog是按照目前的人力物力条件可以完成的。每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

5. 在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

6. 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

7. 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Sprint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

8. 最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
这样周而复始,按照同样的步骤进行下一次Sprint.


六、Scrum流程图



七、Scrum开发流程中的一些场景图

1. Product Backlog (产品需求)

Product Backlog 是Scrum的核心,也是一切的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序,它里面包含的是客户想要的东西,并用客户的术语加以描述。

 包括以下字段:

 ID: 统一标识符,自增长
 Name: 简短的、描述性的名称
 Importance: 产品负责人评出一个数值,指示这个条目有多重要,比如1-5,分数越高越重要。
 Initial estimate(初始估算): 团队的初步估算该条目的工作日。
 Test Case: 简单的测试规范,这段描述可以作为验收测试的伪码表示。
 Notes: 相关信息、解释说明和对其它资料的引用等,一般都非常简短。
 
 为了便于产品负责人判断优先级别,我们也会在产品backlog中使用一些其它字段

 Type(类别): 当前故事的大致分类,例如”后台系统”或”优化”。这样产品负责人就可以很容易选出所有的”优化”条目,把他们的级别都设得比较低。类似的操作执行起来都很方便。
 
 Component: 如“数据库,服务器,客户端”。团队或者产品负责人可以在这里进行标识,以明确哪些技术组件在这个条目的实现中会被包含进来。这种做法在多个Scrum团队协作的时候很有用—比如一个后台系统团队和一个客户端团队—他们很容易知道自己应当对哪些需求负责。
 
 Requestor(请求者): 产品负责人可能需求记录是哪个客户或相关干系人最先提出了这项需求,在后续开发过程中向他提供反馈。
 


2. Daily Scrum Meeting(每日站立会议)

每日的站立会议,参会人员可以随意姿势站立, 任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图,时间控制在15分钟


3. Task Kanban Board(任务看板)

每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)


4. Plan Card (计划令牌)

计划纸牌的作用是防止项目在开发过程中,被某些人所领导。
怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时... 最终评估一个更合理的时间。


八、Scrum开发过程注意事项:

1. 产品负责人应当理解每个故事的含义(通常需求都是由他来编写的,但是有的时候其他人也会添加一些请求,产品负责人对它们划分先后次序)。他不需要知道每个需求具体是如何实现的,但是他要知道为什么这个需求会在这里。

Sprint计划会议非常关键,应该算是Scrum中最重要的活动。要是它执行的不好,整个sprint甚至都会被毁掉。举办Sprint计划会议,是为了让团队获得足够的信息,能够在几个星期内不受干扰的工作,也是为了让产品负责人能对此有充分的信心。

Sprint计划会议成果:
1)Sprint目标。
2)团队成员名单(以及他们的投入程度,如果不是100%的话)
3)Sprint backlog(即Sprint中包括的需求列表)
4)确定好sprint演示日期
5)确定好时间地点,供举行每日scrum会议
                           
整个团队和产品负责人都必须参加sprint计划会议。原因在于,每个需求都含有三个变量,它们两两之间都对彼此有着强烈依赖。
         
2. 范围(Scope)和重要性(Importance)由产品负责人设置。估算(estimate)由团队设置。在sprint计划会议上,经过团队和产品负责人面对面的对话,这三个变量会逐步得到调整优化。会议启动后,产品负责人一般会先概况一下希望在这个sprint中达成的目标,还有他认为最重要的故事,接下来,团队从最重要的故事开始逐一讨论每个故事,一一估算时间。
 
质量分为内部质量和外部质量: 
1)外部质量 是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
2)内部质量 指用户开不到的要素,它们对系统的可维护性有深远影响。可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
 
一般来说,系统内部质量优秀,外部质量仍有可能很差。而内部质量差的系统,外部质量肯定也不怎么样。牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间,接下来的日子里你就要一直为它付出代价。一旦我们放松要求,允许代码库中暗藏问题,后面就很难恢复质量了。






分享到: 

* 发表评论:
Top