规划和掌控复杂项目

在复杂的大型敏捷项目方面，我所拥有的 10 年以上的经历所见：一般来说，人们都是基于对开发成果的预测，进行规划和编制预算。很多时候，开发团队对故事进行了估算，但整个项目的预算却又与该估算相互独立。特别是在复杂项目中，这往往会带来出乎意料的结果（不欢迎的）。面对这些问题，对 Daniel Kahneman 和超越预算理论那伙人的工作进行学习，非常有助于让我更好地理解规范、估算和预算编制之间是如何联系的，以及为何传统方法行不通。当然，我们都知道这些在小项目中是如何运作的，也知道如何通过迭代规划和控制一个项目。然而，我们如何决定赞成还是反对一个项目，如何定义启动某个大型项目的预算，以及如何知道我们的微小迭代（跨越许多特性团队）如何融入长期的项目目标？请注意，我并不是在说小型或常规项目，而是指那些拥有 50 到 300 开发者、持续例如 3 到 5 年才能完成的大型项目，或类似规模的大型产品（产品线）开发。

预测并不可靠

诺贝尔经济学奖获得者 Daniel Kahneman——尽管他是一位心理学家——得到了这样的结论：大部分事情的发生都基于巧合。他给出的例子之一与过去的历史有关——发展成为阿道夫希特勒的那枚胚胎，其实有 50% 的可能诞生的是一位女性。谁知道这个历史分支的不同走向，会对之后世界百年历史产生何种影响？这意味着要想预测复杂的事情是不可能的。

此外，Kahneman 也收集了来自从事该领域研究的同事们的类似工作成果，以验证他的观点。例如，宾夕法尼亚大学的心理学家 Philip Tetlock，收集了超过 8 万条政治和经济学方面的预测。请注意，做出这些预测的人，正是以此为生。因此我们谈论的是一些真正的专家！问题是，这些预测甚至比运用正态分布曲线得出的预测结果还要糟糕。但当被证明预测出错的时候，鲜有人承认自己的预测是错的。大部分专家开始找借口或理由，来解释为什么他们认为自己实际上是对的，只不过时机出了问题——但他们不会提供任何推论，来说明什么类型的时机是正确的。

在另一项研究中，伯克利大学的经济学教授 Terry Odeon 分析了大约 1 万份代理结果，其间涵盖了 16.3 万份交易。关于经纪费用，有趣的一面是，在每次交易中都必定有人相信卖掉股票或其他什么会更有利，同时也会有人相信买入更有利。然而，交易双方一般都被认为是该领域的专家。在这份分析中，Odeon 发现，与买入相比，卖出股票的表现要好 3.2%。

在最后一个例子中，我想提到的是一件基于 Kahneman 自身经历的事情。他过去曾为以色列军方服务。在那里他创造了一项测试，供他和他的团队来评估候选者的军旅职业生涯。我们或许可以很清晰地想象出，在面试之后参加这项测试时，候选者必须解决一些非常困难的问题、搭建一些东西，克服一些东西，而这种方式让谁领先、谁反对、谁是一位好的团队成员等结果都变得“显而易见”。通过在测试中观察申请者，Kanneman 和他的团队总是会对申请者的进一步资格认证树立起高度的自信。然而，每隔几个月他们从指挥官那里获得的反馈都会指出，其评估结果仅仅比盲猜好一点点。有趣的是，Kahneman 和他的同事既没有对方法做出调整，也没有基于这一反馈改变其观察所得到的结论。当看到某位申请者在测试中领先时，对他们来说，显然这依旧是军旅职业生涯的完美候选者。他们对自己的印象过于自信，以至于对他们来说要改变结论似乎是不可能的。

那么，从这些研究中我们能学到什么？实际上有两个非常重要的教训需要牢记：

• 首先，预测将永远是一项容易出错的工作，因为这个世界——或是任何复杂事件——都是不可预测的。
• 其次，高度主观自信（就像专家经常会表现出来的那种自信——无论是推荐参军士兵还是估算某个项目）并不意味着准确，而是意味着专家拥有一个完整的故事。只有在你处于稳定的环境中时，高度自信（有时候又被称为直觉）才可以相信。
• 下面实际上是 Kahneman 研究中的第三条教训——我没有费力去通过研究来验证它，因为这是迭代开发的基础：与长期趋势不同，只要基于以往的行为、模式和成果，人们就可以得到非常精确的短期预测。

让超越预算来帮忙

超越预算（ Beyond Budgeting ）是一项由来自不同公司的 CFO 推动的发展过程。这些 CFO 们对于预算在各自公司的成功中发挥的作用并不满意。我们可能都会有所涉及的典型经验，主要包含两个方面：

• 想象一下这种情景：某人为了某项目申请一笔特定的预算，而该项目最终与预计相比节省了开支。这时，由于担心下次申请资金的时候会被砍掉很大一部分（例如减半），他会想办法把剩下的钱花掉（却并不是为了最初的目标）。因此，这实际上并未对公司的成功做出真正的贡献。
• 现在再想象一下：某人申请了一笔特定的预算，但随后市场发生了变化，从而导致他需要两倍的资金。但由于他没有预先申请，就无法根据市场需求做出应对。公司的成功则再次由于原始的预算而受损。

