[译]Agile、Scrum和 Kanban: 到底什么意思？

原文链接:Agile, Scrum, and Kanban: What the Heck Do These Words Really Mean?

原文作者:GORAN PRIJIC

来源于:https://www.toptal.com

Agile, Scrum, and Kanban: 到底都什么意思？

当一个软件开发人员听到一个新的JavaScript框架或新的IDE的消息，他可能不会问更多的问题来阐明它是关于什么的。但如果他听到一个新的敏捷框架，他可能会做的荷马辛普森式的点头，假装他知道它是什么，但他肯定会有一个问题：到底”敏捷框架”究竟是什么意思。
在现代软件的开发过程中，我们越来越多地听到关于”敏捷”和”看板”的争辩，而且它们往往使用不当。在这篇文章中，我将尝试解释和澄清一些相关的专业术语。

敏捷

如果你想成为同事中的白痴，你应该在谈论开发流程中大量地使用”敏捷”这个词汇。敏捷是一个很宽泛的概念，根据敏捷原则，我们可以想到很多的词汇，比如”敏捷思维”、”敏捷方法”等。但敏捷究竟是什么意思呢？

根据敏捷原则开发方法，”敏捷”指的是”敏捷软件开发”。但”敏捷原则”又是什么鬼？看一下敏捷宣言和敏捷12原则，它奠定了敏捷开发的基础。此宣言：

个人和相互作用高于过程和工具
可工作的软件高于负责的文档
客户协作高于合同和谈判
应对变化的能力高于遵循计划

敏捷原则鼓励持续交付软件功能、团队之间的紧密沟通和应对需求变更的能力。如果你在工作中遵循这些价值观和原则，那么恭喜你在一个敏捷的团队中工作。因此，敏捷软件开发不是一种方法，它是一套遵循相同的原则的不同的方法、框架和技术。可以说，”敏捷”是一个思考和决策的框架。

敏捷是一个思考和决策的框架。

但是为什么在工作中遵循这些原则特别重要呢？

敏捷宣言和原则是软件开发行业历经几十年来不断试错、不多总结出来的最佳的解决方案。在上世纪70到90年代，世界各地不同的开发者和团队一直在尝试不同的工作方法和解决问题的方法论，从而创造了不同的框架和技术（如Scrum和极限编程）。最后，在2001年2月，17个开发者聚集在一起，总结出了在各种各样的工作方法和经验中的共通点。这样，敏捷宣言诞生了。

敏捷宣言是几十年来开发者不断总结的经验和实际解决方案的结晶。

Scrum

如果在不了解敏捷方法的前提下和了解Scrum以及其他敏捷方法的人谈论敏捷方法论的人讨论敏捷方法，你有可能被打脸。

Scrum并不是一种方法论，虽然我们认为Scrum是一种方法论的次数可能比《权力的游戏》的被杀人数还多。Scrum不会回答每一个问题，它不会为你面对的各种情况提供清晰的结果。可能是由于这种不正确的解释，大多数Scrum实施也错了：团队没有从中获取到价值。这样的结果也对Scrum做了不客观的声明：”Scrum并不好用。”

什么是Scrum？Scrum团队这样介绍:

创造性地帮助有价值的产品解决复杂的适应性问题的框架。

所以名义上来讲，Scrum是一个框架。然而通常地，Scrum经常被错误的使用。在实际使用Scrum时，不仅仅要求采用Scrum的结构，还需要整个团队对敏捷原则有着深入的理解才行。

Scrum由三个角色组成:产品所有者、Scrum负责人和开发团队。四个形式:计划会议、每日Scrum、短期评审和总结回顾。三个任务:产品需求列表、需求迭代列表和可工作软件增量。它被组织成有规律的可以称之为开发迭代的框架。迭代周期一般在1-4周。

产品拥有者，负责指导项目的方向。随着新的任务和需求的确定，产品拥有者增加产品需求列表。每次迭代从一个计划会议开始，开发团队从产品的需求中挑选任务，并计划如何实施。其次是开发，在这期间开发团队使用需求迭代列表跟踪进度，满足为每日Scrum的同步活动和适应原定的计划。开发的目标应可以达到可工作软件增量，如果部分可以达到产品的增长那么即可尽早打包上线。在迭代结束时，将在短期评审时将产品的增长展现给产品拥有者，如果需要的话，也要调整原有的需求列表。再之后，整个团队需要参加一次总结回顾会（类似于酒吧会议），商讨现有的工作流程及是否可以得到改进。

虽然总体来讲上面这些就可以解释Scrum，但是如果你想要知道有关Scrum究竟如何工作的，看看我写的这篇文章。

Scrum很容易学习和理解，但很难被采用。有很多原因，这个框架可能不会很好的适合一个项目。它往往需要大量的变化，不仅在日常的发展，而且在文化上。经过很长时间的总结的前提下，很多专家认为Scrum最适合复杂产品的开发。

