处理敏捷团队的支持
有没有人有一个负责新的发展和支持活动的团队？我上周从我的读者中得到了一个很大的问题，我想分享。
我有一个团队，负责支持我们已经创建和发布的内容以及开发新功能或增强功能的释放。我即将将一个Scrum团队从12个人分开到两个六个球队。大多数人都没有愿意全职支持。
通过对潜在的每周传入产品缺陷率的粗略估计，我们试图确定如何最好地处理这种情况，以便我们可以最大化团队的速度，同时确保我们可以在适当的解决时间内处理传入产品缺陷率。自然的趋势是有一个非常保守的速度，但我们希望有更好的结果。
这是一个不像敏捷团队独一无二的问题。多年来，软件组织一直在努力与这一组织一起挣扎。问题的根源是您的项目需要预测的吞吐量。稳定的速度对于一个良好的管理可预测的敏捷项目至关重要......但您的支持活动使得建立稳定的速度几乎不可能。支持是团队无法真正定义或控制的变量。
我想告诉你的是，只要将所有新开发工作的支持票添加到待办事项列表中，并将它们与其他产品特性一起在sprint中按优先级排列。这种方法的问题是，大多数时候支持票是丢弃一切，获取客户的工作活动。支持票也不符合预期。你永远不知道他们会花多长时间，你不知道他们的任务，你甚至可能无法预测他们的相对规模。服务请求必须完成，而且必须现在就完成。
我不知道这个问题有一个神奇的答案。像大多数事情一样，它是理解你的环境的细节，以及你的人民，并提出满足您个人需求的东西。以下是我过去尝试过的一些方法，具有不同程度的成功。愿意为你们回复这个博客，并与您的想法和其他处理这一难题的方法。
方法一
在支持迭代和新的开发迭代之间交替使用团队。团队将基于他们的新开发工作建立一个稳定的速度(每隔一周)，这个稳定的速度可以根据剩余的待办事项来衡量，以平衡范围和结束日期。如果团队在特定的冲刺阶段没有100%的支持，他们可以利用额外的时间在接下来的开发冲刺阶段领先于游戏。
方法两
假设您有一些历史数据，您花费了多少时间进行支持，可以分配固定数量的带宽来支持每个Sprint的活动。例如，每个团队都会分配30％的时间来支持活动和速度将根据他们剩余的新发展的时间出现。
假设支持需求会随着迭代的变化而变化，您将不得不考虑对组织的承诺中的可变性。我会根据团队在一个又一个迭代中交付的成果跟踪最佳情况、最坏情况和平均速度。然后，您可以将业务的这种可变性表示为交付日期的范围或可以在固定日期交付的产品特性的范围。亚博vip9通道
接近三
最后一次（和可能是您的团队最不可取的方法）是有一个团队负责开发和一个负责支持的团队。这将允许开发团队进入凹槽编写新代码和支持团队，以建立他们可以通过支持票所能达到多且速度的模式。因为没有人愿意全职支持，你会把人们旋转进出支持团队并回到新的开发团队。
我对你的想法很感兴趣。请权衡一下你在团队中是如何处理这个问题的，哪些有效(也许更重要的是)哪些无效。
评论（8）
史蒂夫坎贝尔
方法4，对问题和新开发使用单独的开发流的看板。对于问题有单独的QoS协议，例如从报告到部署到生产中需要3天的周转时间。
积极地争辩说，非关键问题可以被视为主要开发流的增强。然后可以适当地优先考虑其他新工作。
以上的好处是，问题是正确的优先考虑的，并且没有必要创建一个单独的维护团队（除非质量非常糟糕）。
杜安蟑螂
这是我们目前正在采取的方法。我们给每个Sprint展示了两个独立的报告，事件工作(看板)和Sprint速度(最后6个Sprint)。当计划我们的Sprint时，我们只引入正常Sprint能够处理的工作量;在我们的例子中是60分。通过拥有这两份报告，你可以快速看到事件高峰和故事速度下降时的情况和影响。真正是请求或增强的事件被转换为故事并放在待办事项中，原始请求者被记录为请求者，事件被关闭并向请求者发送一封电子邮件，让他们知道他们的请求已经被记录。
Mike Cottmeyer.
谢谢你的评论。
我不谈论Kanban，因为我从未在现实生活中使用过这种方法。
请在这里帮助我们，并解释使用看板方法的任何含义。我们是否假设没有迭代?我们是否假设速度被吞吐量度量取代了?一个独立的开发流程在实践中是什么样子的?
沃尔特博德韦尔
不确定方法一在与客户维护SLA时如何工作。
接近两个可以工作。问题是，除非您指定某人支持（方法三），否则您将使它们平衡两（可能具有挑战性）。你可能会看到他们为支持问题分配更多时间，因为它是吱吱作响的轮子。
我过去做过三种方法，效果很好。虽然大多数人不喜欢把时间花在开发新功能上，但他们喜欢这样的事实:当他们离开时，他们就离开了。如果你有多个团队，你可以把大家聚在一起，也可以把它当作一个交叉培训的机会。有关敏捷支持的更多想法，请参阅这个博客条目。
McGeachy.ca.
我通常会遇到同样的问题，但是在QA或生产测试期间支持当前计划的前一个迭代或发布版本。分配一些故事指向“尚未被发现”的支持票是最有效的。
Jurgen Appelo.
谢谢你的帖子，迈克。
我对这个问题：
如何做许多项目:资源规划
http://www.noop.nl/2008/11/how-to-do-many-projects-part-4-resource-planning.html
它适合你的方法
Sithslayer.
我为财富500强公司工作，现在与我们的开发公司进行SLA合同进行谈判。麻烦的是我们正在使用敏捷，我的公司认为这是邪恶的。我的部门很好，但我们正在争论预算。我们分配多少钱来支持敏捷环境？
就像你在你的帖子里说的，我们对我们现在需要的时间有一个很好的估计，我们以后需要的时间等等。由于我们在3周前刚刚推出了一个完全重新架构的网站，所以现在的事情都进入了支持模式。我的公司拒绝做任何事情，除了一个“固定”的数量。他们认为用敏捷方法提供支持会把钱扔到马桶里。我被困在开发者和会计之间。要是他们能看到敏捷在过去18个月里是多么的伟大就好了。
B.Aumann.
Steve Campbell的建议让我想起了一些我在使用的团队中的东西。我们有2周的迭代，我们在一周内花费时间优先考虑和规划客户会议。我们跟踪了支持，开发工作和会议的时间，让我们了解我们每次支出多少时间并分配2个开发人员到修复支持门票。他们没有专门分配开发人员，而是来自我们两支球队的漂浮者。这有助于我们扩散了支持的负荷，并保持可预测的（在1个标准偏差范围内）节奏。不是最轻的系统，因为有一个公平的电子表格沉重升降，但事情已经解决了。
我认为另一个需要考虑的问题是，为什么一支球队会看到这么多FIX IT NOW的门票。TDD是否有失败?是否存在模糊的沟通?我觉得这种味道需要回顾一下。