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