当一个软件开发人员听到关于“新的JavaScript框架”或者“新的IDE”的新闻时，他不需要问多的问题的就能明白它是什么。但如果他听到的是”新的敏捷框架“时，他很可能会点点头，假装他知道它是什么，而他会有一个且唯一一个问题：”敏捷框架“到底是什么鬼？

在现代软件开发环境中，我们日渐听到像”敏捷“、”scrum“和”看板“这些词，并且他们经常会被错误地使用。在这篇文章中，我将会试着解释并澄清其中的一些词。

敏捷

如果你想在人群中脱颖而出，当谈论工作进展时你应该在每句话中都使用”敏捷“这个词。它的范围非常之广，不责成你去非常了解你正在谈论的主题，并且它真的是一个很好的形容词或副词：”敏捷思考“、”敏捷方法“、”根据敏捷原则“。但”敏捷“到底意味着什么？

“敏捷”引自”“，开发方法遵循敏捷原则。而”敏捷原则“又是什么呢？可以看下打下敏捷发展基础的：

         

         人和交互 重于 过程和工具

可以工作的软件 重于面面俱到的文档

         客户合作 重于 合同谈判

   随时应对变化 重于 遵循计划

敏捷原则鼓励可以工作软件的持续交付，团队中紧密的沟通，和对需求改变的高度适应。如果在工作中你遵循这些价值和原则，你可以说正在敏捷环境中工作。所以，敏捷软件开发不是一个方法论，它仅仅是一系列不同的方法、框架和遵循相同原则的技术。可以说，”敏捷“是思考和作出决定的一个框架。

敏捷 是思考和作出决定的一个框架。

但是为什么在我们的工作中遵循这些原则那么重要？

宣言和这些原则是为了应对软件开发挑战而从数十年的演进中搜索出最好的解决方案的结晶。经历过了70年代、80年代和90年代，全世界不同的开发人员和团队已经对工作方法和解决问题的方法作出了实验，发明了不同的的框架和技术（例如scrum和极限编程），甚至并行出现了同样的想法。最后，在2001年1月，17位开发人员聚在了一起并为这些多样的想法和经验找到了共同的特征。这就是宣言被创造的过程。

敏捷宣言是数十年出现的不同的经验和可实现的解决方案的结果。

Scrum

如果你谈论”敏捷“方法却不知道他们意味什么，可能会出差错并在知道”Scrum和其他敏捷方法“的谈论者面前说一些暴露自己的东西。

，尽管我们听到它的次数比权力游戏的被杀的人数还要多。Scrum不会为每一个问题都提供答案，也不会为响应每一个你面对的场景提供清晰的过程。由此作为不正确解释的结果，大部分scrum实现也都是错误的：团队得不到价值。这很可能导致了关于scrum最愚蠢的声明：”scrum没用“。

scrum是什么？中的定义是：

一个人们可以放置复杂自适应问题进内的框架，当清晰地和创造性地尽可能交付最高价值时。

所以它是一个框架，并且像其他可能的框架一样，经常地，被错误地使用。高效地使用scrum不仅仅要求适应scrum设置的结构，还要有深刻的理解以及在贯穿整个团队中对于敏捷原则的感恩。

scrum包含以下角色：产品负责人，ScrumMaster，和开发团队；四种仪式：计划会议，每日站会，Sprint评审，和Sprint回顾；以及三种输出物：产品Backlog，Sprint Backlog，和产品增量。它以我们称之为sprint的定期时间帧来组织。sprint应该持续在一周到四周以内。

产品负责人，即PO，负责引导项目的方向。当新的任务和特性决定后，PO把他们添加到产品Backlog。一个sprint以开发团队从产品Backlog中选择开始工作的任务以及计划怎么实现他们的计划会议为起点。接下来的是开发，在这个过程中开发团队使用Sprint Backlog来追踪进度并在每日站会上碰面以便同步活动和在有需要时调整计划。此开发的结果应该是产品增量，一些可以应用到产品或者马上发布的东西。在sprint的最后，在争论产品Backlog是否需要更多长远的改变的Sprint评审上，这个产品增量将会展示给产品负责人。此后，整个团队将参加讨论工作进度和如何才能提高它的Sprint回顾会议（也可称之为发布会议）。

这里只是寥寥数语，如果需要更多关于scrum如何工作详细的解释，可查看。

学习和理解scrum很容易，但适应它则很难。有很多原因使得这个框架对于项目来说也许是又或者不是一个好的匹配。它通常需要大量的改变，不仅仅是每天的开发，还有文化角度。scrum最适合于维持很久时间并包含不同类型专家的复杂产品的开发。

为什么scrum如此流行，以及为什么相比于传统的瀑布流模型它更有优势？简单来说，是因为它为产品或者客户交付了更多的价值。使用诸如瀑布流这样的”重量级“方法，在恐怖故事比比皆是的数月内没人能看得到任何东西。使用scrum，这种情况是不会发生的。

scrum全部都是关于交付给终端用户的价值。如果你真的使用scrum，你需要在每一个sprint交付一些有价值的东西。价值应该能被评估，并且在接下来的迭代中交付更多的价值的目标下，团队也强制要求进行障碍检查和适应调整。

