我在一家很小的初创公司工作，我们开始使用 Scrum/Agile 开发周期的一种形式。
在很多方面我都喜欢 Scrum。我们的冲刺相对较短（2 周），我喜欢用燃尽图来跟踪团队的进度。我也喜欢功能板，所以我总是知道下一步我应该做什么。从板上取下功能的卡片，完成它然后将其放入烧毁堆中感觉很好。
然而，我们现在进入了第 18 个 Sprint 发布周期，我开始感到有些疲惫。并不是我不喜欢工作或我的同事，只是这些冲刺是……嗯，冲刺。从头到尾，我真的觉得我在与时间赛跑以保持我们的开发速度。当我们完成 sprint 后，我们会花一天时间计划下一个 sprint 的功能集和估计，然后再继续。
对于在成熟的敏捷/Scrum 开发过程中工作的人来说，这正常吗？还是我们错过了什么？在未分配/未跟踪的 Scrum 环境中，通常是否有时间来完成一些小事情并让你头脑清醒？
这是相对正常的，如果项目持续很长时间，有时可能是我们团队成员的抱怨。
我们在这里谈论的关键是可持续的步伐。如果你和你的团队能够长期保持你的步伐，那就太好了——你已经实现了所有 Scrum 团队都在努力争取的超高生产力。
或者，如果您发现自己高估了一天内实际可以完成的工作量，那么您可能需要在回顾期间重新评估这一点。团队在为 sprint 进行容量规划时选择识别的一天中的生产时间量称为焦点因素。
Henrik Kniberg 有这样的说法：
我为新团队使用的“默认”焦点因素通常是 70%，因为随着时间的推移，我们的大多数其他团队都以这种方式结束。
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
但是，听起来您所说的只是一个又一个冲刺的不停冲刺的动力，而不一定是您一天的生产力。以下是我们尝试处理的一些建议：
来自维基百科的倦怠：“倦怠在很大程度上是一个组织问题，由长时间、很少的停机时间以及持续的同行、客户和高级监督引起”
他们还不如在倦怠的定义旁边有一个 Scrum 的图标图像。
如果您认为可以将某人派到其他地方进行短暂的消遣以解决倦怠问题，那么您显然还没有考虑过。曾经在筋疲力尽后去度假，然后回去工作时想，哇！现在我精神抖擞，准备好再忍受 6 个月的这种折磨，直到我终于再次休息。不，发生的事情是你意识到的，哇！我的工作糟透了。现在我真的可以看到我愚蠢的经理的微观管理，开发过程只是另一种以更少的成本从我身上获得更多收益的方式，而我的生命太短暂了……我应该找点别的事情做或者换个工作压力更小的工作.
恕我直言，应禁止短 2 周的 Scrum，除非是小剂量，连续不超过 4-8 次。将其用作处理特殊或关键事情的工具，而不是持续使用。使用常识。
经过 36 周的辛勤工作，你已经筋疲力尽了；那不是 Scrum，那是人性！Scrum 不是为了让你更努力地工作，它是为了帮助你更一致地工作并且具有更大的可预测性。我经常看到人们将正常项目管理的症状与他们认为的敏捷方法的症状混淆（即“客户不断变化的需求——这一定是 Scrum 的错！”）。这是一个重要的区别，因为如果不确定原因，您就无法治疗症状。就我个人而言，我会寻找减少倦怠的方法，例如压力管理技术。有大量关于如何在压力大的环境中取得成功的信息。
我目前工作的团队很好地解决了这个问题。在三个冲刺之后，我们有一周的时间，每个开发人员都可以按照自己的意愿工作。那些附带项目应该与业务价值相关联，但没有完成它的压力。这是让我们开发者探索新技术的一种措施，但它也为我们提供了一周更轻松、更有趣的工作。
这肯定有助于我不被烧毁。
无论您使用什么开发过程，如果团队精疲力尽，就会出现问题。这可能就像人们没有休假他们需要的时间一样简单，也可能是你如何处理你的 Scrums 的细节。从长远来看，团队是有效的，因为每个人都能在此过程中得到他们需要的休息。
Sprint 不是 100 码冲刺；它是马拉松中的一英里（随机），即您可以无限期维持的速度。
您的团队是否在每个 Sprint 结束时进行回顾？这是团队“检查和调整”他们的流程的机会吗？作为 ScrumMaster，我经常要求团队评估团队作为一个实体的“感觉”，以及他们是否玩得开心。我们探索为什么或为什么不，并尝试调整和替代方案。
根据我的经验，团队成员（在一定程度上）享受 Sprint 时间框所限制的“压力”。关键是接近但不超过该区域。根据需要，校准该区域是回顾中的主要检查点。
至于“......在未分配/未跟踪的 Scrum 环境中完成一些小事情并清理头脑的时间”，将团队承诺保持在可用容量的 x%（最好是点数，但可以使用几个小时）如果需要；在任何一种情况下，我发现 60-70% 范围内的东西似乎是常态）是 Sprint 内部可持续性的关键，偶尔的“免费代码日”对于 Sprint 外部非常有效。
一种解决方案是减少一天中花在冲刺上的小时数。
我认识一些人，他们的工作日只有两个半小时的冲刺，剩下的时间专注于各种其他活动：支持、减轻技术债务、研究等。他们的开发速度是相应的。
这似乎有点极端，但如果我没记错的话，在最近广泛的经济冲击袭来之前，它是一家盈利的公司。
您已经进入第 18 个冲刺阶段！？
考虑到每个 sprint 需要 2 周，这意味着 36 周不间断地在同一个项目上工作。您还评论说每天工作大约 6 小时。听起来很多！
我对敏捷方法知之甚少（尽管我们在当前项目中实际上正在使用 Scrum），但是关于您的工作时间（我的意思是，您花在完成一项任务上的时间）有一个原则应该是 60%约 70%。现在，再次计算数字，如果您的劳动日是 8 小时，并且您花费 6 小时工作，那么您实际上花费了大约 75% 的劳动时间。这可能是一个小小的偏差，最终让你有那种感觉。
OTOH，我相信如果你的项目需要很长时间才能完成，sprint 应该更大，而不是 2 周，但不是一个月。考虑你的倦怠图表上的向下曲线：从定期任务消耗开始你的 sprint，并在 sprint 结束前的最后 2 或 3 天减少活动。
敏捷不是一块刻有“工作更快/更强/更好/更努力”的石头，它更像是一片蓝天白云，上面写着：“工作好，美丽多产”。（最后由 daft punk + radiohead 提供了一点笑声）。
我完全明白你在说什么。对于那些说“你的节奏太快”的人，我不确定我是否同意当人们被这个过程精疲力尽时，节奏总是问题。尽管跟踪您的所有进度是一件好事，但它本身也可能是一个压力因素（不跟踪也可能是），而不仅仅是因为如果您的老板/ PM 看到某些事情不顺利，他们会关注您按计划，但为自己。只要拥有这些记录的信息，就会让大多数人的工作比你平时更努力一点，我不确定在你的时间估计上投入更多的时间是否会为每个人解决这个问题。我不认为激励因素（比如你的燃尽图）总是积极的。
有些人不会有这种感觉，有些人会。没有一种适合所有人的工作方式。在我看来，永远不会。
此外，如果您说这些敏捷方法和 sprint 并没有变得更加有效/富有成效，那么您为什么要使用它呢？你认为公司为什么要使用这些方法？不是因为他们好玩……
在我看来，效率/生产力总是以某种价格为代价的。它不会仅仅通过使用魔术方法从任何地方弹出（如果你明白我的意思的话）。
让您变得更有效（工作和压力方面）并减少工作的唯一方法是让其他人完成工作或将其自动化。
在我看来，人们应该总是回顾那些流程，看看什么可以自动化，然后花时间来自动化你的流程。自动化的代价是做额外的工作而不是做“真正的工作”，但无论自动化任务有多小，从长远来看，你总是会获利。总是！如果不是一天，两天。不是一个月，是两个月。不是一年，是两年。你明白了。
但是，我喜欢有时间从事个人项目的想法。大多数公司永远不会允许这样做。但也许你可以说服你的雇主有时间让你的流程自动化，这项工作可能是“冲刺控制之外的”，让你谈论的时间“休息”并为新的冲刺恢复精力。
那只是我的2美分。当人们说这些方法不是为了让我们更有效、更努力地工作时，我有点害怕。他们当然是！当你不知道自己在做什么时，当你的身体告诉你休息时，你就会休息。当你所做的“每一件事”都被追踪时，你就会逼自己。或者我纠正自己，大多数人都是这样工作的，有些人无论如何都会休息。
可持续的步伐是敏捷的关键原则。在执行管理 (SCRUM) 实践和工程 (XP) 实践时，团队可以无限期地在一个又一个冲刺中交付冲刺。但是，因为一个可以并不意味着一个应该。
听起来你需要改变你看到的无穷无尽的冲刺。可以提供许多选项。每 X 次冲刺，一个团队成员（或一对）可以轮换出团队。在轮换期间，您可以支持跑步团队、上课、专注于一组峰值、休假等。
如果团队有 5 对，并且你轮换一个人下线，那么一个人可以每 10 次冲刺（如果是一个人）或每 5 次迭代（如果是一对）轮换一次。您的活动的预算和投资回报问题需要由您的领导和/或业务合作伙伴解决。但显然，有一些时间“磨刀”会给团队带来好处，从而为项目带来好处。让团队保持新鲜和专注是一件非常好的事情。但我们必须记住，我们得到了报酬，我们需要为我们赚到的美元带来价值。