Scrum：太多还是不够？ [关闭]答案

【问题标题】：Scrum: too much or not enough? [closed]Scrum：太多还是不够？ [关闭]
【发布时间】：2009-01-05 15:55:59
【问题描述】：

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

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

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

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

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

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

【问题讨论】：

Scrum 的一个主要问题是：客户。许多客户认为 Scrum 是一种“糟糕”且不安全的工作方式。
只完成了几个 sprint，我很想不要尝试过多地阅读结果，因为在第一次尝试时并非一切都很好。
我投票结束这个问题，因为它不是关于编程的。

标签： project-management process agile scrum

【解决方案1】：

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

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

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

【讨论】：

+1：专注于敏捷；遗留流程几乎总是障碍。
我试图在我的问题中不暴露我的偏见，但我同意你的观点：D 我希望能提出一些改进建议，我可以向 Scrum Master 和 Scrum 中的矛盾提出改进意见我读过的评论让我对自己的观点缺乏信心。
需要注意的一点是，发布通常并不一定意味着更新生产，只是拥有符合生产发布条件的东西，迫使您定期拥有“生产就绪”代码。
不实际发布给客户会剥夺您宝贵的反馈。我至少想定期向一些测试版客户发布。一旦应用变得稳定，发布到生产环境就变得越来越可取。

【解决方案2】：

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

Scrum 背后的主要思想是：

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

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

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

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

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

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

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

【讨论】：

【解决方案3】：

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

我建议在您的业务环境允许的范围内尽量采用教科书 Scrum，看看效果如何，然后调整它。

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

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

【讨论】：

+1：不要通过调整 Scrum 使其看起来更像您的遗留流程来“优化”Scrum。如果您的遗留流程非常好，为什么不继续使用它们呢？如果它们不好，请丢弃它们并从头开始重建。
不确定是不是不接受或不理解这些原则；我认为他最喜欢生产力数据和统计数据。他来自 PM 角色。我想推动更多的 Scrum 原则，但我不够自信，而且 Scrum 点燃的矛盾也无济于事。
@carolclarinet：不要被“Scrum 中的矛盾点燃”所迷惑，其中大部分来自那些做了他们称之为 Scrum 但根本没有敏捷特性的人。 “Scrum，误用”是 James Shore 所说的。没有矛盾，只是人们在敏捷方面做得不好。

【解决方案4】：

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

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

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

【讨论】：

我知道这是一个很难回答的问题。我想我是典型的 CS 类型，希望在灰色区域中获得黑白答案；）谢谢您的帮助。

【解决方案5】：

回答：您需要同时采用 Scrum 和 XP，才能充分利用 Scrum。

原因：

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

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

【讨论】：

【解决方案6】：

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

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

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

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

【讨论】：

【解决方案7】：

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

系统的核心非常简单。

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

好的，诚然，这些步骤已经简化，而且我还没有加入 Scrum Master 和客户。但关键是该框架只是一个基本的时间管理策略。如果你的系统中的人是混乱的并且不擅长完成事情，那么 Scrum 真的不会帮助他们。

【讨论】：

【解决方案8】：

最好从书本上开始应用 Scrum，真正了解 Agile manifesto 的基本原理和价值观，然后再进行定制，以免过程变性。请务必在每次迭代（Sprint）结束时运行retrospectives，以“检查和调整”您的流程并消除浪费。

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

【讨论】：

我也不太明白；我试图说服他这不是一件好事。他似乎真的很喜欢燃尽图的数据和统计数据，包括有多少计划失误。一旦他完成了他的分析，我们就会将未完成的任务转移到下一个 sprint。