为什么我的团队需要SCRUM而不是非正式的，更轻量级的流程？

首先，我想知道我理解SCRUM或它的某些派生词可能是管理软件开发的好方法。似乎所有大公司和我的经理都在使用或曾经使用过它，而我不能以所有这些经验来争论。但是，我一直在努力理解“为什么”，所有阅读甚至我在工作中的SCRUM官方培训都对我没有帮助。只是说辞而已。所以我来这里寻求答案。

到现在为止，我已经由4-5名成员组成的团队非常有效地发展，完全是自组织的，不需要任何培训，方法论或特殊软件。只是在多维数据集中进行讨论，临时会议和一对一代码审查。我现在在工作中被告知SCRUM是必经之路，以及随之而来的一切。当他们向我描述SCRUM时，我读到了以下内容：

• 个人与流程和工具之间的互动
• 工作软件超过全面的文档
• 客户合作而非合同谈判
• 响应计划变更

很好，但是对我来说，所有这些似乎都是常识。为什么需要将其编纂？然后我被告知方法论可以帮助我们应对变化。具体什么SCRUM的各个方面使我变得如此灵活，以至于以前我无法通过临时会议，多维数据集讨论和开发人员计划会议来实现？他们解释了每两周或进行一次冲刺的工作成果的必要性。在我的特定项目中，没有“客户端”，该软件将无法使用一年或一年以上的时间，与此同时，我大概只会每个月或更短时间向高级管理层进行降级。那么，为什么每两周就需要交付产品呢？他们强调了Sprint计划会议的重要性，整个团队将为下一个Sprint安排故事和任务。这与我过去的即席计划会议没有什么不同。为什么每隔一个星期一就要发生一次 为什么要整个团队参与其中？我了解“拥有”该产品的每个成员的概念，但事实是，只有极少数人能够真正地将每个故事分解为任务，而其他人则只是闲着看。

再一次，我了解到大多数人都在此过程背后，因此它必须有效，我需要加入进来。我只想了解为什么。我的问题是我已经练习了这些东西，只是不喜欢不必要地编纂它们吗？也许我还没有看到这些技术的优势，因为它们做得不正确？与我惯于接受的尖锐做法相反，任何关于此的真实，个人信息或建议，将不胜感激。

我认为有两个方面可以回答您的问题，但首先让我祝贺您与似乎很聪明和能干的人员一起工作，他们能够在没有严格定义的流程的情况下进行很多工作，并且仍然可以交付产品。不幸的是，并非所有软件团队都遇到这种情况，因此Scrum的问题之一可能是您和您的同事实际上不需要倾倒您的流程来提高您的效率。您可能已经有效了。

其他团队则不需要，并且需要更严格定义的流程和一些准则来使他们完成任务。这并不意味着这些团队会变得更加愚蠢或缺乏能力，而只是意味着他们可能在自我组织或团队纪律方面存在问题。从人们通常独自工作的地方到团队合作的地方，这也可能是一种简单的学习体验。Scrum可以帮助实现目标，因为它提供了一些易于理解和遵循的准则，但又有效到足以给团队施加压力以使其开始实现。

由于Scrum并没有说明软件开发的方式，因此也使团队可以自由决定（例如，只要您在开发阶段完成，您仍然可以使用相当保守的瀑布方法进行冲刺）。冲刺结束）。

所以团队是一个问题。另一个问题是管理和管理信任。在这里，Scrum可能是好的，因为它是透明的，并允许任何利益相关者查看团队在定义的周期中所取得的进展。因此，这不是“我们正在取得进展，不幸的是我们现在无法向您显示任何内容，但是请相信我们，我们会按时完成”。这甚至可能是正确的，但对于任何经理来说，可以放心地定期进行演示，以确保他们确实看到了进展。

Scrum不是灵丹妙药。出于多种原因，它可能不适用于某些团队，也许对于某些团队，自组织不起作用。也许对您来说却是另一回事，这似乎是将一个流程倾倒在一个已经高效且有组织的团队中。

如有疑问，我会建议您尝试一下。如果它不起作用并且团队的大部分成员不喜欢那样工作，那就不要这样做。但是，请检查几个月（我说几个月，因为前几条sprint会很尴尬，并且您需要时间来调整细节），然后重新进行评估。

