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需要整合地测试界面和服务,这些界面和服务有助于组合利用不同的系统、平台以及相关安全标准。要测试这些应用程序时,就提出了独特挑战。那么如何应对这些挑战呢?下面我们来具体看一下。

  • 复杂事件处理CEP手册

    在金融服务和其他行业中,如何使那些重要且具有战略意义的业务信息以高速数据流的方式到达企业变得尤其重要,而复杂事件处理(CEP)就是这一过程的代名词。在复杂事件处理中,数据是不断变化的,而“操作”是“静态”的。复杂事件处理具备了分析高速数据流并鉴别重要事件的能力,虽然对这些事件的鉴别过程是复杂的,但结果却是无价的。复杂事件处理能够帮助企业及时全面地洞察市场变化,降低风险和提高决策效率。下面我们就来介绍一下复杂事件处理。

  • SOA管理

    SOA管理是经常谈论的一个话题,不管你的组织开始SOA多长时间,SOA管理都是需要多加注意的。首先我们需要弄清SOA管理与SOA治理的区别。

  • 面向服务架构SOA与相关技术

    面向服务的体系结构(service-oriented architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 

    这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。

TechTarget

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