chaos vpn_CHAOS报告和#NoEstimates

chaos vpn

您知道新年的最佳方法是什么？ 回顾项目的成功率！

Standish集团已经发布CHAOS报告已有20多年了。 我发现他们仍然使用相同的项目成功与失败标准并不感到惊讶。 这是CHAOS定义的摘要：

决议类型1，或项目成功 ：项目按时且按预算完成，其所有特征和功能均如最初指定的那样。
决议类型2，或面临挑战的项目：该项目已完成并投入运营，但在预算范围内超出了预算，且提供的功能比最初指定的要少。
分辨率类型3，或项目失败 ：在开发周期中某个时候该项目被取消或已交付， 但未使用 。

如我们所见，铁三角仍然占主导地位。 我们仍在根据初始范围估算初始成本和持续时间的良好程度来衡量成功与否。 由于该研究中有一半的项目陷入了挑战 ，而且失败的比例增加了约20％，我们的行业并没有比以前做得更好（尽管自2004年以来，成功的数量略有增加，失败的项目数量却略有减少） ）。

每个人都变得敏捷时怎么可能？ 敏捷不应该带来每个人都在寻找的生产力和效力吗？ 敏捷不是应该保存所有注定要失败的项目吗？

好吧，首先，不。 那不是，仍然不是敏捷的承诺。 敏捷性是指对市场需求做出有效React的能力。

反正成功是什么？

如果这是我们描述敏捷性的方式，那么我们是否应该基于相同的市场需求来考虑项目的成功？

项目成功意味着客户使用产品，最终金钱就进入了业务。 在这种情况下，敏捷项目（无论是哪种项目）的内容，持续时间和成本都会发生变化，以适应市场需求，从而获得成功。 如果我们放弃了多余的功能，并根据客户的实际需求发布了产品，这是否意味着我们没有成功？

或者，可能要花更多的时间才能找到真正的产品/市场契合度。 我们已经超出预算并超出了时间估算。 但是最终我们的初创公司被MegaCorp买走了，却大张旗鼓地卖了？ 这是一个挑战项目吗？

最后，我们仍然在项目开始时设定成功目标。 当我们对此知之甚少时，我们还没有识别出所有已知的未知数（更不用说未知的未知数了）。 我们在空白的地图上放了一个大头针，为取得适度的经济成功而获得很高的评价，而巨大的经济成功则可能很遥远。

我们从错误的脚开始，并且我们有这样做的动力。

这导致我做出估计，因为当我们没有所有信息时，这就是我们要做的。 我们估算时间和成本，然后做出决定。 该项目可以执行/不执行。 延迟该功能，因为它会花费太多时间来开发（或者会吗？这仍然是一个猜测）。

在2015年敏捷从业者大会上，我将演讲“ 估计或#NoEstimates ”。 估算是驱动决策的唯一方法吗？ 还有其他选择吗？ 我们是否注定要继续根据我们的猜测质量进行评分？

你不想错过那个。

如果尚未注册 ，请注册 。

翻译自: https://www.javacodegeeks.com/2015/01/the-chaos-report-and-noestimates.html

chaos vpn