连续进行Scrum冲刺时会出现倦怠吗？[关闭]

我在一家非常小的创业公司中，我们开始使用一种Scrum / Agile开发周期的形式。

在许多方面，我都很喜欢Scrum。我们的冲刺时间相对较短（2周），我喜欢“燃尽图”来跟踪团队的进度。我也喜欢功能板，所以我一直都知道下一步该做什么。从板上卸下功能卡，将其完成，然后将其放入烧毁的桩中，感觉很好。

但是，我们现在正进入第18个Sprint发行周期，我开始感到有些疲惫。并不是我不喜欢工作或我的同事，只是这些冲刺是...嗯，冲刺。从头到尾，我确实感觉到我在争分夺秒地保持我们的发展速度。完成sprint后，我们将花费一天的时间来计划下一个sprint的功能集并进行估计，然后再次进行。

对于在成熟的敏捷/敏捷开发过程中工作的人来说，这是正常现象吗？还是我们错过了什么？在Scrum环境中，通常是否有时间未被分配/跟踪以完成一些小事情并清理头脑？

这是相对正常的情况，如果项目持续很长时间，有时可能是我们团队成员的抱怨。

我们在这里谈论的关键是可持续的步伐。如果您和您的团队能够长期保持自己的步伐，那就太好了–您已经实现了所有Scrum团队都在努力的超生产力。

另外，如果您发现自己高估了一天实际上可以完成的工作量，则可能需要在回顾期间重新评估。团队在为冲刺进行容量规划时选择承认的一天中的生产时间称为焦点因素。

Henrik Kniberg这样说：

我为新团队使用的“默认”关注因子通常为70％，因为那是我们大多数其他团队随着时间的流逝所致。

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

但是，听起来您在说的只是冲刺不断的冲刺势头，不一定是您一天的工作效率。以下是我们尝试解决的一些建议：

• 在星期五的早晨结束冲刺。早上进行冲刺回顾和回顾，让团队在一天中的其余时间里进行其他工作，以清理头脑。在星期一进行Sprint计划。
• 我们介绍了“实验室日”的概念。这是团队整天都无法参与的项目，他们整天都在通过相互研究以及就特定技术主题进行协作来提高自己的技术技能。大多数时候，他们与特定项目完全没有关系，并且允许团队成员思考较轻的主题。

来自Wikipedia的倦怠：“倦怠主要是由长时间，很少的停机时间以及持续的对等，客户和卓越的监视引起的组织问题”

他们可能在倦怠的定义旁边还有一个Scrum图标图像。

如果您认为可以派人到其他地方进行简短的转移以解决倦怠问题，那么您显然没有考虑过。精疲力尽后去度假，然后回去工作，哇！现在，我感到神清气爽，准备再忍受6个月的酷刑，直到我终于再次休息一下。不，发生了什么，您意识到了，哇！我的工作糟透了。现在，我真的可以看到我愚蠢的经理如何进行微观管理，开发过程，这是使我从中获得更多收益，而生活却太短暂的另一种方式……我应该找到其他事情去做，或者将工作换成压力较小的东西。 。

恕我直言，短时间的2周应禁止Scrum，除非是小剂量，连续剂量不超过4-8次。不能连续使用它作为处理异常或重要事件的工具。使用常识。

经过36周的辛苦工作，您已经精疲力尽；那不是Scrum，那是人的本性！Scrum并不能帮助您更加努力地工作，而是可以帮助您更一致地工作并具有更大的可预测性。我经常看到人们将正常项目管理的症状与敏捷方法的症状相混淆（即“客户不断变化的需求–这一定是Scrum的错！”）。不过，这是一个重要的区别，因为如果不找出原因，就无法治疗症状。我个人将研究减少疲劳的方法，例如压力管理技术。关于如何在压力很大的环境中取得成功的信息很多。

我目前正在研究的团队确实很好地解决了这个问题。经过三个冲刺，我们有一个星期的时间，每个开发人员可以根据自己的需求进行工作。这些附带项目应与业务价值相关联，但没有压力将其完成。这是允许我们的开发人员探索新技术的一种措施，但同时也为我们提供了一周的轻松，有趣的工作。

这肯定可以帮助我避免疲惫。

短跑不是100码短跑；在马拉松比赛中，这是一英里（随机），即您可以无限维持的速度。

您的团队在每个Sprint结束时是否进行回顾？这是团队“检查和适应”过程的机会吗？作为ScrumMaster，我经常要求团队评估团队作为一个实体的感觉，以及他们是否过得愉快。我们探讨了为什么或为什么不这样做，并尝试进行调整和替代。

以我的经验，团队成员喜欢（最大程度）Sprint时限所约束的“压力”。关键是接近但不能超过该区域。根据需要，校准区域是回顾中的主要检查点。

至于“ ...在Scrum环境中未分配/未完成一些小事情并清理头脑的时间”，请将团队承诺保持在可用容量的x％（最好是点数，但可以使用几个小时）如果需要；无论哪种情况，我都发现60-70％的范围似乎是正常的）是Sprint内部可持续性的关键，偶尔的“免费代码日”对Sprint外部也很有效。

