我们正在开发新产品并实施敏捷，特别是Scrum。我们的第一次冲刺是保守计划的，但我们将会错过我们的目标。主要原因是中断和新客户抛出我们已经停止并做出反应的最后一分钟要求。
为了能够帮助识别我们的弱点，以及我可以在第一次冲刺的回顾中得到一些饲料，我有兴趣听到公司开发人员人数与用户人数。你的比例/混合成功吗？仅适用于内部开发，不适用于软件公司或技术公司。关于这个问题的任何意见也受到欢迎，我认为它可以开启一个有趣的讨论。
主要限制因素始终是预算，因此无需在任何意见中加入。
答案 0 :(得分：4)
不要因为第一次冲刺失败而感到不安。第一次100％做任何事都很少见。大多数第一次冲刺都会发现必须修复的问题 - 就像你的情况一样。
您的问题与用户/开发者比率无关。你的问题是正确隔离你的冲刺并确保基本的Scrum交易（sprint中没有范围变化，sprint之间的所有范围变化）都被遵守。要做的事情：
确保每个人都了解 Sprint Backlog无法在Sprint Planning和Sprint Review之间进行更改。如果有人试图通过这本书强迫这个游戏：做异常终止，扔掉所有的工作，计划一个新的冲刺，并对它做所有的大惊小怪。 Scrum要求这样做的原因是让中断和范围变更的成本高度可见，令人痛苦地显现出来。
缩短短跑。两周冲刺对我们来说非常有效，因为很容易向任何经理类型解释他可以等待2-3周的功能。我们的PO最终在这方面做得很好。
如果出于任何原因，您有短暂的修复/功能，无法等待两周建立“消防员” - 每个sprint投入一名开发人员处理此类问题，请不要计划为他做任何定期工作。为了避免倦怠使它成为一个旋转功能 - 有人是每个冲刺的消防员。嘿，你甚至可以买一把消防员的帽子。 ：）
我们做了1＆amp;在我们的第一次冲刺之后（2007年回归），就像你的一样。它帮助了很多，所以我们没有必要做3.我建议3有一个有这种需求的团队并且它运作得很好。
答案 1 :(得分：3)
太多用户不是（不应该）是一个问题。开发人员与用户的比率取决于产品类型和行业/领域，而不是方法。小型收缩包装产品（由最小团队甚至单个人开发）可以拥有数百万用户（例如Total Commander），而由数百人组成的庞大内部企业产品可以拥有6个用户。
问题在于显然您的用户不熟悉Scrum，并且您没有使用单个产品积压（或者没有向您的用户介绍过它）。
您应该有单一产品所有者，他们决定进入下一个sprint的内容，
答案 2 :(得分：3)
如果您在此sprint的sprint中允许新的要求，您没有做scrum 。
我唯一允许的是生产软件中的严重错误。这些都必须修复。如果需要，可以在这里为每个sprint分配一个或两个devs负责修复错误。
答案 3 :(得分：2)
scrum Sprints 的本质是你不能用最后一刻的要求打断它们。
关于你所谈论的比例，它在很大程度上取决于你的产品是什么，你在哪个行业，以及很多这样的事情。因此，要使此值有用，您将需要进行一些实验。
但您的开发人员应该依赖您的产品所有者，而不是您的用户群（无论其大小）。
答案 4 :(得分：2)
Sprint是安全区。在sprint开始时，团队与产品所有者讨论产品积压项目，并选择在upcomming sprint中完成这些项目的子集。团队提交到这些项目。团队责任是提交提交的项目，因此除了团队之外，没有人可以在sprint期间引入新项目（这通常发生在项目开发速度超出预期的情况下）。
每个SCRUM项目必须有一个产品所有者（如果有多个产品所有者，必须有hiearchy）负责产品积压。如果产品所有者在sprint期间需要新项目，唯一的方法是取消当前sprint并启动新项目。
答案 5 :(得分：2)
可能更有意义的比率为developers : features/projects。如果管理员将所有可用资源提交给sprint，则更有可能需要中断其中至少一个以获得关键支持问题（例如）;对于诸如“嗯，你提前完成，所以你可以放弃这个额外的功能”这样的事情来说，这是一个很滑的斜坡，在这一点上你已经打破了SCRUM背后的核心原则之一。
我感觉你即将开始为你的部门开展更多人数的活动，以减轻对现有团队的压力;或许更好的长期方法是管理客户的期望（无论是内部还是外部），这样您现有的员工人数仍然可以灵活地进入并处理中断;同时，他们可以管理将额外需求推迟到后期冲刺的期望。
答案 6 :(得分：1)
开发人员人数与用户人数
我可能会因此而被投票，但我认为这在很大程度上是不相关的。
有几个人为数百万用户提供了很棒的产品。
正如有一个巨大的打击力量开发的项目从未超过平庸的门槛。
答案 7 :(得分：0)
用户人数/开头人数不是相关指标。
你可以让一个用户产生大量的变化而不是数百个不会产生任何（很少）变化的用户。
相关内容是请求的更改量以及管理和跟踪的更改方式。
如果您可以显示要求已经改变了多少，而仍在实施和设计其他要求，那么您将获得您的饲料。
答案 8 :(得分：0)
任何敏捷方法的最大误解之一就是你可以随着时间的推移进行弥补。
虽然这一般都是正确的，但关键是项目管理和沟通。
像生活中的很多事情一样，你可以做任何事情，但结果却是如此。如果我买法拉利可以吃得起吗？
如果我要求额外的功能，那将对项目产生多大影响。
所以在规划期间 MoSCoW（必须，应该，可能或不会）要求 估计需要多长时间 你不能用必须或者应该填写Sprint / Timebox
在sprint / timebox期间 监控Estimates所需的时间 重新计划
发生中断时。记录它并将其提供给Time Taken要求。下一组估算包括和中断因素。敏捷中的估计是一种艺术形式！
要求更改时 估计需要多长时间，与原始估计值进行比较 通知业务用户该效果 在MoSCoW中优先考虑
沟通很重要。如果您要我在那里添加该按钮，我将无法打印发票。
由于MoSCoW，它可能在sprint 4中是一个Wont项目可能会达到应有或必须的程度。
另外，将敏捷视为一种工具包，您无需为SCRUM或任何其他方法规定适用于您所处文化的重要部分。