当软件开发人员听到“新的JavaScript框架”或“新的IDE”的消息时，他不需要进一步询问这是什么意思。但如果他听说了“新的敏捷框架”，他可能会像荷马·辛普森(Homer Simpson)一样点头，同时表现得好像他知道这是什么，但他心里只有一个问题:“敏捷框架”到底是什么意思?
在目前的软件开发环境中，“敏捷”、“scrum”和“看板”等词被频繁的错误使用。在这篇文章中，我们将尝试定义和解释其中的一些名词。
敏捷
在讨论工作流程时，如果你想从人群中脱颖而出，那么在每句话中都要使用“敏捷”这个词。这是一个非常漂亮的形容词或副词:“思考敏捷”、“敏捷方法”或“根据敏捷原则”。它的范围相当广，不需要你对所讨论的话题了解太多。但是“敏捷”到底是什么意思呢?
“敏捷软件开发”是一种遵循敏捷原则的开发方法。然而，“敏捷原则”到底是什么?看看作为敏捷开发框架的敏捷宣言和12条敏捷原则。宣言引用
人员和交互，而不是程序和工具
功能软件以上详细文档
客户参与合同谈判
适应变化vs坚持计划
敏捷原则促进频繁有效的软件交付、密切的团队沟通，以及对不断变化的需求的高度灵活性。如果你在日常操作中坚持这些理念，你就可以宣称你在敏捷环境中工作。因此，敏捷软件开发本质上是几种方法、框架和技术的集合，它们遵循相同的概念，而不是特定的方法。
敏捷可以被认为是一种思考和选择的方式。
用于思考和选择的框架称为 敏捷。
但为什么在我们的工作中坚持这些理念如此重要？
对多年来针对软件开发困难而开发的最佳答案的追求，导致了《宣言》及其指导原则的创建。来自世界各地的不同团队和开发人员在20世纪70年代、80年代和90年代尝试了工作流程和解决问题的策略，创造了新的框架和方法(如scrum和极限编程)，甚至同时得出了相同的结论。最后，在2001年2月，17名开发者聚在一起，发现了所有这些不同的想法和体验的共同元素。宣言就是如此创建的。
敏捷宣言是随着时间的推移出现的一些见解和可行的解决方案的结果。
SCRUM
如果你不理解什么是“敏捷”方法，你就有可能随口说出“Scrum和其他敏捷方法”之类的话，这会让你在了解这个话题的人面前显得很愚笨。
在《权力的游戏》中，尽管scrum被称为一种方法论的次数更常见于死亡次数，但它并不是一种方法论。Scrum不会为你提供在你遇到的每种情况下应该采取的具体步骤，也不会为你提供所有问题的答案。大多数scrum实现同样不准确:团队没有获得价值，这可能是错误理解的结果。下面的结论可能是关于scrum最荒谬的说法:“scrum不起作用。”
你如何进行scrum?根据Scrum指南，Scrum是:
“一个框架，使人们能够应对复杂的适应性挑战，同时通过生产力和创造力生产高价值产品。”
它是一个框架，与任何框架一样，它可能会被不正确且频繁地使用。除了采用 Scrum 制定的框架外，有效使用 Scrum 还需要整个团队对敏捷原则有透彻的理解和尊重。
Scrum 中的角色包括产品负责人、Scrum Master 和开发团队。
计划会议、Daily Scrum, Sprint Review 和 Sprint Retrospective 是更多的 Scrum 仪式。
此外，还有三个工件：产品增量、冲刺待办事项和产品待办事项。
冲刺是 Scrum 项目划分的重复时间段。通常，它们会持续两周。
项目的方向由 产品所有者。产品负责人在决定后将新任务和功能添加到产品待办事项列表中。开发团队从待办事项中选择要处理的任务，并在 sprint 之前的计划会议上决定如何实施它们。下一步是开发，在此期间开发团队使用积压工作来监控进度，并每天召开会议来协调任务并进行任何计划调整。产品增量——可以添加到产品中并立即可用的东西——应该是开发的最终结果。产品增量在冲刺结束时的冲刺评审中呈现给产品所有者，如果需要更多更改，则在补充产品积压工作时。然后整个团队聚集在一起进行 sprint 事后分析，讨论工作流程和任何改进。
Scrum 易于学习和理解，但采用起来具有挑战性。由于各种原因，这个框架可能适合也可能不适合项目。它经常需要在日常发展和文化方面进行重大改变。 Scrum 在创建需要各种专家且经久耐用的复杂产品时效果很好。
为什么 Scrum 如此受欢迎，与传统的瀑布模型相比，它有哪些优势？简单地说，因为它为产品及其客户提供了更大的价值。有很多关于像瀑布这样的“重量级”方法论的恐怖故事，几个月来没有看到任何项目。这对于 Scrum 是不可行的。
Scrum 的核心是为最终用户提供价值。如果你想真正从 Scrum 中受益，你必须在每个 sprint 中创造一些有价值的东西。价值是可以量化的，团队不得不审视障碍并做出调整，以便在接下来的迭代中产生更多的价值。
在大多数软件开发项目中，我们并不是在建造摩天大楼，因此我们不需要在开始之前就准备好完整的计划并始终坚持下去。我们正在创建软件，我们可以灵活地随着环境的变化进行调整，并在创建产品时更改产品的规格。重要的开发人员曾经将此视为第八大罪，但从产品的角度来看，它在提高可预测性和降低风险方面具有许多优势。 Scrum 在创建时就考虑到了这一技能，并且在使用时，它提供了一种可靠且有效的方法来处理必要的更改。
规划扑克、结对编程、测试驱动开发 (TDD)、行为驱动开发 (BDD) 和其他方法与 scrum 结合使用。它们是比 scrum 的实际组件更兼容的实践。看板是一种经常与 scrum 结合使用的方法，但是，对于这两个概念彼此之间的含义存在很多误解。
看板
哪个更好，scrum 还是看板？当你讨论 Scrum 和看板时，这是听众经常问到的问题。因为这相当于比较苹果和橘子，或者问“煎饼和啤酒哪个更好”，你不知道如何回答。两者都优越。
一种称为看板的直截了当的方法旨在实现及时交付，而不会使团队成员负担过重。尽管它比 scrum 灵活得多，但它与 scrum 的相似之处在于最终目标是尽可能提供最大的价值。
软件开发者社区并没有创建看板。它实际上起源于丰田制造程序，并广泛用于其他领域。看板是一组概念和实践，你可以从中选择以满足你的需求；在实施或使用它时，你没有必须遵守的严格规则。但是，软件开发中最流行的看板之一是使用带有用于任务和工作阶段列表的看板。
开发过程中任务的状态由列表示。三列，标记为“待办事项”、“进行中”和“完成”，构成了最基本的示例。结果，项目被放入“待办事项”列表，在开发开始时移动到“进行中”列，然后在转移到最后一列时被视为“完成”。当然，它可能更复杂：
积压>定义规范>准备开发>开发>代码审查>测试>部署>（没有人真正使用它>完全删除）
每一列可能有一个子列；例如，“发展”栏可以分为“规划”和“编码”栏； “测试”栏可分为“单元测试”和“集成测试”栏；等等。如果合适，专家可能有自己的专栏。根据其要求，团队定义列和阶段。根据“拉”的想法，只有在迫切需要时才应将作业添加到工作流中。
该板的目标是说明该过程，这是第一个重要的看板活动。看板实际上可以在没有任何板的情况下使用！它可能是 Google 工作表上的简单任务列表，每个作业的状态由不同的背景颜色指示，也可能是甘特图、图表或表格。它甚至可能采用办公室里的水桶的形式，用球作为家务，每个水桶代表任务的条件。简单地可视化工作流程并使整个过程透明化。
减少工作的批量大小是另一个关键思想。这只是表明你不应该多任务处理。这可能需要你同时处理的项目更少。如果团队中有 3 名设计师，则团队可以决定将“设计”列中的工作数量限制为三个。
团队被认为是看板过程中最关键的组成部分，就像在 scrum 中一样。但与 scrum 不同的是，它没有规定角色，因此如果你不想更改当前程序，可以坚持使用已有的角色。持续改进也是如此：与 Scrum 的 Sprint Retrospective 不同，它规定了单个事件，特别是对于那个过程，看板通常会推动你不断学习和改进。
我应该用什么？
看板和 Scrum 实际上没有可比性，也不是相互不兼容的。虽然看板说，“到底是什么，保持你当前的角色和职责，”Scrum 有明确定义的角色。看板允许你从当前流程开始，而 Scrum 则强制你修改工作方法。在 scrum 中，框架为事件指定了一个精确的时间表；在看板中，没有事件。然而，他们有很多共同的特点：他们拥有相同的价值观，将团队成员视为系统的“老板”，并且从根本上具有相同的目标：不断减少浪费和障碍。
但更有意义的是问“我应该在我的特定项目和我的特定团队中使用什么？” Scrum 可能比看板更难采用，因为看板不需要那么多的流程和文化变革。另一方面，Scrum 提供了更多的结构来指导流程，如果每个人都在同一页面上，则可以大大减少开销。
然而，两者的吸引力都在于它们都不是一套严格的指导方针。你可以自由挑选最适合你的 Scrum 组件，例如每日会议或审查。此外，没有理由不能将看板合并到 Scrum 中。
当整个团队都使用该框架时，Scrum 已被证明是非常有效的。但根据我们的经验，一些客户让我们在 Scrum 环境中工作变得很有挑战性。当需要进行流程和文化转变时（尤其是与认为自己正在创建下一个 Google 的人一起工作时！），可能很难正确部署 Scrum。另一方面，看板更具适应性，不会迫使人们做出改变。根据几位作者的说法，看板是实现敏捷性的好途径，并且使采用 scrum 变得更简单。其他人声称采用 scrum 最终应该会产生看板。
没有“一刀切”的方法，因为每项工作都是独一无二的。作为项目经理，你可以选择最适合你团队的功能。
请密切关注领类博客和社交媒体渠道以获取更新！
