敏捷 - 入门

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

敏捷中的角色

Scrum Master

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

• 促进所有角色和职能之间的密切合作。

• 消除任何障碍。

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

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

• 确保 Agile Inspect &适当利用 Adapt 流程，包括

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

产品负责人

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

• 定义需求并确定其价值的优先级。
• 确定发布日期和内容。
• 积极参与迭代规划和发布规划会议。
• 确保团队正在处理最有价值的需求。
• 代表客户的声音。
• 接受符合完成定义和定义的验收标准的用户故事。

跨职能团队

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

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

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

敏捷团队以迭代方式交付用户故事，每次迭代持续 10 到 15 天。每个用户故事都根据其积压优先级和大小进行规划。团队使用其能力减去团队可用于完成任务的小时数减去来决定他们有多少计划空间。

点

点定义团队可以投入多少。点通常指 8 小时。每个故事都以点为单位进行估算。

容量

容量定义个人可以投入多少。容量以小时为单位进行估算。

什么是用户故事?

用户故事是一种需求，它定义了用户需要什么功能。用户故事可以有两种形式 −

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

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

用户故事和任务的关系

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

故事完成时

团队决定完成的含义。标准可能为 −

• 所有任务(开发、测试)均已完成。
• 所有验收测试均已运行并通过。
• 没有缺陷。
• 产品所有者已接受该故事。
• 可交付给最终用户。

什么是验收标准?

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

如何定义需求?

需求定义为

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