您如何将Scrum应用于维护和遗留代码改进？

正如标题所示......我如何将scrum流程应用于任何不能用于新代码的东西,并且可以在某种程度上进行估算？

当我还想计划做事时,如何将scrum流程应用于维护和紧急修复(可能需要5分钟到2周才能修复)环境类型？

基本上,我如何克服难以用scrum流程估算的计划外任务和任务？或者我只是在这个环境中应用错误的流程？

基本上,我如何克服难以用scrum流程估算的计划外任务和任务？或者我只是在这个环境中应用错误的流程？

您在此环境中使用了错误的进程.您需要的是一个堆栈/队列管理过程,它与您计划/估计的SCRUM开发过程是分开的.

原因很简单,双重:

正如您在帖子中提到的,通常很难估计维护任务,特别是涉及遗留系统的情况.一般和遗留系统中的维护任务特别倾向于涉及"卷曲"问题,或者具有长"尾",其中一个看似简单的修复需要稍微更难以改变另一个组件,这反过来需要对操作进行大修一些子系统,反过来......你明白了.

通常在处理维护任务时,在完成估算之后,您也已经完成了解决问题的工作.这使得估算过程成为一种规划工具.那些坚持将估算与解决维护任务问题分开的人只是增加了不必要的开销.

简而言之,您需要一个排队系统.它将包含以下组件:

已经确定需要注意的"池"任务.新提出的项目应始终进入池中,而不是队列.

将这些任务移出池并进入队列的过程.通常需要商业/技术知识的组合.

一个明确排序的任务队列,负责维护队列的开发人员可以从前面选择.

一种在队列中移动项目的方法(重新确定优先级).允许"跳跃队列"关键/紧急项目.

一种用于传递不中断服务队列的已完成项目的方法.这很重要,因为提供维护项目的开销通常远低于开发工作.你不希望你的维护团队坐在那里等待构建和测试团队每天他们提供错误修复时给他们好的一天.

排队管理还有其他细微差别,但要实现这些细分应该会让您走上正确的道路.

如果你的环境中有那么多的流失,那么你的密钥将是更短的迭代.我听说团队每天都在进行迭代.您还可以转向看板类型样式,其中您有一个具有固定限制的队列(通常非常低,如2或3个项目),并且在完成之前不能再添加任何项目.

我要做的是尝试一周的迭代,每日站立,积压优先级和"完成,完成".然后在5或6周后重新评估,看看有什么可以改进的.不要害怕按原样尝试这个过程 - 并且一旦你尝试过它就不要害怕将它调整到你的环境中.

最近在雅虎上发布了一份名为Agile for Support and Operations的PDF文件,该文件最近发布在Scrum开发列表中.

没有人说积压物品必须是新代码.维护工作,无论是错误修复,增强功能还是数据修复,都可以放入产品Backlog中,进行估算并确定优先级.这实际上是使用Scrum的最大好处之一 - 没有更多关于用户是否存在错误修复或增强功能的论据.

使用Waterfall,有一种默认的理解,错误是开发人员的责任.不知何故,他们可以在不影响新代码和功能开发的情况下修复它们.因此,它们对用户"免费",但给开发人员带来了巨大的不便.

在Scrum中,您认识到所有工作都需要时间.没有"免费".所以开发人员自由地接受某些东西是一个bug,但它仍然存在于产品Backlog中.然后由客户决定修复错误是否比添加新功能更重要.你可以忍受一些错误.