【转】看板和Scrum相得益彰

看板和Scrum
看板和Scrum都是软件工程方法论中的轻量级方法，可以认为都是起源于敏捷和精益的方法论，它们都是过程工具，在比较工具的时候得谨慎一些。比较是为了更好地理解，而不是评判优劣(刀叉哪样更好？)，工具的价值恰恰在于它限制了你的选择。限制多好还是少好，比较软件工程的几个工具：

Scrum 和 RUP 的主要区别在于，RUP 给你的东西太多了，你得自己把不需要的东西去掉；而 Scrum 给你的东西太少了，你得自己把需要的东西加进来。生存在一个快速变化且充满竞争的世界，外部需求模糊而难以理解，轻量级的方法论也越来越得到重视，少即是多，灵活应用工具达成业务目标才是王道
不过我们还是要关注每样工具有哪些约束的。假如你在用 Scrum，又决定不用固定时长的迭代（或是其他任一款 Scrum 的要素），就不要说你在用 Scrum 了。 Scrum 本身已经足够浓缩了，如果你去掉一些东西，然后还叫它 Scrum，那这个词就失去了意义，只会带来困扰。
看板不仅仅只是有一个可视的板就叫看板，比较下面两个板，就可以很明显发现两者的区别。

Scrum 和看板都是经验主义的产物，你用的时候需要先进行试验，然后根据自己的环境作调整。实际上，你必须得先试验。 Scrum 和看板都没给出一切问题的答案，它们只是给了一些基本约束，以此驱动过程改进。
这种方式有很多叫法：改善（Kaizen。即持续改进，精益术语），内省与调整（Inspect& Adapt，Scrum 术语），经验式过程控制（Empirical Process Control），乃至科学方法（The Scientific Method）。
最核心的一点就是反馈环。改变 => 检查结果 => 从中学习 => 继续改变。一般
而言，反馈环越短越好，这样可以快速调整过程。

究竟什么是 Scrum，什么是看板？
Scrum 简述
我们不是靠一个庞大的团队，花大量时间造出庞然大物；而是用小团队在短时间内做出小块的东西来，在有规律的集成中组装出全貌。

把组织拆分成小规模的、跨功能的自组织团队
把工作拆分成一系列小而具体的交付物。按优先级排序，估算每项任务的相对工作量
把时间拆分成固定大小的短迭代（通常为 1-4 周），在每个迭代结束时对基本可以交付的代码进行演示
在每个迭代结束后跟客户一起检查发布目标，并据此优化发布计划，更新任务优先级
每个迭代结束后进行回顾，进行过程优化
看板简述
看板的本质是一个很朴素的思想：在制品（work-in-progress，WIP）必须被限制。

将流程可视化
限制 WIP（在制品，work in progress）──明确限制流程中每个状态上最多同时进行的任务数
度量生产周期（完成一件任务的平均时间，又称循环周期），对流程进行调优，尽可能缩短生产周期，并使其可预测
二者都是既精益又敏捷
一般来讲，Scrum 和看板跟精益思想和敏捷宣言里面的价值观和原则是相当吻合的，
当然我就不在这里过一遍了。举些例子看看：
• Scrum 和看板都是拉动式计划系统，跟精益的 JIT（准时化）库存管理原则是
一致的。这表示团队决定从什么时候开始干活，干多少活。等他们准备就绪
的时候就把工作“拉”过去，而不是从外部“推”进来。就像打印机只有在准备
打印的时候才把下一页拉进去一样（当然，打印机还是有些小小库存的）。
• Scrum 和看板都基于持续的、经验主义的过程优化，这跟精益的改善原则是
一致的。
• Scrum 和看板都强调响应变化胜过遵循计划（虽然看板的响应速度一般要比
Scrum 快），这是敏捷宣言的四项价值观之一。

