敏捷开发：Scrum 和 Kanban 的区别

包括国内一些知名公司在内，很多开发团队的开发模式是四不像：说敏捷不够敏捷，说瀑布，又顶着敏捷的帽子。当然也没有必要完全拘泥于教义，适合实际项目状况就可以，很多人信奉也是实用主义。

感恩两家小公司，一家开发团队虔诚信仰并全员培训CMMI，另一家开发团队虔诚信仰并全员培训敏捷。刚从CMMI的公司进入敏捷公司感觉各种不规范各种不适应，但没多久就发现敏捷真香。。话又说回来，虽然没人喜欢CMMI的繁文缛节，所谓完善的流程、规范的制度，但这大概率是大公司走向僵化的必然之路。。

扯远了，这里简单看看 Scrum 和 Kanban 的区别，这也是曾经困扰本人的问题之一。感觉下面这篇文章讲的还可以。

---

敏捷开发流程：

敏捷是理想型指标和原则，看板和Scrum是帮助团队坚持敏捷原则并完成工作的基本框架。本文详细介绍了在Scrum和看板之间做出选择时要考虑的关键因素，以及如果我们无法做出决定时该怎么办。

Scrum和看板实践之间的区别很容易总结出，但这只是表面上的。虽然这两种框架实践起来不同，但原则基本相同，他们都将帮助团队以更高的效率构建更好的产品和服务。

看板

看板可以让你手头的工作变得可视化，并限制正在进行的大量工作，最大化提升效率(或优化流程)。团队通过使用看板并不断改进他们的工作流程，能够有效减少从项目(或需求)开始到结束所花费的时间。

Scrum

Scrum团队通常以Sprints的固定时间间隔为准来交付最终产品，他们的做法是创建循环任务，以便快速收集和集成客户反馈。Scrum团队采用特定的角色，创建特殊的工具，并定期举行会议来保持项目的进展。

Scrum：结构化的敏捷方法

使用Scrum的团队，需要承诺在每个Sprint结束时交付一些有价值的工作增量。Scrum专注于小的增量工作，帮助团队不断进行学习，以预测和了解到接下来要做什么。

Scrum工作节奏

Scrum发展很快，每2-4个星期就有一个明确的开始和结束日期。短时间框架迫使复杂的任务被分解成更小的需求，并帮助团队快速学习。但关键的问题是：您的团队能够如此快速地交付可用代码吗?Sprint 的进行中还包括 Sprint 计划、Sprint 评审和回顾会议，并穿插着每日Scrum 站立会议。这些Scrum仪式都是轻量级的，在循环任务的基础上运行。

交付方式

每次Sprint结束时发布版本一直是Scrum的最佳实践，团队为每个Sprint设置一个目标，在Sprint评审会议上决定是否要发布。

Scrum角色

Scrum有三个明确定义的角色：产品负责人为客户提供支持，管理产品 Backlog，并帮助开发团队确定所做工作的优先级；Scrum Master 帮助团队坚持 Scrum 原则；开发团队完成项目工作，交付增量。

那谁来管理 Scrum 团队？答案是：没有设定这个角色。Scrum 团队属于自治型，尽管职责不同，但每个人都是平等的，所有人都坚定于一个共同的目标：为客户提供有价值的产品。

关键指标

Scrum团队的核心指标是速度，即在一个Sprint周期中完成的需求数量，它为下一阶段Sprint及团队要承担的工作作出了预测性指导。

多变性

Scrum团队有时会得到客户反馈，并了解到他们所做的可能不符合客户的预期价值。在这种情况下，Sprint的范围应该以“客户期望的价值”为中心来改变。

看板：持续改进，流程灵活

看板有助于可视化我们手头的工作，限制正在进行的工作(WIP)，制定完整工作流程。看板对于项目任务复杂、优先级划分明晰的团队非常有用，Scrum需要对整体工作内容进行高度控制，而看板则灵活度更高。

看板工作节奏

看板基于一个连续的工作流结构，它能够让团队保持敏捷，随时准备适应不断变化的任务优先级。工作项(通常由卡片表示)排布在看板上，它们从工作流程的一个阶段流向下一个阶段，基本工作流阶段包括：To Do（未开始）- In Progress（进行中）- In Review（审查中）-Done（已完成）。想了解更多“工作流”内容也可以查看：制定工作流来获得团队更高效率。

看板最大的优势是为团队定制出工作的标准流程。例如我们文章创作项目，流程包括“初稿-稿件审核中-稿件审核通过（待排期）-稿件已发布”，审核人可以很全面的把控内容的创作质量。

交付方式

理论上，看板并没有规定交付任务的固定时间。如果任务完成得更早(或更晚)，团队就可以根据需要发布产品，而不必等待Sprint Review这样的发布里程碑。

看板的角色

整个团队都可以共享看板，也为所有需要交付的任务负责。虽然有些团队聘请了敏捷教练，但与Scrum不同的是，没有一个“看板大师”能让所有事情都顺利运行。

关键指标

交付时间和周期时间是看板团队的重要指标，即处理任务从开始到完成所需的平均时间。循环任务的完成时间的长短，体现了一个看板团队的效率高低。

看板中，处理工作瓶颈的方法是WIP限制，它可以控住工作流任何一个阶段中的卡片数量（即任务量）。当您达到WIP限制时，类似于Worktile的看板工具就会为该列（流程阶段）设置任务上限，团队就会更多的专注于这一阶段的工作。

多变性

看板十分灵活，工作项可以随时更改。新的工作项被添加到待办事项列表中，现有的卡片可以根据优先级的规划情况被暂定或删除。此外，如果团队工作量发生变化，可以重新校准WIP限制，并相应地调整工作项。

Worktile官网：www.worktile.com
内容整理：Worktile
文章首发于「Worktile官方博客」，转载请注明来源。

小结

相同点

两者都符合精益和敏捷思考
两者使用”拉动式”安排日程
两者限制开发中工作数目
两者是透过透明度来驱动过程开进
两者基于自我组织团队
两者要求把工作细分
在两个情况下发布计划都是基于经验数据（速度／开发周期）持续优化

不同点

Scrum	看板开发方式
要求定时迭代	没指定定时限迭代，可以分开计划、发布、过程改进，可以事件驱动而不是限定时限
团队在每个迭代承诺一定数目的工作	承诺不是必须的
以速度（Velocity）作为计划和过程改进的度量数据	使用开发周期作为计划和过程改进的度量数据
指定跨功能团队	没有指定跨功能团队，也容许专门团队
工作任务细分，可于一个迭代中完成	没有指定工作任务大小
指定使用燃烧图	没有指定任何图表
间接限制开发中工作（每个迭代）	设定开发中工作的限制（每个工作流程状态）
规定估算过程	没有指定任何估算方式
在迭代中不能加入新工作任务	只要生产力容许，可以随时加工作任务
由单一团队负责 Sprint Backlog	多个团队和团员分享看板
指定三个角色（产品负责人／ScrumMaster/团队）	没有指定任何团队角色
Scrum board 在每个迭代后重设	看板反映持久开发情况
规定优先化的 product backlog	优先级是非必须的