在敏捷项目中避免局部优化

  实际的贪婪算法很容易收敛到局部最优解，同时缺少全局最优解。 如果没有建立EPIC技术用户故事和指南，以及正常的业务EPIC用户故事，情况也是如此。   这是人们的经历吗？ 有时是，这是我的经验。其中一个例子就是我们所处理的用户故事被分解得太多，而解决方案是扩大它们以使我们的设计更加全球化。有时，同一个项目中的不同企业Scrum团队与不同的技术框架用途和方法相冲突。   这实际上是个问题吗？ 如果您忽略技术EPIC用户故事或指南，这只是一个问题。   如果是这样，你使用什么技术来避免这种局部最优并保持敏捷？ 以下是一种解决此问题的敏捷方法： 在敏捷发布计划期间，还提出了一个技术EPIC用户故事，而不仅仅是提出商业EPIC用户故事。技术EPIC用户故事将从技术架构，应用框架，质量标准和全球设计考虑等方面获得产品愿景。这些可以分解为更小的技术用户故事，并拥有Scrum团队这有助于让这些用户故事发挥作用。用户故事的一个例子可能是：“作为技术项目经理，我希望整个企业项目使用A，B，C框架，并根据X，Y，Z编码标准编码，以便项目开发一致工作。 如果您不想单独为此创建一个Scrum团队，那么只需将它们作为积压旁边的提醒卡，以便开发团队用作指南。 作为测试指南，我们曾经将成功的集成测试作为每个积压的完成标准。在集成环境中对所有企业团队部署的所有工作软件进行了全局测试，以确保其可以发布。因此，从开始到结束日志，主题都是针对全球工作软件而不仅仅是本地工作软件。 最后，敏捷开发涉及始终关注质量，其中一个质量问题可能是糟糕的设计或过于本地化的设计。当发现它时，应该在该积压本身内重新设计，然后继续进行其他积压工作。     

我一直在做一个有这个问题的项目，并没有有效地处理它。 代码的本地质量 - 比如一个包的规模 - 也不错。但是在更大的范围内存在问题;包之间的重复逻辑（但不是代码），使用批量重新计算工作，我们应该使用事件驱动的方法，将系统拆分为错误的地方的单独服务等等。 通过重构单个类或包可以解决这些问题。结果，他们从未发生过正常的事件。我们进行了较小规模的重构 - 在添加功能时，我们会在启动之前在该区域进行重构，并在完成之后再次进行重构（以及我们正在努力编写好的代码）。但这从未导致重构更大的建筑问题。 我们都意识到了这些问题，我们在我们的过程中没有任何东西让我们解决它们。 我们所做的一个值得注意的胜利是两个远程相关模块之间存在重复。基本上，有代码用于呈现显示某些计算结果的网页，以及用于生成执行类似计算的报告的后台作业。计算代码是共享的，但设置计算的代码不是;一个由用户的视图首选项驱动，而另一个由配置的报告作业驱动。我们有一个实现的功能，它将涉及为计算添加一个新的方面，这意味着为这两种配置添加更多项，然后向两组计算设置代码添加业务逻辑。我们设法让产品经理（我们的客户代理）同意为我们可以重构的工作预算足够的时间来统一用户视图偏好和配置的报告工作的想法，从而丢掉复制的一面，然后实现该功能。这花费的时间比仅实施两次要长，但产品经理明智地意识到这将使我们能够更快地实现跨越页面和报告的未来功能。 我们这样做的过程中的机制是为重构工作编写故事。基本上，像“作为产品经理，我希望页面和报告使用通用的计算设置代码，以便我可以更快地添加功能”。这绝对不是一个适当的故事，但它适用于系统，它完成了这项工作。 我认为，如果这个项目的运行有点健康，那么就会出现这样一个源源不断的故事。我们承认我们有很多架构债务，并且支付它的工作具有价值，并且将我们的固定时间分配给它，可能大约20％（这实际上意味着一次一对）。然后，就像我们为客户导向的工作所做的那样，我们可以生成功能/史诗，故事和任务。这些将来自团队自己，而不是产品经理。 可悲的是，在开发和产品管理方面之间没有足够的沟通和信任，这是可行的;我们可以说产品说我们遇到了问题，这很重要，需要很长时间才能解决，他们无法知道这是不是真的。因此，他们通常不愿意安排时间去做。令人遗憾的是，每个人都同意存在问题并且修复它们会很好，我们实际上只是陷入了困境。     

在我的实验中，如果你正在使用具有固定时间/要求的项目环境，那么是，大多数时候敏捷导致局部最优。 但我的观点是，在复杂的努力中，要求，团队本身甚至目标都会发生变化。敏捷也在接受变革。 然后，矛盾的是，这种贪婪的策略在处理移动目标时作为全局优化的合理选择。