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

Question

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

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

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

score 22 · Accepted Answer

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

您为此环境使用了错误的过程。您需要的是与您计划/估计的 SCRUM 开发流程分开的堆栈/队列管理流程。

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

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

简而言之，您需要一个排队系统。它将具有以下组件：

已被确定为需要注意的任务“池”。新提出的项目应该总是进入池，而不是队列。
将这些任务移出池并进入队列的过程。通常需要业务/技术知识的组合。
明确排序的任务队列，以便负责为队列提供服务的开发人员可以简单地从队列前面挑选。
一种在队列中移动项目的方法（重新划分优先级）。允许为关键/紧急项目“插队”。
一种交付已完成项目的方法，不会中断队列的服务。这很重要，因为交付维护项目的开销通常明显低于开发工作。您不希望您的维护团队在每次交付错误修复时都坐等构建和测试团队批准。

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

score 11 · Accepted Answer

如果您的环境中有这么多的流失，那么您的关键将是更短的迭代。我听说过团队进行每日迭代。您还可以转向看板类型样式，其中您有一个具有固定限制（通常非常低，如 2 或 3 个项目）的队列，并且在完成之前不能添加更多项目。

我要做的是尝试一周的迭代，包括每日站立、积压优先级和“完成，完成”。然后在 5 或 6 周后重新评估，看看有什么可以改进的。不要害怕按原样尝试这个过程——一旦你尝试过，不要害怕根据你的环境对其进行调整。

还有一个名为Agile for Support and Operations in 5 minutes的 PDF ，最近发布到Yahoo!的Scrum Development 列表中。

score 5 · Accepted Answer

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

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

在 Scrum 中，您认识到所有工作都需要时间。没有“免费”。因此开发人员可以自由地接受某些东西是错误，但它仍然会进入产品待办列表。然后由客户决定修复错误是否比添加新功能更重要。有一些你可以忍受的错误。

score 2 · Accepted Answer

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

相反，我听说团队发现在维护阶段更容易采用 Scrum。因为更改较小（没有大的设计更改），因此更容易估计。任何新的变更请求都会添加到产品积压中，由开发人员估计，然后由产品所有者确定优先级。

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

如果您暗示灭火类型的活动，请为此类活动保留一部分迭代工作配额。根据历史趋势/活动，您应该可以说，例如，我们每次迭代的速度为 10 个故事点（4 人团队 5 天迭代）。我们每个人每周花大约一天时间应对紧急情况。所以我们应该只为下一次迭代选择 8 点的 backlog 项目是现实的。如果我们没有紧急问题，我们将从优先积压中挑选下一个最重要的项目。
CoryFoy 在他的回复中提到了一种更动态/实时的方法，其中包含看板便利贴。

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

AFAIR Scrum 不强制使用估算技术。使用团队最熟悉的技术。工时/故事点等。我相信，在估算方面做得更好的唯一方法是实践和经验。同一组人坐在一起估计新任务的次数越多，他们的估计就越好。在维护类型的环境中，我会假设它更容易估计，因为该系统或多或少为团队所熟知。如果没有，请安排/使用尖峰以获得更多清晰度。

我感觉你想在这里吃一头大象。我建议以下几口

score 1 · Accepted Answer

将所有修复和改进视为单独的故事并进行相应的估计。我个人的观点是，那些需要不到 10 到 15 分钟才能解决的事情应该立即完成。对于那些需要更长的时间，它们成为当前“修复和改进”迭代周期的一部分。与估计常规需求一样，您作为一个团队进行最佳猜测。随着更多信息的曝光，以及估计值的调整，迭代和即将到来的冲刺。

很难将迭代周期应用于修复和改进，因为它们往往会阻止系统按应有的方式工作，并且“业务”会施加压力让它们尽快上线。在这一点上，它可能会更好地转移到一个非常短的迭代周期，比如一两个星期。

score 1 · Accepted Answer

将所有没有故事的“错误修复”视为新代码。估计它们，并照常工作。通过将它们视为新故事，您将建立一个故事和测试库。只有这样，您才能开始固定应用程序的行为。

看看Michael Feathers的《有效地使用遗留代码》。这是一个摘录的链接。http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

-杰森

score 1 · Accepted Answer