在大部分软件开发中，我们并不是在建设摩天大楼；我们不需要在开始前要准备好整个计划，并严格执行这个计划直到最后。我们正在开发软件，并且我们有能力针对不同的场景做出调整以及在开发过程中改变产品需求。很长一段时间内，很好开发人员把这看作是第八重罪（eighth deadly sin），但从产品的角度它对于优化可预测性和风险控制有着巨大的好处。scrum围绕着这个能力发展了起来，而它的实现则提供了一种处理必要变化的可靠且高效的方式。

很多技术与scrum配合使用：计划扑克，结对编程，测试驱动开发（TDD），（BDD），和其他。他们不仅是scrum的一部分，还是兼容的技术。与scrum一起经常被提到的一个方法是看板，并且对于这两者相互之间的关系有着大量的困惑。

看板

当你谈论scrum和看板时，人群中经常会问到的一个问题将会是，”哪个更好，scrum还是看板？“你不知道如何作答因为这就像把苹果和橙子比较，或者问，”哪个更好，薄煎饼还是啤酒？“ 两者都不错。

看板是在未超过团队成员负荷的同时致力于即时交付的一个简单方法。它和scrum中在最后交付最大化价值的目标一样，但它比scrum更加灵活。

看板不是软件开发社区发明的。实际上，它来源于丰田的制造过程，并且已广泛应用在其他领域。没有你需要遵循的严格过程，也没有你需要实现和使用看板的严格方式，而是，有一系列原则和实践你可以从中选择以适应你的需要。但在软件开发中有一个最常使用的看板实现包含了看板白板的使用，它包含了代表工作状态的列，和任务。

列代表着开发过程中各个任务的状态。简单的示例包含着这三列：”待办“，”进行中“和”已完成“。所以，任务可以添加到”待办“，当任务开始时移到”进行中“，并且移到最后一列时被当作为”已完成“。当然，它也可以更加复杂：

“Backlog” --> “定义规范” --> “准备开发” --> “开发” --> “code review” --> “测试” --> “部署” （--> “没人使用” --> “移除”）。

每一列都有其子列；例如，“开发”可以划分为“计划”和“编码”；“测试”可以划分为“单元测试”和“集成测试”，等等。如果适当的话，列也许专门针对于专家。团队根据需要定义列和状态。每一个“拉”的理念，仅当需求是即时时任务才能进入此工作流。

这个白板的目的是为了可视化工作流，这也是看板中首要关键的实践。实际上，看板也可以一点也不用白板！它可以是在Google表格中通过不同的背景色代表任务状态的简单的任务列表，或者可能是甘特图，图，表。。。它甚至可以是办公室中一系列的桶，每个桶代表着任务不同的状态，而球则当作是任务来使用。只要能可视化工作流以及提供整个过程的透明度即可。

另一个重要原则是减少你努力的批次。简单地，这意味着避免多任务。这意味着减少你同时工作的任务量。如果你的团队中有三个设计人员，那么团队将会在“设计”这一列中设置最大的任务量为三。

像scrum一样，看板也在过程中把团队视为最重要的计量。但它并不像scrum那样建议角色，并且你可以保持既有的角色以免对已有的流程作出改变。针对持续提高相同的标准：看板通常喜欢你学习和持续提高，却不像scrum的sprint回顾那样为此指定具体的事件。

我应该使用哪个？

scrum和看板并不是相互排斥的但也并非可以完全兼容。在scrum中，有定义好的角色，而看板则会说，“搞什么鬼，保持你当前的角色和职责就可以了。”scrum会强制你改变工作的方式；看板则允许你从既有的流程开始。在scrum中，框架会对事件制定一个清晰的时间表；在看板你并没有事件。然而，他们也在着大量的相同之处：两者都是以价值为中心，团队成员被尊称为系统中的“老大”，并且本质上，他们有着相同的使命：不断消除浪费并消除障碍。

但问题，“在我特殊的项目和特殊的团队中我该使用什么？”意味着更多的场景。看板不要求那么多的流程和文化改变，且在大多数情况下，相比scrum它更容易适应。另一方面，scrum明显地提供了更多引导流程的结构，以便当很多人都在相同的页面时可以消除大量的开销。

但这两者之美都不是一系列严格的规则。没什么可以阻止你为自己拾取和选择最好的scrum元素，例如每日站会和回顾。也没理由你不能将看板白板和scrum结合起来。

scrum已被证明当整个团队能很好理解它时它是一个高效的框架。然而，在我的经验中，我发现和某些客户在scrum中一起工作时很困难。针对合适的scrum实现而要求的过程和文件变化太多太多了（特别当处理相信他正在创造一个谷歌的人时）。另一方面，看板更为灵活且不强制人们作出改变。有些作者也说看板是通往敏捷性的一个好途径，且比scrum提供更容易的实现。其他人则说使用scrum应该最终会引入看板。

真相则是每个项目都是不同的，没有放之四海而皆准的解决方案。作为一个项目管理者，由你来决定对于你的团队什么最有用。

本文翻译作者为：dogstar，发表于开源中国个人博客；欢迎转载，但请注明出处，谢谢！