如今在大多数的软件开发组织中，没有专门的维护工程（SE）团队来关注已发布产品的维护和支持。工程（研发）团队除了完成产品的功能开发外，要花费同样的时间来完成维护任务。然而，支持服务品质协议（SLAs）的维护支付的客户通常都很严格，所以比起研发，维护工程经常有更高的优先权。然后遵循scrum的工程团队由于维护工程问题的大量涌入以及对于迅速解决问题的需求，他们无法成功地递交承诺的功能。在功能开发和修改bug中挣扎反作用于团队士气和工作积极度。
以下基于scrum的选择是由小组成员提出建议来克服在这些情况下发生的问题的。
在每个sprint中将成员置身于维护工程
使用这个选项，每个sprint中有一位或两位团队成员以循环赛的方式置身于维护工程中去。这消除了对于忙里忙外任务的需求，并且团队保持了他的士气和工作积极性。因为所有的团队成员轮流维护工程的任务，所以他们获得了对于代码质量的洞察力，重现开发问题，以及为了修改问题发布产品所需要的成本和人力。随着时间的流逝，这会对代码质量造成一个自然的改进。
此外，由于剩余的成员的能力是为了考虑到功能的发展，这个方法保证了sprint任务在很大程度上被满足。如果维护工程的需求不大，那专门负责维护工程的成员可以修改其他内部的错误，从而提高总体的产品质量。
Kanban
团队决定所有维护工程任务的优先顺序，团队成员根据优先顺序来工作。使用Kanban，使正在进行中的项目的数量减到最低，因为每位团队成员只能在同一时间做一项任务。这个模式关于准确地预估发布周期带来了某种挑战，但它同时也为增进产品质量带来了巨大的进步。
更短的sprint
将sprint的持续时间减到到一周，每个星期都排一下bug的优先级。这个方法是否成功取决于服务品质协议的期望。
分步解决
团队速率在研发和维护工程中是均匀分配的。团队根据2个同步的产品待办列表工作，一个是针对功能开发的，另一个是针对维护工程任务或者问题。维护工程问题伴随着他们的服务品质协议目标，以类似于开发故事的方式被引入到scrum仪式中。例如，可能有一个故事来改进满足服务品质协议的响应时间。在sprint回顾期间，团队研究问题度量来决定服务品质协议是否能被实现。团队有ITIL(信息技术基础架构库)，作为完成定义的一部分以及其scrum板的一部分。一个有计划的任务可以被创建为一个可复用的故事，并且贯穿scrum过程。
这里需要一些灵活性来按需改变sprint中的目标，以防在sprint中期有主要意外。但如果能力在由计划驱动的工作和意外驱动的工作中良好分配的话，重新分配优先等级是很少见的。
单日sprint
当服务品质协议极其严格以及其他方法都不切实际的时，单日sprint是一个解决问题的新方法。单日sprint是指从早晨开始，到晚上结束，其中包括所有的标准的组件，例如sprint计划，速率计算，以及评审。不过sprint回顾会议可以放在次要位置，或者可以在有这个需求的基础上来举行。
单日sprint模式如下：
1、当天的第一分钟：Product owner提供需要修正的问题的清单，以及待定的功能。
2、当天第二十分钟：团队举行sprint计划会议并且承诺当天要解决的问题和功能。
3、当天的第四个小时：团队会通过非官方的方式来向他人提供一小部分更新。（例如，“修复了这个问题，并且已经为上线做好准备”）
4、当天的第七个半小时：团队开始对当天承诺的任务做收尾工作。
5、当天的第八个小时：团队将今天的工作转移到为交付准备的服务器，并且演示当天做的所有修改，然后结束sprint。
这个方法对于问题的彻底变化是一天，并且团队在框架内。
坚固sprint
如果团队继续由于维护工程问题的大量涌入而超负担，那么是时候与管理人员谈一谈使用一些坚固的sprint来修改这些已存在问题的可能性。如果使用地适当，改进产品质量会为节省成本带来巨大的潜力。一个坚固的项目专门关注修改问题上。没有新的功能被开发。这样减少了问题的数量，团队获得了些喘气的空间。
总结
除了综上所述的所有方法，在以下的领域投入时间和精力在一段时间后也会带来更好的结果：
理解维护问题的根本原因
自动化你的测试
代码重构和可维护性
小组讨论提出这些所有的解决方案，并且除此之外可能有其他的创新想法。如果你的团队有发现任何想法，让我们来一起倾听。与此同时，祝大家一切顺利！