您询问如何使用流程应对紧急情况。尝试为需要在生产环境中破解代码并同时连接用户的事情保留“紧急”一词。否则，利益相关者可能会滥用这个词，并对他们想要快速处理的任何事情发出紧急情况。缺乏流程并不意味着失控：必须有人负责宣布紧急情况，有人（最佳实践是其他人）必须授权正常流程之外的更改，然后对其负责。

除此之外，使用每次迭代来完成一些修复和改进的建议可能是最好的方法。

score 1 · Accepted Answer

这在很大程度上取决于应用程序的生命周期。如果这是一个很快就会重试的“日落”应用程序，当然，重点只会放在修复最优先的错误上。

如果产品“成熟”并且有路线图并且正在继续发展，那么您将需要修复和增强功能。通过重构保持设计清洁和发展有很多动力。这可能意味着定期的次要和主要版本 [eFixes - 紧急修复程序/热修复程序除外]。您可以尽情享受敏捷的实践，因为增强和修复可以被载入故事板并成为您的 Sprint 待办事项的一部分。整个列表将成为您的产品待办列表。

底线：如果你想重构并保持你的应用程序设计干净[如果专注于错误修复，程序员往往会走捷径]，它只能发生在一个“活”的应用程序中。一种进化和更新的。敏捷是天作之合。

即使您只有修复（它是图灵完备的；）或 Sunset 应用程序），如果它们都可以被卷入一个 sprint 并在每个 sprint 的生产端卷入，它也会有所帮助。如果修复需要在修复后立即投入生产，那么应用 Scrum 会困难得多。

score 1 · Accepted Answer

我们在这种情况下应用了 scrum。

一些成功的关键。
1. 企业中的每个人都购买 Scrum 理念（这对成功至关重要
） 2. 大约 2 周的 Sprint（我们的 2-3 个第一次 sprint 需要 1 周的时间来了解流程）
3. 在任何情况下都不能加分到当前 sprint 4. 如果出现真正的紧急情况，停止 sprint，进行回顾并开始新的 sprint。
5. 花时间进行回顾（有时间分享关于上一个 sprint 并对其进行分析）
6. 在 sprint 中插入至少一项任务以改进流程（通常添加到回顾中的积压工作中）；这对部队士气有好处，最终你会减少紧急情况。
7. TIME BOXED 每日站立会议

对于估计，通常你估计得越多，你就会变得越精确。Scrum 的优点是每个程序员都可以选择自己的任务，如果他认为这不切实际，可以设置一个新的估计。如果您在估算方面仍有问题，请让您的团队找到解决方案……您可能会对他们提供的内容感到惊讶。

对于 2 周的修复。如果是原始估计，请将其切成小块。如果你做了一个更乐观的估计（比如说 2-3 天），这个问题应该会成为站立会议中的障碍。也许其他人对如何解决它有想法。您可以决定进行一些结对编程以找到解决方案。有时，只是向其他程序员描述错误对调试有很大帮助。您也可以在 sprint 中的其他任务之后延迟它。这个想法是交付功能齐全的任务。如果你没有时间完全修复它并展示它，即使你完成了 90%（是的！我们知道这意味着什么），你认为它没有在 sprint 中完成。在下一个 sprint 中，您将能够通过正确的时间估计来解决它。

最后，据我了解，Scrum 更多的是关于拥有“工具”来改进您的流程。你从简单的事情开始。你做小迭代。在每次迭代中，您都有一个FIX TARGET完成而不是无限的错误列表。因为您从计划中的列表中选择您的任务（反对分配它们），您变得更加投入交付它。通过站立会议，您每天都会看到您的待办事项清单……您希望尊重前一天的参与。通过迭代，您可以花时间互相交谈，并确定哪些方面进展顺利，哪些方面应该改进。您还采取行动改进它并继续做有效的事情。不要害怕改变任何东西，即使是我所说的 ;) / 甚至是 Scrum 本身的任何基础......真正的关键是让 Scrum 适应你的团队需要快乐和高效的东西。一次迭代后您将看不到它，但其中很多......

score 1 · Accepted Answer

我强烈建议您查看冲刺/迭代会给您带来什么价值。当有足够多的任务需要优先处理，并且当您的利益相关者需要大致了解何时完成某事时，应用它们是有意义的。