无论您使用什么开发流程，如果团队都精疲力尽，那都是错的。这可能很简单，因为人们没有按照他们的需要休假，或者可能是在如何处理混乱的细节中。从长远来看，团队是有效的，因为在此过程中每个人都能获得所需的其余信息。

一种解决方案是减少一天中冲刺所花费的时间。

我知道有些人的工作日只有短短的两个半小时，其余的时间则集中在其他各种活动上：支持，减轻技术负担，研究等。他们的发展速度也据此设定。

这似乎有些极端，但是如果我没有记错的话，那是一家盈利的公司，直到最近广泛的经济冲击来袭。

您正在第18个冲刺中！？

考虑到每个冲刺2周，这意味着36周不间断地从事同一项目。您还评论说每天工作约6个小时。听起来很多！

我对敏捷方法学不甚了解（尽管我们实际上在当前项目中使用Scrum），但是关于工作时间（我的意思是，您花费在执行任务上的时间）有一个原则应为60％约70％现在，再次进行数字计算，如果您的劳动时间长达8个小时，并且您花费6个小时工作，那么您实际上就是在花费约75％的劳动时间。这可能会有些许偏差，最终使您有那种感觉。

OTOH，我相信，如果您的项目需要很长时间才能完成，则冲刺应该更大，而不是2周，而是一个月。考虑一下倦怠图表上的向下曲线：通过常规任务刻录开始您的sprint，并在sprint结束前的最近2或3天减少活动。

敏捷不是刻有铭文的石头：“工作更快/更坚固/更好/更坚硬”，它更像是一片蓝天与白云，上面写着：“做得更好，更美丽，工作效率更高”。（最后一点点笑声由傻朋克+广播电台提供）。

我完全理解你在说什么。对于你们中那些说“您的节奏太快”的人，我不确定我是否同意当人们被这个过程精疲力尽时，节奏永远是问题。即使跟踪您的所有进度都是一件好事，但它本身也可能是一个压力因素（并且不跟踪也可以），不仅是因为如果老板/ PM看到事情没有进展，还会在您身边根据计划，但适合您自己。仅拥有此已记录的信息，将使大多数人比以往任何时候都更加辛苦，而且我不确定在您的时间估算上花更多的时间会为每个人解决。我认为激励因素（例如您的疲倦表）并不总是积极的。

有些人不会这样，其他人会。没有一种工作方法能适合所有人。我认为永远不会。

另外，如果您说这些敏捷方法和冲刺并没有变得更加有效/多产，那么为什么还要使用它呢？您为什么认为公司完全想使用这些方法？不是因为他们很有趣。

在我看来，有效性/生产力总是要付出某种代价。仅仅使用魔术方法就不会从任何地方弹出（如果您明白我的意思）。

使您变得更有效率（在工作和有压力的情况下）并减少工作量的唯一方法是让其他人来完成工作或将其自动化。

在我看来，应该始终检查那些流程，看看可以实现哪些自动化，并花一些时间来使您的流程自动化。自动化是以付出额外工作而不是进行“实际工作”为代价的，但是无论自动化任务有多小，从长远来看，您总会从中受益。总是！如果不是一日，则是两日。没有一个月，两个月。没有一年，两年。你明白了。

但是，我喜欢抽出时间从事个人项目的想法。不过，大多数公司永远都不允许这样做。但是，也许您可​​以说服您的雇主花点时间来使您的流程自动化，并且这项工作可能不在“冲刺控制范围之内”，以便您有时间谈论“休息”并为新的冲刺回馈精力。

那只是我的2美分。当人们说这些方法不能使我们更有效，更努力地工作时，我会感到有些恐惧。当然是！当您无所事事时，身体会告诉您休息。当跟踪您所做的“所有事情”时，您将推动自己。或者我纠正自己，大多数人都是这样工作的，有些人还是会休息的。

可持续的步伐是敏捷的关键原则。在执行管理（SCRUM）练习和工程（XP）练习时，团队可以无限期地完成sprint。但是，因为一个罐头并不意味着一个罐头就应该。

听起来好像您需要针对您前面看到的一连串的冲刺进行更改。可以提供多种选择。每X个冲刺，一个团队成员（或一对）就可以轮流离开团队。在轮岗期间，您可以支持奔跑团队，参加课程，专注于一组钉刺，休假等。

如果团队有5对，并且您将一个人下线，那么一个人可以每10个Sprint（如果是一个人）或每第5个迭代（如果是对）进行一次偏离轮换。您的活动的预算和投资回报问题将需要您的领导和/或业务合作伙伴解决。但是很明显，有一些时间“磨锯子”将为团队带来收益，从而使项目受益。使团队保持新鲜和专注是一件好事。但我们必须记住，我们正在获得报酬，我们需要为我们赚到的美元带来价值。

我认为您缺少某些东西，但您不是唯一的一个。正如吉姆·史密斯（Jim Highsmith）所说：“速度越来越多地被用作生产力度量（而不是原本打算的容量校准度量），它过于关注交付的故事点的数量。”

我想这就是您的团队正在发生的事情。我建议阅读这篇海史密斯的恕我直言开创性文章：速度是杀死敏捷！