数据库索引什么时候会被打破_估计可能会被打破，但这不是邪恶的-CSDN博客

数据库索引什么时候会被打破

罗恩·杰弗里斯（Ron Jeffries）的文章《估算是邪恶的》（Evil）谈到了对软件项目的荒谬估算是多么荒谬，以及团队最终可能陷入的噩梦场景：

…然后，我们要求开发人员在完成所有这些工作时“估计”。 他们对这种产品的了解也比以往任何时候都少，而且他们对这些要求中的大多数不太了解。 但是他们尽力了，他们想出一个约会。 公司是否接受此日期？ 当然不是！ 首先，这只是一个估计。 其次，很明显，开发人员会留下很多的懈怠，而他们总是这样做。 第三，那不是我们想要的时候。 我们希望早点。

因此，我们推回了开发人员的估计，然后越来越努力地倾斜，直到我们确定我们已经将他们遗留的所有脂肪挤出来了。有时我们甚至只是告诉他们何时必须完成。

无论哪种方式，开发人员都离开房间，低着头，非常确定他们再次被要求做不可能的事情。商界人士写下了日期：“开发发誓他们将在11月13日下午12:25完成。”

软件估算被破坏

软件评估-我们大多数人这样做的方式- 已失效。作为一个行业，我们很不擅长评估，很长一段时间以来我们都对此不满意，而且没有证据表明我们在这一方面做得更好。

开发人员知道这一点。企业知道这一点，因此他们不相信开发团队的想法，而是尝试制定自己的计划。管理层也知道这一点，因此他们会围绕估算工作（我会把所有事情加倍），或者更糟的是，他们滥用估算，将其砍掉，然后将其用作推动团队朝着无法实现的目标迈进的杠杆。

杰弗里斯（Jeffries）说，即使是那些试图正确估计的团队，也确实过分关注可预测性（以及所有试图实现可预测性的开销和肚脐注视），而实际上他们应该尽力尽快完成正确的事情，这是企业真正关心的全部。

因此，因为这很困难，并且因为我们不擅长，并且因为某些人忽略或滥用估计值，所以我们应该完全停止估计。

作为开发人员，我们需要做的是确保我们了解对业务最重要的事情，将问题分解为最小的部分，并立即开始迭代，交付某些东西，然后再进行下一个最重要的事情，并继续前进，直到业务得到他们真正需要的东西。如果您不能说服“他们”（赞助商）这是正确的工作方式，那么请仔细评估一下以使项目获得批准（知道您提出的任何想法都会出错，并且无论如何都要进行管理）并且业务将忽略它或对您使用它），然后投入实际工作：了解对业务最重要的事情，将问题分解为最小的部分，并立即开始迭代。换一种说法

“停止估算。 开始发货”。

马丁·福勒（Martin Fowler）在最近的《宗旨的目的》一文中写道，只有在估算值可以帮助您做出“重大决策”时才需要估算值。他的示例包括分配资源（投资组合管理可以/不可以-Jeffries在上面描述的游戏）和协调，您的团队的工作需要与其他团队相适应（尽管他只谈论与其他开发人员的协调，而忽略了与客户，合作伙伴和其他与软件开发无关的项目进行协调）。还有很多其他时候需要估算：交付固定价格合同，计划预算，何时需要达到到期日（例如，无论是否完成，整个行业都会发生变化））。

在剩下的时间里，如果您的团队足够小并且他们知道自己在做什么，并且他们与企业紧密合作并经常交付工作软件，那么没有人会非常在乎估计–坦白地说，这是如何我的团队做了很多工作。

但这是解决问题的方法，而不是项目管理方法。

如果您不知道自己在建造什么，为什么要估算？

它可以用于在线初创公司和其他探索性开发：您认为自己的想法不错，但是不确定细节，人们喜欢什么以及会流行什么。如果您真的不知道自己要建造什么，那么就没有必要去估计需要多长时间了。有人会决定您可以花多少钱，从简单开始，尽快提供有用和重要的东西（“ 最低可行产品 ”），这样您就可以获得反馈并不断进行迭代，直到希望有足够的人使用它并告诉您您真正需要建造的东西，或者用光了钱。

