用看板管理软件开发流程

1. Scrum or Kanban?

做了多年软件,感觉软件开发的过程是没办法“管理”的。软件开发从本质上讲是一种理想的逻辑思维工作, 高水平的软件开发很大程度上取决于程序员个人的主动性、工作能力和学习能力。可是实际工作中又需要产品开发过程的可视化。可视化意味着:

  1. 做基本的产品功能计划。计划包括任务分解和时间估算。
  2. 了解产品开发过程中任务的完成状态。其中最主要的是工作量、开发速率和开发瓶颈。

目前较流行的软件流程管理方法有Scrum和Kanban(看板)。这二种方法侧重点不同:Scrum偏重固定周期交付一定的功能集合,看板侧重流程的可视化以及限制工作量带来的可持续交付能力。选择一种方法其实是对这种方法背后思考逻辑的认同。

如果一个团队用新技术开发一种新产品,而且团队成员有比较强的自我驱动能力,那么看板可能是一种更好的选择。原因如下:

  1. 对于新技术新产品,开发时间估算非常困难。与其在限定时间的Sprint(冲刺)去完成不能准确估算时间的功能模块,不如在连续的时间里尽心交付。
  2. 看板方法限制进行中的工作数量,不赶进度,有利于长期持续交付高质量产品。
  3. 可视看板界面简单、直观。看板方法比较容易理解,额外管理开销比较小。

2. 看板任务的颗粒度与分层

理想情况下,一个看板中各个任务的工作量比较接近,任务也有相同的状态流程。可是实际的软件开发却包含很多不同时间、不同种类、不同工作量的任务。 比如业务需求分析无论多少都是必须先有个大概了解才能进行其他工作,需求分析需要的时间不定。各种任务的颗粒度也有很大区别。我们既需要高层全局的把握,也需要了解每日的工作状态。

一旦我们把一个产品的业务需求(用户故事集合)在设计阶段分解为很多可以独立开发交付的子系统(通常是微服务模块),看板就可以提供子系统和具体模块开发过程的可视化。通常一个新产品的开发周期比较长,任务种类繁多,我们可以采用三层看板系统来提供可视化。第一层是颗粒度为一到三个月的产品看板,包含整个产品的所有子系统模块。一个子系统通常是一个微服务、中间件或用户界面等相对独立的模块。第二层是颗粒度为一到三周的子系统看板,所有正在进行中的子系统都有一个看板。第三层是颗粒度为一到八小时的开发看板,用于显示一个子系统中所有正在开发的模块。产品看板包括产品总体的需求分析、设计和各个微服务的拆解。子系统看板则包括单个子系统的的需求,设计和模块分解。开发看板是子系统中各个自模块的开发状态。

各个层次的关系是集合的整体和部分的关系,因而是同时进行,迭代增量更新的。开始的时候有个大概产品规划和大的系统框架,每个部分的功能和接口都比较模糊。产品看板的目的是梳理出子系统的依赖关系,确定大概开发顺序和时间。 子系统看板则是子系统的概要分析、设计和模块实施视图。开发看板则是每日的工作进度状态视图。上层看板的任务和状态会根据下层看板的状态改变有所增删改的调整。

3. 基于看板的开发流程

使用看板系统的基本原则是所有的产品开发工作都会首先反映在看板上。只有在看板上调度之后才能开始一项任务。任何任务状态的改变要及时反映在看板上。这样就达到了看板的二个主要目的:任务的调度与产品开发进程的可视化。

3.1 产品规划

这是产品开发的开始。主要工作是产品的基本功能描述,微服务功能的划分和技术栈的选择。在产品看板的任务列表(backlog)项目包括需求分析, 设计,以及各个微服务或子系统。其中分析和设计可能有多次,多次分析/设计按照目的不同的成为不同的工作任务。任务的状态包括:进行中,审核和完成。

3.2 子系统的规划

一旦某个子系统状态从任务列表改变为进行中,就需要建立一个微服务或子系统看板。和产品规划类似,需要对该微服务或子系统进行详细的需求分析、设计和模块划分。在子系统看板的任务列表(backlog)项目包括需求分析, 设计,以及各个子系统任务以及集成测试任务。任务状态包括:进行中,审核和完成。

3.3 模块开发

子系统模块划分完成后就建立开发看板。任务列表包括所有的模块以及比如集成测试等的相关任务。看板的状态包括进行中、审核、完成。

(revised on 2016-07-23)

Written on July 20, 2016