1.缩短平均周期时间

排队理论（Little’sLaw）是约翰·利特尔（JohnLittle）于1961年提出的，是一个有关周期时间与在制品关系的简单数学公式，这一法则为精益生产的改善指明了道路。Little’slaw的原始公式如下。

吞吐率（Throughput）=在制品（WIP）÷平均周期时间（AverageLeadTime）

另一种表达方式如下。

平均周期时间=在制品÷吞吐率

例如，一个团队的交付速率是平均每个月交付20个特性，假设你作为产品负责人提出一个新特性，那么团队需要多久能完成这个新特性呢？

假定Backlog里有60个特性在排队，如果你提的新特性不插队，那么你需要等待的时间是3个月（60个特性÷20个特性/月）。

对于客户来说，他们非常期望缩短产品或服务的交付周期时间，也就是说，让他们等待的时间越短越好。遗憾的是，在我们的软件行业，很多组织和团队为了缩短周期时间，采取的方法往往是加班或加人。

迈克尔·科思用自己的项目做过试验。他的团队从第二周迭代开始加班，加班后的这一周产出速率较第一周提高了很多，但是从第三周开始速率下降；到了第四周，速率继续下降；到第五周的时候，速率已经降到低于第一周。如果对于已经有加班习惯的团队来说，在此基础上继续延长工时，也会有同样的结果，即短期内的产出会有所提升，但是长期不会再有效，甚至会降低产出。

早在1975年，小弗雷德里克·布鲁克斯（FrederickP.Brooks.Jr.）在其所著的《人月神话》（TheMythicalMan-Month）中就提出过一个经典观点：给一个已经延期的软件项目增加人力，会让这个项目更延期。不幸的是，大家仍旧将“加人”当作救命稻草。

真正能够从本质上提升效率的方法是投资敏捷技术实践，比如自动化测试、持续集成、加速构建效率、持续交付、自动化运维等技术。这些方法对效率的提升会有很大帮助，但是需要一定的时间和资源成本的投入。

大部分团队习惯在排队理论公式中的“吞吐率”上下功夫，却忽视了在制品限制。如果将在制品数量控制在最低限度，那么即便在吞吐率没有显著提升的情况下，也会对平均周期时间起到立竿见影的效果。

2.打破在制品堆积的恶性循环

在制品持续堆积会对产品和客户都产生极大的副作用，而且可能会形成一个连锁反应，如图7-18所示。

（1）在制品在某个流程环节或所有流程环节堆积，势必造成相应流程环节的周期时间变长，从而导致总的交付周期延长。

（2）某个流程环节的周期时间变长，会导致产品质量反馈慢；产品总的交付周期延长，会导致用户或客户的反馈周期延长。

图7-18在制品堆积的连锁反应

（1） 产品质量反馈慢（例如，开发团队提交了代码后，大量需求等待测试）会造成缺陷堆积。而在批量修复的过程中，开发工作又会引入新的缺陷，进而上线后有成批的缺陷产生，致使产品质量差。测试工程师将在产品测试中或上线后发现的批量缺陷都返回给开发团队，使其成为产品Backlog的一部分，这在无形中又增加了在制品数量，使在制品堆积更加严重。

（2） 创新产品得到用户验证前，很多时候团队实际在做自己“假设有价值”的需求。如果那些“假设有价值”的需求长时间得不到用户的反馈，团队就无法调整方向，导致很多未经验证的低价值或无价值的需求源源不断地进入Backlog，从而进一步增加了在制品的数量。同时，这些需求会与那些对用户真正有价值的需求争夺宝贵的研发资源。

（3） 产品质量差，同时业务响应慢，必然导致用户或客户对产品的满意度降低。

团队可以通过限制在制品数量，打破这个恶性循环，如图7-19所示。

图7-19在制品限制产生的正向连锁反应

（1）限制在制品数量，会让产品特性的交付周期缩短。

（2）交付周期缩短，会让产品质量的反馈周期以及用户或客户的反馈周期缩短，从而使团队响应业务的速度变快。

（3） 当质量的反馈周期缩短后，从测试和线上返回开发的缺陷会减少，从而产品质量会有所提升。

（4） 从测试和线上返回开发的缺陷减少，在团队的Backlog里排队的缺陷就会减少，从而使在制品数量降低。

（5）用户或客户的反馈周期缩短后，那些未经验证的无用的或低价值的需求也会减少，从而间接地使在制品的数量降低。

（6）产品质量的提高，同时团队对业务响应的速度变快，必然会提升用户或客户对产品的满意度。

