敏捷 - 快速指南

敏捷 - 入门

敏捷是一种软件开发方法，使用 1 到 4 周的短迭代增量构建软件，以便开发过程与不断变化的业务需求保持一致。敏捷不是采用预先预测所有需求和风险的 6 到 18 个月的单程开发，而是采用频繁反馈的流程，在 1 到 4 周的迭代后交付可行的产品。

敏捷中的角色

敏捷大师

Scrum Master 是团队领导者和促进者，帮助团队成员遵循敏捷实践，以便他们能够履行自己的承诺。Scrum Master 的职责如下：

实现所有角色和职能之间的密切合作。
删除任何块。
保护团队免受任何干扰。
与组织合作跟踪公司的进展和流程。
确保正确利用敏捷检查和调整流程，其中包括
- 每日站会，
- 计划好的会议，
- 演示，
- 审查，
- 回顾会议，以及
- 促进团队会议和决策过程。

产品拥有者

产品负责人是从业务角度驱动产品的人。产品负责人的职责如下：

定义需求并确定其价值的优先顺序。
确定发布日期和内容。
在迭代计划和发布计划会议中发挥积极作用。
确保团队致力于最有价值的需求。
代表客户的声音。
接受满足已完成定义和定义的验收标准的用户故事。

跨职能团队

每个敏捷团队都应该是一个自给自足的团队，拥有 5 到 9 名团队成员，平均经验为 6 到 10 年。通常，敏捷团队由 3 至 4 名开发人员、1 名测试人员、1 名技术主管、1 名产品所有者和 1 名 Scrum Master 组成。

产品负责人和 Scrum 管理员被视为团队接口的一部分，而其他成员则被视为技术接口的一部分。

敏捷团队如何规划其工作？

敏捷团队通过迭代方式交付用户故事，每次迭代持续 10 到 15 天。每个用户故事都是根据其积压优先级和大小进行规划的。团队利用其能力（团队有多少时间可以完成任务）来决定他们必须规划多少范围。

观点

一个点定义了团队可以承诺的程度。一个点通常指8小时。每个故事都以点数来估计。

容量

能力定义了一个人可以承诺的程度。容量以小时为单位估算。

什么是用户故事？

用户故事是一种需求，它将用户所需的功能定义为功能。用户故事可以有两种形式 -

作为<用户角色>，我想要<功能>，以便<业务价值>
为了<业务价值>作为<用户角色>我想要<功能>

在发布计划期间，使用相对规模作为点对用户故事进行粗略估计。在迭代计划期间，故事被分解为任务。

用户故事和任务的关系

用户故事讲述了要做什么。它定义了用户的需求。
任务谈论如何完成它。它定义了如何实现功能。
故事是通过任务来实现的。每个故事都是任务的集合。
用户故事在当前迭代中规划时被划分为任务。
任务以小时为单位估算，通常为 2 到 12 小时。
使用验收测试来验证故事。

当一个故事完成时

团队决定完成的意义。标准可能是 -

所有任务（开发、测试）均已完成。
所有验收测试都正在运行并已通过。
没有缺陷是开放的。
产品负责人已经接受了这个故事。
可交付给最终用户。

什么是验收标准？

标准定义了功能所需的功能、Behave和性能，以便产品所有者能够接受。它定义了要做什么，以便开发人员知道用户故事何时完成。

要求是如何定义的？

要求定义为

用户故事，
具有验收标准，并且
实施故事的任务。

敏捷 - 宣言

2001 年 2 月，在犹他州的 Snowbird 度假村，17 位软件开发人员聚集在一起讨论轻量级开发方法。他们会议的结果是以下软件开发敏捷宣言 -

我们通过实践并帮助他人开发软件，从而发现更好的软件开发方法。通过这项工作，我们认识到了价值 -

流程和工具上的个体和交互

工作软件胜过综合文档

客户协作胜过合同谈判

响应变化遵循计划

也就是说，虽然右侧的项目有价值，但我们更看重左侧的项目。

敏捷宣言的十二项原则

