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应还具备技术、市场和其他的专业知识，可以帮助团队实现目标。