【原】敏捷开发过程控制程序

敏捷开发过程控制程序

文件状态： [ ] 草稿 [ ] 正式发布 [ ] 正在修改	文件编号：
	当前版本：

编制	审核	批准	生效日期

版本历史

版本/状态	作者	参与者	日期	摘要

1 目的

2 适用范围

3 名词定义

术语和缩写	解释
敏捷开发	敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。
极限编程 XP	一种敏捷方法，极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
Scrum	一种敏捷方法，Scrum是一个轻量级的软件管理过程。Scrum注重的是管理和组织实践，而XP关注的是实际的工程实践，两者可以很好地协同工作——它们解决的是不同领域的问题，可以互为补充，相得益彰。
Backlog	Backlog由所有的功能特性，包括业务功能，非业务功能（技术、架构和工程实践相关），提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。
Product Backlog	产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护
Sprint Backlog	在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。 已定 Product Backlog是 Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。
User Story	用户故事：描述对用户有价值的功能。用户故事也可以定义为分配给软件开发组的特定业务需求。
系统集成测试（SIT）	多个迭代完成后进行的迭代集成测试。

4 职责

角色	职责
Scrum Master （敏捷教练）	保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。
Product Owner（PO产品经理）	业务角度驱动项目，传播产品的明确愿景，并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目，在 Sprint 中帮助团队完成自己的工作，不干扰团队成员，并迅速提供团队需要的所有信息。
Scrum Team	有自我管理的、负责开发产品的人组成。全职能性团队
SQA人员	独立负责制定质量保证计划、对项目组执行本标准软件开发过程的执行情况，输出产品进行审计。
DBA	负责安装、配置、优化和管理项目相关数据库，包括开发、测试和生产环境；参与技术构架方案、软件需求规格和数据建模的评审。。
运维技术组	编写《更新部署操作手册》，负责实施软件更新部署，软件更新上线后的事件处理。

5 工作程序

5.1 进入条件

【符合敏捷开发条件】

无法一开始就能定义最终产品，过程中需要研发、创意、尝试错误，无法使用固定的流程。

敏捷强调迭代和增量开发、与客户密切合作以及跨职能团队，以构建可工作的软件。

【敏捷的文化基础】

信任的文化：管理者信任员工，充分放权

积极主动的文化：员工积极主动的工作，不偷懒

团队协同的文档：团队成员是互补的，互相帮助的

沟通的文化：在团队内及时、充分的沟通信息

5.2 退出条件

敏捷软件生命周期结束

5.3 输入

输入制品	备注
产品需求说明书	根据业务需求提出的有针对性的业务及产品解决方案，包括业务流程、产品功能、成本效益等，是系统设计的依据，具体描述软件产品的功能和非功能需求。
交互稿	可裁剪，根据实际项目需求
设计稿	可裁剪，根据实际项目需求
对接接口文档	可裁剪，根据实际项目需求

5.4 输出

输出制品	备注
Product Backlog	产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护
Sprint Backlog	在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。 已定 Product Backlog是 Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。
测试用例	测试用例是为特定目标开发的测试输入，执行条件和预期结果的集合
测试总结报告	系统测试总结报告是对每次迭代（单元测试、集成测试、系统测试）的测试结果、缺陷分析进行的分析评估，并最终给出测试停止标准所规定的相关数据项。
…	以实际裁剪文档为准

5.5 过程流程图

5.5.1 敏捷生命周期

5.5.2 敏捷开发过程流程图

5.6 过程活动描述

5.6.1 计划

活动名称		计划
角色和职责		PO、Scrum team、Scrum master
活动接口	进入条件 （或活动启动的事件）		项目采用敏捷生命周期
	活动的输入		产品需求说明
	活动的输出		Product Backlog
	退出条件 （或触发其他活动的事件）		Product Backlog评审通过
任务		Scrum master组建团队； PO建立项目Product Backlog； PO为Product Backlog设定优先级； Scrum team进行初步估计； Scrum team搭建工作环境； PO收集来自业务部门，领导等渠道的信息，从业务角度和市场价值输出一份按优先级顺序的、明确的、可度量的、合理的 产品需求列表Product Backlog；
使用工具		SVN
相关过程		无
备注		迭代1~迭代n，迭代内部原则上不接受变更，如客户强烈要求需做特别说明，po调整优先级，提交需求变更申请单，Scrum team进行评估，更新Sprint Backlog； 迭代1~迭代n，迭代周期建议在1~4周。

5.6.2 迭代开发（迭代1~迭代N）