客户满意度- 通过尽早和持续交付有价值的软件来满足客户的要求是最优先的。
欢迎变化- 在软件开发过程中，变化是不可避免的。不断变化的需求应该受到欢迎，即使是在开发阶段的后期。敏捷流程应该致力于提高客户的竞争优势。
交付工作软件- 考虑到更短的时间尺度，频繁地交付工作软件，从几周到几个月不等。
协作- 业务人员和开发人员必须在项目的整个生命周期中一起工作。
动机- 项目应该围绕有动机的个人建立。提供一个支持各个团队成员并信任他们的环境，使他们感到有责任完成工作。
面对面对话- 面对面对话是向开发团队以及在开发团队内部传达信息的最有效且最有效的方法。
根据工作软件衡量进度- 工作软件是关键，它应该是进度的主要衡量标准。
保持恒定的步伐- 敏捷流程旨在实现可持续发展。业务、开发人员和用户应该能够与项目保持一致的节奏。
监控- 定期关注卓越技术和良好设计以增强敏捷性。
简单性- 保持事情简单并使用简单的术语来衡量未完成的工作。
自组织团队- 敏捷团队应该是自组织的，不应该严重依赖其他团队，因为最好的架构、需求和设计都来自自组织团队。
定期回顾工作- 定期回顾已完成的工作，以便团队能够反思如何变得更加有效并相应地调整其Behave。

敏捷 - 特征

迭代/增量并准备好发展

大多数敏捷开发方法将问题分解为更小的任务。对于任何需求都没有直接的长期规划。通常，迭代的计划时间较短，例如 1 到 4 周。为每次迭代创建一个跨职能团队，负责软件开发的所有职能，如规划、需求分析、设计、编码、单元测试和验收测试。迭代结束时的结果是一个工作产品，并在迭代结束时向利益相关者演示。

演示后，将听取评审意见，并计划根据需要将其纳入工作软件中。

面对面沟通

每个敏捷团队都应该有一名客户代表，例如 Scrum 方法中的产品负责人。该代表被授权代表利益相关者行事，他可以在迭代之间回答开发人员的疑问。

信息辐射器（物理显示器）通常位于办公室的显着位置，路人可以看到敏捷团队的进展。该信息辐射器显示项目状态的最新摘要。

反馈回路

每日站会是任何敏捷开发的常见文化；它也称为每日站会。这是一种简短的会议，每个团队成员互相报告他们所做的事情的状态、下一步要做什么以及他们面临的任何问题。

敏捷 - 每日站立会议

每日站立会议，顾名思义，是敏捷团队所有成员之间的每日状态会议。它不仅提供了定期更新的论坛，还使团队成员的问题成为焦点，以便能够快速解决。无论敏捷团队如何建立，无论办公地点在哪里，每日站会都是必须要做的练习。

什么是每日站立会议？

每日站立会议是所有团队成员之间的每日状态会议，大约持续 15 分钟。
每个成员都必须回答三个重要问题 -
- 我昨天做了什么？
- 今天我要做什么？
- 我面临的任何障碍.../我被阻止是由于...
每日站会是为了更新状态，而不是为了任何讨论。为了进行讨论，团队成员应在不同时间安排另一次会议。
与会者通常站着而不是坐着，以便会议很快结束。

为什么站立很重要？

每天举行敏捷站立会议的好处如下：

团队可以每天评估进度，看看是否可以按照迭代计划交付。
每个团队成员都会告知他/她当天的所有承诺。
它可以让团队了解任何延误或障碍。

谁参加站立会议？

Scrum Master、产品负责人和交付团队应该每天参加站会。
我们鼓励利益相关者和客户参加会议，他们可以作为观察员，但不应该参加站立会议。
Scrum Master 的责任是记录每个团队成员的疑问和他们面临的问题。

地理分散的团队

如果敏捷团队成员来自不同时区，则可以通过多种方式进行站立会议 -

轮流选择一名成员，可以参加位于不同时区的团队的站立会议。
每个团队单独举行站立会议，在 Rally、SharePoint、Wiki 等工具中更新站立会议的状态。
准备好各种通信工具，例如电话会议、视频会议、即时消息或任何其他第三方知识共享工具。

敏捷——完成的定义

下面给出了用户故事、迭代和发布的完成定义。

用户故事

用户故事是用用户日常语言的几句话表述的需求，并且应该在迭代内完成。用户故事完成时

所有相关代码均已签入。
所有单元测试用例均已通过。
所有验收测试用例均已通过。
帮助文本已写入。
产品负责人已经接受了这个故事。

迭代

迭代是在产品发布期间要处理和接受的用户故事/缺陷的时间盒集合。迭代是在迭代计划会议期间定义的，并通过迭代演示和审查会议完成。迭代也称为冲刺。迭代完成时

产品备份已完成。
性能已经过测试。
用户故事已被接受或移至下一个迭代。
缺陷已被修复或推迟到下一次迭代。

