摘要:
本文主要描述Scrum中完成的定义(Definition of Done,DoD)以及验收标准(Acceptance Criteria,AC)的用法。

“坑”的描述

完成的定义,即DoD不清晰,不仅仅是概念本身可能存在误解,常常由深层次的原因引起的。

完成的定义 与 验收标准

实际可能的例子

每日站会上,团队成员A:“昨天我完成了条目1!今天我将开始工作于条目2上。”

两天后,产品负责人找到团队,“条目1怎么回事,这个流程和我想要的并不一样……”

上面这个场景,每天都在不同的团队上演着。为什么会发生这样一幕?有可能他们缺少完成的定义与验收标准

完成的定义(摘录自Scrum指南)

“完成”的定义

当产品待办列表项或增量被描述为“完成”时,每个人都必须理解“完成”意味着什么。虽然在不同Scrum团队之间或许会存在显著差异,但是每个团队成员必须对完成工作意味着什么有相同的理解;以便确保透明化。这就是 Scrum 团队的“完成”定义,用来评估产品增量是否完成。

这一定义也同时被用来指导开发团队了解在Sprint计划会议时能够选择多少产品待办列表项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能增量。 开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的,所以产品负责人可以选择立即发布它。

如果“完成”的定义对增量来说是开发组织的惯例、标准或指南,那么所有Scrum团队都必须遵守它,以此为最低标准。 如果增量“完成”的定义不是开发组织的惯例,那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产品发布由多个 Scrum 团队一起开发,那么所有 Scrum 团队中的开发团队必须一起参与制定“完成”的定义。 每个增量都添加至之前的所有增量上,并且经过彻底地测试,以此确保整合在一起的所有增量都能工作。

随着团队的成熟,“完成”的定义会扩展,包含更为严格的标准来保证更高的质量。当使用新定义时,在先前“完成”增量中可能会发现尚需完成的工作。任何产品或系统都应该对其上面开发的工作有“完成”的定义。

Scrum指南中我们可以看出:

  • 整个产品有统一的完成的定义
  • 完成的定义是Scrum团队制定的,并共同理解的
  • 每个团队可以定制自己的完成的定义
  • 完成的定义可以扩展(当团队成熟之后)

完成的定义一个例子(有下划线的内容为当前产品的完成的定义,随着团队成熟,其他未有下划线的部分,可以逐步加入到完成的定义中):

验收标准

验收标准(AC)是针对单个条目(如用户故事)而言的,如何验收(或确保)单个条目是满足客户要求的。验收标准具有如下的作用:

  • 定义用户故事或特性的边界
  • 帮助厘清客户要求
  • 团队与客户(以及产品负责人)达成共同理解
  • 根据验收标准可以有效的产生测试用例

验收标准的一个例子:
用户故事:

作为一个互联网银行用户,

我想要看到每日交易明细,

以便我很清楚每笔交易之后自己的账务情况。

验收标准的例子如下:

  • 默认显示最近一周的每笔交易明细
  • 显示当前账户余额
  • 显示指定日期时间段的交易明细

完成的定义与验收标准

共同点

  • 都是描述一个条目(特性,用户故事)是否完成的
  • 都需要团队参与讨论并得出结果的

不同点

  • 完成的定义是普遍性的,对每一个条目(特性,用户故事)都适用;而验收标准是具体的,只针对单个条目适用的
  • 完成的定义不需要客户参与讨论制定;而验收标准可能有客户(或干系人)参与,并从中提取

建议

  1. 在第一个Sprint之前,团队需要明确制定出初步的完成的定义(如果是多个团队工作在一个产品上,需要有产品级别的完成的定义);
  2. 针对每一个条目,在和产品负责人(或客户)讨论后,有明确的验收标准(AC)

针对本文的观点,您有任何建议与意见,欢迎与BoB取得联系。

BoB at c4at.cn

CATCenter for Agile Transformation 敏捷变革中心 CAT(Center for Agile Transformation)

  • 是中国第一家专注于组织敏捷转型及敏捷领导力发展的咨询公司。
  • 我们由中国第一批受过美国敏捷联盟专业认证的敏捷教练所组成。
  • 我们具备丰富的敏捷实践经验,也都热爱分享和服务我们的客户。

联络方式:
info@centerforagiletransformation.com
关注我们