翻译自： Scrum or Kanban: Which form of Agile is best for your teams?
关于scrum
scrum是当前最流行的敏捷开发方法之一。我们把scrum称为“框架”是因为他定义了一种轻量级的项目管理框架，可以用这种框架在进行日常开发。实际上，scrum并没有定义任何他自己的开发实践， 而是留给开发团队自己去探索最适合自己的开发方式。
团队用scrum里的 sprint 来把开发工作划分成一个一个的时间段。 一个sprint通常是两周，但是也可以跨度到1-4周。
Scrum的优点和缺点
因为scrum提供一种很严格的项目管理框架， 对于刚开始敏捷开发，并且不知道从哪里开始的团队来说是上上之选。 scrum的轻量级和灵活度可以让团队有极大的自由度来调整流程，以适应独特的团队和组织文化。
但是，scrum也不可避免的也有缺点。
第一个缺点就是scrum不建议在sprint中间接受任何变化。这意味着团队必须等待一个sprint（一般来说两周）才能重新调整优先级。 相对与传统的瀑布开发来说，两周的响应期还是会快很多， 这种响应起又被称为“冷静期”，在睡个好觉之后，很多看起来很关键的变化似乎就不那么重要了。所以，对于处在相对稳定期的团队来说，两周的变更冷静期并不是大问题。但是，对于处于维护期间的团队来说，每天都会出现更高优先级的事情要处理，两周的需求冻结就不大使用了。对于这种类型的项目和团队，就需要另外的开发方式了。
关于Kanban
Kanban是一种比scrum更简洁的方式, Kanban基于工作流，它随时接受对新插入进来的工作的排序，这样让团队能够更快的响应变化
Kanban和Scrum的不同之处
至此，你应该已经了解到了一些Scrum和Kanban的不同之处。 比如， Scrum是有节奏的将工作划分为小批量， 而Kanban更倾向让工作流动起来。由于Kanban团队不用定期的做sprint计划，他们可以自由的开始一项新的工作，只要他们遵循在制品的个数限制即可。
由于Kanban并不会看的很远，两者只见的不同更多的浮现了出来。 例如，不同于scrum, kanban团队不要求一定是多功能的团队， kanban团队由更小的更专业的团队组成，比如开发团队，测试团队，运营团队这样的团队划分并不少见， 每一个人对负责看板中不同的部分。 同样，不同于scrum的还有，kanban也不要求用户故事一定要在开始工作之前就估算好。 实际上，那些使用kanban的团队也同样会用一用相对估算的方式，从中收益。
看板没有详细定义实践并不代表这些实践不用做，相反要理解kanban只是将要做哪些实践的决定留给了团队。
例如，尽管kanban没有明确描述站会是流程的一部分，但是很多团队仍然会将这种好的团队实践应用起来。为什么会这样呢？因为事实证明每日站会对很多团队很有好处。
Kanban的优点和缺点
Kanban最大的好处就是它的简洁，她非常容易理解并且立即开始实行。它的灵活性让它更容易跟现有的流程结合起来， 让团队更加平滑的转移到敏捷工作流程中来。
Kanban缺乏冲刺的预见性同时也可以是巨大的优势，让团队能够快速调整优先级。 在这些场景下，Kanban允许团队更快的作出调整，而scrum很难做到这一点。
有趣的是，Kanban具有的这些优势同时也是它最大的劣势， Kanban的简单和灵活可能会被团队滥用，更改优先级可以在瞬间发生，这也会导致团队容易动摇，因此还是需要谨慎处理。
另外, scrum提供了一种渐进式的项目管理框架，在这个框架内可以加入合适的工程实践，而Kanban对于从哪里开始还是一片空白。对于还没有任何流程或者不确定未来方向的团队来说用kanban可能会有写风险。对敏捷完全不懂的团队来说更不知道到哪里开始kanban。
哪一种适合你的团队呢？
如果你的团队开始敏捷转型的初期，并且需要快速有效的导入新的流程，那么scrum可能比较合适。比如，怎样拆分发布或者每个团队需要那些角色。
scrum对于专注于新产品开发的团队非常有效，尽管优先级仍然会有所变化，但是还不至于每天都变。 1至4周的迭代长度足以使团队应对优先级的变化。还有，定期的迭代计划和评审也更容易让组织进行之后的计划，哪怕只是定义即将可能会有的发布计划也是极好的。
另一方面， 如果你的团队发现优先级的调整比较频繁，已经不能在一个迭代内保持相对稳定，那么kanban可能是一个好的选择。 Kanban比scrum更加灵活的应对更频繁的需求变更。
如果你的团队已经有比较成熟，功能也很强大的流程并且运转良好，用scrum的流程可能会出来一些新的冲突，这时候用看板也是一个不错的选择。
想想哪种方式对你是最好的？
Agile有很多种形式，而scrum 和kanban只是其中的两种， 不论你从哪一种形式开始， 很少有用纯scrum或者纯看板方式。更多的团队会将两种方式里的工程实践结合起来创造出适合自己组织和文化的scrumban。
像这样想想，什么是更好的工具？ 锤子还是螺丝刀？ 其实并没有唯一的答案， 正确的答案是基于你当前的情况以及你想解决什么样的问题。有时候锤子很好用， 有时候螺丝刀更好用。 对于一下大型的项目， 你可能两个都需要。
敏捷也是一样的道理， 与其选择只用一种方法， 还不如了解更多的选项，然后创建出适合你自己团队的流程。