Scrum：太多还是不够？

Question

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

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

1. Scrum实现失败，因为Scrum的过程没有得到足够的密切关注。
2. Scrum实施失败，因为组织不会将Scrum适​​应自己的环境/文化/实践。
3. Scrum的过程并不重要;只有敏捷宣言中的价值才重要。

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

• Have you had a bad experience with Scrum or Sprinting?
• Is Scrum evil?
• Is Agile Development Dead?

我必须承认我们还没有遵循Scrum的所有指导原则：我们没有在冲刺结束时发布，我们的Scrum Master不希望我们将任务移出sprint积压接近冲刺结束时，他可以看到我们的计划已经关闭了多少（这意味着燃尽图表永远不会变为0），紧急的客户支持问题仍然具有破坏每个人计划的难以置信的能力，仅举几个例子。

我的问题是：在尝试解决这些问题和其他问题时，尝试更接近官方Scrum流程更好，更接近我们的一些预Scrum流程，或者更好地冥想Scrum的原则，试图完全提出一个不同的过程？

Answer 1

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

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

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

Answer 2

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

Scrum背后的主要思想是：

从需求到开发以及回到利益相关方之间有一个紧密的反馈循环。

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

将软件保持在任何特定冲刺结束时可以释放的状态。

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

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

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

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

Answer 3

Scrum 工作。并非在所有情况下都适用于所有团队，但它已被证明有效。

我建议您尝试使用教科书Scrum，就像您的业务环境允许的那样，看看它是如何工作的，然后调整它。

为什么你的Scrum主管不希望将任务移出sprint backlog？他不是100％接受Scrum的原则吗？ （我会认为这在Scrum主人中令人担忧）

实施Scrum的大多数问题实际上只是Scrum流程暴露的团队或业务中的问题，例如 - 如果您的冲刺被无法预料的支持问题抛弃，这表明您没有分配足够的资源来支持

Answer 4

每家公司都不同，每个项目都不同，每个客户都不同。

我认为，在一个不符合方法的环境中过于严密地遵循scrum（或任何其他方法），因为你在一个合适的项目中过于宽松地遵循scrum，因此很容易失败。

最后，QA网站中的一些通用答案无法取代对您自己的项目，公司，团队和客户的认真分析 - 没有神奇的公式，您必须自己做出决定。

Answer 5

答案：你需要同时采用Scrum和XP来获得scrum的全部好处。

<强>理由：

原因是基于多年的XP和Scrum，特别是我从Jeff Sutherland的演讲中获得的知识（2009年5月在伦敦的ACCU）

• Scrum是一种管理技术 - 不一定是软件生产方法。有些人在其他域中使用scrum，例如准备博物馆展览和运行宗教机构......所以它有你需要的机制，让一个多学科团队以小幅度的方式适应工作。
• Scrum，最初包括所有极端编程实践。 Jeff Sutherland实际上说过，他从未见过scrum项目在不使用极限编程实践的情况下实现了scrum测量的更高生产率订单。
• Scrum和XP都来自相同的背景 - 面向对象的编程，特别是Smalltalk。当管理人员创建scrum时，程序员开始开发XP。您需要两个方面 - 开发实践和管理实践。
• 故意从Scrum中删除XP实践，以便更容易采用。 - 实施XP实践很难，并且很难快速采用它们。 Jeff实际上说Ken Schwaber删除了XP实践以帮助人们开始使用scrum。现在的危险在于，这种最小的混乱已成为人们所看到和期待的一切。
• 很多非技术项目经理现在教scrum - 但他们没有教授XP的技能
• 并非所有开发人员都认为XP实践易于采用 - 它们可能难以销售，而且需要几个月而不是建立基本Scrum所需的2天。

Answer 6

Scrum不会尝试解决软件开发中的技术问题。这只是一个小管理过程。

• 通过开出大量不必要或不相关的技术工作，<强> scrum的强大之处在于它不会妨碍。
• scrum的弱点是它没有告诉你要做什么好的技术实践。

极限编程确实解决了软件开发中涉及的技术问题，它非常适合scrum。 Scrum人员没有强迫每个人都去做XP技术实践的原因是实施这些技术实践大约需要6个月，而不是实施最基本的scrum需要2天。

scrum是否是“邪恶的” - 它肯定存在缺陷。 我们在2009年伦敦XP Days上详细讨论了XP和Scrum之间的不安关系： http://xpday-london.editme.com/WhereHasXpGone

Answer 7

Scrum并不是你所展示的问题。大多数开发方法都可以工作，甚至是瀑布，就像我们喜欢抨击它一样，有效。 Scrum确实让你更专注于重要的事情，但它不会阻止人们做出错误的决定，就像没有真正遵循这个过程一样。

该系统的核心非常简单。

查看问题。 定义完成的内容。 创建一系列可以帮助您完成任务的任务。 估计这些任务。 选择足够的，以便您可以在短时间内完成任务。 完成任务。 冲洗并重复。

可以肯定的是，这些步骤已经简化，我没有投入scrum master和客户。但重点是框架只是一个基本的时间管理策略。如果系统中的人员混乱而且不善于完成任务，那么scrum确实无法帮助他们。

Answer 8

最好在本书中开始应用Scrum，并在自定义之前真正理解Agile manifesto中的基本原则和值，以便该过程不会变性。确保在每次迭代（Sprint）结束时运行retrospectives以“检查并调整”您的流程并消除浪费。

对于您的Scrum Master，他可以跟踪从当前Sprint中删除的内容。此外，Sprint是根据之前的Sprints成就计划的，而不是之前计划的。我不明白这一点。