我对敏捷开发非常积极，并且断断续续地从事敏捷项目大约 13 年。但我有一个我从未真正能够解决的问题。它似乎并不总是表现出来，但它已经咬了我几次。
在某种意义上，敏捷似乎是一种“贪婪算法”。从价值最高的故事开始，优化系统以精确地完成该故事，然后重复。
实际的贪心算法容易收敛到局部最优解，而缺少全局最优解。
这是人们的经历吗？
真的有问题吗？
如果是这样，您使用什么技术来避免这种局部最优，同时保持敏捷？
【问题讨论】：
标签： agile
实际的贪心算法容易收敛到局部最优解，而缺少全局最优解。
如果没有建立 EPIC 技术用户故事和指南，以及正常的业务 EPIC 用户故事，这也是如此。
这是人们的经历吗？
有时是的，这是我的经验。一个例子是当我们处理的用户故事被分解太多时，解决方案是扩大它们以使我们的设计具有更全球化的视野。有时，同一个项目中的不同企业 scrum 团队会与不同的技术框架使用和方法发生冲突。
真的有问题吗？
如果您忽略技术 EPIC 用户故事或指南，这只是一个问题。
如果是这样，您使用什么技术来避免这种局部最优并保持敏捷？
这是解决此问题的一种敏捷方法： 在敏捷发布计划期间，不仅要提出业务 EPIC 用户故事，还要提出技术 EPIC 用户故事。技术 EPIC 用户故事从技术角度具有产品愿景，包括技术架构、应用程序框架、质量标准和全球设计考虑等。这些可以分解为更小的技术用户故事，并拥有一个 Scrum 团队这有助于让这些用户故事发挥作用。一个用户故事的例子可以是：“作为一名技术项目经理，我希望整个企业项目使用 A、B、C 框架，并按照 X、Y、Z 编码标准进行编码，以便项目开发具有统一性工作。 如果您不想为此单独组建 Scrum 团队，那么只需将它们作为提醒卡放在待办事项旁边，供开发团队用作指导。
作为测试指南，我们曾经将成功的集成测试作为每个待办事项的完成标准。在集成环境中对所有企业团队部署的所有工作软件进行了全球测试，以认为其可交付。因此，从开始到结束积压工作，主题都是为全球工作软件设定的，而不仅仅是本地工作软件。
最后，敏捷开发涉及持续关注质量，质量问题之一可能是糟糕的设计或过于本地化的设计。当发现这一点时，应该在该积压工作本身内重新设计它，并为其他积压工作继续前进。
【讨论】：
我参与的一个项目遇到了这个问题，并且没有有效地处理它。
代码的本地质量——比如说，超过一个包的规模——还不错。但是在更大的范围内存在问题；诸如包之间的逻辑（但不是代码）重复、在我们应该使用事件驱动方法的情况下使用批处理重新计算作业、在错误的位置将系统拆分为单独的服务等。
这些问题都不能通过重构单个类或包来解决。结果，它们从未在正常的事件过程中发生。我们以较小的规模进行了重构——当添加一个特性时，我们会在开始之前在那个区域进行重构，并在我们完成之后再次进行重构（以及在我们进行的过程中努力编写好的代码）。但这从未导致重构更大的架构问题。
我们都意识到了这些问题，只是在我们的过程中没有任何东西可以让我们解决这些问题。
我们确实取得的一个显着胜利是两个远相关的模块之间存在重复。本质上，有代码可以渲染一个网页，显示一些计算的结果，还有一个后台作业来生成执行类似计算的报告。计算代码是共享的，但设置计算的代码不是；一个由用户的视图偏好驱动，而另一个由配置的报告作业驱动。我们有一个要实现的功能，它涉及向计算添加一个新方面，这意味着向两种配置添加更多项目，然后向两组计算设置代码添加业务逻辑。我们设法让产品经理（我们的客户代理）同意为工作预算足够的时间，以便我们可以重构以统一用户视图偏好和配置报告工作的想法，因此丢弃重复的一侧，然后实现该功能。这比仅仅实施两次花费的时间更长，但产品经理很明智地意识到，这将使我们能够更快地实施跨越页面和报告的未来功能。
我们这样做的过程中的机制是为重构工作编写故事。本质上，类似于“作为产品经理，我希望页面和报告使用通用计算设置代码，以便我可以更快地添加功能”。这绝对不是一个合适的故事，但它适合系统，并且完成了工作。
我认为，如果这个项目的运行更健康一点，那么这样的故事就会源源不断。我们会承认我们有很多架构债务，而偿还债务的工作是有价值的，并将我们固定的时间分配给它，也许大约 20%（这实际上意味着一次一对）。然后，我们可以生成功能/史诗、故事和任务，就像我们为面向客户的工作所做的那样。这些将来自团队本身，而不是产品经理。
遗憾的是，开发和产品管理双方之间没有足够的沟通和信任，因此这是可行的；我们可以对产品说我们有问题，这很重要，而且需要很长时间才能解决，他们不知道这是不是真的。因此，他们通常不愿意安排时间来做这件事。可悲的是，每个人都同意存在问题并且解决它们会很好，我们只是在实际执行时陷入僵局。
【讨论】：
根据我的经验，如果您的项目环境具有固定的时间/要求，那么是的，大多数情况下敏捷会导致局部最优。
但我的观点是，在一项复杂的工作中，需求、团队本身甚至目标都会发生变化。敏捷也是关于拥抱变化。 然后，矛盾的是，这种贪心策略在处理移动目标时成为全局优化的合理选择。
【讨论】：