基于这些经验，提出超越预算理论的人开发了多种类型的原则和推荐建议。这些原则和建议都并不是让人们一定要摆脱预算，而是希望更灵活地使用。例如，按年度沟通预算被视作不灵活的做法，而推荐的建议是使用诸如滚动预算这样的方式——这意味着每个月都要核查该把钱花在何处才最有利。滚动预算的另一个备选方案，是基于事件制定预算，这样在任何出现变更的时候，预算都将会被重新考虑。

在我看来，超越预算最重要的洞见之一是区分目标与预测。其根本原因在于，每个目标都应该是雄心勃勃的，而预测（或估算）则是通往目标的桥梁。现在，如果强制要求目标和预测二者一致，那么要么是目标不再是雄心勃勃的，要么估算是一场骗局。

运用超越预算理论

为了决定是赞成还是反对某个项目或产品，某个人首先会有一个初步想法，随后他或许会询问一位资深开发者甚而是一支团队，以便获得用数字形式展现的工作量，以及由此而来的成本。问题在于，在此时此刻，大家对项目的了解还不是很多，因此估算也并不多么可靠。有时候，是由销售在没有咨询开发部门的情况下就给出了估算，而后做出了决策。（当然，无论是谁提出这样一份最初的估算，对开发来说，毫无疑问它都不会被认真对待，而一旦我们了解了更多信息，将会对其进行调整……）

从 Kahneman 和超越预算的研究结果来看，刚刚描述的方法并无益处。首先，它忽略了超越预算对目标和预测之间的区分。其次，与 Kahneman 的观点相反，这一方法假定复杂项目可以被预测。第三，与超越预算的建议相反，它建议提前批准预算。

实际上，我们需要的是首先去弄清楚整体目标。为了避免仅仅依赖于一支专家小组（注意 Kahneman 的研究结果），我建议基于不同背景的小组推动这一工作。根据项目情况，这里的小组可以由来自诸如客户、市场人员、销售、产品管理者等群体的人组成。而且小组最好能够得到科学方法的支持，以便找出市场的真正需求——就像精益创业所建议的那样。这项工作的产出并不是一份估算，而是对公司（或客户）希望通过这一项目所实现的业务价值的定义。通过观察业务价值，我们会调整心态，将关注的焦点从关注成本，转变到能够获得的收益上。可以通过讨论来定义业务价值，在讨论中使用 Delphi 会话，又或是像我过去常做的那样：使用规划扑克的变体。对后一种方法，不要使用估算的数字来推动讨论，而是让团队成员使用关于业务价值的数字。

接下来的事情，也并不是去询问需要花费多长时间，相反，这一支背景各异的团队必须弄清楚他们愿意花多少钱（基于他们之前得出的业务价值）。自然地，与开发者们进行评估时所采用的方式类似，这个团队将会挣扎着（在一开始）得出一个投资的数字。然而，业务必须决定它想把钱花在哪里。从开发的角度来看，任何事情都可以用一种极其精巧和昂贵的方式（一般来说这也是非常符合工作道德的，例如干净的代码）去做，但同样也可以用一种低成本的方式来实现（可能会产生难以维护的代码）。因此，业务必须判断业务价值，到底价值几何（可能会导致要求廉价解决方案）。这并不意味着在规划过程中，开发者无需肩负任何责任——他们的任务是保证业务能够理解廉价（或昂贵）的解决方案可能会产生什么样的影响。因此，此时此刻，焦点并不在于估算，而是关于业务价值和公司想要进行的投资的决策，必须推动开发。再一次的，这些驱动力来自业务，而不是开发。某些团队却恰恰相反，他们要求开发不止在故事层面进行估算，还要在史诗层面（例如通过 T-Shirt 的尺码进行估算），或者甚至是在项目的层面。在更粗粒度的层面进行估算本身并不是个问题，只要估算是用来帮助更好地理解内容的。然而，尝试回答项目、史诗或故事花费多少（或持续多长时间）却是聚焦在错误的问题上了。再次重申，应该询问的问题是，价值几何，以及我们愿意为此投入多少。

这样，业务价值和投资就定义了控制开发的框架。最好的情况下，二者都应该被分解到故事层面，不过至少也应该到史诗层面。对大型项目来说，我们已经拥有了从至少三个层面进行规划的良好经验。最高的层面是整体项目规划（一般称之为路线图）。第二个层面是发布规划，每个发布最多覆盖三个月的时间。因此，在开始某次发布之前，史诗必须用业务价值和投资来进行定义。在迭代层面（最低层面），进行经典迭代规划（也就是 Sprint 1 和 2）之前，要先定义故事的业务价值和投资。根据发布的长度（以及项目复杂度），我们有时候需要 Mike Cohn 曾称之为“滚动预测规划”的东西。因此，我们查看故事的业务价值和投资，不只是为了即将到来的一次迭代，而是同时也为了未来的两次甚至三次迭代。在这些不同层面进行规划，为业务提供了这样的可能性：首先在粗粒度层面定义业务价值和投资，并在接下来用迭代的方式将业务价值和投资进行更细粒度的定义。对大型项目来说，立即在细粒度层面定义，一方面是不可能的，另一方面也没有用处——因为业务价值（以及投资的缘由）很有可能将会随着时间的推移而发生变化。

