敏捷开发: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 优先级是非必须的