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

Question

正如标题所暗示的..。我如何才能将scrum过程应用于任何不能在新代码上工作并且在某种程度上可以估计的东西呢？

我如何将scrum流程应用于维护和紧急修复(修复可能需要5分钟到2周)类型的环境，而我仍然想要做一些事情？

基本上，我如何克服计划外任务和使用scrum过程很难估计的任务？或者我只是在这个环境中应用了错误的过程？

Answer 1

如果你的环境中有那么多的波动，那么你的关键将是更短的迭代。我听说过团队每天都在做迭代。您也可以转向看板类型，在看板类型中，您的队列有固定的限制(通常非常低，例如2到3个项目)，并且在完成这些项目之前不能添加更多的项目。

我会做的是尝试一周的迭代，每天站立，backlog优先级排序，以及“完成，完成”。然后在5到6周后重新评估，看看有什么可以改进的。不要害怕按原样尝试这个过程--一旦你尝试过了，也不要害怕根据你的环境来调整它。

还有一个叫做Agile for Support and Operations in 5 minutes的文件，最近被贴到了雅虎的Scrum Development list上。

Answer 2

基本上，我如何克服计划外任务和使用scrum过程很难估计的任务？或者我只是在这个环境中应用了错误的过程？

您在此环境中使用了错误的进程。您需要的是一个堆栈/队列管理流程，它独立于您计划/估计的SCRUM开发流程。

原因很简单，有两个方面：

1. 正如您在帖子中提到的，估计维护任务通常非常困难，特别是在涉及遗留系统的情况下。一般的和遗留系统的维护任务特别倾向于涉及“卷曲”的问题，或者有一个很长的“尾巴”，其中一个看似简单的修复需要对另一个组件进行稍微困难的更改，这反过来需要对某些子系统的操作进行全面检查，这反过来又...你明白了。
2. 在处理维护任务时，当你完成估算时，你也已经解决了问题。这使得作为计划工具的评估过程变得多余。那些坚持将维护任务的估计与解决问题分开的人只是增加了不必要的开销。

简单地说，你需要一个排队系统。它将包含以下组件：

• 已确定为需要注意的任务的“池”。新提出的项目应该始终进入池中，而不是队列中。
• 将这些任务移出池并放入队列的过程。通常需要业务/技术知识的组合。
• 一种任务队列，它有明确的顺序，以便负责服务队列的开发人员可以简单地从队列的前面挑选。
• 一种在队列中移动项目的方法(重新排列优先级)。允许关键/紧急项目的“插队”。
• 一种传递完成项目的方法，它不会中断队列服务。这一点很重要，因为交付维护项目的开销通常比开发工作低得多。你不想让你的维护团队坐上一天，等待构建和测试团队在他们每次交付错误修复时都给他们许可。

队列管理还有其他细微差别，但将它们放在适当的位置应该会让您走上正确的道路。

Answer 3

没有人说待办事项必须是新的代码。维护工作，无论是错误修复、增强还是数据修复，都可以放入产品待办事项清单中，并对其进行评估和优先排序。这实际上是使用Scrum的最大好处之一--不再与用户争论某事是错误修复还是增强。

对于瀑布，有一种默契，那就是bug是开发人员的责任。不知何故，他们可以在不影响新代码和功能开发的情况下修复它们。因此，它们对用户来说是“免费的”，但给开发人员带来了极大的不便。

在Scrum中，您认识到所有工作都需要时间。没有“免费”这个词。因此，开发人员可以自由地接受这是一个bug，但它仍然会出现在Product Backlog中。然后由客户决定修复bug是否比添加新功能更重要。有一些你可以忍受的bug。