当Scrum不断冲刺的时候会发生倦怠吗？
我与一个非常小的创业公司，我们开始使用Scrum /敏捷开发周期的forms。
在很多方面，我喜欢Scrum。 我们有比较短的冲刺（2周），我喜欢烧毁图表跟踪球队的进展。 我也喜欢function板，所以我总是知道我应该接下来做什么。 感觉很好，从电路板上取下一张function卡，将其完成，然后放入烧毁的堆中。
但是，我们现在正在进入我们的第十八个Sprint发布周期，我开始感觉有点被烧毁了。 不是我不喜欢工作或者我的同事，只是这些冲刺是…好吧， 冲刺 。 从开始到结束，我实际上感觉就像是在与时间赛跑，以保持我们的发展速度。 当我们完成冲刺时，我们花了一天的时间来计划下一个冲刺的function集和估计，然后我们再去。
对于在成熟的敏捷/ Scrum开发过程中工作的人来说，这是正常的吗？ 或者我们错过了什么？ 在Scrum环境中，通常有时间是未分配/未跟踪的，以便完成一些小的事情并清理你的头脑？
这是相对正常的，如果项目持续很长一段时间，有时候会成为我们团队成员的抱怨。
我们在这里谈论的关键是可持续的步伐 。 如果你和你的团队能够长期保持你的速度，这是非常好的 – 你已经达到了所有Scrum团队所追求的超高生产力。
另外，如果你发现你高估了你一天可以完成多less工作，那么在回顾过程中你可能需要重新评估。 一个团队在进行冲刺能力计划时select承认的一天中的生产时间量被称为关注因子 。
Henrik Kniberg有这样的说法：
我为新车队使用的“默认”焦点因素通常是70％，因为这是我们其他车队大多数时间都已经结束的原因。
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
但是，你所说的听起来就是冲刺之后冲刺不停的冲劲，不一定是你一天的生产力。 以下是我们试图处理的一些build议：
- 周五早上结束冲刺。 在早上进行短跑回顾和回顾性的训练，并让队伍在今天的其他时间做些别的事情来清理头脑。 在星期一接受Sprint计划。
- 我们介绍了“实验室日”的概念。 这些是整个团队从项目中被带走的整整一天，他们通过彼此的研究和在特定的技术主题上的合作来花费一天的时间来提高自己的技术技能。 大多数情况下，他们与具体项目完全没有关系，可以让团队成员思考更轻松的话题。
从维基百科的倦怠：“倦怠在很大程度上是由长时间，很less的停机时间，并持续的同行，客户和上级监督造成的组织问题”
他们可能还有一个Scrum的图标图像旁边的职业倦怠的定义。
如果你认为你可以派别人到别的地方做短暂的转换来解决倦怠问题，那么你显然没有想到这一点。 被烧掉后再度去度假，回去工作想，哇！ 现在我已经清醒了，准备再度进行6个月的折磨，直到我终于再度rest。 不，你知道发生了什么，哇！ 我的工作很糟糕。 现在我真的可以看到我的愚蠢的pipe理者的微观pipe理和发展过程是如何让更less的人从我身上得到更多的东西，而这样的生活又太短了……我应该find别的事情去做，或者把工作转移到压力之下。
恕我直言，短2周Scrum应禁止，除非小剂量，不超过4-8连续。 用它作为特殊或批评性事物的工具，而不是连续的。 使用常识。
经过36个星期的努力，你已经疲惫不堪; 那不是Scrum，那是人性的！ Scrum不是为了让你更努力地工作，而是帮助你更加一致地工作，并且具有更强的可预测性。 我经常看到有人将正常项目pipe理的症状与敏捷方法的症状混淆了（即“客户不断变化的需求 – 这一定是Scrum的错！”）。 这是一个重要的区别，虽然因为没有确定原因，你不能治疗的症状。 就我个人而言，我正在考虑如何减less压力pipe理技术的倦怠。 那里有大量关于如何在压力环境中取得成功的信息。
冲刺不是一个100码的短跑; 在马拉松中，这是一（随机）英里，也就是说，你可以无限期保持的速度。
您的团队是否在每个Sprint结束时进行回顾？ 这是团队“检查和调整”他们的过程的机会吗？ 作为一名ScrumMaster，我经常要求团队评价团队作为一个实体“感觉”，以及他们是否有乐趣。 我们探索为什么或为什么不做，并尝试调整和替代。
根据我的经验，团队成员可以享受（限制）Sprint时间框约束的“压力”。 关键是接近，但不能超过该区域。 根据需要，校准该区域是回顾过程中的主要检查点。
至于“在Scrum环境中，未分配/未跟踪以完成一些小事情并清除自己的头脑的时间”，将团队承诺保留在可用容量的x％（分数，最好是小时数）如果需要的话;无论是哪种情况，我发现60-70％的范围似乎是常态）是Sprint内部可持续发展的关键，偶尔的“免费代码日”对于Sprint外部来说非常适用。
不pipe你使用什么样的开发stream程，如果团队被烧毁了，有什么地方是错误的。 这可能就像人们没有休假时间一样简单，也可能是在处理你的Scrum的细节上。 从长远来看，团队是有效的，因为每个人都可以得到他们需要的一切。
一个解决scheme是减less冲刺当天花费的小时数。
我知道有些人的工作日只有两个半小时的冲刺，其余的时间都集中在其他各种活动上：支持，减免技术债务，研究等等，他们的发展速度是相应的。
这可能看起来有点极端，但如果我没有弄错的话，直到最近广泛的经济冲击袭击之前，这是一个有利可图的公司。
我目前所在的团队很好地解决了这个问题。 在三次冲刺之后，我们有一个星期的时间，每个开发者都可以根据自己的需求来工作。 那些副项目应该与商业价值联系在一起，但没有压力要完成。 这是一个让我们的开发人员探索新技术的措施，但它也为我们提供了一个更轻松，有趣的工作一周。
这当然可以帮助我不被烧毁。
我完全明白你在说什么。 对于那些说“你的速度太快”的人，我不确定我是否同意，这个过程中，人们总是被淘汰出局。 尽pipe跟踪你所有的进展是一件好事，但也可能是一个压力因素本身（而不是跟踪也是如此），不仅仅是因为如果你的老板/下午，如果他们看到的东西是不会的按计划，但为了你自己。 只有拥有这个logging的信息是会使大多数人的工作比通常所有的时间更难以工作，我不确定把更多的时间放在你的时间估计将为每个人解决这个问题。 我不认为一个激励者（如你的燃烧图）总是正面的。
有些人不会有这种感觉，其他人会这样。 没有一种适合所有人的工作方式。 在我看来，永远不会。
另外，如果你说这些敏捷方法和冲刺没有变得更有效率，那你为什么要使用它呢？ 你为什么认为公司想要使用这些方法呢？ 这不是因为他们很有趣….
在我看来，效率/生产力总是以某种types的价格出现。 它不会仅仅通过使用神奇的方法从任何地方popup（如果你明白了我的观点）。
让你变得更加有效（工作和压力）和减less工作的唯一方法就是让其他人去完成工作或自动化工作。
在我看来，应该总是审查一个stream程，看看什么是可以自动化的，而不是花时间来自动化stream程。 自动化的代价是做了额外的工作，而不是做“真正的工作”，但是无论自动化任务多么微小，你总能从长远利益中获益。 总是！ 如果不是一天，两个。 不是一个月，两个。 不到一年，两年内。 你明白了。
不过，我喜欢有时间做个人项目的想法。 大多数公司将永远不会允许这个。 但是，也许你可以说服你的雇主把时间花在这个时候，使你的stream程自动化，这个工作可能是“冲刺控制之外的”，让你所说的时间“rest”，并为新冲刺获得能量。
那些只是我的2美分。 当人们说这些方法不是为了让我们更有效，更努力的时候，我感到有些害怕。 当然是！ 当你没有跟踪你正在做什么时，你会在你的身体告诉你的时候rest。 当你所做的一切都被追踪时，你会推动自己。 或者我纠正自己，大多数人这样工作，有些人会rest。
你在你的第18次冲刺！
考虑每个冲刺2周，这意味着36周不间断地在同一个项目上工作。 你也评论说，每天工作6个小时左右。 听起来好像很多！
我不太了解敏捷方法（尽pipe我们在当前的项目中实际上使用了Scrum），但是有一个关于工作时间的原则（我的意思是，你花在做任务上的时间）应该是60％ 〜70％。 现在，再次做数字，如果你的工作时间是8小时，而你花费了6个小时的工作时间，你实际上花费了大约75％的劳动时间。 这可能是一个小偏差，终于让你有这种感觉。
OTOH，我相信，如果你的项目需要很长时间才能完成，冲刺应该更大，而不是2周，但不是一个月。 考虑一下你的倦怠图中的一个下降曲线：开始你的冲刺与定期的任务燃烧，并减less你的活动在最后2天或3天前冲刺结束。
敏捷不是刻着“工作更快，更强，更好，更努力”的石头，更像是一片白云，蓝天白云，写着：“工作好，美好，生产力高”。 （在愚蠢朋克+无线电广播的末尾有一点点大笑）。
可持续的步伐是敏捷的关键原则。 在进行pipe理（SCRUM）实践以及工程（XP）实践时，团队可以无限期地在冲刺之后提供冲刺。 但是，因为一个人可以不意味着应该。
这听起来像是你需要改变你在前面看到的无尽的短跑冲刺。 可以提供一些选项。 每个X冲刺，一个团队成员（或对）可以旋转一个团队。 在轮换期间，您可以支持运行团队，上课，专注于一组尖峰，休假等。
如果球队有5对，并且让一个人轮stream离场，那么每个人可以每10次冲刺（如果有一个人）或每5次迭代（如果一对）进行轮换。 您的活动的预算和投资回报问题将需要由您的领导和业务伙伴来解决。 但显然，有时间“磨锯”会给项目带来好处。 保持团队新鲜和专注是一件非常好的事情。 但我们必须记住，我们正在获得报酬，我们需要为我们赚取的美元带来价值。
我认为你错过了一些东西，但你并不是唯一的一个。 正如吉姆·海史密斯（Jim Highsmith）所说： “速度越来越多地被用来作为一种生产力衡量标准（而不是它所打算的能力衡量标准衡量标准），过于关注所交付的故事点的数量。
我想这就是你的团队正在发生的事情。 我build议读这个海史密斯的恕我直言的seminalpost： 速度是杀死敏捷！
