[译] 敏捷、Scrum和看板：这些词究竟是什么鬼？

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


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

敏捷

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

“敏捷”引自”敏捷软件开发“，开发方法遵循敏捷原则。而”敏捷原则“又是什么呢？能够看下打下敏捷发展基础的敏捷宣言：

         

         人和交互 重于 过程和工具

能够工做的软件 重于面面俱到的文档

         客户合做 重于 合同谈判

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

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

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

可是为何在咱们的工做中遵循这些原则那么重要？

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

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

Scrum

若是你谈论”敏捷“方法殊不知道他们意味什么，可能会出差错并在知道”Scrum和其余敏捷方法“的谈论者面前说一些暴露本身的东西。

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，发表于开源中国我的博客；欢迎转载，但请注明出处，谢谢！