敏捷是一种软件开发方法，可使用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个小时。
• 故事使用验收测试进行验证。

故事完成后

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

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

什么是验收标准?

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

如何定义需求?

需求定义为

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