新团队，刚接触持续交付实践，遇到这种状况，怎么办？

“在引入新的工作模式时，需要更加注重原有工作惯性的改变。”

刚刚接触敏捷迭代开发的团队，

常常会出现一系列的反模式。

而这些反模式都是由工作惯性导致的。

这会让团队看起来在“敏捷开发”，

实际上并没有什么本质变化。

若不及时纠正，

没有达到预期效果不说，

很可能团队成员会有很多抱怨。

例如：

“换汤不换药”，“ 纯粹在折腾人”…… 

“形式主义”，“ 浪费时间”……

下面我们就来看看，如何发现这些“工作惯性”。

累积流图就是有效的识别工具之一。

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

对于了解敏捷开发和累积流图的读者来说，

它反映出的问题非常明显且直接。

然而，对于没有接触过的人，

可能就会认为：

“这个图很正常嘛，我们本来还没有上线，本来就应该是这样的。”

真的是这样吗？

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

为什么是“大项目” 呢？

1、团队成员多

这个项目团队由四个子领域团队组成，

一共40+专职开发人员，

每个子领域约有5～10+个开发人员不等， 

而且，每个领域又分成多个子模块。

每个子领域都有一个核心组，

由四个角色组成，他们分别负责：

• 交付管理（Delivery Management），

• 产品管理（Product Management），

• 技术管理（Tech Lead），

• 内部项目管理（Internal Project Management）。

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

2、项目工作规模大

• 项目周期预估需要几个月的时间，才能大规模推广使用；

• 项目内容需要全新开发，并非在现有产品上进行迭代；

• 项目是一个集成系统， 需要将多个原有系统集成在一起；

3、极少人有过敏捷开发经验

绝大多数团队成员以前都使用传统方式（ 或者原始本能方式）进行软件开发，并未受过敏捷开发迭代指导。

另外，

即使有极少的几个具有敏捷迭代开发经验的成员，

但是，

他们分别来自于不同的背景，

而敏捷迭代开发在行业内并无一个共识标准，

每个人对实践的理解也各有不同。

所以，团队需要一段时间进行协作磨合。

4、需要支持不同类型的软件项目

这些类型可以分为四个维度，分别是：

• 业务类型

• 软件形态

• 基础设施

• 编程语言

5、团队中没有专职测试人员

需要自己保证软件质量。

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

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

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

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

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

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

这个新团队中的每个人都在努力工作，

而且需求都被拆分成比较小的工作单元，

为什么还会导致“在制品过多，交付周期过长”呢？

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

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

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

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

这带来的后果就是：

在迭代结束的验收时，

发现有很多需求因质量问题而无法验收，

这就是所谓的“未完成的工作”。

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

更深层次的原因可能是：

1）安排了过多的工作量，这是最常见的原因。开发人员一直都是以“自己开发完成”来估计工作量， 通常不包含“高质量验收通过”。

2）盲目自信。大家都彼此相信“每个人都能够高质量交付工作”，并没有想过“无测试人员”带来的质量影响。

3）固守原来的职责。

• 产品人员认为，质量验收工作不是自己的工作内容。

• 开发人员认为，自己一定要做“高价值”的开发工作。自己的开发成果应该没什么大问题。

• 项目交付负责人认为，子领域团队会自行安排好质量验收工作。

4）测试环境很难使用，不方便对需求进行验证。

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

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

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

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

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

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

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

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

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

即使用了所谓的“ 敏捷迭代”，

这也会让所谓的“敏捷开发”变回“瀑布开发”，

将质量风险延迟到项目后期。

也许，有人会抬杠，说：

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

那就忽略上面的内容吧～

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

以上各类问题的解决方案，尽在乔梁所著的畅销书

《持续交付2.0(增订本)》

为组织转型领导者

提供体系化方法论

乔梁老师开课啦~视频课程《持续部署实战解析（Golang版）》， 限时特价！

（扫码订阅）