为什么Scrum这么受欢迎，为什么它比传统的瀑布模型更有优势？简单地说，因为它为产品和用户提供了更高的价值。与“重量级”的方法论相比（如瀑布模型），恐怖的地方比比皆是，

Scrum关心交付给最终用户的价值。如果你真的使用Scrum，你需要在每次评审提供一些有价值的东西。并且价值可以被测量，并且团队也可以审视自己和加以适应，以为下一次迭代的目标贡献更多的价值。

在大多数软件开发中，我们不是在建造一座摩天大楼；我们也无需开始之前就做好全部的、并且坚持到最后的计划。我们正在开发软件，我们有能力适应不同的情况，并在开发过程中改变产品的需求。很长一段时间以来，许多开发者认为这是致命的罪恶，但从产品的角度来看，这是对优化的可预测性和风险控制非常有益的。Scrum正是围绕着这个点，提供了一个可靠的和有效的方式处理需求变更
许多技术试图通过Scrum来配合使用，比如结对编程、测试驱动开发(TDD)、行为驱动开发(BDD)及其它。虽然它们并不是Scrum的一部分，但是它们与Scrum是相互兼容的。在Scrum中经常被提及的是Kanban，对与Scrum和Kanban的关系困惑大多数人们。

Kanban(看板)
当你谈论Scrum和Kanban时，大家常问的问题是：”哪个更好，Scrum还是Kanban？“，你不知道该怎么回答，因为这就像比较苹果和桔子，或者问：”煎饼还是啤酒，哪一个更好？”，两者都是更好的。

看板是指能够及时交付成果并且使得团队成员不会高负载的简单方法。它的目标是在迭代终期提供最大的价值，与Scrum的目标很相似，但是它比Scrum灵活得多。

Kanban不是由软件开发社区发明的。事实上，它有它起源在丰田，并且在其他领域有广泛的使用。在使用Kanban时，没有严格的程序和方式。相反地，它有一套原则和做法，你可以选择这些做法以适应你的需要。在软件开发中使用Kanban时，通常包含代表工作的阶段和任务。

列代表在开发过程中的任务的状态。最简单的例子包括三列：“To Do”、“In Progress”和“Done”，所以，任务被添加到“To Do”，当开发开始时移动到“In Progress”，开发完毕后移动到”Done”。当然，它可能更复杂：

需求列表 → 定义规范 → 准备开发 → 开发 → 代码审查 → 测试 → 部署

每一列都有子列。例如，”开发”可以分为”技术评审”和”编码”；”测试”可以分为”单元测试”和”集成测试”等。团队根据需要定义了列和阶段。

在Kanban中，思考工作流的目标是第一要务，事实上，Kanban可以做到不需要做任务列！它可以通过不同的背景颜色表示任务状态，可以是甘特图，图，表等，甚至可以在你的办公室里，用一套水桶来表示代表任务的状态，使用球代表任务。只需通过可视化的工作流和过程为整个开发过程提供透明度。

另一个重要的原则是减少每次任务的大小。简而言之，这意味着避免团队成员多任务。这可能意味着在同一时间，你工作的任务量减少。如果你在一个团队中有三个设计师，这个团队可能会在”设计”列中设置最多的任务是3个。

像Scrum，Kanban也看重团队在开发过程中最重要的角色。你可以保持现有的角色以避免更改现有的流程。持续改进：Kanban鼓励你持续学习和改进，而不只是保持这个流程一成不变，如Scrum的总结回顾。

我们应该使用哪一个？

Scrum和看板并不是相互排斥的。在Scrum中，有明确的角色，而看板说:”管他的，保持你当前的角色和任务就好”。Scrum会迫使你改变你的工作方式；Kanban要求你以现有的流程开始。在Scrum中，框架规定了一个清晰的时间表；然而，他们有很多相似之处：两者都是以实现高价值为中心，团队成员拥有更高的责任感。在本质上，他们有相同的使命：不断消除浪费和消除障碍。

但问题是：”以我特别的项目和我特别的团队我应该使用哪一个？”。Kanban不需要过多的流程和文化的改变，而且，在大多数情况下，它比Scrum会更容易采用。另一方面，Scrum提供更多的组织结构来指导这个过程，可以消除大量的开销，只要每个人都在同一频道上。

但两者的优势是并没有严格的规则。没有什么能够阻止你挑选最适合你的Scrum的元素，如每日回忆或审查。所以没有理由不将Kanban加入到Scrum中。

当整个团队对敏捷原则理解得很好情况下时，Scrum的已被证明是一个非常有效的框架。然而，以我的经验来看，我发现很难与一些客户通过Scrum的工作。因流程和文化的变化，适当的Scrum实施要求的东西太多了。另一方面，Kanban是更加灵活的，而且也不强迫团队成员做改变。一些作者还说，Kanban是一个很好的途径，且比Scrum更容易在团队中实施。有人说Scrum使用者最终会转移至Kanban。
事实上，每个项目都是不同的，并不会存在一个最优的解决方案。作为一个项目经理，你团队的工作效率取决于你的决定。