项目管理：如何用累积流图发现团队运行问题？

什么是累积流图？看这里

我们今天讨论的是一个真实发生的案例。

有问题的累积流图

这是一个刚刚接触敏捷开发方式的大项目，在一个迭代周期（两周）中的累积流图。

累积流图

对于了解敏捷开发和累积流图的读者来说，它反映出的问题非常明显且直接。

然而，对于没有接触过的人，可能就会认为“这个图很正常嘛，我们本来还没有上线，本来就应该是这样的。”

真的是这样吗？

在描述这些可能的问题之前，我们先介绍一下这个“刚接触敏捷的大项目”。

一个刚接触敏捷的大项目

为什么是“大项目” 呢？

• 团队成员多。这个项目团队由四个子领域团队组成，一共40+专职开发人员，每个子领域约有5～10+个开发人员不等，而且，每个领域又分成多个子模块。每个子领域都有一个核心组，由四个角色组成，他们分别负责：
  • 交付管理（Delivery Management，也就是子领域的全权负责人），
  • 产品管理（Product Management），
  • 技术管理（Tech Lead），
  • 内部项目管理（Internal Project Management）。

当然，这些只是角色，并非一定是四个不同的人员。

• 项目工作规模大。（1）项目周期预估需要几个月的时间，才能大规模推广使用；（2）项目内容需要全新开发，并非在现有产品上进行迭代；（2）项目是一个集成系统，（4）需要将多个原有系统集成在一起。

• 极少人有过敏捷开发经验。绝大多数团队成员以前都使用传统方式（或者原始本能方 式）进行软件开发，并未受过敏捷开发迭代指导。另外，即使有极少的几个具有敏捷迭代开发经验的成员。但是，他们分别来自于不同的背景，而敏捷迭代开发在行业内并无一个共识标准，每个人对实践的理解也各有不同。所以，团队需要一段时间进行协作磨合。

• 需要支持不同类型的客户软件项目。这些类型可以分为四个维度，分别是：

• 团队中没有专职测试人员。这是一个比较大的挑战。因为项目有人机交互界面，支持很多的客户角色，需要自己保证软件质量。

迭代节奏安排

在《持续交付2.0》一书中的第六章「业务需求协作管理」中，专门讨论过“迭代中的小 波浪交付”，也就是“小瀑布模式”。

为了避免这种不均衡的团队协作流，这个团队使用了下面的迭代节奏，如下图所示：

迭代节奏

累积流图的“一横一纵”

某个迭代的累积流图仍旧就如下所示，问题就表现在一横一纵上。

累积流图的一横一纵

这个累积流图反映出的直接问题是：「 WIP 过多」，而且，单个需求的交付周期较长。

一横，是指 Lead Time，也就是：单个需求的交付周期，如上图中的水平线所示。

一纵，是指WIP，即 Work In Process 。也就是：精益软件开发中所说的“在制品”，如上图的垂直线所示。

每个人都在努力，为什么还会发生这种事情？

这个新团队中的每个人都在努力工作，而且需求都被拆分成比较小的工作单元，为什么还会导致“在制品过多，交付周期过长”呢？

通常是因为团队中的各角色原有的工作惯性所致。例如：

（1）产品人员只负责分析需求；

（2）开发人员只忙于完成分配给自己的开发任务；

（3）很少有人及时对已完成需求进行质量验收。

这带来的后果就是：

在迭代结束的验收时，发现有很多需求因质量问题而无法验收，这就是所谓的“未完成的工作”。

而且，这个累积流图的最后一日，充分展示了这一点。

深层次的原因

更深层次的原因可能是：

• 安排了过多的工作量，这是最常见的原因。开发人员一直都是以“自己开发完成”来估计工作量， 通常不包含“高质量验收通过”。
• 盲目自信。大家都彼此相信“每个人都能够高质量交付工作”，并没有想过“无测试人员”带来的质量影响。
• 固守原有的角色职责。
  • 产品人员认为，质量验收工作不是自己的工作内容。
  • 开发人员认为，自己一定要做“高价值”的开发工作。自己的开发成果应该没什么大问题。
  • 项目交付负责人认为，子领域团队会自行安排好质量验收工作。
  • 测试环境很难使用，不方便对需求进行验证。

最后这个测试环境的问题在这个项目中尤其严重。

因为涉及到多个系统的集成，而要对这些系统建立稳定的测试环境，是非常棘手的事情。每个开发人员更想尽快完成安排给自己的工作，所以并没有去做环境管理这类公共事务。

当然，以上只是一部分可能的原因。

解决这类问题的方式就是：

（1）每个迭代少安排一些开发工作量。为了每个迭代都很平滑，开发人员也要参 与 下一迭代的需求准备工作。

（2）安排多个时间点进行质量验收，例如，每周三和周五。可组织PD，交付经理（如有必要，甚至是开发人 员）及时对已完成的需求进行质量验收。

（3）发现 Bug ，尽早修复，尽早验收。

（4）安排专人完成自动化创建测试环境的工作。

（5）一定要引入自动化测试。否则，每个迭代的手工质量验收工作量会越来越大。

没有“高质量要求”的迭代，所谓的“敏捷开发”，意义都不大。

即使用了所谓的“敏捷迭代流程”，这也会让所谓的“敏捷开发”变回“瀑布开发”，将质量风险延迟到项目后期。

也许，有人会抬杠，说：

「我们的软件还在初期，不要求高质量。」

那就忽略上面的内容吧～

另外，很多技术管理者也更倾向于开发更多的需求，而不是“更多高质量的需求”。