可能会引起争议，但是Scrum最好是减轻管理层对敏捷的恐惧，或者与已经表现不佳的团队一起使用。如果您的团队运转良好，实现目标，赚钱并感到幸福，那么Scrum不会为您买任何东西，因为它所做的只是破坏您所做活动的良好平衡（并使团队成功）。Scrum不是灵丹妙药。以我的经验，它只能帮助那些缺乏良好估计和沟通能力的团队。在有效沟通的环境中进行实际估算的团队只会受到Scrum流程开销的阻碍。

信不信由你，在Scrum出现之前，确实存在优秀的软件团队。Scrum帮助坏人变得更好。

尽管有点间接，但是这里的大多数答案已经列举了原因。当她谈到透明度时，安妮的答案特别有启发性。也就是说，允许经理查看正在发生的事情。当舒尔茨谈到人们无法掩盖他们懈怠的事实时，舒尔茨的回答也涉及到这一点。

所以我想说其他人已经在说些什么，但是要用一种更直接的语言：SCRUM的主要目标不是管理软件开发，SCRUM的主要目标是衡量软件开发。

其他系统之前已经尝试过，人们提出了无数的度量标准来尝试和评估软件开发，但是都失败了。SCRUM从根本上解决了问题，并将度量的负担从管理者转移到了开发人员本身。逻辑很简单：谁能比做自己的工作更好地估计需要花费多长时间？

现在，问题在于程序员过于乐观了。询问程序员做某件事需要多长时间，他通常会低估任务实际的难度。SCRUM提供了控制此的工具：

• 日常会议以评估进度并获得项目的总体视图
• 估算以“点”完成，而不是小时/天，以提取时间
• 燃尽图和折磨/野兔图以可视化点的速度
• 板上的故事和任务，以全面了解工作量
• 冲刺和迭代作为截止日期，以便我们可以衡量进度
• Scrum管理员，所有者和团队成员的特定角色，以避免作弊的诱惑

等等

您可能会注意到以上所有内容主要做两件事：

1. 他们衡量工作。要完成的工作，正在完成的工作或已经完成的工作。
2. 他们尽力避免过分乐观的程序员的问题，以获得更好，更实际的估计。

实施SCRUM的时间越长，估算值就越准确。实际上，我个人认为仅运行sprint +积压订单+燃尽图就足以治愈大多数程序员对做某事需要花费多长时间的错误估计。

我个人认为SCRUM的目的是满足那些高层管理人员无法或不会落后于精简流程的老组织。我在一个严重使用SCRUM的部门中担任建筑师（鸡）大约一年了。我以前的背景是硅谷的初创公司，其中大多数使用精简，临时和高度迭代（有时每周甚至每天推送）功能集中的流程。我发现SCRUM，至少我们在过程上实现它的方法是过大的（至少在某些方面比瀑布更重（至少从开发人员的角度来看）。公平地说，我将说我们过程的一个方面是所不同的是，我们的产品所有者实际上更类似于IT组织中的需求分析人员。结果，他们倾向于使来自企业的信息变得乏味，更糟的是，企业无法向开发团队负责（这需要定期连续注入用户故事）。但是，在我未来的创业公司中，我不会使用SCRUM。我可能只会在管理需要增加开销的情况下使用它。

我不会从纯粹主义者的角度讲。我觉得您能够以类似于Scrum所说的方式执行它。但是，最主要的是您可以运行节目。如果您休假一个月会怎样？

我将Scrum视为简化您所做的所有事情的机制，并在此基础上定义了一些方面。这样，在您不在的情况下，其他人也可以复制它，也可以将其复制到其他项目。但是，scrum不是灵丹妙药。我见过很多刚开始使用Scrum的人（因为它很流行），并且因为不了解它的本质而遭到殴打。

PS：Scrum并不要求您的冲刺必须为两周。可能长达一个月（根据您的情况）。

请先查看我对问题的评论。

SCRUM是一种敏捷的软件开发范例。因此，它本身就是敏捷的。它不假定您必须遵循其经典模型。我怀疑是否有人这样做。我曾经在多个组织工作过，每个团队都将其适应他们的需求。在发布某些公共产品/库/ API时，没有客户/消费者并不稀奇。我从来没有一个。在我的情况下，我们的总经理担任了一位，而国际海事组织就好像没有一位。

