看板在行动(Kanban in Action)

作者:DavidAnderson 原文
翻译:ZhangV 2007-11-26

之前,在讨论我在corbis所使用的软件工程管理方法时 ,我曾提到引入看板系统来维持项目运行。因为它的引入,我们现在每个月平均发布两个新的版本。然而,这些并没有使用传统的敏捷开发方法如两周迭代(two week iteration)或快速迭代(sprint)。而是用看板系统来管理变更请求(CR-Change Request)。当CR被完成时,它被设在准备发布状态,并在每周三被发布。

尽管我们让没有用Visual Studio的开发人员使用了outlook的teamlook客户端联入Team Foundation Server跟踪所有CR,但基本上的日常工作,我们都是使用白板作为看板来跟踪所有CR,把Post-It当作看板卡。

我们的支持过程是由一组常见的软件工程资源驱动的,没有一个专职的支持维护团队。通过设置看板,我们可以向管理层保证 – 我们正在履行我们的承诺,我们使用了一定的资源来进行支持活动,而不需要特别指出是谁在负责。

每天早会上所有团队成员会围绕看板来进行当天的工作安排,讨论进度和当前存在的问题。达伦戴维斯,作为项目经理,会主持会议,并分析每张卡片并与其他成员讨论。每张卡上写着CR的标题以及ID,及负责人的名字。每个负责人有责任根据当前CR的进行阶段移动相应CR的卡片。达伦利用每天的早会来保证Team Foundation Server上的数据和看板是同步的。该看板系统基本上是自我组织(self organizing),但整个团队每天都会验证它的有效性。

一些关键概念。红星 – 这个任务已经严重超时的,超过28个工作日服务水平协议( SLA),通过该系统。这使”迟到”的项目能够自我加速,不需直接管理干预。粉红色卡表示这个CR在Team Foundation Server里还是open的。这些粉红色卡包含了描述信息和在Team Foundation Server里的ID 。还有一些其他类型的卡片:黄色-客户提出(customer-valued)的CR;蓝色-客户提出(和要求)的BUG;绿色-IT维护项,如:的sql 2005的升级;橙色-新增(或额外)的BUG;粉红-issue。

看板限制卡片最多只能有20张,分为不同阶段,系统的分析,开发,测试,构建/合并,部署。此外,我们也允许有3个bug可以放在任何地方。这样可以有效地利用闲散资源。当人手不够的时候,我们会减少这个数量,或者干脆不要。此外,还有两个维护项,这让我们能解决固定分配一些资源到大大系统维护和升级,例如API版本升级,与平台的升级。 如net2.0或sql server 2005 。

看板赋予我们三个成功要素:

  • 减少“进行中(work-in-progress)”, (讽刺的是,这些事情本身会限制工作的完成)
  • 量入而出(如果有新的CR,首先看看板上有没有足够的空间)
  • 确定优先顺序

我们每周和公司的技术总监开会讨论,决定任务的优先等级。他们从后台日志中拿出新的CR并考虑怎么把他们配置到看板上。这迫使他们思考哪些是最重要的事情。看板强迫他们给出优先等级。

看板还把我们从定时迭代的压迫(constraints of time-boxed iterations)中解放出来。尽管我们现在每两个星期发布一个新版本,大的任务可以在系统中最多可以存在60天。那些对于“一(两)周迭代”来说太大的任务同样可以放到看板里,而不需要特殊对待。

最后,看板解放了我们,我们不再把每个迭代都当作一个小型的项目而投入过多的管理成本它基本上是自行组织和管理,除非有特殊情况出现,如需要加快请求或因环境或系统的维修问题变更发布时间。

technorati的标签:敏捷,朱+安德森,精益生产,看板,软件+工程

顺便问一下customer-valued怎么翻译?

最后修改:2009-8-12

Comments are closed.