Kanban是一种流行的框架,用于实施敏捷DevOps软件开发。它需要实时沟通的能力和完全透明的工作。工作内容在Kanban Board上直观地表示,允许团队成员随时查看每项工作的状态。


Kanban在当今的敏捷和DevOps软件团队中非常重要,但Kanban的工作方法可以追溯到几十年前。在1940年代后期,丰田开始根据超市用来存放货架的相同模型优化其工程流程。让超市库存的产品刚好能满足消费者的需求,这种做法优化了超市和消费者之间的物流。由于库存水平与消费模式相匹配,超市通过减少在任何给定时间必须持有的过剩库存量来显着提高库存管理效率。同时,超市仍然可以确保消费者需要的产品始终有货。

当丰田将同样的系统应用到其工厂车间时,目标是更好地将其庞大的库存水平与材料的实际消耗保持一致。为了在工厂车间(以及与供应商)实时沟通产能水平,工人将在团队之间传递一张卡片或“Kanban”。当生产线上使用的一箱材料被清空时,一个Kanban被传递到仓库,描述需要什么材料,这种材料的确切数量等等。仓库收到请求之后,将这种材料发送到工厂车间,同时将他们自己的Kanban发送给供应商,等待供应商补充这种材料。供应商就将这种材料运送到仓库,同时开始使用这种材料的原料进行制作,并等待采购新的原料。虽然这种信号传递的技术来自1940年代,直到今天,制造流程的核心仍然是需求与供给“刚好匹配”。

软件开发团队的Kanban

如今的软件开发敏捷团队将相同的“刚好匹配”原则用于将正在进行的工作 (WIP) 与团队的能力相匹配。这为团队提供了更灵活的规划、更快的输出、更清晰的重点和整个开发周期的透明度。

虽然该框架的核心原则与时代无关,并且几乎适用于所有行业,但软件开发团队在敏捷实践中取得了更显著的成功。部分原因是,一旦软件团队了解了基本原则,他们就可以开始以很少甚至没有开销的方式进行实践。与在工厂车间实施Kanban会涉及更改物理流程和添加大量材料不同,软件团队唯一需要的物质就是board和card,甚至这些都可以是电子化的。


Kanban board

所有Kanban团队的工作都围绕着Kanban board,这是一种用于工作可视化并优化团队之间工作流程的工具。虽然物理板在某些团队中很受欢迎,但电子板是任何敏捷软件开发工具中的一个关键功能,因为它们具有可追溯性、更容易协作以及可从任何地点访问。

无论团队的board是实体的还是电子的,它们的功能是确保团队的工作是可视化的,他们的工作流程是标准化的,并且所有的瓶颈和依赖都能被立即识别和解决。初级的Kanban board具有三步工作流程:待办、处理中和完成。不过,根据团队的规模、结构和目标的不同,任何团队的独特流程都可以通过设置工作流来满足。

Kanban方法论依赖于工作的完全透明和实时沟通的能力。因此,Kanban board应该被视为团队工作的唯一真实来源。


Kanban card

Kanban表示了一种视觉信号。让无形的工作可视化,对于Kanban团队,每个工作项都表示为board上的单独卡片。

在Kanban board上将工作表示为卡片的主要目的是让团队成员以高度可视化的方式通过其工作流程跟踪工作进度。卡片包含有关该工作项的关键信息,使整个团队能够全面了解负责该工作项的人员、正在完成的工作的简要描述、估计该工作需要多长时间等等。电子板上的卡片通常还会包含功能截图和其它对经办人有价值的技术细节。允许团队成员在任​​何时间点,对每个工作项的状态以及所有相关细节都可见,确保提高关注度、完全可追溯以及快速识别瓶颈和依赖关系。

Kanban的好处

Kanban是当今敏捷团队采用的最流行的软件开发方法之一。Kanban为各种规模团队的任务计划和完成提供了以下几个的好处。

计划灵活性

Kanban团队只专注于正在进行的工作。一旦团队完成了一个工作项,他们就会从backlog的顶部取出下一个工作项。因为当前工作项之外的任何更改都不会影响团队,Product Owner可以在不干扰团队的情况下自由地重新排列待办事项中的工作优先级。只要Product Owner将最重要的工作项排列在待办事项列表顶部,开发团队就可以确保他们正在为业务带来最大价值。所以不需要像Scrum中一样按固定周期进行迭代来计划工作任务。

