敏捷需求管理_良好的敏捷需求曲线

敏捷需求管理

关于敏捷和需求曲线，我很抱歉，很抱歉。 延迟的部分原因是软件需求并不简单。

在我上一次有关软件经济学的文章中，我讨论了为什么自定义软件的软件需求曲线既高（即人们需要大量软件）又缺乏弹性（即成本增加不会使需求减少太多）。看看应用敏捷如何改变需求曲线。

为了解释在敏捷环境中软件需求发生了什么，我们需要考虑不同的可能性。 因此，让我们从一个好新闻故事开始-不好的新故事和分析将在以后的博客文章中进行。

这个故事是关于一个团队如何使用敏捷软件开发减少对软件的需求并更快地交付产品。 这是大多数敏捷倡导者会联想并乐于推广的故事。 这就是敏捷应该发挥作用的方式……。

曾经有一个团队采用敏捷软件开发。 最初，他们能够按更规律的时间表将增强的软件演示给业务中的其他人。 他们为此做了一件大事，并邀请其他人来看看。 这产生了关于他们正在创造的事物的反馈：一些好东西，有些不是很好，一些要求更多的东西，以及一些被要求取消的东西。

过了一会儿，他们宣布发布更多常规版本。 而且由于该软件“准备发布”的频率更高，因此企业可以决定：“我们现在是否想要它-可能带来任何痛苦？ 还是我们要再等一会儿？” （正如他们所说，手里的一只鸟值得在灌木丛中两只。）

同时，该团队正在采用可提高代码质量的技术实践–他们还具有减少代码量的副作用。 这不仅提高了团队的生产力，因为他们需要维护的代码更少并且没有要解决的错误，而且还意味着企业没有太多理由抱怨错误。

（根据我的经验，对于某些团队来说，关于“您是否已解决它？”和“我们可以释放它？”的对话开始消失了，这表明企业不知道要什么。他们已经忘记了或从来不知道他们真正想要什么。）

团队在某些时候还采用了用户故事。 随着他们在这项技术上的进步，他们面临着挑战：“谁真正想要这个故事？”。 不久，故事就从“作为用户”发展为更具体的故事。

有一天，“产品负责人”意识到：他们不是在制造一种产品，而是在制造两种产品。

总体而言，要做的产品待办事项会更好，因为两个产品都有两个待办事项，每个都有自己的用户/客户群。 用户故事帮助他看到了这一点。

当他重组积压工作时，他发现他有三堆。 产品A，产品B并不合理。 两种产品中都没有很大一部分积压，可能多达三分之一。 它们是人们想要的好主意，但是当您分析它们时，它们并不属于任何地方，论据薄弱。

该图以图形方式显示了需求曲线。 团队从需求D开始，敏捷供应为Sa。 重组后的产品出现了各自的需求曲线Da和Db。 这些中的每一个都可以独立地进行推理。

在任何价格点，A加B的总需求都小于D（原始总需求），因为有些工作已经消失了。 注意：我没有建议对曲线的斜率进行任何更改，不同的产品可能具有不同的弹性，但这是另一种讨论。

尽管团队一直在与许多错误进行斗争，而他们的输出对于组织的其他成员来说却是一个黑洞，而当他们认为自己正在开发一个大产品时，这种洞察力就被他们所掩盖了。

这就是敏捷应该在需求方面工作的方式。 通过清晰，专注于交付，反馈给用户和客户，人们可以得到他们想要的东西。

但是，你知道吗？ 该团队的所有成员仍在工作，并且仍在软件上工作。 实际上，我认为团队可能会有所增长。 仍有工作要做，仍然有需求。

敏捷一方面减少了需求，但公司仍有许多工作要做，其中很多都意味着软件。 在一个地方减少需求只会使团队有更多的时间去完成其他需求的工作。

（好吧，如果我在讲这个故事时想起一个团队时是诚实的，我已经简化了它（剔除了一些粗略的边缘），并对其进行了一些综合以包括其他示例。我不认为这使故事无效，因为这应该是这样。）

参考：来自敏捷，精益，模式博客的JCG合作伙伴 Allan Kelly 的良好敏捷需求曲线 。

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

敏捷需求管理