在不同层面运用这一方法，确保了开发总是由业务价值和投资而不是估算驱动的。对于开发团队，我依旧推荐为估算故事采用规划扑克过程。然而，这是为了在团队中创建有关故事的知识所做的，而并不是为了驱动开发。因此，只有对驱动对话来说，得出的估算数字才是重要的，特别是当团队成员最初并不同意估算数字的时候，对其各自不同的假设进行讨论，将创建对故事的共识。在这种方式下，对团队来说估算依旧有帮助，但却不会驱动规划。定义优先级，以及定义对于在开发范围中纳入哪些、移除哪些，将基于故事的价值——它将以业务价值和投资的方式（而不是将持续多长时间，或是需要消耗多少故事点）来衡量。因此，业务价值与投资一起为优先次序和开发提供了一份指南。例如，如果某个特定故事被分配了低投资额，而且它无法产出高业务价值，那么它的优先级必定是有争议的（与它故事点的估算无关）。此外，对这样的故事来说，开发团队显然应该考虑最经济的解决方案；如果并不存在这样的方案，那么就应该用具有更高业务价值（和 / 或公司决定进行更多地投入）的故事来取代它。

与滚动预算或基于事件的预算类似，我们必须定期核查业务价值和投资业。例如，至少每隔一个迭代就要看一下都学到了什么：从利益干系人那里（例如，哪些变更将提供有竞争力的优势）、从市场（例如，我们需要在哪里进行投入以创建更高的业务价值），以及从开发那里（例如，某个特定技术能够提供哪些优势）。接下来分析这些将如何在不同层面影响业务价值和 / 或投入。最好先查看一下这些对发布计划意味着什么——一般来说它只影响发布计划这个层面，因此无需将其放大到整个项目的层面。然而，在某些时候也存在这样的情况：路线图也会受到变更的影响。当然，在为即将到来的迭代（而且如果可能的话，也为了滚动的展望计划，即接下来的两到三个迭代）定义业务价值和投入的时候，应该考虑学到的新的教训。

总之，如果客户的竞争优势正是我们的焦点，那么业务必须被业务价值驱动。迄今为止，在敏捷开发中我们一直在谈论业务价值，但我们只考虑了优先级（一般来说，除此之外也会考虑估算）。然而只有将投入与业务价值结合，才能够确保我们永远将客户兴趣中的价值最大化。

结语

近期的研究结果，与来自超越预算的洞察一起，证明了我们许多人都曾经历的事情：准确的预测是不可能的，因为这个世界是不可预测的（特别是在现如今）。从一位专家处获得高度可信的预测，只不过意味着这位专家讲了一个完整的故事，而不代表预测的精度很高——因此，与其询问一位专家，还不如向一组背景各异的人去求教。

为了不掉进将估算与规划混杂在一起的陷阱，我们应该定义业务价值、提出愿意投入这份事业的投资并将这些价值用于规划。这些价值将帮助我们做出支持或反对启动某个项目的决定，并帮助我们得出项目（或产品）的路线图和发布计划。因此特别对于项目和史诗层面，业务价值和已定义的投资将驱动开发。

短期预测是有可能的，因此请测量速度，并在规划下次迭代时将其纳入考虑范围。而迭代和利益干系人的反馈，将帮助我们改进对业务价值和投资的处理。因此，一方面，业务价值和投资控制着迭代；在另一方面，迭代的反馈则促进业务价值和投资的提升。或者换句话说：路线图影响着发布规划，而后者又影响着迭代，反过来也一样——迭代的结果反馈到发布规划，而这又反馈到路线图。因此业务价值和投资被当作滚动预算来对待，他们将被定期重新审视，因此所有学到的教训都会被重新考虑。

延展阅读

Thinking Fast and Slow（中译本名为《思考，快与慢》或《快思慢想》）, 作者 Daniel Kahneman，企鹅图书出版

Implementing Beyond Budgeting，作者 Bjarte Bogsnes，John Wiley & Sons 出版

Beyond Budgeting Roundtable (超越预算的主页)

Agile Estimating and Planning（中译本名为《敏捷估计与规划》），作者 Mike Cohn，Prentice Hall 出版

关于作者

Jutta Eckstein是来自德国布伦斯维克（Braunschweig）的一位独立教练、顾问和培训师。基于超过十五年项目和产品开发方面的经验，她对敏捷过程有着深入理解。她专注于推动组织机构层面的敏捷开发，并已经帮助全世界许多团队和组织机构完成向敏捷方法的转型。对于在中到大型分布式任务关键型项目中运用敏捷过程，她有着独到的经验。这也是她的著作 Agile Software Development in the Large 和 Agile Software Development with Distributed Teams 的主题。她是敏捷联盟的成员，以及敏捷开发、面向对象和模式领域的许多欧美会议的程序委员会委员。

查看英文原文： Planning and Controlling Complex Projects