本文主要是介绍精益和敏捷的较量：你知道敏捷开发有 Scrum 和 Kanban 两种管理模式吗？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
很多开发者谈到敏捷的管理方式过程大概是这个样子的，一个项目会分成多个迭代，每个迭代计划一些用户故事，在迭代周期到来前完成开发和交付，最后总结每个迭代的经验。
这里的开发管理过程都是围绕着迭代进行的，那么有没有不需要迭代的敏捷管理模式呢？答案是肯定的，这就是 Kanban 模式。以迭代为核心的那种模式叫做 Scrum。
Scrum 始于敏捷，而 Kanban 模式来自于精益思想，两者都是为了能够适应不断变化的需求而设立的项目管理方法。
为什么会有两种敏捷管理模式？
很多人的理解是敏捷就是小瀑布模式。这个说法只能说是部分正确的。如果仔细阅读敏捷宣言，我们可以看到它强调的是沟通、合作、交付和应对变化。最快捷的应对变化的方法，难道不是做完一个就交付一个，在客户提出反馈后及时修改的循环吗？Kanban 就是为这个目的而生的。
当项目有以下特点时，采用 Kanban 的管理模式就能更敏捷的应对客户。
- 需求迅速变化
- 需要及时交付
- 需要及时处理客户反馈
采用 Kanban 模式的团队应该能随时接受计划的变更，能做到持续交付，也就是做完一个用户故事就能够交付一个。
如果团队希望在规定时间范围内有固定的工作计划，到期交付指定的内容，那么就应该采用 Scrum 管理模式。这种模式有点像周期很短的瀑布模式。它适合于下面特点的项目：
- 清晰的产品路线图
- 分阶段实现
- 客户能忍受交付周期
Scrum 和 Kanban 分别是如何组织工作的？
上图是Scrum 和 Kanban 管理模式的对比。Scrum 是一种结构化的管理方式。开发团队有固定的迭代周期制定工作计划。在一个迭代的工作计划制定完成了以后，在整个迭代周期中不能修改，因为开发计划是开发团队的承诺，在迭代周期中必须完成，如果不能完成就需要在反思会上总结经验教训。
Scrum 的效率指标通常是在每个迭代中完成的故事点数。这是一个经验值，每个开发团队在一个迭代中能完成的故事点数是不可比的。使用故事点数的好处是在用户故事裁剪会上检验是否每个人对用户故事的理解是否一致，使用用户故事点数表示的速度 (Velocity) 也能用来预测剩余的用户故事还需要多长时间才能完成。
从上图可以看到，Kanban 的管理方式要自由的多。它没有固定的周期，团队在限定同时进行的项目的前提下 (WIP: working in progress)，尽可能快的完成用户故事。
看板使用 Cycle Time, Lead Time, WIP 来衡量开发团队的效率。事实上使用 Scrum 的开发团队也可以使用指标来衡量自己的开发效率。
什么是 Cycle Time?
Cycle Time 指的是一个用户故事从开始开发到完成的时间，用“天”来表示。这是衡量开发团队研发效率的一个指标。在 Kanban 管理模式中还会使用这个指标来衡量一个用户故事是不是拆分的合理。如果某个用户故事的完成时间突然变大或者突然变小，团队就应该分析用户故事的拆分是否合理以保证开发团队能够按照希望的节奏交付。
什么是 Lead Time?
Lead Time 指的是从需求（用户故事）创建到完成所花的时间，单位也是“天”。这是衡量产品经理是否敏捷的一个指标，因为需求的提出是由产品经理完成的。如果产品经理提出一个需求以后，在几个月以后团队才开始实现这个需求，这必定会导致 Lead Time 增加。如果 Lead Time 远远大于 Cycle Time 可能的原因是需求太超前，也可以表明客户对某些需求本身没有强烈要求。
什么是 WIP？
WIP 是 Work In Progress 的缩写，也就是正在进行中的项目。在 Kanban 模式中团队通过控制 WIP 的数量来控制交付时间。根据 Little’s law， WIP 越大等待时间越长。关于如何使用 WIP 来控制交付时间的方法可以参考下面的文章：
https://blog.csdn.net/surfirst/article/details/121347805
什么是 CFD？
CFD 是累积流程图，用来反映一共有多少个正在进行的工作项目。控制好CFD的平均值可以有效地管理团队的专注度，让团队先集中精力完成手上的工作。这也是 Kanban 的一个重要指标。下面的团队使用的是 Scrum 在 CFD 平均值上达到了 21，显然是太高了。
两种方式哪种更敏捷？
如果从交付速度上来看，使用 Kanban 的团队会限制 WIP，尽力做到做完一个就能交付一个，所以更为敏捷，但是这要求团队要做到一专多能，当队员手头工作完成以后，能够迅速认领任何任务，帮助团队达成整体目标。Kanban的整体指导思想来自于精益思想的价值流和单件流，以减少浪费为主。
如果团队文化喜欢有长期的规划，步步为营，产品比较成熟，客户也能接受交付周期，那么可能以结构化管理方式为主的 Scrum 模式会更适合团队的管理模式。Scrum 的整体指导思想是敏捷宣言，以沟通、交付和适应变化为核心。
能结合在一起使用吗？
两种方法当然是可以结合在一起使用的。敏捷中有一种 Scrumban 的管理方式结合了两者的特点，使用 Scrum 结构化方式组织迭代的工作，在项目进行中并不完全拒绝计划的变化，控制 WIP 尽力做到完成一个交付一个，使用 Kanban 的指标体系 Cycle Time, Lead Time, 以及 CFD 来衡量团队的效率。
总结
本文介绍了敏捷的两种管理模式：Scrum 和 Kanban。开发团队可以根据自己的文化特点决定使用哪种模式，也可以结合两种管理模式的特点，以一种模式为主，适当加入另一种模式的管理方法。
参考链接
拒绝996：如何使用“单件流”概念来提高软件项目交付的准时性？
拒绝加班：如何避免开发完成了但是不能交付的困境？
拒绝加班：是不是只有“全栈”工程师才能实现软件开发的“单件流”
关注公众号
查找公众号: agileddd，或者扫码关注：
这篇关于精益和敏捷的较量：你知道敏捷开发有 Scrum 和 Kanban 两种管理模式吗？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
