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

敏捷中的角色

Scrum大师

Scrum Master是团队负责人和协助者，可以帮助团队成员遵循敏捷实践，从而实现他们的承诺。 Scrum Master的职责如下-

• 使所有角色和职能之间紧密合作。

• 删除任何块。

• 保护团队免受任何干扰。

• 与组织合作以跟踪公司的进度和过程。

• 确保正确利用敏捷的Inspect＆Adapt流程，其中包括

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

产品拥有者

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

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

跨职能团队

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

产品负责人和Scrum主管被认为是团队界面的一部分，而其他成员则是技术界面的一部分。

敏捷团队如何计划工作?

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

点

点数定义团队可以投入多少。一个点通常是指8个小时。每个故事以点数估算。

容量

容量定义一个人可以承诺的数量。容量以小时为单位。

什么是用户故事?

用户故事是一项定义用户要求的功能要求。用户故事可以采用两种形式-

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

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

用户故事和任务的关系

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

故事完成后

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

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

什么是验收标准?

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

如何定义需求?

需求定义为

• 用户故事
• 具有验收标准，以及
• 实施故事的任务。

敏捷-宣言

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

我们正在探索通过开发和帮助他人来开发软件的更好方法。通过这项工作，我们实现了价值-

• 流程和工具上的个人和互动
• 通过综合文档工作软件
• 通过合同谈判进行客户合作
• 响应变更按照计划

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

敏捷宣言的十二项原则

• 客户满意度-通过尽早并持续交付有价值的软件，可以满足客户的最高要求。

• 欢迎更改-在软件开发过程中不可避免发生更改。不断变化的需求应该受到欢迎，即使在开发阶段的后期也是如此。敏捷流程应努力提高客户的竞争优势。

• 交付有效的软件-考虑到更短的时间，经常交付有效的软件，从几周到几个月不等。

• 协作-在项目的整个生命周期中，业务人员和开发人员必须一起工作。

• 动机-项目应该围绕有积极性的人建立。提供一个环境来支持单个团队成员并信任他们，以使他们感到有责任完成工作。

• 面对面的对话-面对面的对话是向开发团队内部和内部传达信息的最有效的方法。

• 根据工作软件衡量进度-工作软件是关键，它应该是进度的主要衡量标准。

• 保持稳定的步伐-敏捷过程旨在实现可持续发展。业务，开发人员和用户应该能够与项目保持恒定的步调。

• 监控-定期关注技术卓越性和良好的设计以增强敏捷性。

• 简单性-使事情保持简单，并使用简单的术语来衡量尚未完成的工作。

• 自组织的团队-敏捷团队应该是自组织的，并且不应该严重依赖其他团队，因为最好的架构，需求和设计都来自自组织的团队。

• 定期检查工作–定期检查所做的工作，以便团队可以思考如何提高效率并相应地调整其行为。

敏捷-特征

迭代/递增且随时可以发展

大多数敏捷开发方法将问题分解为较小的任务。没有针对任何需求的直接长期规划。通常，计划迭代的时间间隔很短，例如1-4周。为每次迭代创建一个跨职能团队，该团队可从事软件开发的所有功能，例如计划，需求分析，设计，编码，单元测试和验收测试。迭代结束时的结果是一个有效的产品，并在迭代结束时向涉众展示。

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

面对面的交流

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

信息辐射器(物理显示器)通常位于办公室的醒目位置，路人可以在其中看到敏捷团队的进度。该信息发送器显示了项目状态的最新摘要。

反馈回路

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

敏捷-每日站立

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

什么是每日站立?

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

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

  • 我昨天做了什么?
  • 我今天要做什么?
  • 我面临的任何障碍… /我因…而受阻

• 每日站立是为了状态更新，而不是任何讨论。为了进行讨论，团队成员应在其他时间安排另一次会议。

• 与会者通常是站着而不是坐着，这样会议才能很快结束。

为什么站立很重要?

每天进行敏捷站立的好处如下-

• 团队可以每天评估进度，并查看是否可以按照迭代计划进行交付。
• 每个团队成员都将自己当天的承诺告知所有。
• 它为团队提供了任何延迟或障碍的可见性。

谁来站起来?

• Scrum负责人，产品负责人和交付团队应每天参加站立会议。

• 鼓励利益相关者和客户参加会议，他们可以充当观察员，但不应参加站立会议。

• 记下每个团队成员的疑问和他们面临的问题是Scrum管理员的责任。

地理位置分散的团队

敏捷团队成员可以在不同时区进行操作，可以通过多种方式进行站起来-

• 轮流选择一个成员，该成员可以参加位于不同时区的团队的站立会议。

• 每个团队都有一个单独的站台，使用Rally，SharePoint，Wiki等工具更新站台的状态。

• 准备好各种通讯工具，例如电话会议，视频会议，即时通讯程序或任何其他第三方知识共享工具。

敏捷-完成的定义

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

用户故事

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

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

迭代

迭代是有时间限制的用户故事/缺陷的集合，这些故事/缺陷将在产品发布时进行处理并接受。在迭代计划会议期间定义迭代，并通过迭代演示和审查会议完成迭代。迭代也称为sprint 。迭代完成时

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

发布

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

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

敏捷-发布计划

发布计划的目的是创建一个计划以向产品交付增量。每2至3个月完成一次。

涉及谁?

• Scrum Master -Scrum Master充当敏捷交付团队的推动者。

• 产品负责人-产品负责人代表产品待办事项列表的一般视图。

• 敏捷团队-敏捷交付团队提供有关技术可行性或任何依赖关系的见解。

• 利益相关者–客户，项目经理，主题专家等利益相关者在制定发布计划决策时充当顾问。