Scrum vs. 看板
相似性
• 都是既精益又敏捷。
• 都是拉动式计划。
• 都限制了 WIP。
• 都以透明的方式驱动过程改进。
• 都关注于尽早交付、频繁交付可发布的软件。
• 根基都是自组织型团队。
• 都需要把工作拆分。
• 发布计划都是根据经验数据（生产率/生产周期）不断优化的

差异

Scrum	看板
规定了固定时长的迭代。	固定时长的迭代是可选的。计划、发布、过程改进等活动可以各有各的节奏。它可以由事件驱动，不用非要固定时长。
团队承诺当前迭代做完一定量的工作。	承诺是可选的。
用生产率作为计划和过程改进的默认度量手段。	用生产周期作为计划和过程改进的默认度量手段。
规定了跨功能团队。	跨功能团队是可选的。可以有专职团队。
任务必须分解，以便在 1个 Sprint里面能做完。	没规定任务规模。
规定了燃尽图。	没规定专门的图表形式。
间接限制（每个 Sprint 的）WIP。	直接限制（每个工作流状态的）WIP。
规定了估算。	估算是可选的。
不能往进行中的 Sprint 里面加任务。	只要有人手富余就可以加任务。
一个 Sprint Backlog 归一个团队所有	一张看板图可以由多个团队或多人共用。
规定了三种角色（PO、 SM、 Team）	没有规定任何角色。
每个 Sprint 之间重置 Scrum 板。	看板图一直保留着。
规定了经过优先级排序的产品backlog。	优先级排序是可选的。

再说看板

相比Scrum和其他方法，刚刚看到看板是让人觉得非常简陋的方法论，看板的本质是一个很朴素的思想：在制品（work-in-progress，WIP）必须被限制。但是这个是怎么会产生如此大的影响，或许是一种蝴蝶效应吗？
David Anderson在文中的序一写了不少解释，直接引用一下：

这件事情听上去并不是革命性的变化，也似乎不会对团队和组织的绩效、文化、能力、成熟度产生多么深刻的影响。但它却奇迹般地做到了！！看板看似虽小，但却能影响业务中的一切.

看板是一种改变管理方针的途径。它不是软件开发、项目管理的生命周期或者流程。它是给现有的软件开发生命周期或者项目管理方法中引入变化的途
径。实施看板的原则是把当前的工作作为起点，通过价值流分析来理解当前的流程，然后为每个环节中的在制品上限达成共识。让看板信号拉动着工作流动起来。

看板所提倡的是渐进式演化，逐渐向敏捷和精益的价值观靠拢。它并不要求像秋风扫落叶一般，把过去的工作方式一扫而光；它是随风潜入夜，润物细无声。它的改变是所有人彻底理解并达成共识的。

看板不是在一个短短的午后时光里，靠着天赐般的灵感喷涌孕育出来的。它用了多年时间才渐渐成型。那些在文化、能力、成熟度、组织等各方面带来奇迹般改变的哲学和社会学因素都是我们所未曾想象过的，但它们切切实实地发生在了眼前。看板引发的很多结果都是反直觉的。看上去机械化的操作──WIP 上限和拉动式生产──却会对人与人之间交互、协作的方式产生长久深远的影响。不管是我，还是其他人，在刚开始使用看板的时候，都没有预想到这一点。

附：敏捷方法之极限编程(XP)和 Scrum区别

Differences Between Scrum and Extreme Programming

区别之一：迭代长度的不同

XP的一个Sprint的迭代长度大致为1-2周, 而Scrum的迭代长度一般为 2-4周.

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现，则可以考虑用另外的需求将其替换，替换的原则是需求实现的时间量是相等的。而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队收到干扰

区别之三: 在迭代中，User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。但Scrum在这点做得很灵活，可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.

区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量

Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试，结对编程，简单设计，重构等约束团队的行为。因此，原作者认为，这点上，XP的做法值得认同的，但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念，结合敏捷模式，表达给团队的信息是“你是一个完全自我管理的组织，但你必须要实现TDD, 结对编程, …等等”

不难发现，这四个区别显见的是： Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束

作者建议，在管理模式上启用Scrum，而在实践中，创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)