对于成熟的团队来说，好的“完成的定义”是什么样的？

当查看各种来源的完成定义的示例时，它们通常包括以下几点：

• 代码完成
• 单元测试运行
• 同行评审或配对的代码
• 签入代码
• 文档更新
• …

在我们的团队中，我们有一个类似的列表，但是没人看过，因为这些观点如此明显，以至于任何人都不会跳过这些步骤。因此，我们想知道这是否主要是团队过渡到敏捷过程的工具，以及我们是否不应该摆脱它。

另一方面，许多文献声称，所有高绩效团队对完成都有很强的定义。这种暗示我们可能会错过改进的机会。

那么，对成熟团队所做的明确定义的例子有哪些？它们通常包括哪些点？

指南适用于所有人。正如您提到的，在一个成熟的团队中，每个人都在做，所以这并不意味着没有地方。假设有一个新成员加入，而该成员以前从未接触过这种方法。拥有适当的结构对他至关重要。他不必打扰其他成员，也不必“忘记”可交付成果。

我认为，列出所有内容，包括显而易见的内容。也许，为不那么明显的人提供一个“简短的作弊清单”，如果它对那些想要简短清单的人有所帮助，但考虑新成员加入的情况。

这是一个反复的过程，每次您看到可以改进的地方时，都将其添加到完成的定义中。加班，您将制定一份与您的公司相关的清单。Anann已经提到了一些值得的事情。

仅仅因为这些要点是显而易见的，并不意味着人们会始终坚持下去。让我们再举两个例子-飞行员和外科医生。一架商用客机或一间手术室的座舱有多人，他们之间有很多教育和经验。但是，事情仍然出错–步骤混乱，忘记了某些东西，做错了一些东西。我已经看到许多消息来源站点显示，可以通过清单来防止由于飞行员错误而导致的大量飞机事故（多达70％）。根据研究人员的说法，在医学界，使用检查表可以预防多达29％的荷兰医疗事故诉讼。尽管这些人已经受过训练，事后看来很可能会发现他们做错了什么，但是发生了一些事情，导致他们失职。我还没有读过，但是清单宣言应该是相关的。它是从医学专业写的，但是使检查表或流程图可见以提醒操作的好处适用于任何专业。

因此，第一步是创建事物列表，这些事物是您完成的定义的一部分，并使之可见。任务有多明显并不重要，如果需要完成任务以使故事完成，则该任务必须在列表中。该列表必须在团队可见的地方。请注意，它不一定是花哨的或正式的 -也许只是每个人在问一个故事完成前需要问自己的一系列问题。

第二步是确定清单中的内容以完成定义。您需要完成的所有工作都应明确，明确，可以接受且切合实际。它还需要在时间范围内考虑完成。例如，您不需要在完成的定义中包括“修改代码”或“修改设计”-如果您不需要更改工作产品，则无需故事。

我怀疑一个很好的清单可以作为完成定义的基础：

• 是否已更新所有相关的单元，集成，系统和验收测试？
• 工作产品是否已转变为可发布的形式？例如，构建代码，可导出文件格式的文档等。
• 是否所有相关工作产品都经过同行评审？工作产品的示例包括源代码（生产和测试），注释，设计文档，测试过程和用户​​手册。
• 是否已执行所有相关测试（在所有测试级别）并通过？
• 代码是否已合并到集成存储库中？

当然，您需要为完成做一个好的定义，其中包括团队和客户认为可以增加价值的任何其他活动。如果它在清单上，那么应该做一些事情来为某人（团队，客户，用户）增加价值。通过清楚地枚举您的工作，您还可以识别并消除无关的活动以改善流程。

实际上，这听起来像是您很幸运：

在我们的团队中，我们有一个类似的清单，但是没人看过，因为这些观点如此明显

您的团队已经“成熟” ；-)。但是总有改进的空间！

对你的问题：

那么，对成熟团队所做的明确定义的例子有哪些？它们通常包括哪些点？

在列表的顶部，您可以添加：

各种代码质量指标：-不稳定性，抽象-LOC与DLOC（已记录）-等等...

经验法则可能是该指标不会随着您的提交而变差。最重要的是，如果有人确实使指标变得更好，则可以制定“ done：withExcellence”。尽管此操作（度量标准不断提高）通常不是开发阶段（新功能）的一部分，而是重构阶段。

在我过去的一家公司中，我们有一个“完成”的定义，该定义表示您的指标必须保持在某些阈值以下，如果超过该阈值，则尚未完成。（除非您有非常非常好的借口，例如复杂的计算，否则循环复杂性永远都不能超过15。）

Checkstyle类型的违规行为也是如此，尤其是当您有自定义规则集来检查团队的代码风格时。如果您违反编码标准，则尚未完成。

然后，您不仅可以执行UnitTest，还可以测量代码覆盖率。如果没有覆盖至少50％，则说明您还没有完成。尽管这是完成的一种确定的定义，但是由于您应该对核心/主要/关键方法进行测试，而不必对代码库的100％进行测试。

哦，是的。。。如果您拥有（应该）具有自动分支集成的CI服务器，则仅当您在DEV分支中的提交与当前的LIVE分支合并且没有任何错误时，您才能完成。（单元测试等）

嗯...这就是我从过去的公司/项目中所知道的全部信息，您的列表中没有提到。

我希望能给你一些想法;-)

干杯，

安南

在TDD / BDD环境中，“完成”的定义（技术上为“代码完成”，因为Matt S的“真正'完成'”的定义是正确的）：

• 所有自动测试均通过（这些自动测试应包括针对该故事编写的新测试，以验证所需功能或行为是否存在并可以正常工作）
• 通过了代码审查（团队中至少有一位高级开发人员很满意，可以使您的工作成为代码库的一部分，并且您没有“欺骗”或“破坏”整个故事的方式）
• 成功提交（包括通过所有自动测试，代码覆盖率指标，样式警察检查的构建机器人）

此时，您可以继续。这三点很关键，但这是普通团队编码人员必须关心的。无论是书面还是书面形式，它们在TDD环境中都是不可侵犯的。另外，当编码员是进行记录的人时，记录是另外一点。在我上一个敏捷团队中，文档由BA / QA处理；他们知道客户想要什么，已经运行了UAT，因此最有能力以对客户有意义的方式记录新功能，因此，文档不是编码人员“完成”定义的一部分，尽管它是一部分团队的定义。