在敏捷项目中避免局部优化[关闭]

实际的贪心算法容易陷入局部最优解,而丢失全局最优解。

如果没有建立EPIC技术用户故事和指导原则,以及正常的业务EPIC用户故事,这是正确的。

这是人们的经历吗?

有时是的,这是我的经验。一个例子是,当我们所处理的用户故事被分解得太多时,解决方案是扩大它们,以便对我们的设计有一个更全球化的展望。有时,同一个项目中的不同企业scrum团队,与不同的技术框架使用和方法相冲突。

这真的是个问题吗?

如果是这样,您使用什么技术来避免这样的局部优化,同时保持敏捷?

在敏捷发布计划期间,不仅要提出一个业务史诗般的用户故事,还要提出一个技术史诗般的用户故事。技术史诗级用户故事将从技术的角度,在技术架构、应用程序框架、质量标准和全球设计考虑等方面,具有产品愿景。这些可以分解为较小的技术用户故事,并有一个Scrum团队,致力于让这些用户故事发挥作用。一个用户案例可以是:“作为一个技术项目经理,我希望整个企业项目使用a、B、C框架,并按照X、Y、Z编码标准进行编码,这样项目开发工作就有了统一性。 如果您不想为此单独组建一个scrum团队,那么只需将它们作为提醒卡保存在积压日志旁边,以便开发团队用作指导原则。

最后,敏捷开发需要持续关注质量,其中一个质量问题可能是糟糕的设计或过于本地化的设计。当这一点被发现时,它应该在backlog中重新设计,然后继续进行其他的backlog。

我一直在做一个有这个问题的项目,但没有有效地解决它。

这些问题都不能通过重构单个类或包来解决。因此,他们从来没有发生在正常的过程中的事件。我们以较小的规模进行重构——在添加特性时,我们会在开始之前重构该区域,然后在完成之后再进行重构(同时也会在进行时努力编写好的代码)。但这并没有导致重构更大的体系结构问题。

我们确实取得了一个显著的胜利,那就是两个远亲舱之间出现了重复。从本质上讲,有代码来呈现一个显示一些计算结果的网页,还有一个后台作业来生成执行类似计算的报告。计算代码是共享的,但用于设置计算的代码不是;一个由用户的视图首选项驱动,而另一个由配置的报告作业驱动。我们要实现的功能包括向计算添加新方面,这意味着向两种配置添加更多项,然后向两组计算设置代码添加业务逻辑。我们设法让产品经理(我们的客户代理)同意为工作安排足够的时间,以便我们可以对其进行重构,将用户视图首选项和已配置的报告作业的思想结合起来,因此放弃重复的一面,然后实现该功能。这比仅仅实现两次需要更长的时间,但是产品经理非常明智地意识到,这将使我们能够更快地实现跨越页面和报表的未来功能。

我们这样做的机制是为重构工作编写故事。本质上,类似于“作为一个产品经理,我希望页面和报表使用通用的计算设置代码,以便更快地添加功能”。这绝对不是一个恰当的故事,但它符合系统,它完成了工作。

我认为,如果这个项目的运作更健康一点,那么就会有这样源源不断的故事。我们会承认,我们有很多建筑债务,而偿还这些债务的工作是有价值的,并且会将我们的固定时间分配给它,大概20%(这实际上意味着一对一对)。然后我们就可以生成特性/史诗、故事和任务,就像我们为面向客户的工作所做的那样。这些将来自团队本身,而不是产品经理。

遗憾的是,开发和产品管理双方之间没有足够的沟通和信任,这是可行的;我们可以对产品说,我们有问题,这很重要,需要很长时间才能解决,他们不知道这是真是假。因此,他们一般不愿意安排时间去做。可悲的是,每个人都一致认为存在问题,解决这些问题是件好事,我们只是在实际行动上陷入僵局。

根据我的经验,如果你在一个有固定时间/需求的项目环境中工作,那么是的,大多数时候敏捷会导致局部最优。

但我的观点是,在复杂的工作中,需求、团队本身甚至目标都会发生变化。敏捷还包括接受变化。 然后,矛盾的是,在处理移动目标时,这种贪婪的策略作为全局优化的合理选择。