Scrum:太多还是不够？

我的公司最近开始使用Scrum; 我们做了2次短跑.我们还在学习,但我们已经在开发过程中暴露并解决了一些问题.总的来说,我觉得这对我们有好处.

在阅读福音传教士,愤世嫉俗者和其间所有人的关于Scrum的许多互联网思考中,三个常见且有些矛盾的主题对我来说很突出:

Scrum实现失败,因为Scrum的过程没有得到足够的密切关注.

Scrum实现失败,因为组织不会将Scrum适​​应其自己的环境/文化/实践.

Scrum的过程并不重要; 只有敏捷宣言中的价值才有意义.

在这些SO问题的回答中可以看到这些例子:

你有Scrum或短跑的糟糕经历吗？

Scrum邪恶吗？

敏捷开发是否已经死亡？

我不得不承认我们还没有遵循Scrum的所有指导原则:我们没有在冲刺结束时完成发布,我们的Scrum Master不希望我们将任务移出sprint backlog结尾他可以看到我们的计划已经关闭了多少(这意味着燃烧图表永远不会变为0),而紧急的客户支持问题仍然具有破坏每个人计划的难以置信的能力,举几个例子.

我的问题是:在尝试解决这些问题和其他问题时,最好是尝试更接近官方的Scrum流程,更好地接近我们的一些Scrum前流程,或者更好地冥想Scrum的原则试着想出一个完全不同的过程吗？

我会说,如果你不提前和经常发布,你真的错过了敏捷的关键组成部分之一.如果您不这样做,您的流程就不灵活,并且必然会遇到传统的,计划驱动的流程所带来的相同类型的问题.这可能是一个暂时的情况,因为你只是习惯了事情,但你需要尽快(并定期)开始发布.

你总是会遇到show-stoppers的问题,但你可以通过缩短你的冲刺长度来解决这个问题.客户可能无法等待一个月,但他们可能会等待2周才能完成某些事情.因此,较短的冲刺长度可以帮助您将一些请求推迟到下一个冲刺,从而减少它们的破坏性.您还需要与客户一起预先确定中断实际上会导致您的节奏受到影响.如果他们知道他们选择的功能因某些请求而被延迟,他们可能会自愿选择等待.

我要做的另一个观察是,与几乎任何事情一样,最好是在你学习的同时尽可能地遵循模式.一旦掌握了基本原则,就可以看到一些原则可以更明确地被修改,破坏或替换,以改进流程.直到你真正得到它,你改变的东西可能会伤害或帮助 - 你真的不知道,因为你没有经验告诉你应该如何工作.除非你的Scrum大师真的很有经验,否则你可能希望更接近定义的练习,直到你有更多的冲刺.

我在Scrum上读到的几乎所有内容都说其中一个关键是调整流程以适应您自己的情况.没有两个开发团队是相同的,不同的事情适用于不同的人.

Scrum背后的主要思想是:

从需求到开发以及回到利益相关者,有一个紧密的反馈循环.

这允许开发团队不断验证他们正在构建实际需要的东西,并允许在需求和期望发生变化时轻松调整开发.利益相关者可以随时添加或删除功能,他们可以根据需求的变化调整功能的优先级.

保持软件处于任何给定sprint结束时可释放的状态.

这并不是说你已经发布了每个sprint,但是如果客户决定他们想拥有最新的东西你就可以.这也有助于开发团队避免集成地狱的情况,这种情况来自于人们在一个时间内独立工作几个月的项目.

对开发过程中的内容完全透明,每个人都需要愿意做出权衡.

这是大多数项目失败的地方,如果每个人都购买进程,Scrum可以真正成功.因此,许多开发项目都设置为发布必须在Y日期发布X功能,并且没有灵活性来更改它.这导致了半完成的功能和错误的软件,因为开发人员填写了他们的清单中的所有必需功能.

实际情况是,软件开发中出现意想不到的事情.通过Scrum流程中的开放式沟通和自愿参与者,客户和开发人员可以持续评估项目的当前状态,并做出有关项目剩余工作优先级的明智决策.