敏捷入门读物

敏捷开发如何不同于其他方法?

敏捷项目以增量方式构建软件,通常使用 1-14 周的短迭代,来使开发满足不断变化的业务需求。

而不是一刀切的方式,事先预测所有要求和风险的 6–18 个月 的发布:

敏捷通过每 1–4 周的迭代交付有效且经过测试的代码来适应频繁的反馈:

敏捷团队中有哪些不同的角色?

Scrum 专家扮演了仆人式领导者的角色,有助于团队坚持实践,从而做出和实现承诺。职责包括:

  • 启用所有角色和职能间的紧密合作
  • 删除障碍并保护团队不受干扰
  • 与组织协作跟踪进度并重组组织结构和流程
  • 确保敏捷的监管和适应性流程得到利用,其中包括每日例会、计划会议、演示和复查以及回顾
  • 促进团队会议和决策制定会话

产品所有者从业务角度推动产品。职责包括:

  • 定义要求并将其价值按优先级排序
  • 确定发布日期和内容
  • 在迭代和发布计划会议中扮演积极角色
  • 确保团队始终专注于最有价值的要求
  • 代表客户的心声
  • 验收满足团队已完成定义的情景和已定义的验收标准

敏捷团队

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

敏捷团队在迭代中工作以交付用户情景。

团队基于每个情景的积压工作优先级和规模将情景计划到其迭代中。

团队根据其产能(可用于完成任务的可用小时数)确定计划进迭代的范围大小。

为什么应该关注情景分数?

  • 分数:定义团队可以承诺的数量
  • 产能:定义一个人可以承诺的工作量

什么是用户情景?

用户情景是用于定义用户所需要的功能的要求。它可以采用两种格式:

  • 作为用户角色>我需要功能>以便业务价值>
  • 为了业务价值>,作为用户角色>我需要功能>

在发布计划期间,通过相对比例(如分数)提供用户情景的粗略规模估算。

在迭代计划期间,将情景拆分成任务。

敏捷在生成有用且现实的估算方面非常严谨。

用户情景和任务之间的关系是什么?

用户情景讨论的是用户需求。

任务是如何实现功能。情景由任务实施。实际的工作比情景更加细化。每个情景实际上是任务的集合。

我们等待将情景拆分成任务,直到为当前迭代计划情景。及时制定详细信息可以利用学习和反馈。

任务按小时估算,通常在 2-12 个小时之间。

情景已通过验收测试验证。

情景何时完成?

团队可决定何时完成。条件可能包括:

  • 所有任务已完成(开发、测试、文档)
  • 所有验收测试正在运行并且通过
  • 零个未结缺陷
  • 已由产品所有者验收
  • 无法向用户交付

团队定义其已完成定义并承诺在每个迭代期间完成该定义的所有情景。

验收标准是什么?

定义该功能所需的功能、行为和性能的标准,以便其为产品所有者或客户验收。

验收标准的角色是定义已完成的内容,以便开发人员了解完成该情景的时间。如果您不想留下供开发人员定义的情景区域,则可以编写验收标准。例如,如果您强烈感觉应如何对错误消息进行措辞,可以提供设计文档来说明错误消息的格式和措辞,或者您可以为每个可能生成错误的情景编写验收标准以指定消息措辞。

如何在敏捷中定义要求?

定义为:用户情景、验收标准以及要实施情景的任务。

反馈

需要更多帮助? CA Agile Central 社区为您提供一站式自助和支持。要将反馈或支持请求提交到 CA Agile Central 支持、获取解答并与其他用户协作,请加入我们的 CA Agile Central 社区