敏捷开发操作规范(自己总结)

2021年2月11日发(作者：revive什么意思)

精心整理

敏捷开发的相关简介

敏捷定义

Scrum

是一个轻量级的软件开发方法

Scrum

< p>
是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期

包括若干个小的迭代周期，

每个小的迭代周期称为一个

Sprint

，

每个

Sprint< /p>

的建议长度

2

到

4

周。

在

S crum

中，

使用产品

Backlog

来管理产品或项目的需求，

产品

bac klog

是一个按照商业价值

排序的需求列表，列表条目的体现 形式通常为用户故事。

Scrum

的开发团队总是先开发的是对 客户

具有较高价值的需求。在每个

Sprint

中，

Scrum

开发团队从产品

Backlog

中挑选最有价值的需求

进行开发。

< p>

Sprint

中挑选的需求经过

Sprint

计划会议上的分析、讨论和估算得到一个

Sprint

的任务列

表，我们称它为

Sprintbacklog

。在每个迭代结束时，

Scrum

团队将交付潜在可交付的产品增量。

敏捷的原则

个体与交互

胜过

过程与工具

可以工作 的软件

胜过

面面俱到的文档

客户协作

胜过

合同谈判

响应变化

胜过

遵循计划

这四句价值观用语句表达就是：

< br>自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代

< p>
结束时交付经过编码与测试的有价值的软件。

胜过

与客户确定合同后在初期制定并 遵循基于活动的完整计划，在重型过程和工具指导下，通过完成

大量文档进行知识传递， 最后交付需求。

《敏捷宣言》

12< /p>

条原则

1.

最 优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。

2.

欢迎需求变化，甚至在开发后期。敏捷过程控制、利用变化帮助客户取得竞争优 势。

3.

频繁交付可用的软件，间隔 从两周到两个月，偏爱更短的时间尺度。

4.

在整个项目中业务人员和开发人员必须每天在一起工作。

5.

以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够 完成工作。

6.

在开发团队内外传递 信息最有效率和效果的方法是面对面的交流。

7.

< p>
可用的软件是进展的主要度量指标。

8.

敏捷过程提倡可持续发展。发起人、开发者和用户应始终保持稳定的步调。

9.

简化——使必要的工作最小化的艺术——是关键。< /p>

10.

持续关注技术上的精益求精和良 好的设计以增强敏捷性。

11.

最好 的架构、需求和设计产生于自我组织的团队。

12.

团队定期地对运作如何更加有效进行反思，并相应地调整、校正自己的行为。

精心整理

敏捷的角色

1

产品负责人

产品负责人（

ProductOwner

）的职责如下：

?

确定产品的功能。

?

决定发布的日期和发布内容。

?

为产品的

ROI

负责。

?

根据市场价值确定功能优先级。

< /p>

?

每个

Sprint

，根据需要调整功能和优先级（每个

Sprint

开始前调 整）

。

?

接 受或拒绝接受开发团队的工作成果。

2ScrumMaster

作为

Te amLeader

和

Productowner

紧密地工作在一起，他可以及时地为团队成员提供帮助。

他必须

:

?

保证团队资源完全可被利用并且全部是高产出的。

?

保证各个角色及职责的良好协作。

?

解决团队开发中的障碍。

?

做为团队和外部的接口，屏蔽外界对团队成员的干扰。

?

保证开发过程按计划进行，组织

< br>DailyScrum

,

SprintReviewan dSprintPlanningmeetings

。

3Team

负责产品的开发

?

一般情况人数在

5-9

个左右

?

团队要跨职能

（包括开发人员、测试人员、用户界面设计师等）

< p>
?

团队成员需要全职。

（有些情况例外，比如数据 库管理员）

?

在项目向导范围内有权 利做任何事情已确保达到

Sprint

的目标。

?

高度的自组织能力。

< /p>

?

向

ProductOwner

演示产品功能。

?

团 队成员构成在

sprint

内不允许变化。

?

团队整体向产品开发负责。

敏捷工件

1

、

Product

Backlog

有优先级的故事列表，并估算故事点

产品订单：产品订单（

ProductBacklog

）是整个 项目的概要文档，它包含已划分优先等级的、

项目要开发的系统或产品的需求清单，

包括功能和非功能性需求及其他假设和约束条件。

产品负责

精心整理

人和团队主要按业务和依赖性的重要 程度划分优先等级，

并作出预估。

预估值的精确度取决于产品< /p>

订单中条目的优先级和细致程度，

入选下一个冲刺的最高优先等级 条目的预估会非常精确。

产品的

需求清单是动态的，随着产品及 其使用环境的变化而变化，并且只要产品存在，它就随之存在。

而

且，

在整个产品生命周期中，

管理层不断确定产品需求或对之 做出改变，

以保证产品适用性、

实用

性 和竞争性。

2

、

SprintBacklog

当前

Sprint

要完成的任务列表，并估算工时

?

团队成员自己挑选任务，而不是指派任务

?

对每一个任务，每天要更新剩余的工作量估算

?

每个团队成员都可以修改

Spr intbacklog

，增加、删除或者修改任务

< p>
冲刺订单：

冲刺订单是大大细化了的文档，

用来界 定工作或任务，

定义团队在

Story

中的任务

清单，

这些任务会将当前冲刺选定的产品订单转化为完 整的产品功能增量。

冲刺订单在冲刺规划会

议中形成，

其包含的不会被分派，

而是由团队成员签名认领他们喜爱的任务。

任务被分解为以小时

为单位，

没有任务可以超 过

16

个小时。

如果一个任务超过

16

个小时，

那么它就应该被进一步分解。

每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量，且仅团队有权改变其 内容。

3

、发布燃尽图

直观反应当前发布剩余的工作量，以

Sprint

周期数和 故事点数为单位。

燃尽图（

Burn downChart

）是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间，显

示当前冲刺中随时间变化而变化的剩余工作量

（可以是未完成的 任务数目，

或在冲刺订单上未完成

的订单项的数目）

< p>
。剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。

我们可以借助它设想在增加或减少发布功能后项目的情况，

我们可能缩短开发时间，

或延长开发期

限以获得更多功能。它可以展示项目实际进度与计 划之间的矛盾。

4

、

Sprint

燃尽图

Spr int

燃尽图直观的反映了

Sprint

过程中，剩余的工作量情况，

Y

轴表示剩余的工作，

X

轴表示

Sprint

的时间。随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上

的误差或者遗漏工 作量有可能呈上升态势。