在这种情况下，我强烈建议结合三种方法：

尽早为下一次迭代安排尽可能多的传入任务
使用昨天的天气计划您需要计划多少缓冲区来处理必须立即处理的任务
使用非常短的 sprint，以便最大化可以等到至少下一次迭代开始的任务数量

事实上，对于每个敏捷/Scrum 项目都是如此，因为它们处于维护模式——添加到现有的工作系统——从迭代 2 开始。

如果迭代不能提供足够的价值，您可能想看看看板/排队系统。基本上，当您完成一项任务时，只需从优先任务队列中拉出下一个任务。

score 1 · Accepted Answer

在我看来，这取决于你多久发布一次“真正的”版本。在我们的特定情况下，我们每年发布一个主要版本，并在一年中发布一些次要版本。

这意味着当 sprint 完成时，它不会立即部署到我们的生产服务器上。大多数时候，在我们完成完整的“项目”之前会进行一些冲刺。当然，我们演示了我们的 sprint，并在我们的测试服务器上部署了我们的 sprint。整个“项目”将经历一些端到端的测试，最终将部署到我们的生产服务器 -> 这是一个小版本。我们可能会决定我们不会立即将它部署到我们的生产服务器，例如当它依赖于需要首先升级的其他产品/项目时。然后我们在我们的主要版本中部署它。

但是，当我们的生产服务器出现问题时，可能需要立即采取行动。因此，没有时间向产品所有者询问目标或重要性（如果我们甚至有一个用于解决问题），因为它会阻止我们的客户使用我们的应用程序。在如此紧急的情况下，这类问题不会被放入 Product Backlog 或 sprint 中，而是作为一个单独的项目尽快解决、测试和部署的纯维护任务。

我们如何将它与我们的 Sprint 结合起来？为了让我们的团队成员专注于冲刺，我们决定让我们的员工“选择加入 - 选择退出”团队。这意味着一个或多个人不会成为某个 Sprint 团队的一员，而是可以专注于其他工作，例如这些紧急修复。在下一个 Sprint 中，此人将再次成为团队的一员，其他人将负责紧急呼叫。

另一种选择可能是，我们预计 Sprint 中有 20% 的时间用于“计划外任务”，但这会错误地表明我们可以在 Sprint 中完成的工作量（我们不会有相同数量的紧急修复）每个冲刺）。我们还希望我们的团队成员专注于 Sprint，在 Sprint 中进行这些紧急修复会分散我们的团队成员的注意力。“上下文切换”也意味着时间损失，我们试图避免这种情况。

这完全取决于您的“环境”以及解决紧急问题的速度。

score 0 · Accepted Answer

通过认识到 Sprint 的某些部分由需要解决的那些计划外的“火灾”组成，我取得了一些成功。即使在短暂的冲刺中，这些也可能发生。如果开发团队有这些责任，那么在 sprint 计划期间，只有故事被提交给 sprint，为这些其他计划外活动的发生和处理留出足够的空间。如果在 sprint 期间，没有“火”点燃，那么 tam 可以从 backlog 的顶部提取故事。在许多方面，它变成了一个队列。

优点是对积压有承诺。缺点是存在这个能力漏洞，可以作为将团队拖入非关键任务的机会进行交流。如果容量差距被未跟踪的计划外工作所填补，速度也会有很大差异。

我解决部分问题的一种方法是创建一个“支持”故事，用代表团队可以分配给支持活动的可用时间的任务来填充该容量的其余部分。当支持情况进入无法推迟到积压工作的 sprint 时，就会创建一个带有任务的新故事，并重新估计占位符支持故事和任务以解释新的注入。如果支持事件没有进入 sprint，那么随着积压项目的出现以填补未使用的容量，这个支持故事就会减少。

结果是 sprint 保留了一些所需的流程，并且人们觉得当他们需要承担支持工作时他们不会被烧毁。速度更一致，燃尽跟踪正常，但也有每个冲刺发生的支持注入的记录。然后在 sprint 回顾期间，我们可以评估计划内和计划外的工作，如果下一个 sprint 需要采取不同的行动，我们可以这样做。如果这意味着新的 sprint 持续时间，或者与组织中的某人进行有针对性的对话，那么我们就有数据来支持新的决策。

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

12 回答 12

Related

Reference