每个迭代总是完不成计划的工作？

你所在的项目是否常常完不成迭代计划？你是否总在思考如何给每个迭代增加产能？在每个迭代的时间、人力都相同的情况下，到底如何产生更多价值工作？答案也许是，做好质量内建！

精益软件开发的经济学成本模型

下图是看板方法之父大卫.J.安德森在他的《看板方法》一书中提出的精益软件开发的经济学成本模型。

精益软件开发的经济学成本模型

图中所示的是在一个迭代中，项目中若干类型的活动的分布。翻译成公式来理解如下：

V = c + 2e + I
I = i + d

V代表value，即产能，是模型中最大的矩形，代表我们一个迭代能够完成的所有工作；
c代表coordination，即协调成本，是模型中红色部分，它被认为是一个高成本事情，占据一定产能。放到一个迭代中来看的话，协调成本分布在整个迭代周期中，不随时间推移而增加或减少；
e代表event，即事务成本，是模型中的蓝色部分，占据另一部分产能。放到一个迭代中来看的话，事务成本分布在迭代的开始和结束，这些事务成本不因时间推移而增加或减少，是固定成本；
大写I代表increment，即总体增值工作，是模型中的绿色矩形部分，它是一个迭代实际为客户交付的价值；
小写i代表纯增值工作，即模型中的纯绿色部分，是按照预期交付的增值工作；
d是damage，即破坏负载工作，是模型中的紫色部分，它是打乱正常工作节奏的非预期中的工作。破坏负载工作存在于绿色矩形之中，代表它也会为客户交付价值，但是它产生的价值是包含在总体增值工作当中的，它并没有产生新的价值，且破坏负载工作会随着时间的推移而增加成本，会进一步压缩纯增值工作的空间。

如何增大增值工作空间

如何让每个迭代的增值工作空间更大？从模型中推导出，可以采取的方式有，压缩事务成本空间和协调成本空间，减少破坏负载工作。

减少事务成本？

项目在开始时的准备成本和结束后的清理成本都可以归为事务成本。在敏捷软件开发模式下，每个迭代初的事务成本有迭代计划会议、估点会议；每个迭代结束的事务成本有showcase会议、回顾会议等。这些事务成本并不会带来额外增值，但这些成本是必须的。迭代初的事务成本是为工作良好开展做准备，迭代末的事务成本是为工作结束做确认和总结。用精益的术语来说，他们是必要的浪费。

减少协调成本？

当两个人或者更多人一起试图达成一个共同目标时，就需要协调。项目中任何涉及沟通和日程安排的活动，都会产生协调成本。每个迭代的协调成本有每日站会、以及各类会议时间地点的协调、编写邮件或者即时消息同步工作状态或者寻求工作帮助等。每日站会、敏捷软件开发中的卡墙、以及我们常常挂在嘴边的一切透明原则，本质上都是为了减少协调成本。

当多个迭代运行下来，事务成本和协调成本基本已经稳定，压缩空间几乎没有，那能释放增值空间的就只有破坏负载工作了。

破坏负载工作

何为破坏负载工作

破坏负载工作，指的是那些如果早前的交付具备更好的质量而本可避免的工作。这些工作包括返工和缺陷。

如何减少破坏负载工作

由于破坏负载工作会随着时间的推移，占用更多的增值工作空间，所以这类工作我们需要尽早识别，并且避免此类工作。而质量内建可以尽早识别返工和bug，从而消灭或者减少破坏负载工作。

返工最常见的情况是需求变更。我认为应对需求变更的根本方式是，交付有价值的需求。整个团队要关注交付的价值是什么，而不是交付的功能是什么。价值是敏捷项目管理三角的其中一角，同时也是质量内建的基础。当我们关注点在交付价值，才更能提早发现低价值甚至无价值的需求，从而减少需求变更。这似乎也给QA带来了一些新的视角，稳定的需求也可以是一条质量度量标准。

缺陷最常见的情况是每个迭代过程中产生的bug。质量内建活动，比如持续集成、测试先行、重构、code review、代码共有、代码即文档等能够提高代码质量，减少bug产生或尽早发现bug，从而减少破坏负载工作。