糟糕的敏捷需求曲线

在解释敏捷需求曲线时，我在上一篇文章中讲了一个好消息。 这次我想讲一个坏消息。 这是每一个经典项目经理对敏捷的恐惧，我们不经常讲述它的故事，但是它可能会发生。 一旦我讲了这个故事，我们就可以对敏捷需求曲线进行适当的分析。

因此，一个经典的项目经理看着敏捷，他看到了他最大的恐惧：没有范围限制。

没有签名可以确切地说明要构建的内容，甚至没有用铅笔签名，更不用说鲜血了。 有一些松散的“故事”。 但是他被告知敏捷和敏捷就是这样工作的，因此，根据他的更好判断，他陷入了困境–毕竟，他有时需要在自己的简历上加入敏捷。

在某种程度上，经典的项目经理是对这种恐惧的正确选择。

经过IT及其IT分包商多年的努力，企业听到了敏捷和“是的！ –我们终于要得到想要的东西。 不再为冗长的文档而烦恼，不再需要等待，也不再有错误。”

如今，当我去与一家公司谈论“走敏捷”时，敏捷宣传机器已经击败了我。 不幸的是，对于某些业务方面的人，他们认为“走敏捷”意味着他们可以随时随地拥有他们想要的任何东西。 如果开发团队是敏捷的，那么逻辑就是如此，那么即使企业不断改变主意，他们也将快速交付并准确交付所需的产品。

毕竟，这就是敏捷开发本身的方式，您几乎不能责怪业务方面。 不幸的是，敏捷作为“所有人的万事通”和“我不需要改变自己在做的事情”比健康更普遍。

这种态度的下一个效果是大大提高了需求曲线，如果确实影响了弹性，则可能会进一步减小弹性。

需求曲线从D移至D'。 在每个价格点，企业都希望得到更多。 当然，企业不会这样想。 他们只是在问自己一直想要的东西，但是现在，因为它是“敏捷”的，所以不受限制。

以前，需要以书面形式（大量书面形式）提出每个请求，并与各种管理者争辩，这意味着做出请求需要付出他们不愿付出的努力（一个代价）。 没有敏捷，一切都荡然无存，需求无限。

我知道有一个“项目”相当大，我们正在谈论数十个人。 需求旺盛，企业不断思考新想法，分析师不断在要求中找到更多工作，开发人员发现更多工作，而测试人员则更多（因为最初的质量无法满足需求）。

简而言之：我已经看到需求激增，我认为敏捷使之更有可能，因为它消除了以前用于控制需求的许多限制。

如果团队没有兑现（通常是不合理的）期望，那么“敏捷”将成为击败团队的另一种工具。

在这里值得注意的是：随着需求的产生，需求的大部分总是存在但被隐藏了。 还有一个更有趣的问题是：此需求的哪些要素值得做？ 这个问题需要等待。

我们需要在上面的图中添加供应。 我们需要在此处考虑并在此图中显示两种情况：

方案1：需求移至D'，但开发商仍在按原始供给曲线S进行操作。在这种情况下，数量和价格在两个维度上都将上升。 下图显示了这一点，黄色区域是敏捷前的成本，而绿色区域则是额外的成本。

情况2：需求再次移至D'，但这一次，团队按照Sa（供应敏捷）曲线进行操作。 这样我们得到这个图：

现在的情况变得更加复杂：由于供应具有弹性并且对价格做出了响应，因此生产的软件比开始时要多，但是单价却更低。 因此，蓝色表示增加的成本，而紫色表示节省的钱。

我敢打赌，您要问的直接问题是：他们的储蓄额是否超过了增长额？

碰巧是的。 在我的绘图工具上，目标区域占据了45个网格正方形，蓝色占据了46个网格正方形。

但是，这些曲线是我为便于阅读而放置的，没有任何实际团队的任何数据。 两者之间的差异很小，表明事情可能会发展。

应该问的一个更重要的问题是：团队能否带来更多利益？ 更多价值？

当我开始撰写此博客文章时，我的目的是表明交谈敏捷本身可以增加需求。 我要强调的问题是需求旺盛，而这不仅限于敏捷。 尽管我认为敏捷会让情况变得更糟。

我还展示了，如果开发团队确实是敏捷的，他们可以解决这个问题，但尚不清楚。

翻译自: https://www.javacodegeeks.com/2014/01/the-bad-agile-demand-curve.html