发布

发布是一个重要的里程碑，代表产品/系统的工作、测试版本的内部或外部交付。发布完成时

系统经过压力测试。
性能已调整。
进行安全验证。
灾难恢复计划经过测试。

敏捷 - 发布计划

发布计划的目的是创建一个计划来交付产品增量。每 2 至 3 个月进行一次。

谁涉及？

Scrum Master - Scrum Master 充当敏捷交付团队的促进者。
产品负责人- 产品负责人代表了产品待办事项的总体视图。
敏捷团队- 敏捷交付团队提供有关技术可行性或任何依赖性的见解。
利益相关者- 客户、项目经理、主题专家等利益相关者在围绕发布计划做出决策时充当顾问。

规划的先决条件

发布计划的先决条件如下 -

由产品负责人管理的排名产品待办事项列表。通常，产品所有者认为可以包含在版本中的五到十个功能
团队关于能力、已知速度或任何技术挑战的意见
高瞻远瞩
市场和业务目标
确认是否需要新产品积压项目

所需材料

发布计划所需的材料清单如下 -

发布议程、目的
活动挂图、白板、记号笔
投影仪，在计划会议期间共享具有所需数据/工具的计算机的方式
规划数据

规划数据

进行发布计划所需的数据列表如下 -

先前的迭代或发布计划结果
各利益相关者对产品、市场状况和截止日期的反馈
先前版本/迭代的行动计划
要考虑的特征或缺陷
先前版本/估计的速度。
组织和个人日历
来自其他团队和主题专家的输入来管理任何依赖关系

输出

发布计划的输出可以如下 -

发布计划
承诺
要监控的问题、关注点、依赖性和假设
改进未来发布计划的建议

议程

发布计划的议程可以是 -

开幕式- 欢迎致辞、评审目的和议程、组织工具和商业赞助商介绍。
产品愿景、路线图- 显示产品的大图。
查看以前的版本- 讨论可能影响计划的任何项目。
发布名称/主题- 检查路线图主题的当前状态并进行所需的调整（如果有）。
Velocity - 显示当前版本和以前版本的速度。
发布时间表- 审查关键里程碑以及发布时间范围内的决策以及发布中的迭代。
问题和疑虑- 检查任何疑虑或问题并记录下来。
审查和更新完成的定义- 审查完成的定义，并根据自上次迭代/发布以来团队成员的技术、技能或变化进行适当的更改。
要考虑的故事和项目- 展示产品待办事项中的用户故事和功能，以考虑在当前版本中进行调度。
确定大小值- 如果速度未知，则计划要在发布计划中使用的大小值。
粗略故事的大小- 交付团队确定所考虑的故事的适当大小，如果故事太大，则将故事拆分为多个迭代。产品负责人和主题专家澄清疑虑，阐述验收标准，并进行适当的故事分割。Scrum Master 促进协作。
将故事映射到迭代- 交付团队和产品所有者根据大小和速度在迭代中移动故事/缺陷。Scrum Master 促进协作。
新的关注点或问题- 根据以前的经验检查任何新问题并记录下来。
依赖性和假设- 检查发布计划期间计划的任何依赖性/假设。
提交- Scrum Master 要求进行规划。交付团队和产品负责人将其视为最佳计划，然后承诺进入下一个计划级别，即迭代计划。
沟通和后勤规划- 审查/更新发布的沟通和后勤计划。
停车场- 处理停车场意味着所有项目都应该得到解决或设置为行动项目。
分发行动项目和行动计划- 在其所有者之间分发行动项目，处理行动计划。
回顾- 征求参与者的反馈以使会议取得成功。
关闭- 庆祝成功。

敏捷-迭代计划

迭代计划的目的是让团队完成一组排名靠前的产品积压项目。这一承诺是根据迭代长度和团队速度确定的。

谁涉及？

Scrum Master - Scrum Master 充当敏捷交付团队的促进者。
产品负责人- 产品负责人处理产品待办事项列表及其验收标准的详细视图。
敏捷团队- 敏捷交付定义了他们的任务并设置了履行承诺所需的工作量估计。

规划的先决条件

产品待办事项中的项目已确定大小并分配有相对的故事点。
产品负责人已对组合项目进行了排名。
每个投资组合项目都明确规定了验收标准。

规划流程

以下是迭代计划涉及的步骤 -