我们回到了进化原型，但严格关注最小的功能和优先级（仅做重要的事情，甚至不要尝试考虑整个项目，因为您可能不必始终交付它）和快速的反馈循环。现在称为“ 精益启动 ”方法。

如果明天要再次更改它，为什么要估算？

以这种方式工作对于许多在线业务也很有意义：Facebook，Twitter，Linkedin，Etsy Netflix如今都以这种方式工作。他们不断提供小的功能，或者将较大的更改分解为小步骤，并尽快将它们推出不完整但“黑暗”的状态（每天几次），不断摆弄UI，添加个性化功能和新渠道，与新的合作伙伴集成并不断捕获行为数据，以便他们可以告诉用户哪些变化或他们至少愿意忍受什么，尝试新的想法并进行A / B测试，知道其中有些或大多数想法会失败。

这项工作可以由小型团队独立完成，因此每个“项目”的规模和成本都很小。营销部门想要添加一个新界面或进行某种小型实验（细节是模糊的，我们将不得不对其进行迭代），大概只需要几周或一个月或两个月的时间，几个聪明的人在一起，您会看到可以快速完成工作。如果它不起作用或花费的时间太长，请取消它并继续下一个想法。这是一种注意力缺乏的工作方式，但是如果您追求的是新客户或新的收入来源，而客户会忍受您对他们的试验，那么它会起作用。

不用担心估计，只要让它起作用

例行维护（任何没有固定/失效日期的日期）也可以通过这种方式完成。大卫·安德森（David Anderson）支持看板的最有说服力的论点（无需估算就可以工作，并且不断推出个别工作）是在简化维护和运营工作。

企业对这种工作的管理方式并不在意–他们只是希望尽快修复重要的事情，并以尽可能低的成本进行。大部分工作是由个人或小型团队完成的，因此任何工作的成本也很小。您可以假设一切都需要3天或要做的事情，而不是花时间去尝试估计每个更改或修复，而如果您在3天后还没有完成，则停下来并将其上报给管理层，让他们查看并决定是否工作需要更多的范围界定，或者应该完全完成。专注于完成工作，每个人都很高兴。

为什么要费心估计–这只是另一个移动应用

而且它适用于移动应用程序开发，这又是由小型团队完成的大部分工作，并且大多数重点都放在用户体验上，其中不确定性更多地围绕客户的喜好（产品概念，外观和感觉–这意味着要进行大量的迭代设计工作，原型设计和可用性测试……这将花费多长时间？）而不是技术风险或项目风险。

但是您不能不估计就无法运行项目

是的，很多工作已经完成，并且可以由小型团队在小型项目中完成，如果项目足够小且足够短，那么您可能不需要花太多时间或根本就不花时间进行估计，因为您并没有真正在运行项目，您正在解决问题。

但是，这种工作方式并不能扩展到大型组织，这些组织运行着具有重大业务和技术风险的大型项目和大型程序，这些业务和技术风险需要进行全面管理，并且需要在不同团队之间进行协调，这些团队在不同的地方做很多不同的事情在不同的时间，有很多切换，集成点和依赖项。在这里，可预测性–知道自己的位置并信心满满地向前看（以及其他每个人将要成为的地方）–比最小化周期时间，快速反馈和即兴发挥更为重要。

这取决于您是否需要将大型项目交付，还是可以解决许多较小的问题。尽管有证据表明软件开发项目的平均时间正在缩短（因为人们已经知道，较小的项目失败的频率较小，或者至少失败的速度更快），但有些问题太大了，无法一一解决。因此，估计不会消失-我们大多数人必须了解更好的估计，并且会做得更好。

#NoEstimates –无需估算即可构建软件–就像早期的敏捷开发一样。然后，这一切都是由小型的crackjack程序员团队快速交付小项目（或不交付但仍然快速完成），并且违背了公认的开发方法。敏捷没有扩展，但是它引起了很大的轰动，并取得了足够的成功，最终许多想法进入了主流，我们找到了平衡敏捷和纪律的方法，因此，如今，敏捷开发方法已被成功地用于甚至更大的规模。规模计划。我看不出有人会如何在不估计的情况下成功地管理大型项目，但这并不意味着有些人不会尝试–我只是不想在尝试时就在周围。

参考： 估计可能会被破坏，但我们的JCG合作伙伴 Jim Bird在Building Real Software博客上说的并不邪恶。