“完成”谬论

作为敏捷实践者，您学习的最早想法之一是“完成，完成，完成”。 它背后有很多想法，但是对我而言，它归结为信任。 如果您不知道“完成”是什么意思，那么下一个让您实现交付的人可能会感到惊讶。

通常，我们不喜欢惊喜。

因此，无论何时交付，质量是什么或包含什么质量，最好对“完成”的真正含义达成共识。 如果可能，请在交货之前。

在敏捷团队中，“完成”的故事通常被定义为软件中的工作流程。 成熟的团队在故事中付出了足够的努力以确保它能够正常工作-自动测试，代码审查，部署自动化-接近团队对“工作软件”的定义。

如果团队将所有这些准备就绪，那么似乎如果我们预先定义了所有故事，我们实际上就会知道我们在功能，版本或产品级别上有多少“完成”。

直到足够好出货为止，它永远不会完成

我们不喜欢在敏捷方面进行大量的准备工作，因为事情会发生变化。 它们越大，将引入更多的变化。 它适用于需求，设计，体系结构和计划。

如果这是真的，那么我们永远无法真正知道我们正在前进多少。 如果团队目前正在处理最初为发行而提出的最初50个故事中的第25个故事，那么我们真的中途了吗？

在接下来的几个冲刺中，情况可能会发生变化-我们可能会学习到一些会促使我们删除或添加故事的东西，并有可能用其他故事取代它们。

在确切的时间点上，我们真的不知道我们做了多少。 这适用于功能，产品和产品组合级别。 我们只能决定是否准备好发货。 如果功能，产品或产品组合已准备好发布。 通常是采购订单或类似产品的人都必须说-好的，就足够了，发货。

即使在故事级别，我们也不会总是有时间编码和测试每条路径。 因此，即使一个“完成”的故事也可能无法真正完成，但仍然足以发布。

没关系。 因为无论从故事到作品集的任何级别，达到100％的完成都是浪费。 我们不需要其中的所有故事或功能。 一个好的产品负责人知道什么时候可以发货。

聪明的人会多次发货以获取反馈和学习，因为他们永远不会“理解”产品。

我们真的从来没有做过。 没关系。

翻译自: https://www.javacodegeeks.com/2015/06/the-done-fallacy.html