1.缩短平均周期时间

排队理论（Little’sLaw）是约翰·利特尔（JohnLittle）于1961年提出的，是一个有关周期时间与在制品关系的简单数学公式，这一法则为精益生产的改善指明了道路。Little’slaw的原始公式如下。

吞吐率（Throughput）=在制品（WIP）÷平均周期时间（AverageLeadTime）

另一种表达方式如下。

平均周期时间=在制品÷吞吐率

例如，一个团队的交付速率是平均每个月交付20个特性，假设你作为产品负责人提出一个新特性，那么团队需要多久能完成这个新特性呢？

假定Backlog里有60个特性在排队，如果你提的新特性不插队，那么你需要等待的时间是3个月（60个特性÷20个特性/月）。

对于客户来说，他们非常期望缩短产品或服务的交付周期时间，也就是说，让他们等待的时间越短越好。遗憾的是，在我们的软件行业，很多组织和团队为了缩短周期时间，采取的方法往往是加班或加人。

迈克尔·科思用自己的项目做过试验。他的团队从第二周迭代开始加班，加班后的这一周产出速率较第一周提高了很多，但是从第三周开始速率下降；到了第四周，速率继续下降；到第五周的时候，速率已经降到低于第一周。如果对于已经有加班习惯的团队来说，在此基础上继续延长工时，也会有同样的结果，即短期内的产出会有所提升，但是长期不会再有效，甚至会降低产出。

早在1975年，小弗雷德里克·布鲁克斯（FrederickP.Brooks.Jr.）在其所著的《人月神话》（TheMythicalMan-Month）中就提出过一个经典观点：给一个已经延期的软件项目增加人力，会让这个项目更延期。不幸的是，大家仍旧将“加人”当作救命稻草。

真正能够从本质上提升效率的方法是投资敏捷技术实践，比如自动化测试、持续集成、加速构建效率、持续交付、自动化运维等技术。这些方法对效率的提升会有很大帮助，但是需要一定的时间和资源成本的投入。

大部分团队习惯在排队理论公式中的“吞吐率”上下功夫，却忽视了在制品限制。如果将在制品数量控制在最低限度，那么即便在吞吐率没有显著提升的情况下，也会对平均周期时间起到立竿见影的效果。

2.打破在制品堆积的恶性循环

在制品持续堆积会对产品和客户都产生极大的副作用，而且可能会形成一个连锁反应，如图7-18所示。

（1）在制品在某个流程环节或所有流程环节堆积，势必造成相应流程环节的周期时间变长，从而导致总的交付周期延长。

（2）某个流程环节的周期时间变长，会导致产品质量反馈慢；产品总的交付周期延长，会导致用户或客户的反馈周期延长。

图7-18在制品堆积的连锁反应

（1） 产品质量反馈慢（例如，开发团队提交了代码后，大量需求等待测试）会造成缺陷堆积。而在批量修复的过程中，开发工作又会引入新的缺陷，进而上线后有成批的缺陷产生，致使产品质量差。测试工程师将在产品测试中或上线后发现的批量缺陷都返回给开发团队，使其成为产品Backlog的一部分，这在无形中又增加了在制品数量，使在制品堆积更加严重。

（2） 创新产品得到用户验证前，很多时候团队实际在做自己“假设有价值”的需求。如果那些“假设有价值”的需求长时间得不到用户的反馈，团队就无法调整方向，导致很多未经验证的低价值或无价值的需求源源不断地进入Backlog，从而进一步增加了在制品的数量。同时，这些需求会与那些对用户真正有价值的需求争夺宝贵的研发资源。

（3） 产品质量差，同时业务响应慢，必然导致用户或客户对产品的满意度降低。

团队可以通过限制在制品数量，打破这个恶性循环，如图7-19所示。

图7-19在制品限制产生的正向连锁反应

（1）限制在制品数量，会让产品特性的交付周期缩短。

（2）交付周期缩短，会让产品质量的反馈周期以及用户或客户的反馈周期缩短，从而使团队响应业务的速度变快。

（3） 当质量的反馈周期缩短后，从测试和线上返回开发的缺陷会减少，从而产品质量会有所提升。

（4） 从测试和线上返回开发的缺陷减少，在团队的Backlog里排队的缺陷就会减少，从而使在制品数量降低。

（5）用户或客户的反馈周期缩短后，那些未经验证的无用的或低价值的需求也会减少，从而间接地使在制品的数量降低。

（6）产品质量的提高，同时团队对业务响应的速度变快，必然会提升用户或客户对产品的满意度。