Scrum：太多还是不够？ [英] Scrum: too much or not enough?
问题描述
我的公司最近开始使用Scrum；我们完成了2个冲刺。我们仍在学习，但我们肯定已经暴露并解决了开发过程中的一些问题。因此，总的来说，我认为这对我们有好处。
在阅读福音派，愤世嫉俗的人以及介于两者之间的每个人在互联网上有关Scrum的许多困惑时，这三个常见且有些矛盾主题对我很突出：
- Scrum实施失败是因为对Scrum的过程没有足够的关注。
- Scrum实施失败，因为组织没有使Scrum适应其自身的环境/文化/惯例。
- Scrum的过程并不重要；
在对以下SO问题的回答中可以看到这些示例：
我必须承认我们还没有遵循Scrum的所有准则：我们尚未在sprint的末尾发布版本，Scrum Master不希望我们在sprint的末尾将任务移出sprint积压，以便他可以看到我们的计划有多少（这意味着燃尽图永远不会变为0），而且紧急的客户支持问题仍然具有无与伦比的破坏力例如，yone的计划。
我的问题是：在尝试解决这些问题和其他问题时，尝试并成为更接近正式的Scrum流程，更好地接近我们的某些Scrum之前流程，还是更好地沉思Scrum原理以尝试并提出完全不同的流程？
您将始终拥有阻止显示的问题，但是您可以通过缩短冲刺长度来帮助解决此问题。客户可能无法等待一个月，但他们可能需要等待2周才能完成某些工作。这样，较短的Sprint长度可以帮助您将某些请求推迟到下一个Sprint，从而减少干扰。您还需要提前与客户联系，以确保干扰实际上正在影响您的步伐。他们可能会自愿选择等待，如果他们知道自己选择的功能由于某些请求而被延迟。
我要说的另一种看法是，与几乎所有东西一样，这是最好从学习时尽可能地遵循模式开始。一旦掌握了基本原理，就可以更清楚地看到一些可以弯曲，破坏或替换的原理，以改进流程。在您真正掌握它之前，您所做的更改可能会伤害或有所帮助，因为您没有经验告诉您事情应该如何运作，所以您真的不知道。除非您的Scrum主管真的很有经验，否则您可能希望熟悉定义的实践，直到您获得更多的冲刺。
My company has recently started using Scrum; we've done 2 sprints. We're still learning, but we've definitely exposed and fixed some problems in our development process already. So in general I think it has been good for us.
In reading many of the internet musings about Scrum from evangelists, cynics and everyone in between, three common and somewhat contradictory themes have stood out to me:
- Scrum implementation fails because the processes of Scrum are not followed closely enough.
- Scrum implementation fails because the organization does not adapt Scrum to its own environment/culture/practices.
- The processes of Scrum are not important; only the values in the Agile Manifesto matter.
Examples of these can be seen in the responses to these SO questions:
I have to admit that we're not yet following all the guidelines of Scrum: we haven't done a release at the end of the sprints, our Scrum Master doesn't want us to move tasks out of the sprint backlog near the end of the sprint so that he can see how much our planning was off (which means the burndown chart never goes to 0), and urgent customer support issues still have incredible power to disrupt everyone's planning, for a few examples.
My question is: in trying to solve these and other issues, is it better to try and be closer to the official Scrum processes, better to be closer to some of our pre-Scrum processes, or better to meditate on the principles of Scrum to try and come up with a different process altogether?
I would say that you are really missing one of the key components of agility if you don't release early and often. To the degree that you don't do this, your process is not agile and bound to suffer the same sorts of problems that traditional, plan-driven processes have. It may be that this is a temporary condition as you are just getting used to things, but you need to start releasing soon (and regularly).
You'll always have the problem with show-stoppers, but you may be able to help this by shortening your sprint length. The customer may not be able to wait a month, but they may be able to wait 2 weeks for some things. A shorter sprint length, then, may help you to defer some requests to the next sprint making them less disruptive. You also need to be upfront with the customer that the disruptions are actually causing your pace to suffer. They may voluntarily choose to wait if they know that their chosen features are being delayed by some requests.
Another observation that I would make is that, as with almost anything, it's better to start out by following the pattern as closely as you can while you are learning. Once you have a good grasp of the fundamental principles, you can then see where some principles can be bent, broken, or replaced much more clearly to improve the process. Until you really get it, the things you change may hurt or help -- you really have no idea since you don't have the experience that tells you how things ought to be working. Unless your Scrum master is really experienced, you may want to hew closer to the defined practices until you've got a few more sprints under your belt.
这篇关于Scrum：太多还是不够？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
