“完成”谬论

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

通常,我们不喜欢惊喜。

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

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

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

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

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

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

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

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

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

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

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

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

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

你可能感兴趣的