提示:

高明的Product Owner在考虑更改待办事项时总是与开发团队合作。例如,如果用户故事1-6在待办事项中,则用户故事6的预估可能基于用户故事1-5的完成情况。与开发团队确认变更始终是一个很好的做法,以确保没有意外。 

缩短时间周期

周期时间是Kanban团队的一个关键指标。周期时间是一个工作项经历团队工作流程所花费的时间——从工作开始到交付的那一刻。通过优化周期时间,团队可以自信地预测未来工作的交付时间范围。

相同技能被多个团队成员掌握,可以获得更小的周期时间。当只有一个人拥有某一项技能时,这个人就会成为工作流程中的瓶颈。因此,团队应采用能传播技能的基本最佳实践,如代码审查和指导来帮助传播知识。共享技能意味着团队成员可以承担异构工作,从而进一步优化周期时间。这也意味着,如果出现工作瓶颈,整个团队可以蜂拥而至,让流程再次顺利进行。例如,测试不仅由QA工程师完成,开发人员也能参与其中。

在Kanban框架中,整个团队都有责任确保工作在整个过程中顺利进行。

更少的瓶颈

同时处理多个任务会降低效率。在任何一个时间段进行的工作项越多,工作场景切换就越多,这阻碍了工作项的完成路径。这就是为什么Kanban的一个关键原则是限制在制品(WIP:Work-in-progress)的数量。当缺乏重点、人员或技能时,在制品限制会突出显示团队流程中的瓶颈。

例如,一个典型的软件团队可能有四种工作流状态:待办、处理中、代码审查和完成。他们可以选择将代码审查状态的WIP限制设置为2。这似乎是一个很低的限制,但有充分的理由:开发人员通常更喜欢编写新代码,而不是花时间审查别人的工作。低的限制,可以鼓励团队特别关注在审查状态下任务,并在提出自己的代码审查请求之前审查其他人的工作。这最终减少了整个周期时间。

视觉指标

核心价值观之一是强烈关注在工作中持续不断地提高团队效率和效力。图表为团队提供了一种视觉机制,以确保他们不断改进。当团队可以看到数据时,就更容易发现流程中的瓶颈,并消除它们。Kanban团队使用的两种常见报告是控制图和累积流图。

控制图显示每个任务的周期时间以及团队周期时间的滚动平均值。

提示:

团队的目标是减少任务在整个过程中移动的时间。在控制图中看到平均周期时间下降是成功的标志。 

累积流图显示了每个状态上的任务数量。团队可以通过查看某个状态下问题数量的增加现象,来轻松发现瓶颈。诸如“In Progress”或“In Review”等中间状态的任务尚未交付给客户,当工作确实被上游处理完成时,这些状态中的任务积压可能会增加大规模集成冲突的可能性。 


持续交付

持续交付(CD)是频繁向客户交付工作价值的做法。持续集成 (CI)是一种全天候自动构建和测试代码的做法。它们共同形成了一个CI/CD流水线,这对于开发团队(尤其是DevOps团队)在确保高质量的同时更快地交付软件至关重要。

Kanban和CD完美地融合,因为这两种技术都专注于及时和单一地交付价值。团队越快将创新推向市场,他们的产品在市场上的竞争力就越大。Kanban团队精准地专注于这一点:持续优化向客户交付价值的工作流程。

Scrum与Kanban

Kanban和Scrum有一些相同的概念,但有非常不同的方法。它们不应该相互混淆。


SCRUM

Kanban
节奏

固定时长的定期Sprint(比如每2周)

持续流动
发布方法在每个Sprint结束时由Product Owner决定是否发布持续交付或由团队自行决定
角色Product Owner、Scrum Master、开发团队没有预先定义的角色。一些团队会和敏捷教练共同商定角色。
关键指标速度(Velocity)周期时间(Cycle Time)
变更处理团队应努力在Sprint期间不更改Sprint的计划,这样做会影响对计划的承诺,团队士气和信任度都收到冲击变化可以随时发生


一些团队将Kanban和Scrum的理念融合到“scrumban”中。他们从Scrum中获取固定时长的Sprint和角色,并从Kanban中关注WIP限制和周期时间。但是,对于刚开始使用敏捷的团队,我们强烈建议选择一种方法或另一种方法并使用它运行一段时间。熟练掌握方法以后再进行新的尝试。