进行2周的冲刺很难。好辛苦 3周更好，但对于经验丰富且熟悉流程团队的人来说确实如此。我们有四个星期或一个月。这样一来，我们就可以有足够的时间“解决”，一开始就可以发言，而由于整个测试过程中更多，最终我们可以更有信心。我喜欢那个，我至少要坚持三个星期。

与我合作的另一个团队除了积压之外，什么都没有。他们会聚在一起，报告状态以及下一步的工作。完成所有操作后，他们将提出另一个待办事项列表。他们知道这不是SCRUM，但对他们有用，这很重要。

它更轻巧吗？肯定是。但这不是SCRUM。我喜欢SCRUM的地方在于它促进纪律。人们感到每天交付东西的压力。每个人都知道别人在做什么，而他失败了，每个人都会知道。即使试图掩盖这一事实（撒谎），也比其他过程要明显得多。因此，当您像该团队那样进行分散和简化时，您必须确保与合适的人一起做。否则，它可能很快就崩溃了，变成了毫无意义的地位会议，每个人都会呆在那里，然后想：“我在这里做什么？我知道我需要做什么，怎么办？”

那是我的两分钱。我像开发一样做自己的SCRUM：计划工作，拆分任务，估计任务，观察进度。这真的帮助我掌握了一切。我将SCRUM中的某些内容应用于我外包的项目，这对我来说非常有效。

只是...保持敏捷;-)

我建议您忽略scrum。几年后，一种新的时尚将会出现，您会变得不那么愤世嫉俗，仍然能够全心全意地拥抱它。实际上，您可以迅速成为专家。然后，您可以在上面写一本书并在会议上发言，从而赚很多钱。

由于很多事情都是周期性的，因此这种新时尚很可能是类似于RUP的繁重过程。您将看到的是，每个人都将遵循轻量级敏捷流程，而这些流程将因项目失败而受到指责。因此，当然，合理的解决方案是需要更多的前期计划和设计！

认真地说，我认为您不需要Scrum。Scrum中没有什么比其他竞争敏捷过程更好。它也有很多愚蠢的名字。

很好，但是对我来说，所有这些似乎都是常识。为什么需要将其编纂？

通常将Scrum与较旧的，重量级的方法进行比较。这些方法试图通过执行更多文档，更多签核以及更多的预先计划来使无反馈瀑布式工作。敏捷宣言（您在引用）是这些想法的逆转。

然后我被告知方法论可以帮助我们应对变化。SCRUM的哪些特定方面允许我变得如此灵活，以至于以前我的临时会议，多维数据集讨论和开发人员计划会议无法实现？

听起来您已经具有敏捷的结构。如果您已经对变化做出了很好的反应，那么您显然不需要帮助。某些过程变得与过程密不可分，以至于要修复错误需要进行全面的分析和功能设计阶段，并且最早要到明年才能进入项目。

他们解释了每两周或进行一次冲刺的工作成果的必要性。在我的特定项目中，没有“客户端”，该软件将无法使用一年或一年以上的时间，与此同时，我大概只会每个月或更短时间向高级管理层进行降级。那么，为什么每隔两周明确需要交付产品呢？

Original Scrum规定了一个月的冲刺。在缩短冲刺方面，敏捷大男子主义的趋势令人讨厌。（“是啊，我们的冲刺只是的一个一天......”）客户/客户是谁不得不说，该项目是好走，或需要更多的工作的权限。如果您每个月都向高级管理层进行降级，那么他们可能是您的客户，并且您可能已经非常接近Scrum。

根据您对团队工作的描述，Scrum可能并没有太大不同。您可能会从标准化中获得一些价值，因为如果您使用Scrum术语，则更容易向外界解释发生了什么。另外，Scrum可以用作屏蔽。例如，Scrum规定团队应该做出技术决策-指出这一原则可能是获得否则很难出售的技术价值的好方法（例如，Pair编程）。

Scrum基本上是您的团队可以实现的接口。如果您这样做了，那么您将对如何与团队外部的人进行交流有个好主意，而他们对如何与您进行交流也将有一个好主意。只有您知道您的团队是否需要这个。

我们不在工作中使用Scrum。我们使用在敏捷和精益中建立的方法，在许多方面都相似。我已经在包括领导在内的3-5人规模不等的团队中使用了此过程。尽管存在差异，但我认为您可能可以帮助您确定Scrum是否对您的情况有用。

