Scrum 可以在现实世界中发挥作用吗
我工作的团队已经大力拥抱 Scrum。 我真的很喜欢它的想法，但发现我们不断地不得不做出妥协以适应我们的发展现实。 这会降低 Scrum 的效率并导致其他开销。
我要问的是，人们是否能够成功地使用纯粹的 Scrum 进行工作，这样做是否值得。 或者说，妥协是不可避免的。
我问这个问题是因为 Scrum 似乎有点不能容忍偏差，如果它接受世界不能总是改变以适应 Scrum 并在它不起作用的地方找到解决方案，那么它可能会成为一种更好的方法。
The team I am working in has embraced scrum in a big way. I really like the idea of it, but find that we are constantly having to make compromises to fit with our development reality. This is making scrum less effective and causing other overheads.
What I am asking is have people out there managed to work with pure scrum and does it pay of to do so. Or is it inevitable that compromises have to be made.
I ask this as scrum seems to be a little intolerant to deviation and it may make a better methodology if it were to accept that the world can’t always be changed to fit scrum and have work around for places where it doesn’t work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Scrum 绝对可以容忍偏差，但我认为这里的关键点是你的陈述“我们不断地必须做出妥协以适应……”。当然，如果你改变你的方法论，你就会改变你做事的方式。就像说：“我们现在是一家 LISP 商店。 但我们真的必须用 LISP 编写代码吗？还是仍然可以使用 C#？”
拥抱 Scrum 并接受您做事的方式将会改变的事实。您一定会获得好处。不幸的是，Scrum 需要被所有利益相关者接受，不仅仅是开发团队，要真正高效。
Scrum is definately tolerant to deviation, but I think the key point here is your statement 'we constantly having to make comprimises to fit..". Well of course, if you change your methodology, you change the way you do things. Its like saying "We are now a LISP shop. But do we actually have to write our code in LISP or can we still use C#?"
Embrace scrum and accept that the way you do things will change. You will definately reap the benefits. Unfortunately scrum needs to be accepted by all the stakeholders, not just the development team, to be truly efficient.
认真审视您所做的妥协，看看它们是否不会让您背离 Scrum/敏捷的核心价值观。
很长一段时间以来，我店里的人们一直声称我们是敏捷的，但他们真正的意思是需求变更几乎可以随时推进开发。 我们有各种各样的程序和说明需要遵循，但绝不是“轻装上阵”。
如果每个人都清楚我们并没有真正使用 Scrum、XP，那么这不一定是一个大问题或另一种真正敏捷的方法。
只有当引入某些内容而不调整其他核心内容时，它才会变得危险 - 你最终会试图在一个只会因此惩罚你的系统中保持敏捷。 您尝试修复 4 周的迭代，但无论如何您每周都会收到新的最优先要求，并且不允许您忽略它们。 您需要制定详细的计划，并且在冲刺期间只要有轻微偏离计划的情况就会收到投诉。 您最好的团队成员经常被打扰来帮助其他团队解决问题。
这不是敏捷，无论你如何努力称之为敏捷，它都行不通。
因此，也许您的实际情况是一样的，只是您的组织还没有真正做好准备。
Take a good hard look at the compromises you are making, and if they aren't pushing you away from the core values of Scrum / Agile.
For the longest time people here at my shop have been claiming we're Agile, but what they really mean is that requirements changes can be pushed to development at almost any time. We have all kinds of procedures and instructions to follow, and it's anything but "travel light".
That's not necessarily a big issue if everyone is clear that we aren't really doing Scrum, XP or another truly agile methodology.
It only gets dangerous when some things are introduced without adapting other core things - you end up trying to be agile in a system that will simply punish you for it. You try to fix a 4-week iteration but you get new top-priority requirements every week anyway, and you're not allowed to ignore them. You're asked for a detailed planning and get complaints whenever something slightly deviates from it during a sprint. Your best team members are constantly interrupted to help out other teams with their problems.
That's not agile, and it won't work no matter how hard you try to call it agile.
So maybe the reality of your situation is the same, and your organization just isn't really ready for it yet either.
我们的团队现在使用 Scrum 已经好几年了，尽管一开始存在一些问题，并且需要进行大量宣传，直到管理层接受它并改变与团队合作的方式，但它提高了我们的生产力并增强了我们的知识转移跨团队成员。
根据我的理解，scrum 非常容易出现偏差，依赖于通过回顾（对于开发人员）和短期迭代（来自项目规划方面/管理）不断的反馈和适应。 当然，所有相关方（开发人员、Scrum 管理员、产品所有者/管理层/客户）都必须接受 Scrum 的工作方式与大多数其他非敏捷开发方法不同，并且他们必须修改一些当前的方法。
我个人认为，与我过去经历过的其他“静态”开发/项目方法相比，scrum 给了我更大的自由和效率。
Our team is now using scrum for several years and although there have been issues at the beginning and a lot of evangelizing was needed until management accepted it and changed their way of working with the teams, it has leveraged our productivity and enhanced our knowledge-transfer across the team-members.
From my understanding scrum is very open to deviation, relying on constant feedback and adaption through the retrospective (for the developers) and short iterations (from project planning side/management). Of course, all parties involved (developers, scrum masters, product owners/management/clients) have to accept that scrum works differently than most of the other non-agile development approaches and that they have to modify some of their current methodologies.
I personally think, that scrum gives me a greater freedom and effectiveness than with the other "static" development-/project-approaches I experienced in the past.
可以，但并不适合所有人。 事实上，它并不适合大多数地方，因为那里有大量商店无法满足它的先决条件。 而且，几乎每个人都使用自己的 Scrum 版本。
It can, but it's not for everyone. In fact, it's not for most places, because the pre reqs for it aren't met by a rediculous number of shops out there. Also, pretty much everyone does their own version of Scrum.
我们最近开始使用 Scrum，并且我们也在根据我们的需求对其进行调整。 不过，我认为所有方法论都是如此。
有些事情，比如每日 Scrum 会议，我们觉得有点太频繁了：我们现在每周举行两次 Scrum 会议。
我们的冲刺并不像想象的那么严格：我们经常在冲刺结束前的中途添加一两个功能。
最后，也许也是最重要的，我们的 Scrum Master 和产品负责人是同一个人。
总体而言，一切进展顺利。 我最喜欢的是燃尽图。
希望这可以帮助。
We have recently started to use Scrum, and we are also adapting it to our needs. I think this would be true will all methodologies, though.
There are things like the daily Scrum meetings which we felt were a bit too frequent: we now have Scrum meetings twice a week.
Our sprints are not as rigid as they are supposed to be: we often add a functionality or two in a sprint halfway before the end.
Finally, and probably most importantly, our scrum master and the product owner are the same person.
Overall, things run smoothly. What I like most is the burn down chart.
Hope this helps.
如果您能阐明您正在谈论的一两个“妥协”，您可能会得到更好的答案。 我不确定您是否在谈论程序问题、任务积压的管理、站立会议需要多长时间，或者如何处理版本控制。
我在大公司环境中的“纯 Scrum”经历非常非常顺利。 我想不出使用 Scrum 模型会带来任何负面影响。
You might get even better answers if you could illuminate just one or two of the "compromises" you're talking about. I'm not sure whether you're talking about procedural issues, management of the task backlog, how long to make your standup meeting, or what to do about version control.
My experience with "pure scrum" in a big corporate environment has gone really really well. I can't think of anything that was compromised in a negative sense by using the Scrum model.
是的，有哪些妥协？ 也许你并不总是结对编程？
所有开发人员都需要让每个人都意识到中断的影响。 如果有人花2秒去接触未干的油漆，那么画家会花多少时间？ 如果你只是粉刷了这个地方，那还不算什么，但如果所有的用品都被收起来了怎么办？
让您的经理、用户、客户团队领导知道您可以处理他们的新紧急情况，但他们想放弃/推迟什么？ 没有人免费乘车。
Yes, what are the compromises? Maybe you don't always program in pairs?
All developers need to make everyone aware of the impact of interuptions. If someone takes 2 seconds to touch wet paint, how much time will it take away from the painter? Not to much if you just painted the spot, but what if all the supplies have been put away?
Let your managers, users, clients team leaders know that you can handle their new emergency, but what do they want to give up/delay? Nobody rides for free.