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

敏捷中的角色

Scrum Master

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

• 实现所有角色和功能之间的紧密合作。
• 删除任何块。
• 保护团队免受任何干扰。
• 与组织合作以跟踪公司的进度和流程。

• 确保Agile Inspect＆Adapt流程得到适当利用，包括

  • 每日站立，
  • 计划会议，
  • 演示，
  • 评论，
  • 回顾会议，和
  • 促进团队会议和决策过程。

产品拥有者

产品负责人是从业务角度推动产品的人。职责或产品负责人如下 -

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

跨职能团队

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

产品负责人和Scrum master被认为是Team Interface的一部分，而其他成员则是Technical Interface的一部分。

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

敏捷团队在迭代中工作，以提供每次迭代为10到15天的用户故事。每个用户故事都是根据其积压优先级和大小来规划的。团队使用其能力 - 团队可以使用多少小时来完成任务 - 来决定他们计划的范围。

Story Point 点

Point定义了团队可以提交多少。一点通常指8小时。每个故事都以分数估算。

容量

容量定义了个人可以提交多少。容量估计为小时。

什么是用户故事？

用户故事是定义用户需要什么作为功能的要求。用户故事可以有两种形式 -

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

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

用户故事与任务的关系

• 用户故事讲述了要做什么。它定义了用户需要的内容。
• 任务谈论如何完成。它定义了如何实现功能。
• 故事由任务实现。每个故事都是一系列任务。
• 用户故事在当前迭代中计划时分为任务。
• 任务以小时计算，通常为2至12小时。
• 使用验收测试验证故事。

当一个故事完成

团队决定做什么意味着什么。标准可能是 -

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

什么是验收标准？

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

如何定义需求？

要求定义为

• 用户故事，
• 有了验收标准，和
• 实现故事的任务。

敏捷 - 宣言

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

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： -

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

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

敏捷宣言的十二项原则

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

敏捷 - 特征

迭代/增量和准备进化

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

演示之后，将审核评论并计划根据需要合并到工作软件中。

面对面交流

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

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

反馈回路

每日站立是任何敏捷开发的共同文化; 它也被称为每日Scrum。这是一种简短的会话，每个团队成员互相报告他们所做的事情，下一步该做什么以及他们面临的任何问题。

敏捷 - 每日站立

顾名思义，每日站立是敏捷团队所有成员之间的每日状态会议。它不仅提供定期更新的论坛，而且还将团队成员的问题集中在一起，以便快速解决。无论办公地点如何，无论如何建立敏捷团队，每日站立都是必须的做法。

什么是每日站立？

• 每日站立是所有团队成员之间的每日状态会议，大约持续15分钟。

• 每个成员都必须回答三个重要问题 -

  • 我昨天做了什么？
  • 我今天要做什么？
  • 我面临的任何障碍...... /我因......而被封锁
• 每日站立是为了状态更新，而不是任何讨论。对于讨论，团队成员应该在不同的时间安排另一次会议。
• 参与者通常站立而不是坐着，以便会议快速结束。

为什么站立是重要的？

每日站立敏捷的好处如下 -

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

谁出席了站立？

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

地理位置分散的团队

如果敏捷团队成员在不同的时区运营，可以通过多种方式进行站立 -

• 轮流选择会员，谁可以参加位于不同时区的团队的站立会议。
• 每个团队单独站立，在Rally，SharePoint，Wikis等工具中更新站立状态。
• 拥有各种各样的通信工具，如电话会议，视频会议，即时消息或任何其他第三方知识共享工具。

敏捷 - 完成的定义

用户故事，迭代和发布的完成定义如下。

用户故事

用户故事是在用户的日常用语中用几句话表达的要求，并且应该在迭代内完成。用户故事在何时完成

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

迭代

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

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

发布

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

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

敏捷 - 发布计划

发布计划的目的是创建一个计划，以便为产品提供增量。每2至3个月完成一次。

![图片上传中...]
)

谁参与了？

• Scrum Master - Scrum master是敏捷交付团队的推动者。
• 产品负责人 - 产品负责人代表产品待办事项的一般视图。
• 敏捷团队 - 敏捷交付团队提供有关技术可行性或任何依赖关系的见解。
• 利益相关者 - 像客户，项目经理，主题专家这样的利益相关者担任顾问，因为决策是围绕发布计划做出的。

规划的先决条件

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

• 由产品负责人管理的排名产品积压。通常采用五到十个特征，产品所有者认为可以包含在版本中
• 团队关于能力，已知速度或任何技术挑战的意见
• 高层愿景
• 市场和业务目标
• 确认是否需要新产品积压项目

所需材料

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

• 发表议程，目的
• 翻转图表，白板，标记
• 投影仪，在计划会议期间共享具有所需数据/工具的计算机的方式
• 规划数据

规划数据

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

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

产量

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

• 发布计划
• 承诺
• 要监控的问题，顾虑，依赖关系和假设
• 建议改进未来的发布计划

议程

发布计划的议程可以是 -

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

敏捷 - 迭代计划

迭代计划的目的是让团队完成一系列排名靠前的产品积压项目。此承诺是基于迭代长度和团队速度的时间框。

谁参与了？

• Scrum Master - Scrum master是敏捷交付团队的推动者。
• 产品负责人 - 产品负责人处理产品待办事项的详细视图及其验收标准。
• 敏捷团队 - 敏捷交付定义了他们的任务，并设置了履行承诺所需的工作量估算。

规划的先决条件

• 产品待办事项中的项目已调整大小并分配了相对故事点。
• 产品所有者已对产品组合项进行了排名。
• 已为每个项目组合项目明确说明了接受标准。

规划过程

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

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

速度计算

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

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

任务能力

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

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

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

5×8×10 = 400小时

规划步骤

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

敏捷 - 产品Backlog

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

产品Backlog为何重要？

• 它是经过准备的，可以对每个特征进行估算。
• 它有助于规划产品的路线图。
• 它有助于对功能进行重新排名，从而可以为产品添加更多价值。
• 它有助于确定优先排序的内容。团队对项目进行排名，然后建立价值。

产品积压的特征

• 每个产品应该有一个产品积压，可以有一组大到大的功能。
• 多个团队可以处理单个产品待办事项。
• 功能排名基于业务价值，技术价值，风险管理或战略适应性。
• 在发布计划期间，排名最高的项目会被分解为较小的故事，以便在将来的迭代中完成。

敏捷 - 实用术语

验收标准

这是产品所有者或客户设定的条件，以便接受有效且符合其要求的功能。

积压修饰

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

容量

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

特征

对产品或对利益相关者有价值的能力的改进，可以在发布中开发。

迭代

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

增量

增量是产品在逐渐发展时的变化状态。它通常由里程碑或固定迭代次数表示。

产品拥有者

产品所有者是敏捷交付团队的成员，负责收集产品待办事项中的业务需求并对其进行排名。产品所有者在发布/迭代中传达要执行的操作。他/她设定承诺并负责保护团队在迭代期间不受任何需求变化的影响。

产品积压

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

产品待办事项

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

点

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

发布

一个时间框，用于完成工作以支持向软件提供可测试的增量。在scrum中，发布包含多次迭代。

需求

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

故事点

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

短跑

与迭代相同。

时间盒

确定可交付成果的固定持续时间。通常，随着时间框的修复开始和结束日期，资源的数量也是固定的。

任务

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

用户故事

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

速度

在迭代或时间框中对接受的工作进行加权的度量。通常它是迭代中接受的故事点的总和。