Scrum 和 Kanban
Kanban 源自丰田生产方式的管理方法
看板管理，是指为了达到JIT（Just-in-Time）准时生产方式而控制现场生产流程的工具，主流商学院都对“看板”——这一源自丰田生产方式的管理工具有所介绍。
Kanban方法也广泛的流行与软件开发团队中，尤其是采用敏捷开发的敏捷团队中。
Scrum和Kanban的对比
| Scrum | Kanban |
| Scrum 强调计划。它从Sprint计划开始，到Sprint回顾结束。举行了许多会议，有助于确保团队与下一个步骤、优先事项以及从以前的Sprint中的经验总结保持一致。 | 看板可以随时做出改变。这意味着这里的僵化程度较低，事情会经常发生变化。 |
| 它建议收集Sprint期间的时间测量值 | 看板建议用图表来概括团队随着时间的推移所取得的进展。 |
| Scrum不再要求团队做出承诺。相反，它是关于Sprint的目标和预测。 | 看板依赖于时间限制和预测。 |
| 它强调计划，因此评估在Scrum中具有非常重要的作用。 | 看板对估计没有强制性要求。 |
| 每个人都有自己的角色和责任。 | 在个人责任方面，没有设定的角色如此灵活。 |
| Sprint的持续时间是固定的。持续时间从2周到1个月不等。 | 看板不是基于持续时间的。这是关于循环时间的测量。 |
| 团队需要承担特定数量的工作。 | 无需承诺，团队可以选择。 |
| 在这种方法中，跨职能团队非常重要，因为他们可以处理任何可能导致软件开发瓶颈的中断。 | 拥有专门的团队很重要。 |
| 无法将新的任务添加到正在进行的Sprint中。 | 如果有额外的容量，可以很容易地添加新项目。 |
| Sprint Backlog工作仅由单个团队拥有。 | 多个团队可以共享看板。 |
| 可交付成果由Sprints决定，必须完成一组工作，并准备好进行评审。 | 产品和过程在需要的基础上持续交付。所以Testing和Review过程是同时进行的。 |
| Scrum软件开发方法主要关注Product Backlog。 | 看板方法完全集中在Process Dashboard上。 |
| 每个团队成员在Scrum Master中都有一个特定的角色：决定Timelines、PO设置的Goals和Objectives，以及团队成员执行开发工作。 | 团队没有预先定义的角色。但是，可能仍然有一个项目经理；鼓励团队合作。 |
| 最适合具有不断变化优先级的项目。 | 非常适合具有稳定优先级且不可能随时间变化的团队。 |
| 通过Sprint 测量生产速度（Velocity）。 |
使用周期时间或完成整个项目所需的确切时间来衡量生产。 |
| Scrum需要从传统模型完全转变为将要实现项目的敏捷Scrum模型。 | 看板不允许在项目中进行剧烈的改变。 |
| 它是一种理想的方法，适用于优先级差别很大的项目。 | 最适合具有稳定优先级的团队。 |
| 在Scrum中，整个团队致力于协作和完成任务，以提供质量开发工作。 | 团队努力实现目标，减少完成整个过程的时间。因此，缩短时间周期是成功的最大标志。 |
| Scrum强调它的时间表；新项目不能添加到正在进行的迭代中。 | 看板本质上更具迭代性，因为它没有特定的时间框架。这样，只要有额外的容量，就可以不断地添加新项目。 |
| 全部工作是在Batches / Sprint中完成的。 | 整个项目是在单线程工作项流的移动上执行的。 |
| Scrum Master充当问题解决者。 | 看板鼓励每一个团队成员都是领导者，并在他们之间分担责任。 |
| Scrum规定时间限制的迭代。即存在时间盒 Time-boxed的概念 | 看板关注于为单个迭代计划不同的持续时间。 |
| Scrum帮助公司节省时间和金钱。 | 看板方法专注于持续改进、生产力和效率。 |
| 实现各级稳定一致的有效沟通。 | 由于看板板的视觉特性，团队成员更容易实现他们的目标。 |
| 在Sprint中，对进行Coding和Test进行评审（Review）。 | 由于看板板的视觉特性，团队成员更容易实现他们的目标。 |
| 由于短周期的Sprint和定期的反馈，很容易适应不断变化的情况。 | 它是为一个定期、稳定的输出而设计的，客户需求的重大变化会使看板失效。 |
| 项目的总成本是最小的，这可能导致更快更便宜的结果。 | 如果一个任务的估计不正确，那么项目总成本就永远不会准确。在这种情况下，任务可以分散到几个Sprints阶段。 |
| 这种方法只需要有经验的团队成员。因此，如果团队由非专家组成，项目就不能及时完成。 | 没有为每个阶段分配特定的时间框架，因此团队成员永远不会知道在每个阶段他们可以花费多少时间。 |
| 在这种敏捷的Scrum方法中，在预定的时间交付高质量的产品更容易。 | 它是为一个定期、稳定的输出而设计的，客户需求的重大变化会使看板下降。 |
| 即使团队成员离开团队，项目计划也不会受到干扰。 | 如果团队成员在开发过程中退出，可能会损害项目开发。 |
| Scrum Daily Meeting有时会让团队成员感到沮丧。 | 过时的看板会导致开发过程中出现问题。 |
| 大型项目可以很容易地划分为易于管理的Sprints。 | 只适用于小型团队，因此不适合大型团队。 |
总结
- Scrum是一个敏捷的过程，它允许我们集中精力在最短的时间内实现业务价值。
- 看板是管理软件开发工作的可视化系统。
- 看板方法促进了持续改进，生产率和效率可能会提高。
- Scrum专注于Product Backlog/Sprint Backlog工作，而看板依赖于Dashboard。
- Scrum Master充当问题解决者。
- 看板鼓励每一个团队成员成为领导者，并在他们之间分担责任。
- Scrum 规定时间限制Sprint。
- 看板关注于为单个迭代计划不同的持续时间。
