Scrum还是Kanban，你想清楚了吗?（scrumbs）

Scrum or Kanban?

这不是个好问题

这两者都有对应的实践和准则，也都有值得学习的部分，会带给我们不同的思考维度，所以我们可以选择站在更宏观的角度，心态更开放些，考虑实际处境，如何选择共存，或是取长补短，才是我们要关注的。

Scrum和Kanban都受到精益思想的影响，像精益生产，精益产品开发，精益敏捷软件开发，他们虽然都是不同的实践，甚至针对的目标也是不同的，但是他们都建立在下面的四个基础理念之上：

1系统思考

2持续改进

3降低工作流和反馈机制的延迟现象

4对质量的承诺

Scrum和看板都可以被看作是精益思想的部分完善，精益思想是能够帮助我们合理地评估Scrum和Kanban,而且能够帮助理解在实际工作场景中应该如何针对性地实施。

Scrum优势？

Scrum的实施精髓是通过跨功能的团队共同协作，在1-4周的迭代里完成工作。通过这样的设置，是能够帮助减少工作流中的延迟，因为我们是能够高频率地看到一个交付物的，那么反馈也是能够及时地传达给团队，同样的，PO在一个迭代结束时可以通过评审会帮助评审产品是否合格，如何改进，所以说Scrum能够帮助减少反馈系统的延迟。

Scrum劣势？

1.Scrum不是从系统性思考的角度出发。Scrum它采用自下而上的方法。大多数情况下，团队单独工作，然后再尝试协调在一起，最终满足整个组织的业务需求（Scrum-of-Scrums）。事实上，这种自下而上的方法仅关注到了价值流的一部分。

2.Scrum也没有在团队中界定明确的工作流程：Scrum没有明确地管理在制品。

Scrum尽可能不去做限制，否则你的团队就失去了整个过程中自主优化的可能性，因为Scrum希望你自组织，自管理，自优化，所以不框死。

那么Scrum没有明确地管理在制品这种说法也是正确的。Scrum这么做的理由同样是让你自己控制，获得更大的灵活性。

事实上，Scrum 是用迭代中的Velocity来控制在制品，比方说你的产能是20个点，4-5个故事，那就是你的WIP。

Scrum使用Velocity数据告诉咱们，我们的产能大概是多少，可以用这个来参照，看看这个迭代里你的团队可以完成多少的工作量，以此控制整体的WIP。

而Scrum不具备的这两个因素，系统思考价值流和明确管理工作流程，这两者基本上都能提高协作和工作效率的。

我们了解了Scrum的优势和不足，那么看板又有哪些优势和不足呢？

看板如何实现精益思想呢？

看板的三个基本原则：

-可视化让工作流程明确

-限制在制品（WIP）的数量

-增强流动

看板作为一种拉动的方式被大多数人熟知。它有两个咒语，“Flow when you can, pull when you must” and “Stop starting and start finishing.”

看板通过关注流程和管理WIP，减少反馈系统和工作流程的延迟。

工作流的可视化和明确也可以改善协作，即使跨区域团队也能够产生作用。看板对于企业文化和背景都是比较敏感的，即企业文化和背景对看板容易产生影响，而且使用看板时，当前的角色，职责和工作头衔都不会产生太大的变动。

看板又遗落了什么呢？

由于看板对文化和背景的敏感性，所以看板强调从企业当前的位置出发提供解决方案。

那么问题来了，有时候呢通常会有一些实践啊或者不同的组织结构啊，是可以立即产生一些改进的效果的，也能够为每个人更好的学习创造条件，但因为我们强调文化和背景这些环境因素，所以不做出变动，那么很明显，提升改进的速度就可能比团队预期的要慢很多。

小总结:

两者的利弊

Scrum和看板不仅仅是不同的实践，它们也是基于不同的转换模型。虽然两者在许多情况下都有效，但它们的实施形式却各有特色。

Scrum的转型模型让团队采用一系列实践，这些实践能够一开始就避免很多产品开发的可能障碍。这种变化是比较突然的，而且对很多企业来说，可能是“破坏性的”。

Scrum要发挥作用，就必须遵循其核心实践和角色设定，然而，这在有些企业其实是有困难的，涉及到成本。

虽然说Scrum的框架对于不同部门不同行业都是灵活的，但是遵循的实践和角色却是不那么灵活，比如，你必须按照迭代，必须按照3355实施。

看板的转换模型致力于更好地理解您正在做的工作，并且遵循流程原则。

它是基于事件的进程而发生的变化，而不是Scrum要求的一开始就需要变化。但是，在许多情况下，看板对工作流程的关注同时，却忽略了其跨职能团队的价值。

关于两者对于在制品的控制，举个例子：

比方说，小A手上有很多事情同时都在进行中，虽然团队在用Scrum，可是她忙不过来，因为很多事情同时在展开。

所以我们可能就会看到小A的情况是很多时候每个事情都会做到30%，而不能很快结束。

如果是Kanban，那么在这里，Kanban强硬指定在板上只能同时进行多少张卡，即是WIP。强硬的不让小A碰WIP外的事情。

Scrum则说，你已经长大了，这个情况你自己想想怎么办吧，会不会同时进行少一些的事件会更好呢?

所以Scrum这里是用教成人的方法，拍拍你的肩膀说，你想下可以怎么办

Kanban则更像教小孩的方法，把WIP数字写在那里，硬性的规定不让你去移动卡片。

教小孩，用Kanban方法最直接。

教大人，用Scrum的方法比较睿智。

所以Kanban的WIP管理流程里的某个细节，Scrum的WIP管理团队迭代工作量。

我们不要忘记，Kanban源自于管理工厂里的工人，Scrum源自于管理研发团队。

管这两种人需要用的手段很不一样。

强强联合，共创辉煌

事实证明，所有团队都应该采用Scrum和Kanban（甚至是极限编程）的好几种做法。

Scrum，看板和XP有共同点的做法：

使用小批量的工作

团队自组织

每日站会

我们应该使用的Scrum实践：

进行估算和速度

应该使用的看板实践：

专注于完成

让所有工作都可见

有明确的工作流程

明确管理WIP

应该使用的极限编程实践：

使用验收测试驱动开发（ATDD）

持续集成并使用自动化测试

那么，如何选择呢？考虑下面两个问题：

1你会使用迭代吗？迭代是有用的，因为它们提供了规则 - 时间盒给你一个结束日期并让焦点聚焦在完成的概念上。

如果说团队处理的是维护的工作，或者是没有特定计划的，那他们只要专注于处理的过程和完成的结果，这时候并不要求一定遵循迭代了。

然而，即使在这些具有输入，输出，演示等的共同节奏的情况下，迭代仍然是有用的。

2你会使用跨职能团队吗？无论您是否可以拥有跨职能团队，他们都是个好主意。尽可能地创建它们。

通过关注哪些是有助于团队的效率的：快速，可持续和高质量地创造价值。

这取决于团队的背景和他们所做的工作类型。单独选择Scrum或看板都可能会导致错过基于精益思维的混合模型提供的机会。

因为每种方法都提供了宝贵的见解; 实际上，Scrum，Kanban和XP的几种实践对几乎每个团队都很有用。