任何试图应用Scrum的故事都出错了？

Question

问题被标记为社区维基，原因很明显。

我的同事们对Scrum非常重视，他们对此非常兴奋。 但是，在进行日常编程时，优先考虑的事情往往是“完成”，“尝试在第一时间做好”。当然，上市时间很重要，但随后不得不雇用大量的技术支持并且积压了大量旧的但仍然存在严重错误，这听起来也不合适。

我担心，通过Scrum，我们将开始关注表单，真正了解它的用途以及如何更智能地工作。

所以，我想知道 - 那里有着名的Scrum闻到了吗？您是否一直在使用Scrum方法并注意到他们没有多少帮助或创建了不同类型的问题？我相信，如果你在工作的某些事情上承认某种失败，那将是胆量。也许它发生在过去，或者朋友的朋友在酒吧里讲过一次故事......

如果您对此问题有疑问，请与我们联系。感谢。

Answer 1

我曾在一家公司工作，该公司试图将Scrum引入一个大部分定制的软件服装，仍然使用传统的工时估算（几个月）等等。那里的教训很清楚：你的团队的速度应该推动成本估算，而不是相反。这在一段时间内特别具有破坏性，因为基本上交付日期从一开始就没有与开发团队协商确定，因此团队的平均速度是预先确定的。结果，我们最终加工了大量的加班费，只留下了用于进一步规划的不具代表性的速度。

从该课程中学习，开发团队有机会参与项目的提案和定价阶段。这暴露了一个新的教训：如果你每周花费20多个小时来计划会议（即使在达到一个稳定的过程之后），你就会做错误的Scrum 。我们遇到的问题是我们的业务模式/客户关系仍然要求订单项目成本细分，严重详细要求等等。因此我们需要（作为一个团队）基本上分解，计划，并计算（通过计划扑克）项目开始时每个未来sprint项目的成本。这使得无法利用Scrum的一个固有特性：尽可能地执行即时规划（因为需求将会发生变化）。

我仍然不相信有一个可识别的Scrum变体可以很好地适用于这种商业模式，而现实是，作为一个开发团队，如果没有更高级别的购买，你将无法实施Scrum。我见过Scrum在我工作的其他地方取得了巨大的成功。我个人的建议是聘请一名顾问来评估Scrum是否（以及如何）为贵公司提供什么，以及它的外观。请记住，敏捷方法论是具有可塑性的，但是将它们弯曲得太远，你不太可能从中受益。

Answer 2

scrummerfall和scrumbut

尝试执行Scrum的团队的常见故障模式是scrummerfall和scrumbut。每个人都在说/正在思考你在做Scrum但是忽略了Scrum的重要方面或者没有丢弃瀑布的有害方面。

Answer 3

稻草人瀑布的变化成本不断上升。

Scrum假设一个低而稳定的变化成本，以便其速度和估算测量工作。但是，Scrum没有提供任何工具或实践来降低变更成本。

Scrum还假设一个团队能够信任和协作。这种做法鼓励这种做法，但如果文化不对，往往会分崩离析。这是我写的关于Cargo-Cult Agile价值观的博客文章：http://lizkeogh.com/2009/05/22/cargo-cults-and-agile-values/

我建议专注于协作和沟通，并运行XP中的一些实践。 TDD，重构，集体代码所有权和配对都很好。我见过很多Scrum / XP混合动力车的效果很好。

回顾展不太可能将缺乏技术实践作为有用的变化添加到流程中，因为没有它们的反馈循环是几个月的顺序 - 在冲刺中是不明显的。任何文化问题往往会使回顾会比现在更不安全，所以他们也不会被标记出来。

Answer 4

当我想到SCRUM时，我想起了“荷马”：

alt text http://www.fullsickbro.com/images/TheHomer.jpg

Answer 5

迈向Scrum Smells目录，来自Mike Cohn：

http://www.mountaingoatsoftware.com/system/article/file/11/ScrumSmells.pdf?1267552461

要想成功使用Scrum，您必须尊重其核心原则，而不是尝试应用其他所有方面。

我见过几十个开发团队试图进行scrum和失败，因为他们没有接受适当的培训。在最糟糕的情况下，他们失去了对管理层的信任。

聘请经验丰富的Scrum大师或教练将增加您成功的机会。

Answer 6

Martin Fowler最近发表了一篇有趣的话http://martinfowler.com/snips/201007151824.html。他提出的一点是，要敏捷，需要进行流程更改以及不同的技术实践。他指出，在没有相应的技术实践变更的情况下，公司在进行流程变更时未能做到敏捷。他指出，Scrum是人们在不改变技术实践的情况下进行的常见流程变革。