规划的前提

发布计划的前提条件如下-

• 排序的产品待办事项，由产品负责人管理。通常，产品所有者认为可以使用五到十个功能，这些功能可以包含在发行版中

• 团队关于能力，已知速度或任何技术挑战的意见

• 高层视野

• 市场和业务目标

• 确认是否需要新产品待办事项

所需材料

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

• 发表议程，目的
• 活动挂图，白板，标记
• 投影仪，共享计划会议期间需要数据/工具的计算机的方式
• 计划数据

计划数据

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

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

输出

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

• 发布计划
• 承诺
• 要监视的问题，关注点，依存关系和假设
• 改善未来发布计划的建议

议程

发布计划的议程可以是-

• 开幕式-欢迎词，审查目的和议程，组织工具和业务发起人介绍。

• 产品愿景，路线图-显示产品的大图。

• 查看以前的版本-讨论可能影响计划的任何项目。

• 发布名称/主题-检查路线图主题的当前状态，并进行必要的调整(如果有)。

• 速度-显示当前版本和先前版本的速度。

• 发布时间表-查看关键的里程碑并确定发布时间以及发布内的迭代时间。

• 问题和疑虑-检查任何问题或疑虑并记录下来。

• 审查和更新的定义中完成-审查的基础上的技术，技能或团队成员自上次迭代/释放的变化进行并作出适当修改的定义。

• 要考虑的故事和项目-在当前发行版中提供要考虑进行计划的产品待办事项列表中的用户故事和功能。

• 确定尺寸值-如果速度未知，则规划要在发布计划中使用的尺寸值。

• 缩小故事的大小-交付团队确定要考虑的故事的适当大小，如果故事太大，则将故事分为多个迭代。产品负责人和主题专家将澄清疑问，详细说明接受标准，并进行适当的分类。 Scrum主管促进了协作。

• 将故事映射到迭代中-交付团队和产品所有者根据大小和速度在迭代中移动故事/缺陷。 Scrum主管促进了协作。

• 新问题或新问题-根据以前的经验检查任何新问题，并记录下来。

• 依赖关系和假设-检查在发布计划期间计划的任何依赖关系/假设。

• 提交-Scrum主管要求进行计划。交付团队和产品负责人将其标记为最佳计划，然后承诺移至下一个计划级别，即迭代计划。

• 沟通和物流计划-审查/更新发布的沟通和物流计划。

• 停车场-处理停车场意味着应解决所有项目或将其设置为操作项目。

• 分发行动项目和行动计划-在其所有者之间分发行动项目，处理行动计划。

• 回顾-征集参与者的反馈以使会议成功。

• 关闭-庆祝成功。

敏捷-迭代计划

迭代计划的目的是使团队完成排名靠前的产品待办事项集。该承诺根据迭代的时间和团队速度在时间上加框。

涉及谁?

• Scrum Master -Scrum Master充当敏捷交付团队的推动者。

• 产品负责人-产品负责人处理产品待办事项的详细视图及其接受标准。

• 敏捷团队-敏捷交付定义了他们的任务，并设定了履行承诺所需的工作量估算。

规划的前提

• 产品积压中的项目已调整大小并分配了相对的故事点。
• 产品所有者已对投资组合项目进行了排名。
• 每个投资组合项目都明确规定了接受标准。

规划过程

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

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

速度计算

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

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

任务能力

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

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

假设一个团队有5名成员，致力于在一个项目上全职工作(每天8小时)，并且在迭代过程中没有人请假，那么两周迭代的任务能力为-

5×8×10 = 400小时

规划步骤

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

敏捷-产品积压

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

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

• 已经做好准备，以便可以对每个功能进行估算。
• 它有助于规划产品路线图。
• 它有助于重新排列功能的等级，以便可以为产品增加更多的价值。
• 它有助于确定首先要确定的优先级。团队对项目进行排名，然后创造价值。

产品积压的特征

• 每个产品应具有一个产品待办事项列表，该待办事项列表可以包含一系列从大型到大型的功能。

• 多个团队可以处理一个产品积压。

• 功能排名是根据业务价值，技术价值，风险管理或战略适用性进行的。

• 在发布计划期间，排名最高的项目会分解为较小的故事，以便可以在以后的迭代中完成。

敏捷-有用的条款

验收标准

这是产品所有者或客户设置的条件，以便接受有效的功能并遵守其要求。

积压整理

这是一个持续的过程，产品经理或客户通过从敏捷团队获得反馈来管理积压的产品。此过程涉及确定投资组合项目的优先级，将其分解为较小的项目，为将来的迭代计划它们，创建新故事，更新验收标准或详细制定验收标准。

容量

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

特征

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

迭代

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

增量

增量是随着产品逐步发展而改变的状态。通常用里程碑或固定迭代次数表示。

产品拥有者

该产品所有者是敏捷交付团队的一成员，负责在产品积压收集和排名的业务需求。产品负责人传达要在发布/迭代中执行的操作。他/她设定承诺，并负责保护团队免受迭代过程中需求的任何更改。

产品积压

设置功能性和非功能性产品要求。

产品待办事项

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

点数

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

发布

一个完成工作以支持将可测试增量交付给软件的时间框。在Scrum中，发行版包含多个迭代。

需求

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

故事点

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

短跑

与迭代相同。

时间盒

一个固定的持续时间，在该持续时间中将开发可交付成果。通常，除了固定时间的开始和结束日期外，资源的数量也固定。

任务

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

用户故事

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

速度

在迭代或时间盒中加权已接受工作的度量。通常，它是迭代中接受的故事点的总和。