1,目的
本流程是公司过程体系文件的一部分,用于描述软件系统敏捷开发过程,包括过程中涉及的角色和职责、主要的活动以及输出的主要工作产品
2. 范围
本规程适用于所有采用敏捷开发模式的软件项目。
3. 定义
001,Product Backlog:
一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级。Product backlog应该涵盖所有用来构建满足客户需要的产品特性,包括技术上的需求。
002,Sprint Backlog:
Sprint Backlog 是Sprint计划会上产出的一个工作成果。当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后,这些功能点就会被细化成为
003,Sprint Backlog:
一个完成Product Backlog功能点的必需的任务列表。
004,Sprint计划会:
根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Sprint计划会是用来细化当前迭代的开发任务的。
005,每日站会:
ScrumMaster需要组织团队成员每天开站会. 这个会议是用15分钟的时间来让大家反馈三个问题:昨天做了什么?今天计划做什么?遇到什么困难?
006,Sprint演示会:
在每个Sprint的最后一天召开Sprint演示会,用于演示本Sprint开发的产品功能。
007,Sprint回顾会:
在每个Sprint的最后一天召开回顾会,由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式,找出好的方式以后继续发扬;找出需要做的更好的地方,想办法提升;在下一个sprint中引入何种好的方法。
,008,Sprint燃尽图:
在Sprint时间段上显示所有剩余工作时间逐日递减的图,因整体上总是递减而得名。
009,发布燃尽图:
在发布周期上堵上显示所有剩余工作时间逐日递减的图。
5. 关键角色及应负责任
001,ProductOwner:
确定产品的功能
决定发布的日期和发布内容
为产品的profitability of the product (ROI)负责
根据市场价值确定功能优先级
调整功能和调整功能的优先级
接受或拒绝接受开发团队的工作成果
002,ScrumMaster:
(ScrumMaster负责在团队中正确、完整地贯彻Scrum流程,特别要对以下工作负责):
清除挡在客户和开发工作之间的障碍
确保团队合理的运作Scrum
003,Scrum Team: (一个跨职能的小团队,团队拥有交付可用软件需要的各种技能):
确定Sprint目标和具体说明的工作成果
在项目向导范围内有权利做任何事情已确保达到Sprint的目标
自组织的团队
向Product Owner演示产品功能
团队成员:ProductOwner,设计师,开发人员和测试人员。
设计师:负责软件架构、接口协议、数据字典等的设计;
开发人员:负责软件设计、编程、测试、分析需求等任何必要的工作;
测试人员:负责软件的测试,包括每日的集成构建测试、Sprint验收测试等。
7. 活动描述
001,Product Backlog准备期:
参与角色:Product Owner。
主要活动:由Product Owner整理、输出Product Backlog用于Sprint的制定。Backlog中的功能性和非功能性需求,需事先划分优先级
输入:市场调查、市场分析、用户需求分析报告、立项报告等
输出:Product Backlog
002,Sprint计划会:
参与角色:The Team
主要活动:
Sprint计划会议(第一重要)
1天(8小时)
sprint 项目周期,通常三周
计划会议1 (9:00-12:00)
会议进程:9:00 - 9:30:ScrumMster对sprint 目标进行总体介绍,概括产品backlog。定下演示的时间地点。
为每日scrum会议(以下简称每日例会)安排固定的时间地点(如果和上次不同的话)。
9:30-12:00:确定在本次Sprint中实现的backlog条目、添加遗漏的backlog条目、评估backlog的工作量、确定backlog的优先级、过大的backlog条目进行拆分、所有重要性高的backlog 条目都要填写如何演示;。会议结果:为计划会议2的进行准备好既定产品Backlog
计划会议2 (14:00-18:00)
会议进程:14:00-18:00:将backlog条目分解为任务、评估任务工作量(以小时为单位)、如果任务超过一天,尝试将其分割成几个小任务、考虑工作中的所有细节(编码、测试、代码评审、会议、学习新技术、编写文档)、依据情况调整Sprint backlog、团队确认Sprint目标。
会议结果:所有人都可以获取Sprint Backlog中的任务。由ScrumMster整理输出Sprint需要完成的文档清单
输入:Product Backlog
输出:由ScrumMaster输出Sprint Backlog、Sprint 任务表、sprint 目标、团队成员名单(以及他们的投入程度,如果不是100%的话)。确定sprint 演示日期。确定时间地点,供举行每日scrum会议。Sprint文档清单。
003, 每日站会:
参与角色:The Team
主要活动:ScrumMaster需要组织团队成员每天在固定的时间和固定的地点开站立会. 这个会议是用15分钟的时间来让大家过一下scrum的状态。在会上,每个团队成员需要问3个问题:我昨天做了什么,今天做什么,遇到哪些障碍。谁都可以参加这个会议,但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观,用于发现任何新的依赖,定位项目成员的要求,实时的调整当天开发计划.。
输入:Spring Backlog
输出:更新的任务板内容、更新的燃尽图
004,Sprint演示会
参与角色:The Team
主要活动:用来演示在这个Sprint中开发的产品功能给Product Owner. Product Owner会组织这阶段的会议并且邀请相关的利益相关者参加。业务,市场,技术都要做相关的评审。由Product Owner来决定Product Backlog中的哪些功能已经开发完成。
会议进程:
团队按照Backlog条目,逐个地介绍此次Sprint的结果和演示新功能;
如果产品负责人想要改变功能,则添加一个新条目到产品Backlog
如果对功能有一个新的想法,则添加一个新条目到产品Backlog
如果小组报告项目遇到阻碍现在还没解决,则把障碍加入到障碍Backlog
会议结果:对这次Sprint的结果和整个产品的开发状态的共识。
输入:Spring完成的代码或者完成的文档
输出:master更新的Product Backlog、演示会结果收集表
005, Sprint回顾会
参与角色:The Team
主要活动:Sprint回顾会议(第二重要)
时间:3小时
地点:在一个封闭的房间中
过程:指定某人当秘书。Scrum master向大家展示sprint backlog,在团队的帮助下对sprint 做总结。包括重要事件和决策等。
轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法,他认为什么是好的,哪些可以做的更好,哪些需要在下个sprint 中改变。
对预估生产率和实际生产率进行比较。如果差异比较大的话,分析原因。
快结束的时候,Scrum master 对具体建议进行总结,得出下个sprint 需要改进的地方。
输入:演示会结果收集表、bug统计表、Sprint backlog
输出:ScrumMaster总结 Sprint项目报告
006, 输出迭代产品
参与角色:The Team
主要活动:由团队成员将Sprint计划会议中确定的工作产品上传到配置库的指定位置。
输入:所有工作产品的产生
输出:软件源码、相关已确定的文档、记录
007, 验收测试
参与角色:The Team(测试人员)
主要活动:由团队中的测试人员对迭代产品进行全面测试并出具验收测试报告
输入:上传到配置库的迭代产品;
输出:验收测试报告
008, 判断产品是否完成,结束开发
参与角色:Product Owner
主要活动:由Product owner依据既定的产品规格内容、市场情况、产品质量情况等多方面因素判断已开发的工作产品是否符合要求,是否还需要继续开发?
输入:验收测试报告
输出:继续开发决议
8. 其他要求
8.1 Sprint计划会:
为Sprint定下演示的时间地点,这个时间一旦定下就不允许改变;
要对过大的backlog条目进行拆分;
所有重要性高的backlog 条目都要填写如何演示;
如果任务超过一天(6小时),尝试将其分割成几个小任务;
考虑工作中的所有细节,包括编码、测试、代码评审、会议、学习新技术、编写文档;
所有人都可以获取Sprint Backlog中的任务。</span></li>
8.2 Sprint回顾会:
做改进的最佳时机;
在一个封闭的房间中;
在团队的帮助下对sprint 做总结,包括重要事件和决策等;
轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法,他认为什么是好的,哪些可以做的更好,哪些需要在下个sprint 中改变。
8.3 Sprint演示会
确保清晰阐述了sprint 目标。 如果在演示上有些人对产品一无所知,那就花上几分钟来进行描述;
不花太多时间准备演示,尤其是不做花里胡哨的演讲,集中精力演示可以实际工作的代码;
节奏要快,也就是说要把准备的精力放在保持演示的快节奏上,而不是让它看上去好看;
让演示关注于业务层次,不要管技术细节。注意力放在我们做了什么,而不是我们怎么做的;
可能的话,让观众自己试一下产品;
不演示一大堆细碎的bug 修复和微不足道的特性。可以提到一些,但不要演示;
无法演示的工作以报告呈现。
8.4 Sprint站立会
15分钟;
每个人描述三个问题:昨天做了什么?今天要做什么?遇到什么困难?
如果他更新了时间估算,那就在即时贴上写上新的时间,把旧的划掉;
站立会上不解决问题,只提出问题;
更新燃尽图。
8.5其它
代码每日及时提交到SVN库,由Hudson持续集成;
TE每日对新提交的功能进行验证并及时更新TD库;
SPE每日对TD库中的bug进行修正并修改bug状态。
每个Sprint 最短2周,最长4周,从实践来看3周最为合适
建议引入TDD(测试驱动开发)
提倡结对编程
以建立自组织的团队为目的
每个Sprint结束时,由QA输出代码质量报告
依据上一个Sprint的代码质量报告,制定出本次Sprint需要改进的项目,并作为SprintBacklog列入Sprint计划中。
附件:
敏捷宣言:
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。
敏捷遵循的原则
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单是最根本的。
最好的构架、需求和设计出于自组织团队。
每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
ScrumMaster需要具备的品质
负责:要对最大化团队的产出和支持团队成员实施以及使用Scrum负责。ScrumMaster承担这个责任,却不具有任何有助于实现这个目标的权利。
谦逊:优秀的ScrumMaster不能以自我为中心。他必须理解全体团队成员的价值,并以身作则促成其他人达成共识。ScrumMaster的成就来自于看看我帮助完成了什么而不是看看我完成了什么
协作:保障团队中存在一种相互协作的文化。要确保团队成员能够把问题拿出来公开讨论,并与此同时得到他人的支持。当争执发生时,要鼓励团队用共赢方式思考,而不是以赢家和输家的方式思考。要为团队合作建立规范,并指出不合适的行为。
投入:ScrumMaster不应任由问题遗留多日不予解决。
有影响力:ScrumMaster必须会影响团队内和团队外的人。应该懂得如何向别人施加影响,同时又避免独裁式的,因为我这样说了的风格。独裁风格的人绝对不适合做ScrumMaster.
知识渊博:ScrumMaster应还具备技术、市场和其他的专业知识,可以帮助团队实现目标。