敏捷 - 简介
敏捷是一种软件开发方法，通过使用 1 到 4 周的短迭代逐步构建软件，以便开发过程与不断变化的业务需求保持一致。与一次性开发 6 到 18 个月，所有需求和风险都在前期预测的方法不同，敏捷采用了一种频繁反馈的过程，在 1 到 4 周的迭代后交付可用的产品。
敏捷中的角色
Scrum Master（Scrum 负责人）
Scrum Master 是团队领导和协调员，帮助团队成员遵循敏捷实践，以便他们能够履行承诺。Scrum Master 的职责如下：
促使所有角色和职能之间紧密合作。
消除任何障碍。
保护团队不受任何干扰。
与组织合作跟踪公司的进度和流程。
确保正确利用敏捷检查和适应流程，包括：
- 每日站会，
- 计划会议，
- 演示，
- 评审，
- 回顾会议，以及
- 促进团队会议和决策过程。
产品负责人
产品负责人是从业务角度推动产品的人。产品负责人的职责如下：
- 定义需求并确定其优先级。
- 确定发布日期和内容。
- 在迭代计划和发布计划会议中发挥积极作用。
- 确保团队正在处理最有价值的需求。
- 代表客户的声音。
- 接受满足完成定义和定义的验收标准的用户故事。
跨职能团队
每个敏捷团队都应该是一个自给自足的团队，拥有 5 到 9 名团队成员，平均经验在 6 到 10 年之间。通常，一个敏捷团队由 3 到 4 名开发人员、1 名测试人员、1 名技术负责人、1 名产品负责人和 1 名 Scrum Master 组成。
产品负责人和 Scrum Master 被认为是团队接口的一部分，而其他成员是技术接口的一部分。
敏捷团队如何计划工作？
敏捷团队以迭代方式交付用户故事，每个迭代为 10 到 15 天。每个用户故事都根据其待办事项优先级和规模进行计划。团队利用其容量（团队有多少小时可用于处理任务）来决定他们有多少范围可以计划。
点数
点数定义了团队可以承诺多少。点数通常指的是 8 个小时。每个故事都以点数进行估算。
容量
容量定义了个人可以承诺多少。容量以小时估算。
什么是用户故事？
用户故事是定义用户所需功能的需求。用户故事可以有两种形式：
- 作为<用户角色>，我想要<功能>，以便<业务价值>
- 为了<业务价值>，作为<用户角色>，我想要<功能>
在发布计划期间，使用相对规模（点数）对用户故事进行粗略估算。在迭代计划期间，故事被分解成任务。
用户故事和任务的关系
- 用户故事讲述了要做什么。它定义了用户需要什么。
- 任务讲述了如何去做。它定义了如何实现功能。
- 故事由任务实现。每个故事都是任务的集合。
- 用户故事在当前迭代中计划时被分解成任务。
- 任务以小时估算，通常为 2 到 12 个小时。
- 故事使用验收测试进行验证。
故事何时完成
团队决定完成的含义。标准可能是：
- 所有任务（开发、测试）都已完成。
- 所有验收测试都在运行并已通过。
- 没有未解决的缺陷。
- 产品负责人已接受该故事。
- 可交付给最终用户。
什么是验收标准？
标准定义了功能、行为和性能要求，以便产品负责人可以接受它。它定义了要做什么，以便开发人员知道用户故事何时完成。
如何定义需求？
需求定义为
- 一个用户故事，
- 带有验收标准，以及
- 实现故事的任务。