使方法论变得合理

我们将流程明确化，因为我们会在每次sprint总结/审查中审查我们的流程。总结/审查的一部分是确定不适合我们的做法。我们还将讨论我们认为对我们有用的实践，如果有足够的共识，我们将尝试一下。不编纂我们的方法，我们将无法做到这一点。

登出

这是我们流程的主力军。这保证了我们写的是所需要的。当我们获得特定功能时，我们会去找客户。客户就是将要使用您的文字的任何人。在某些情况下，您必须用代表客户的人来代理客户（例如产品管理）。这些是我们的步骤，在完成最后一步之前，该功能尚未完成。

• 从开发板，跟踪器等获取功能。
• 在编写任何内容之前，先与客户交谈并了解他们的需求。
• 实施功能。
• 以最终形式向客户显示工作功能，并在功能完成后让客户签字。

垂直切片

我们在垂直方向上进行所有开发。这支持使用完成的功能以及其他原因进行签核的功能。

• 通过将集成问题与每个功能一起使用来分摊集成问题。帮助消除项目结束时的紧缩时间。
• 因为我们消除了很多交叉依赖关系，因此使我们能够轻松剪切出特征。
• 如果我们需要改变方向，可以使我们停止发展。
• 我们可以进行迭代发布，尽早为客户提供功能。

验收TDD

我们利用单元测试框架来接受tdd。这给了我们很多好处。

• 大型重组无需花费大量的测试返工时间。
• 我们向客户保证功能。
• 我们介绍了代码集成。
• 支持垂直切片开发实践。

构建始终是可发布的

每次推送后，代码应可释放。即使功能不完整，也不应损坏任何东西。所有测试都应该运行，并且所有以前的功能都应该存在。这实际上是我们垂直切片开发的扩展。因此，它具有许多相同的优点。

• 因为我们消除了很多交叉依赖关系，因此使我们能够轻松剪切出特征。
• 如果我们需要改变方向，可以使我们停止发展。
• 我们可以进行迭代发布，尽早为客户提供功能。

持续集成

每次推送都会通过我们的CI构建服务器生成一个构建。构建服务器签出代码，遍历整个测试套件，标记代码，并将其打包以进行部署。加强我们的政策，即构建始终是可发布的。

卡点估计

每个错误，功能和任务都变成“卡片”。卡是具有一定客户利益的最小逻辑工作单元。我们根据我们的规模指出这些。任何超过我们的最大积分值或进一步细分的积分。我们发现积分值越大，完成时的偏差就越大，因此将大牌进一步分解。如果卡具有足够的模糊度，则会将其四舍五入到比例尺中的下一个点值。必须先注销每张卡，然后才能将其视为完整卡。正确的估计支持我们计算速度的能力。

速度

我们有一周的冲刺。每个星期五我们都会进行工作计划，并确定下周的工作重点。根据我们的速度，我们对一周内可以完成多少“工作”有一个好主意。我们的速度是一周内完成的总积分的平均值和中位数。对标准偏差的增加进行分析，以进行错误的估计（总是试图使其变得更好）或增加中断（我与经理交谈）。速度也可以用于估计项目的准确完成日期，但前提是它是唯一正在处理的项目。

增量改进和设计

我们还有一个政策，使代码至少比您发现代码的状态更好。在卡的开头重构/重新设计代码。目标是考虑增量发展中普遍存在的有机增长。我们还按照常规在最后重构。

在大多数情况下，这些是我们遵循的规则以及我们为什么遵循它们。

在我看来，您就像是一个经验丰富，运作高效的团队。恭喜，Scrum / Agile基本上正在规范您的团队在这段时间内一直使用的东西。

我认为对您（整个）公司的好处可能是采用Scrum作为“共同点”，而不是在开发团队的成员之间，而是在开发团队和整个业务部门之间。

在设置Scrum Sprint时，团队可以在两个星期到一个月的建议之间进行选择。更少，并且会有太多的评论和回顾，并且任何更多的内容都可能会阻碍企业在一年内改变方向的能力。听起来您已经找到了1个月的最佳时机，所以请为此努力。

调整Scrum参数有很多余地，我相信您可以向您的企业说明​​您仍在以正确的方式进行Scrum。一个好处是，如果您中途参加业务，他们的参与可能会产生积极的支持。