活动名称		迭代开发（迭代1~迭代N）
角色和职责		PO、Scrum team、Scrum master
活动接口	进入条件 （或活动启动的事件）		Product Backlog评审通过
	活动的输入		Product Backlog
	活动的输出		Sprint Backlog本轮冲刺计划； Code 测试用例 单元测试报告 迭代测试报告； 燃尽图
	退出条件 （或触发其他活动的事件）		冲刺迭代测试完成
任务		Scrum master 组织Scrum team、PO召开冲刺计划会议，制定本轮冲刺迭代计划， Scrum team对Product Backlog中当前优先级高，以及预计在本次冲刺的的Story进行头脑风暴，达成共识； Scrum team更新Sprint Backlog，包含Story任务分解、工作评估、当前任务剩余工时、任务状态，制定冲刺迭代计划； Scrum team Story实现，可引入XP实践：简单设计、测试驱动开发、结对编程、重构、持续集成，实践； Scrum team编制测试用例， Scrum team进行单元测试，输出单元测试报告； Scrum team进行冲刺迭代测试，达到转迭代测试标准，进行缺陷管理，输出迭代测试报告； 项目团队每日晨会进行沟通，通过工具进行可视化管理，进行更新冲刺任务单和燃尽图；
使用工具		SVN，QC
相关过程		无
备注		无

5.6.3 冲刺评审会

活动名称		冲刺评审会
角色和职责		PO、Scrum team、Scrum master，业务部门相关人员
活动接口	进入条件 （或活动启动的事件）		冲刺迭代测试通过
	活动的输入		冲刺迭代计划，团队实际产生的潜在可发布的产品增量，迭代测试报告、单元测试报告
	活动的输出		冲刺评审会纪要，以及经过梳理的产品列表，以及更新后的版本计划
	退出条件 （或触发其他活动的事件）		迭代Showcase被业务部门代表确认
任务		Scrum master 组织Scrum team、PO，业务部门代表召开冲刺评审会， 评审常见方式： 演示潜在可发布产品增量， 总结或者概要说明冲刺目标中哪些完成、哪些没有完成； 讨论产品当前状态；调整产品未来方向。
使用工具		无
相关过程		无
备注		无

5.6.4 冲刺回顾会

活动名称		冲刺回顾会
角色和职责		PO、Scrum team、Scrum master
活动接口	进入条件 （或活动启动的事件）		冲刺评审会结束
	活动的输入		准备的回顾重点、成员对于当前冲刺的主观数据
	活动的输出		在下一个冲刺执行的一系列具体改进措施
	退出条件 （或触发其他活动的事件）		冲刺回顾会议完成
任务		Scrum master 组织Scrum team、PO，召开冲刺回顾会。 冲刺回顾供团队反思Scrum使用情况并提出改进措施。 回顾是Scrum团队成员共同进行的协助活动。 回顾活动基本活动流程包括营造氛围，通过数据建立共同背景，让大家达成共识，得出改进见解，确定改进措施。
使用工具		无
相关过程		无
备注		无

5.6.5 发布

活动名称		发布
角色和职责		PO、Scrum team、Scrum master
活动接口	进入条件 （或活动启动的事件）		所有迭代已完成
	活动的输入		详见《软件更新过程控制程序》
	活动的输出		SIT结果；详见《软件更新过程控制程序》
	退出条件 （或触发其他活动的事件）		用户验收通过
任务		1、Scrum team，开展SIT，输出SIT测试结果报告 2、依照《软件更新过程控制程序》进行发布更新
使用工具		无
相关过程		无
备注		无

6 附：敏捷宣言:四种核心价值观和十二条原则

敏捷宣言，也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。

敏捷宣言强调的敏捷软件开发的四个核心价值是：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

我们遵循以下原则：

【1】我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

【2】欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。

【3】经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

【4】业务人员和开发人员必须相互合作，项目中的每一天都不例外。

【5】激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。

【6】不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

【7】可工作的软件是进度的首要度量标准。

【8】敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

【9】对技术精益求精，对设计不断完善，将提高敏捷能力。

【10】以简洁为本，极力减少不必要工作量。

【11】最好的架构、需求和设计出自于自组织的团队。

【12】团队定期地反思如何能提高成效，并依此调整团队的行为。

7 附：传统瀑布项目与敏捷项目对比

敏捷的优点：

【1】通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险； 【2】通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的要求

【3】 通过小批量减少排队，提供更灵活，快速的交付能力。

敏捷的缺点:

【1】存在过程不好把控风险

【2】依赖团队的能力和和个人的自觉性