我对敏捷开发非常积极,并且已经开展了大约13年的敏捷项目.但我担心自己从来没有真正能够解决这个问题.它似乎并不总是表现出来,但它已经咬了我几次.
敏捷似乎在某种意义上是一种"贪婪的算法".从最高价值的故事开始,优化系统以精确地实现该故事,并重复.
实际的贪婪算法很容易融合到局部最优解,同时缺少全局最优解.
这是人们的经历吗？
这实际上是个问题吗？
如果是这样,你使用什么技术来避免这种局部最优并保持敏捷？
实际的贪心算法很容易收敛到局部最优解，而错过全局最优解。
如果 EPIC 技术用户故事和指南以及正常的业务 EPIC 用户故事没有建立，情况也是如此。
这是人们的经历吗？
有时是的，这是我的经历。一个例子是，当我们处理的用户故事被分解得太多时，解决方案是扩大它们，以获得更全球化的设计视野。有时，同一项目中的不同企业 Scrum 团队会与不同的技术框架用途和方法发生冲突。
这实际上是一个问题吗？
如果您忽略技术 EPIC 用户故事或指南，这只是一个问题。
如果是这样，您使用什么技术来避免这种局部最优并保持敏捷？
这是解决此问题的一种敏捷方法：在敏捷发布规划期间，不仅要提出业务 EPIC 用户故事，还要提出技术 EPIC 用户故事。技术史诗用户故事将从技术角度出发，在技术架构、应用程序框架、质量标准和全局设计考虑因素等方面制定产品愿景。这些可以分解为更小的技术用户故事，并有一个 Scrum 团队它致力于让这些用户故事发挥作用。用户故事的一个例子可以是：“作为技术项目经理，我希望整个企业项目使用 A、B、C 框架，并按照 X、Y、Z 编码标准进行编码，以便项目开发具有统一性如果您不想为此单独组建一个 Scrum 团队，那么只需将它们作为提醒卡放在积压工作旁边，供开发团队用作指导。
作为测试指南，我们曾经将成功的集成测试作为每个待办事项的完成标准。在集成环境中对所有企业团队部署的所有工作软件进行了全局测试，以确保其可以交付。因此，从积压工作的开始到结束，主题都是为全球工作软件而不仅仅是本地工作软件设定的。
最后，敏捷开发涉及对质量的持续关注，质量问题之一可能是糟糕的设计或过于本地化的设计。当发现这一点时，应该在该待办事项本身中重新设计它，并继续处理其他待办事项。