连续进行 Scrum 冲刺会导致倦怠吗？
我所在的公司规模很小，我们开始使用 Scrum/敏捷开发周期的形式。
在很多方面我喜欢 Scrum。 我们的冲刺相对较短（2 周），我喜欢用燃尽图来跟踪团队的进度。 我也喜欢功能板，所以我总是知道下一步应该做什么。 从板上取下某个功能的卡片，完成它，然后将其放入燃尽堆中，这种感觉很好。
然而，我们现在正进入第 18 个 Sprint 发布周期，我开始感到有点精疲力竭。 这并不是说我不喜欢工作或我的同事，只是这些冲刺......好吧，冲刺。 从开始到结束，我真的感觉自己在与时间赛跑，以保持我们的开发速度。 当我们完成冲刺后，我们会花一天的时间来规划下一个冲刺的功能集和估算，然后再出发。
对于在成熟的 Agile/Scrum 开发流程中工作的人来说，这是正常的吗？ 或者我们错过了什么？ 在 Scrum 环境中，通常是否有未分配/未跟踪的时间来完成一些小事情并清醒头脑？
I'm with a pretty small startup and we started using a form of a Scrum/Agile development cycle.
In many ways I enjoy Scrum. We have relatively short sprints (2 weeks) and I like the Burn Down Chart to track the team's progress. I also like the Feature Board so I always know what I should be doing next. It feels good taking down a feature's card from the board, completing it and then putting it in the burn down pile.
However, we are now entering in our 18th Sprint release cycle and I'm starting to feel a little burnt out. It isn't that I don't like job or my co-workers, it is just that these sprints are... well, sprints. From start to finish I literally feel like I'm racing against the clock to maintain our development velocity. When we are done with the sprint we spend one day planning the next sprint's feature set and estimates and then off we go again.
For people who work in a mature Agile/Scrum development process, is this normal? Or are we missing something? Is there normally time in a Scrum enviornment that is unassigned/untracked to get done some minor things and to clear your head?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
这是相对正常的，如果项目持续很长时间，有时我们的团队成员可能会抱怨。
我们在这里讨论的关键是可持续的步伐。 如果您和您的团队能够长期保持您的步伐，那就太好了——您已经实现了所有 Scrum 团队都在努力追求的超高生产力。
或者，如果您发现自己高估了一天实际可以完成的工作量，那么您可能需要在回顾期间重新评估。 团队在进行冲刺容量规划时选择识别的一天中的生产时间量称为焦点因素。
亨里克·尼伯格有这样的说法：
然而，听起来你所说的只是一个又一个冲刺的不间断动力，不一定是你一天的生产力。 以下是我们尝试解决的一些问题的建议：
This is relatively normal and can sometimes be a complaint of our team members if projects continue for a long period of time.
The key to what we're talking about here is sustainable pace. If you and your team are able to sustain your pace over the long term, that's excellent -- you've achieve the hyperproductivity that all Scrum teams are striving for.
Alternatively, if you're finding that you overestimate how much work you can actually get done in a day, then you may need to reevaluate that during your retrospective. The amount of productive time in a day that a team chooses to recognize when doing their capacity planning for a sprint is referred to as a focus factor.
Henrik Kniberg has this to say:
However, what it sounds like you're talking about is simply the nonstop momentum of sprint after sprint, not necessarily your productivity in a day. Here's some suggestions of things we have tried to deal with that:
来自 Wikipedia 关于倦怠的内容：“倦怠很大程度上是一个组织问题，由长时间工作、很少的停机时间以及持续的同行、客户和上级监督引起。”
他们可能会在倦怠的定义旁边放一个 Scrum 的图标图像。
如果你认为你可以派某人去其他地方做短暂的消遣来缓解倦怠，那么你显然还没有想清楚。 曾经在精疲力尽后去度假，然后回去工作时会想，哇！ 现在我精神焕发，准备好再忍受六个月的折磨，直到我终于再次休息。 不，你意识到会发生什么，哇！ 我的工作很糟糕。 现在我真的明白了，我愚蠢的经理的微观管理、发展过程只是另一种让我以更少的投入获得更多成果的方式，而生命太短暂了……我应该找点别的事情做，或者换一份压力较小的工作。
恕我直言，短 2 周的 Scrum 应该被禁止，除非小剂量，连续不超过 4-8 次。 将其用作处理特殊或关键事务的工具，但不要持续使用。 使用常识。
From Wikipedia on burnout: "burnout is largely an organizational issue caused by long hours, little down time, and continual peer, customer, and superior surveillance"
They might as well have an icon image of Scrum next to the definition of burnout.
If you think you can send someone onto something else for a brief diversion to fix burnout, you obviously haven't thought it through. Ever go on a vacation after being burned out and go back to work thinking, Wow! Now I'm refreshed and ready for another 6 months of this torture until I finally get a break again. Nope, what happens is you realize, Wow! My job sucks. Now I can really see how my stupid manager's micro-managing, development process is just another way of getting more out of me for less and life's too short for this... I should find something else to do or change jobs to something less stressful.
IMHO, short 2 weeks Scrum should be prohibited except in small doses, not more than 4-8 in a row. Use it as a tool for exceptional or critical things, not continually. Use common sense.
我目前工作的团队很好地解决了这个问题。 三个冲刺之后，我们有一周的时间让每个开发人员可以做他想做的事情。 这些副项目应该与商业价值挂钩，但没有压力去完成它。 这是让我们开发者探索新技术的一项举措，同时也为我们提供了一周更加轻松、有趣的工作。
这肯定可以帮助我不被烧坏。
The team that I am currently working on solves this problem really nicely. After three sprints we have a week in which each developer may work on what he wants. Those side projects should be linked to business value, but there is no pressure to get it done. It is a measure to allow us developers to explore new technologies, but it also provides us with a week of more relaxed, fun work.
This for sure helps me to not get burned out.
经过 36 周的辛苦工作，您已经精疲力尽了； 这不是 Scrum，这是人性！ Scrum 并不是让您更加努力地工作，而是帮助您更加一致地工作并具有更高的可预测性。 我经常看到人们将正常项目管理的症状与他们认为的敏捷方法论的症状相混淆（即“客户不断变化的需求 - 这一定是 Scrum 的错！”）。 但这是一个重要的区别，因为如果不找出原因，就无法治疗症状。 就我个人而言，我会寻找减少倦怠的方法，例如压力管理技巧。 有大量关于如何在压力环境中取得成功的信息。
You’re getting worn out after 36 weeks of hard work; that’s not Scrum, that’s human nature! Scrum is not there to make you work harder, it’s there to help you work more consistently and with greater predictability. I often see people confusing the symptoms of normal project management with what they perceive are symptoms of agile methodologies (i.e. “the customer keeps changing requirements – it must be Scrum’s fault!”). It’s an important distinction though because without identifying the cause you can’t treat the symptoms. Personally I’d be looking at ways to reduce burnout such as stress management techniques. There’s heaps of info out there on how to succeed in a stressful environment.
无论您使用什么开发流程，如果团队感到精疲力尽，那么一定是出了问题。 这可能很简单，比如人们没有享受他们需要的假期，也可能是你如何处理 Scrum 的细节。 从长远来看，团队是有效的，因为每个人都能得到所需的休息。
No matter what development process you're using, if the team is getting burned out something is wrong. It may be as simple as people not taking the vacation time they need, or it could be in the details of how you handle your scrums. Teams are effective over the long-term because everyone gets the rest they need along the way.
短跑不是 100 码冲刺；而是冲刺。 它是马拉松比赛中的一英里（随机），即您可以无限期维持的配速。
您的团队是否在每个 Sprint 结束时进行回顾？ 这是团队“检查和调整”流程的机会吗？ 作为一名 ScrumMaster，我经常要求团队评价团队作为一个实体的“感觉”如何，以及他们是否玩得开心。 我们探讨原因或原因，并尝试调整和替代方案。
根据我的经验，团队成员（在一定程度上）享受 Sprint 时间盒限制的“压力”。 关键是接近但不超过该区域。 根据需要，校准该区域是回顾中的主要检查点。
至于“......在 Scrum 环境中未分配/未跟踪的时间来完成一些小事情并清醒头脑”，将团队承诺保持在可用能力的 x%（最好是点，但可以使用小时）如果需要的话；无论哪种情况，我发现 60-70% 的范围似乎是常态）是 Sprint 内部可持续发展的关键，偶尔的“免费代码日”对于 Sprint 外部来说效果很好。
A Sprint is not a 100 yard dash; it is one (random) mile in a marathon, i.e. a pace that you can sustain indefinitely.
Is your Team conducting retrospectives at the end of each Sprint? This is the Team's opportunity to "inspect and adapt" their process? As a ScrumMaster, I regularly ask the Team to rate how the Team as an entity 'feels', and if they're having fun. We explore why or why not, and experiment with adjustments and alternatives.
In my experience, Team members enjoy (up to a limit) the 'pressure' that the Sprint timebox constrains. The key is to approach, but not exceed, that zone. As needed, calibrating that zone is a prime checkpoint in a retrospective.
As for "... time in a Scrum environment that is unassigned/untracked to get done some minor things and to clear your head", keeping the Team commitment at x% of the available capacity (points, preferably, but hours can be used if needed; in either case I've found something in the range of 60-70% seems the norm) is key to sustainability inside of a Sprint, and an occasional 'free code day' works well for outside Sprints.
一种解决方案是减少一天中花在冲刺上的小时数。
我认识一些人，他们的工作日只有两个半小时的冲刺，剩下的时间则专注于各种其他活动：支持、减轻技术债务、研究等。他们的开发速度是相应设定的。
这可能看起来有点极端，但如果我没记错的话，在最近广泛的经济冲击袭来之前，它一直是一家盈利的公司。
One solution is to reduce the number of hours in the day spent on the sprint.
I know some people whose workdays consisted of a mere two and a half hour of sprint, with the remainder of the day focused on a variety of other activities: support, relieving technical debt, research, etc.. Their development velocity was set accordingly.
That may seem a bit extreme, but if I'm not mistaken it was a profitable company until the recent widespread economic shock hit.
您已进入第 18 次冲刺！？
考虑到每个冲刺 2 周，这意味着 36 周不间断地工作在同一个项目上。 您还评论说每天工作大约6小时。 听起来很多！
我对敏捷方法论了解不多（虽然我们在当前的项目中实际上使用的是 Scrum），但是有一个关于你的工作时间（我的意思是，你花在完成一项任务上的时间）的原则应该是 60% 〜70％。 现在，再次计算一下，如果您一天的劳动时间为 8 小时，而您工作 6 小时，那么您实际上花费了大约 75% 的劳动时间。 这可能是一个小小的偏差，最终让你有了那种感觉。
OTOH，我相信如果你的项目需要很长时间才能完成，冲刺应该更大，不是两周，而是一个月。 考虑倦怠图上的向下曲线：以常规任务燃烧开始冲刺，并在冲刺结束前的最后 2 或 3 天减少活动。
敏捷并不是一块刻有“工作更快/更强/更好/更努力”的石头，它更像是一片蓝天白云，上面写着：“工作得好，美丽得更有成效”。 （最后有点哈哈，由 Daft Punk + Radiohead 提供）。
You are in your 18th sprint!?
Considering 2 weeks per sprint, that means 36 weeks nonstop working on the same project. You also comment that work around 6 hours each day. That sounds like a lot!
I don't know that much about agile methodologies (although we're actually using Scrum in our current project), but there's a principle about your working hours (I mean, the amount of time you spend doing a task) should be 60%~70%. Now, doing numbers again, if your labor day is 8 hours long, and you spend 6 hours working, you're really spending around 75% of your labor time. This could be a little deviation that has finally make you have that feeling.
OTOH, I believe that if your project will take long time to be done, sprints should be larger, not 2 weeks, but not a month. Consider a downward curve on your burnout chart: Start your sprint with a regular task burn, and reduce your activity on the last 2 or 3 days before the sprint ends.
Agile is not a stone with the engraving:"work faster/stronger/better/harder", it's more like a blue sky with white clouds that read:"work nice, beautiful more productive". (a little lol at the end courtesy of daft punk + radiohead).
我完全理解你所说的。 对于那些说“你的节奏太快”的人来说，我不确定我是否同意当人们因这个过程而精疲力尽时，节奏始终是问题。 尽管跟踪所有进展是一件好事，但它本身也可能是一个压力因素（不跟踪也可能是一个压力因素），不仅仅是因为如果你的老板/PM 发现某些事情进展不顺利，他们会来找你按照计划，但为了你自己。 仅仅拥有这些记录的信息就会让大多数人一直比平时更加努力地工作，而且我不确定在时间估计上投入更多时间是否会为每个人解决这个问题。 我不认为激励因素（比如你的燃尽图）总是积极的。
有些人不会有这种感觉，有些人则会。 没有一种工作方式适合所有人。 在我看来，永远不会。
另外，如果您说这些敏捷方法和冲刺并没有变得更加有效/富有成效，那么您为什么要使用它？ 您认为公司为什么要使用这些方法？ 这并不是因为它们很有趣……
在我看来，有效性/生产力总是以某种代价换来的。 它不会仅仅通过使用魔法方法就凭空出现（如果你明白我的意思的话）。
让你变得更有效率（工作和压力方面）并减少工作量的唯一方法是让其他人做工作或通过自动化来完成工作。
在我看来，人们应该始终审查自己的流程，看看哪些内容可以自动化，然后花时间来实现流程自动化。 自动化的代价是做额外的工作而不是做“真正的工作”，但无论自动化任务有多小，从长远来看，你总是会受益。 总是！ 如果不是一天，就两天。 不是一个月，是两个月。 不是一年，是两年。 你明白了。
然而，我喜欢有时间从事个人项目的想法。 但大多数公司永远不会允许这样做。 但也许您可以说服您的雇主腾出时间来自动化您的流程，并且这项工作可能“超出冲刺控制范围”，以便让您所说的时间“休息”并为新的冲刺恢复能量。
这些只是我的2分钱。 当人们说这些方法不是为了让我们更有效、更努力地工作时，我有点害怕。 当然是！ 当你对自己所做的事情毫无印象时，你就会在身体告诉你的时候休息。 当你所做的“一切”都被追踪时，你就会鞭策自己。 或者我纠正自己，大多数人都是这样工作的，有些人无论如何都会休息。
I fully understand what you are saying. For those of you that say "your pace is too fast," I'm not sure I agree that pace is always the problem when people get burned out by this process. Even though keeping track of all your progress IS a good thing, it can also be a stress factor itself (and not keeping track can be as well), not just because your boss/PM will be on you if they see something is not going according to plan, but for yourself. Just having this logged info is something that WILL make most people work just that little bit harder than you normally would ALL THE TIME and I'm not sure putting more time on your time estimates will fix this for everyone. I don't think a motivator (like your burn down chart) is always positive.
Some people won't feel this way, others will. There is not ONE way of work that WILL fit all. Never will be, in my opinion.
Also, if you say that these agile methods and sprints are not becoming more effective/productive, why are you using it at all? Why do you think companies want to use these methods at all? It's not because they are fun....
Effectiveness/productivity always comes at some type of price, in my opinion. It doesn't pop up from nowhere just by using the magic methods (if you get my point).
The only way for you to become more effective (work and pressure-wise) and do less work is make someone else do the work or by automating it.
In my opinion, one should always review ones processes and see what can be automated and spend time on automating your processes instead. Automation comes at the price of doing extra work instead of doing "the real work" but no matter how small the automated task you will always profit in the long run. ALWAYS! If not one day, in two. Not one month, two. Not one year, in two years. You get the idea.
However, I like the idea of having time off to work on personal projects. Most companies will never allow this though. But perhaps you can persuade your employer to get this time to automate your processes and this work could be "outside of sprint control" to allow the time you are talking about to "rest" and get energy back for a new sprint.
Those were just my 2 cents. I get a bit frightened when people say these methods aren't here to make us more effective and work harder. Of course they are! When you have no trace of what you are doing you will rest when your body tells you to. When "everything" you do is traced, you will push yourself. Or I correct myself, most people work this way, some will rest anyway.
可持续的步伐是敏捷的关键原则。 当进行管理 (SCRUM) 实践和工程 (XP) 实践时，团队可以无限期地交付一个又一个的冲刺。 然而，因为一个人可以并不意味着一个人应该。
听起来你需要针对眼前无休无止的冲刺做出改变。 可以提供多种选择。 每 X 次冲刺，一名团队成员（或一对）可以轮换离开团队。 在轮换期间，您可以支持跑步团队、上课、专注于一组钉鞋、休假等。
如果团队有 5 对，并且您轮换一个人下线，则每个人可以轮换一次第 10 次冲刺（如果是单人）或每 5 次迭代（如果是两人）。 您的活动的预算和投资回报问题需要由您的领导层和/或业务合作伙伴解决。 但显然，有一些时间“磨刀霍霍”会给团队带来好处，从而为项目带来好处。 保持团队的活力和专注是一件非常好的事情。 但我们必须记住，我们正在获得报酬，我们需要为我们赚到的钱带来价值。
Sustainable pace is a key tenet of agile. When doing the management (SCRUM) practices along with the engineering (XP) practices, a team can deliver sprint after sprint indefinitely. However, because one can does not mean one should.
It sounds like you need a change against the endless string of sprints you see ahead of you. A number of options can be offered. Every X number of sprints, a team member (or pair) can rotate off of a team. During your rotation, you can support the run team, take a class, focus on a set of spikes, take vacation etc.
If the team has 5 pairs, and you rotate a person off the line, A person could take an off rotation every 10th sprint (if a single person) or every 5th iteration (if a pair). Issues of budget and return on investment for your activities will need to be addressed by your leadership and or business partner. But clearly, having some time to "sharpen the saw" would bring benefit to the team thus the project. Keeping the team fresh and focused is a very good thing. But we must remember, we are getting paid and we need to bring value for the dollars we earn.
我认为你错过了一些东西，但你不是唯一的。 正如吉姆·海史密斯 (Jim Highsmith) 所说：“速度越来越多地被用作生产力衡量标准（而不是其本来的目的是能力校准衡量标准），这将太多注意力集中在交付的故事点的数量上。”
我猜这就是你的团队正在发生的事情。 我建议阅读 Highsmith 的这篇开创性的文章：速度正在扼杀敏捷性！
I think you are missing something, but you are not the only one. As Jim Highsmith says: “Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.”
I’d guess that is what is happening to your team. I recommend reading this Highsmith’s IMHO seminal post: Velocity is Killing Agility!