确定一次迭代中可以容纳多少个故事。
将这些故事分解为任务并将每个任务分配给其所有者。
每项任务都以小时为单位进行估算。
这些估算可帮助团队成员检查每个成员在迭代中拥有多少任务时间。
团队成员被分配任务时会考虑他们的速度或能力，这样他们就不会负担过重。

速度计算

敏捷团队根据过去的迭代计算速度。速度是在一次迭代中完成用户故事所需的平均单元数。例如，如果团队在最后三个迭代的每次迭代中采用 12、14、10 个故事点，则该团队可以采用 12 作为下一次迭代的速度。

计划速度告诉团队在当前迭代中可以完成多少个用户故事。如果团队快速完成分配的任务，则可以引入更多的用户故事。否则，故事也可以移出到下一次迭代。

任务能力

团队的能力源自以下三个事实 -

一天理想工作时间数
迭代中人员的可用天数
成员专用于团队的时间百分比。

假设一个团队有 5 名成员，致力于在一个项目上全职工作（每天 8 小时），并且在迭代期间没有人休假，那么两周迭代的任务容量将为 -

5 × 8 × 10 = 400 小时

规划步骤

产品负责人描述了产品积压中排名最高的项目。
团队描述了完成该项目所需的任务。
团队成员负责任务。
团队成员估计完成每项任务的时间。
对迭代中的所有项目重复这些步骤。
如果任何个人的任务超载，那么他/她的任务就会分配给其他团队成员。

敏捷 - 产品待办事项列表

产品待办事项列表是待完成项目的列表。项目按功能描述进行排名。在理想的情况下，项目应该分解为用户故事。

为什么产品待办事项很重要？

它的准备是为了可以对每个功能进行估计。
它有助于规划产品的路线图。
它有助于重新排列功能，以便为产品添加更多价值。
它有助于确定首先要优先考虑的事项。团队对项目进行排名，然后构建价值。

产品待办事项的特点

每个产品都应该有一个产品待办事项列表，其中可以包含一组大型到非常大的功能。
多个团队可以处理单个产品待办事项列表。
功能排名是根据业务价值、技术价值、风险管理或战略适应性进行的。
排名最高的项目在发布计划期间被分解为较小的故事，以便它们可以在未来的迭代中完成。

敏捷 - 有用术语

验收标准

它是产品所有者或客户设置的条件，以便接受功能有效并符合他们的要求。

待办事项整理

这是一个持续的过程，产品经理或客户通过从敏捷团队获取反馈来管理产品待办事项。此过程包括对组合项目进行优先级排序、将其分解为更小的项目、为未来的迭代进行规划、创建新故事、更新验收标准或详细阐述验收标准。

容量

它是团队在一次迭代中可以完成的工作量。

特征

对对利益相关者有价值的产品或功能所做的改进，可以在版本中开发。

迭代

基于主题的工作项，可以在规定的时间内完成并在产品发布时接受。迭代工作在迭代计划期间定义，并以演示和审查会议结束。它也被称为冲刺。

增量

增量是产品在逐步开发过程中状态的变化。它通常用里程碑或固定迭代次数来表示。

产品拥有者

产品负责人是敏捷交付团队的成员，负责收集产品待办事项中的业务需求并对其进行排序。产品负责人传达在发布/迭代中要做什么。他/她制定承诺并负责保护团队在迭代期间免受任何需求变化的影响。

产品积压

一组功能性和非功能性产品要求。

产品待办事项

可能是敏捷团队要开发的用户故事、缺陷、功能。

积分

用于设置用户故事、功能或任何其他组合项目的相对大小的通用单位。

发布

完成工作以支持向软件交付可测试增量的时间框。在 scrum 中，一个版本由多次迭代组成。

要求

满足规定的合同或功能的软件产品的规范。用户故事和组合项目是需求类型。

故事点

敏捷团队用来估计用户故事和功能的相对大小的单位。

短跑

与迭代相同。

时间盒

开发可交付成果的固定持续时间。通常，除了固定时间盒的开始和结束日期之外，资源的数量也是固定的。

任务

它是一个工作单元，有助于在迭代中完成用户故事。用户故事被分解为多个任务，每个任务可以在团队成员之间分配，并将他们标记为任务的所有者。团队成员可以根据需要负责每项任务、更新估算、记录已完成的工作或待办事项。

用户故事

列出的验收标准以满足用户的某些要求。它通常是从最终用户的角度编写的。

速度

一种衡量迭代或时间范围内已接受工作的衡量标准。通常它是迭代中接受的故事点的总和。