16

我的公司最近开始使用 Scrum；我们已经完成了 2 次冲刺。我们仍在学习，但我们肯定已经暴露并修复了我们开发过程中的一些问题。所以总的来说，我认为这对我们有好处。

在阅读了许多来自布道者、愤世嫉俗者和介于两者之间的人的关于 Scrum 的互联网思考时，三个常见但有些矛盾的主题对我来说很突出：

  1. Scrum 实施失败的原因是 Scrum 的流程没有得到足够密切的关注。
  2. Scrum 实施失败是因为组织没有使 Scrum 适应自己的环境/文化/实践。
  3. Scrum 的过程并不重要；只有敏捷宣言中的价值观很重要。

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

我不得不承认，我们还没有遵循 Scrum 的所有指导方针：我们还没有在 sprint 结束时发布，我们的 Scrum Master 不希望我们在接近结束时将任务从 sprint backlog 中移出冲刺，以便他可以看到我们的计划偏离了多少（这意味着燃尽图永远不会变为 0），并且紧急的客户支持问题仍然具有破坏每个人计划的不可思议的力量，举几个例子。

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

4

8 回答 8

10

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

你总是会遇到阻碍表演的问题，但你可以通过缩短冲刺长度来解决这个问题。客户可能无法等待一个月，但他们可能会等待 2 周来处理某些事情。那么，较短的 sprint 长度可能会帮助您将一些请求推迟到下一个 sprint，从而减少它们的破坏性。您还需要提前告知客户，中断实际上正在导致您的步伐受到影响。如果他们知道他们选择的功能被某些请求延迟，他们可能会自愿选择等待。

我要提出的另一个观察结果是，与几乎任何事情一样，最好在学习时尽可能地遵循该模式。一旦你很好地掌握了基本原则，你就可以更清楚地看到一些原则可以在哪里弯曲、破坏或替换，以改进流程。在你真正明白之前，你改变的东西可能会伤害或帮助——你真的不知道，因为你没有经验告诉你事情应该如何运作。除非您的 Scrum master 真的很有经验，否则您可能希望更接近已定义的实践，直到您获得更多的 sprint。

于 2009-01-05T16:04:45.110 回答
5

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

Scrum 背后的主要思想是：

从需求到开发再回到利益相关者，有一个紧密的反馈循环。

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

将软件保持在可以在任何给定 sprint 结束时发布的状态。

这并不是说您在每个 sprint 中都发布了版本，而是说如果客户决定他们想要拥有最新的东西，您就可以发布。这也有助于开发团队避免由于人们一次次地在一个项目上工作几个月而孤立地工作而导致的集成地狱的情况。

对开发中发生的事情完全透明，每个人都需要愿意做出权衡。

这是大多数项目失败的地方，如果每个人都参与其中，Scrum 才能真正成功。如此多的开发项目被设置为一个版本必须在 Y 日期发布 X 功能，并且无法灵活地更改它。这导致了半成品的功能和漏洞百出的软件，因为开发人员在他们的清单上争先恐后地获取所有必需的功能。

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

于 2009-01-05T16:35:22.117 回答
2

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

我建议在您的业务环境允许的范围内尽可能多地采用教科书 Scrum，看看效果如何，然后对其进行调整。

为什么您的 Scrum master 不想将任务移出 sprint backlog？他不是 100% 接受 Scrum 的原则吗？（我认为这在 Scrum master 中令人担忧）

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

于 2009-01-05T16:07:12.173 回答
1

每个公司都不一样，每个项目都不一样，每个客户都不一样。

我认为在不适合该方法论的环境中过于密切地遵循 scrum（或任何其他方法论）很容易失败，因为在一个适合的项目中过于松散地遵循 scrum 也会失败。

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

于 2009-01-05T16:05:54.657 回答
1

答：您需要同时采用 Scrum 和 XP 才能获得 Scrum 的全部好处。

原因：

原因是基于多年从事 XP 和 scrum 的工作，特别是我从 Jeff Sutherland 的演讲中学到的东西（2009 年 5 月在伦敦的 ACCU）

  • Scrum 是一种管理技术——不一定是软件生产方法。有些人在其他领域使用 scrum，例如准备博物馆展览和经营宗教机构……因此它具有您需要的机制，可以让一个多学科团队以小增量适应性地交付工作。
  • Scrum，最初包含了所有极限编程实践。Jeff Sutherland 实际上说，他从未见过一个 scrum 项目在不使用极端编程实践的情况下实现了对 scrum 衡量的更高级别的生产力。
  • Scrum 和 XP 都来自相同的背景——面向对象的编程，特别是 Smalltalk。程序员开始开发 XP，而管理人员则创建了 scrum。您需要这两个方面 - 开发实践和管理实践。
  • XP 实践被有意从 Scrum 中删除，以使其更易于采用。- 实施 XP 实践很困难，而且很难让它们快速采用。Jeff 实际上说 Ken Schwaber 删除了 XP 实践以帮助人们开始使用 scrum。现在的危险是，这种最小的 scrum 已经成为人们所看到和期望的一切。
  • 许多非技术项目经理现在教 Scrum - 但他们没有教授 XP 的技能
  • 并非所有开发人员都认为 XP 实践很容易采用——它们可能很难推销，而且需要几个月而不是 2 天的时间来建立基本的 scrum。
于 2009-10-31T13:16:39.713 回答
1

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

  • Scrum的优势在于它不会因规定大量不必要或不相关的技术工作而妨碍工作。
  • Scrum的弱点是它没有告诉你应该做哪些好的技术实践。

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

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

于 2010-01-17T23:09:19.550 回答
0

Scrum 并不是你所展示的真正问题。大多数开发方法都有效，即使是我们喜欢抨击它的瀑布，也有效。Scrum 确实让你更专注于重要的事情，但它不会阻止人们做出错误的决定，比如不真正遵循流程。

该系统的核心非常简单。

看到问题。定义做了什么。创建一系列可以帮助您完成的任务。估计这些任务。从中选择足够多的内容，以便您可以在短时间内完成某件事。完成任务。冲洗并重复。

好的，诚然，这些步骤被简化了，而且我还没有加入 scrum master 和客户。但关键是该框架只是一个基本的时间管理策略。如果您系统中的人员混乱且不善于完成工作，那么 Scrum 真的帮不了他们。

于 2009-01-05T16:15:40.923 回答
0

最好从书本上开始应用 Scrum，真正理解敏捷宣言的基本原则和价值观，然后再进行定制，这样过程才不会变性。确保在每次迭代（Sprint）结束时进行回顾，以“检查和调整”您的流程并消除浪费。

对于您的 Scrum Master，他可以跟踪从当前 Sprint 中删除的内容。此外，Sprint 的计划是基于之前的 Sprint 成就，而不是之前的计划。我不明白它的意思。

于 2009-01-05T16:29:28.697 回答