提高软件开发生产力的秘方

　　虽然前面列举了众多“学习”方面的实践的例子，敏捷团队并不是对学习瓶颈免疫的。有时候在紧迫的任务的压力下，我们会为了短期的利益而跳过学习的步骤（“哦，我们以后会补上”）。在学习上失败的敏捷团队会表现出以下部分或全部症状：

　　◆疲劳（没有依照可持续的节奏来工作）导致士气问题，

　　◆再三地无力在一次迭代中“搞定”，

　　◆持续地让承诺落空（甚至有些承诺的特性和用户故事根本还没动手），

　　◆部署的软件持续地出现缺陷，缺陷之多使得开发计划完全脱离轨道，

　　◆否定回顾的价值，放弃回顾（“因为我们从来都没办法解决发现的问题”）。

　　让你的眼睛盯住瓶颈

　　请看下图：在每个步骤的名称下面的括号里是一个表示速度的数值。两个步骤速度不一致的时候就会产生积压（Inventory）——由于步骤A比步骤B快，A的过剩产品要等待B的处理。整个系统的产出总是为瓶颈所限[5]。也就是说，如果你希望提高整个系统的总体产出，你几乎只需要提高瓶颈部分的表现。在其他地方花功夫纯属浪费，甚至可能起到反作用。这意味着对于下图中的简单顺序过程（SSP），我们唯一的改进办法是调整步骤D。处理其他地方并不能改进系统产出。

　　简单顺序过程

　　如果学习过程确实是软件开发的瓶颈，那么它应该排在我们优先队列的第一位。也就是说我们花功夫在其他地方只会得到非常有限的生产力提高。倒过来说，这意味着任何提高我们的生产力的事物都在某种程度上提高了我们的学习效率。