在讨论Scrum的全部内容时，我发现也许我完全误解了敏捷性。在我看来，Scrum（这当然被认为是敏捷过程）与管理功能，冲刺和角色以及与TDD，结对编程，CI，重构和其他以开发人员为中心的技术无关的东西无关。直到现在）都是敏捷的心脏。现在我面临一个困难！
1）Scrum不了解开发人员是否执行敏捷实践？
2）您可以在不使用自动化测试的团队中实施Scrum吗？是否不执行重构或不遵循敏捷编程实践？
是敏捷开发还是管理？
Answers:
认为Scrum等于敏捷是一个常见的错误。
敏捷遵循敏捷宣言的四个原则。Scrum是符合这些原则的项目管理流程，但它本身并不是敏捷的。XP（TDD，结对编程）是一个开发过程，也与那些原则一致，与Scrum一致，但并不是敏捷的。持续集成，持续交付，DevOps，均符合敏捷原则。
首先遵守原则。所有这些流行语只是人们已经成功地帮助他们遵循原则的方法。但是“成为敏捷”的主要部分是能够在不遵循敏捷原理的情况下随意调整您的流程。
3
agilemanifesto.org/principles.html详细说明了宣言。
@ ashy_32bit：在不了解团队和项目的情况下，任何人都无法回答这个问题。并非每个团队或项目都会从敏捷中受益。但是，我曾在一个团队中工作，该团队正在执行Scrum和CI，而没有其他事情（从敏捷技巧之列），并且在那种情况下它比什么都不做更好。但是随着时间的流逝，我们试图提高敏捷性。
—
pdr 2012年
+1谢谢pdr，这让我感到无比沮丧，因为每个人都说敏捷并意味着争夺，这最终掩盖了实际敏捷原则的好处，因为每个人都认为敏捷意味着日常的站立和冲刺，并且从不了解宣言。
—
Jimmy Hoffa 2012年
@ ashy_32bit我要说的是，Scrum Master将帮助团队在遵循良好流程的过程中变得更加严格和富有情感，但是经验丰富的XP教练将帮助团队在编写良好的代码方面变得更加严格和富有情感。根据您对团队的描述，我猜如果他们以前从未编写过任何测试，他们可以使用帮助编写更好的代码。在这种情况下，他们可能不会编写非常松散的代码或关注设计原理等。当然，假设您的假设团队也很糟糕。
—
Jimmy Hoffa 2012年
我是唯一不认为“敏捷”应该有大写字母的人吗？我不只是一个语法学徒-这很重要。将敏捷性视为一种素质：如果您的团队敏捷，则它是灵活，适应性强，有条理的。当他们谈论“敏捷”时，我总是会感到困惑，就好像这是他们必须遵循的标准模式或流程的名称一样。
—
蒂姆（Tim）
阿利斯泰尔科伯恩（敏捷运动的创始人之一）说，这个关于晶彩（他的敏捷开发方法的一个方面）：
可以使用以下单词向第3级侦听器描述Crystal Clear：
“将4-6人放置在一个配有工作站和白板并可以与用户接触的房间中。让他们每隔一两个月向用户交付运行中经过测试的软件，否则就别管它们了。”
这就是敏捷的定义，诚然，这是对经验丰富的开发人员的了解，他们知道自己在做什么，并且可以信任他们继续做下去。那么这是否意味着您必须使用CI和TDD以及结对编程以及所有其他流行的东西？简单地说...不。
敏捷不是要遵循一系列流程，而是要有效。对您而言意味着什么取决于您的团队及其运作方式，您认为对您有用的东西。如果TDD不能帮助您生成有效的代码，请停止收听那些在网络上大喊大叫并且不使用它的小灯！如果“配对编程”确实可以帮助您的团队集中精力并完成工作，那么请忽略任何浪费时间的人，并像在学校运动会上进行三腿比赛那样组织您的团队。
我很多年前就做过敏捷，所以很多时候我们甚至都没有意识到自己在做敏捷-我们每个月都会提供产品的迭代，并定期修正错误并定期添加新功能。我们进行了绝对零单元测试，因为还没有发明这种东西，也没有编写重构书。因此，是的，没有任何所谓的敏捷实践，您绝对可以进行敏捷。
Alistair也对肯特·贝克说：
当问及XP以及软件工程学院的“能力成熟度模型”的五个层次时，他回答了XP的三个成熟度：
做到一切如写。
完成之后，尝试更改规则。
最终，不管您是否正在使用XP。
最终，不要在乎是否正在使用XP ...明智的话应该提醒您不要陷入陷阱。
底部的陷阱很有趣，如此真实。谢谢你的笑声。另外+1我完全同意。不幸的是，这里规定的整个技术完全依赖于优秀的开发人员（或至少想要成为一名优秀的开发人员）。许多工程师对变坏就容易变得没兴趣。实际上，这可能适用于很多人，而不仅仅是工程师。
—
Jimmy Hoffa 2012年
是敏捷开发还是管理？
敏捷是一组软件开发实践，可以满足灵活性和快速变化的市场需求（或所谓的加速交付）。因此，从总体上看，这是一种灵活的方法，它可以通过以小规模的工作方式分割工作并在2-4周的快速迭代中交付功能来满足客户不断变化的复杂需求。
但是，为了获得这种灵活性，开发团队需要实践敏捷编程实践。
Wiki关于敏捷软件开发的描述：
敏捷软件开发是基于迭代和增量开发的一组软件开发方法，其中需求和解决方案通过自组织，跨职能团队之间的协作来发展。它提倡自适应规划，渐进式开发和交付，一种有时间限制的迭代方法，并鼓励对变化做出快速而灵活的响应。它是一个概念框架，可在整个开发周期中促进可预见的交互。
1）不!!!! Scrum是敏捷的，这意味着敏捷开发实践（TDD，结对编程，CI，重构等）对于Scrum项目的各个方面都非常重要。如果您不使用这些方法，那么弄清您的团队的运转率，估算工作量，设置合适的冲刺大小等将变得更加困难。
2）是的，您可以在不遵循敏捷实践的团队中实施Scrum，但我认为这确实限制了团队的潜力。Scrum / Agile之所以如此成功，很大一部分原因是您从敏捷开发实践中获得的性能和质量提升，这些实践是为每个sprint提供前后完整功能的核心。
如果您小组中的其他人试图说服您敏捷开发实践是浪费时间，那么我认为您应该花一些时间来强调为什么Scrum以及整个敏捷总是对这些实践施加压力。他们确实的确有所作为。
请不要使用诸如“ Scrum / Agile”之类的术语，这些术语与可互换的术语相距甚远，我想您知道这一点，但是当您以这种方式使用它们时，您仍将其永久存在。
—
Jimmy Hoffa 2012年
Scrum敏捷。小写字母“ a”。敏捷是一个形容词，而不是事物的名称。除此之外，我认为这个答案是有道理的。
—
蒂姆（Tim）
@Tim agile这个词是一个形容词，但在这种情况下，敏捷指的是agilemanifesto.org中定义的“敏捷软件开发”标题，因此它不是形容词，而是名词。这是我对人们将Scrum称为敏捷的抱怨，人们认为“ Scrum是敏捷的”，然后再也没有了解敏捷宣言，这就是整个“敏捷”流行语的起源，以及“敏捷”的真正定义。 。形容词将事物称为敏捷是模棱两可的，宣言不是模棱两可的，这是原则性和特定性的。
—
Jimmy Hoffa 2012年