第三章 根除低下的效率

    击鼓传花

    让我们举个更贴切的例子——产品团队的结构。在传统的产品开发与新兴的敏捷拥趸者之间形成了一个战场。谁是对的呢？管它呢！但绝对不要单独地在某一步骤上进行优化——向着期望的结果进行优化。

    期望的结果可以在最短的时期内带来大量的客户价值。记住，客户价值是不可用功能多少来度量的，是通过提供令人满意的高质量的点对点体验来度量的。

    那么你如何快速地提供高质的价值呢？凭借约束理论（Theory of Constraints，TOC）。约束理论认为一项工程以最快的速度达到目的的方法取决于其中最慢的那一个步骤，比如用户体验、内容发布及团队间共享的可以满足你的需求的操作方法。你的项目经理可能会在规范书中指定一个月内平均完成4项软件功能，开发团队能在一个月内完成2项功能，而测试团队一个月能检测3项功能。要达到项目经理要求的速度，条件还远远不够，对吗？

    但是，产品经理们督促项目经理继续写些开发团队无法处理的规范书——优化局部而不是总体。为开发团队添置人力也无济于事（按：《人月神话》与《经济组织》）——同样，眼界太窄了。

    正确的做法是，项目经理与测试团队要与开发团队齐头并进。在各个项目功能间留有足够的余地以保持其机动性，但绝不要让项目经理及测试团队的进度快于开发团队。这种约束理论的策略称为：鼓—缓冲—绳子（Drum Buffer Rope）。因为很难准确预测开发团队的进度，所以你要限制项目功能间的空间，在情况改变的时候，避免开发团队的队列中有太多的工作。

    这就是为什么功能小组能行之有效。向着期望的结果进行优化——工作实例，在功能小组中——Office项目采取的方式——项目经理、开发人员以及测试人员在某一个实例中精诚合作，直到完成测试及集成。他们谁也不能跑到别人前头去。Scrum团队与敏捷编程团队要有相同的工作原则。不是简单的团队组合就完美了（虽然他们间的沟通很容易），是要一起步调一致，不断优化产品，为产品带来完善的、高质量的客户价值。

    作者注：有读者指出软件开发中的关键制约因素是通信带宽。增加通信带宽的最好办法是使团队同处一地，使他们基于功能点对点一起工作。这种方法同样对提升工作进度有效，就如我之前所说。一些Scrum团队也会采用看板模式，这是一种以更简单更直观的方式应用鼓—缓冲—绳子策略的方法。

    不要怨天尤人

    对眼前出现的问题往往很容易就会“一见倾心”并马上进行优化，而不是对你实际应该关心的其他问题进行优化。人们向来如此——我怀疑我们与生俱来就是这样的。这确实是优化错误的做法得出错误的结果这种做法的最好理由，但是这个借口太牵强。

    你应该明白这个道理，如果你没有，你就没有权力兑现一张支票。想想你期望得到的结果，考虑周全，权衡各因素之间的轻重，在总体上进行优化。这并没那么难。我们每天都这么做，就像我们为我们的人生寻找一种均衡。关键是要深思熟虑而不是耍滑头，要早做计划而不是怨天尤人。你做得到，只要单单地将你的目光盯住终点线。