Scrum vs. Kanban:软件开发新方法大比拼

日期:2013-1-7作者:Yvette Francino翻译:蒋红冰来源:TechTarget中国 英文

Kanban   Scrum   敏捷技术   

【TechTarget中国原创】

去年,Scrum似乎很常见,我听到人们经常使用它来等同于“敏捷”。最近,Kanban似乎是叫嚣比较大的一个术语。已经掌握了Scrum的组织正在向Kanban移动。越来越多的ALM厂商正在把Kanban功能加入到他们的产品中,而且一些会议及用户组织也充斥着类似的会议,例如,如何工作“精益”和“连续流动”,这通常就相当于使用Kanban。但是Kanban真正是什么,它是否与Scrum不同?这两者可以一起使用吗?本文中,项目经理和团队领导者详细地讲述了Scrum和Kanban,既说明了两都不同,也介绍了它们可能互补。

  可交付的成果不同

  尽管在什么使软件开发“敏捷”的话题上存在许多争论,但关于具体的方法论上有很多定义。正如前面提到的博客文章, Henrik Kniberg 的“探索Kanban,敏捷开发冉冉升起的新星”和Kanban vs. Scrum文章中,提到Scrum有9条规则,而Kanban只有3条。

  “规则”规定,团队使用如下:

1. Scrum主管(Scrum Master)
2.产品负责人 (Product Owner)
3. 开发团队(Team)
4. 计划会 Sprint Planning Meeting
5. 每日立会(Daily Scrum)
6.冲刺评审(Sprint review)
7. 产品订单(Product Backlog)
8. 冲刺订单(Sprint Backlog)
9. 冲刺燃尽图(Burndown Chart)

  Kanban只要求下面的几点:

1可视化工作流
2.限制以流程为工作中心
3.权衡和优化工作流

  追踪流程使用的测量不同

  在Scrum中,团队使用迭代方法,它是指“定时”或在特定的时间内做增量,称作冲刺,通常情况下是2-4周。在每一个迭代的开始都会有一个冲刺计划会议,会议上从产品订单中选择出案例,选择出案例在下一次迭代中开发。

  为了确定出在每一次迭代中的工作量,团队的执行将会通过“燃尽图”进行跟踪,此图中X轴代表需要完成的工作预估,Y轴是迭代时间线。燃尽图衡量着团队的“周转率”,此“周转率”是一个测量,展示出团队在迭代中的生产效率如何。

  评估每一个安全的任务,通常是用“安全点数”表示是有必要的,从而可以正确地分割工作,分割成他们可以在一次迭代中完成的大小。

  在Kanban中,使用不同的衡量方法来确定项目是否要被跟踪。队列用来表示工作流。例如,一个队列在清单中包含了所有项目,一个队列给开发,一个队列给测试,还有一个队列给部署。通常会使用一个Kanban面板,把案例卡片随着进程在面板上移动。

  不是定时一个案例,要求在一次迭代中此案例必须完成,Kanban限制了WIP或以流程为中心的工作。团队必须给每一次活动确定WIP限制,但是一旦满足了WIP的限制,团队成员必须一起工作,清除所有的阻碍区域。整个生命周期时间就是完成此案例的时间。随着时间对此进行测量,团队交会了解多长时间他们会完成所有案例。Kanban支持者相信使用周期时间最终会允许团队在他们需要时做出准确的估计。

  角色和会议不同

  Scrum定义了非常具体的角色和必须举行的会议。必须有一个Scrum主管、一个产品负责人和一个开发人员团队编码和测试用例。Scrum主管推动会议并帮助所有阻碍团队进程的障碍。产品负责人代表业务人员或用户,帮助阐明案例并区分先后次序。

  Scrum规定要有一个冲刺会议来确定哪一个案例要进行冲刺。有一个日常Scrum会议,有称为站立会议,它是一个简短的会议,让团队明白了解前一天每一个成员都做了什么、他们今天的计划和所有的阻碍。在冲刺的最后,有一个冲刺审查会议来演示所做和的软件,并进行回顾,检查什么进行良好,及什么需要改进。

  Kanban不要求有像Scrum定义的角色和会议;然而,许多从Scrum方法转型的团队维持了在他们Scrum团队中使用的角色和会议。Kanban没有规定衡量和优化流,因此团队没有看到项目的测量和工作方向的持续改进。

  转变不同

  比Kanban更规范的Scrum通常对软件开发团队来说更难以转变。有一个特定的必须遵循的框架,而且如是团队现在正在使用转型的软件开发方法,那么对于团队来说将是一个很大的转变,全新的工作方式和新角色。

  Kanban设计为开始于你正在使用的流程,而且工作方面持续改进。团队鼓励去映射他们目前的工作流流程和确定瓶颈。该流程是为了进化到一个独特的和优化的工作流程的团队的一种手段。

  Scrum和Kanban是互补的吗?

  正如我们所看到的,Kanban并不意味着左右你的方法,而是通过优化改进流程流。Kanban可以和Scrum一起使用,尽管在案例或任务分配和衡量的方式上存在不同。无论是Scrum还是Kanban的实践都可能使用视为“敏捷”的技术,如测试驱动开发或持续集成。在这两种情况中,团队的工作方向是衡量和改进。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Yvette Francino
Yvette Francino

Yvette Francino具有20年全软件周期开发经验。

Ruby on Rails>更多

相关推荐

技术手册>更多

  • 松散耦合的七个级别

    在软件领域,“耦合”一般指软件组件之间的依赖程度。那么,什么是依赖?各种依赖对耦合度和松散度有多大影响?软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中,为了确定系统的耦合程度,必须分析各个级别。下面我们就来具体看一下。

  • SOA与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

  • 开源框架Ruby on Rails

    Ruby on Rails, 也称RoR或简称Rails, 是一个使用Ruby语言写的开源网络应用框架,它是严格按照MVC结构开发的。它努力使自身保持简单,来使实际的应用开发时的代码更少,使用最少的配置。

  • SOA安全

    安全对于许多的IT部门来说都是一个重要的问题之一,但是SOA安全问题完全是在另一个新的纬度上了。对于SOA为一个机构所带来的许多的好处,例如具有在许多不同的提供者和供应商的情况下混合和匹配服务。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算