XP关注价值

揭开极端编程的神秘面纱：关注价值

　　　　　　　 ——如何与客户进行交流以交付他们真正想要的软件

作者：Roy W. Miller 本文选自：IBM DW中国 2003年05月07日 

　　如何与项目出资人（投资软件开发的人）以他们的语言进行交流，但又不违背 XP 告诉我们的原则，对于你们的 XP 团队而言，需要明白这个问题的重要性。这个月，Roy Miller 从他即将出版的书籍 Growing Software: Exploding the Myth of Prediction and Control（定于 2003 年由 Addison-Wesley 出版社出版）中摘录了部分材料，并对其进行了改编，从而向您讲述了如何以上述方式与客户交流。请在相应的论坛中同作者及其他读者一起分享您对本文的看法。 

　　项目资金必须得到落实，而掌管预算的人极有可能对 XP 或灵活（agile）方法知之甚少。如果他熟悉这些编程概念，我怀疑他会认为这些想法十分愚蠢或者过于冒险。向持怀疑态度的资金来源寻求资金可能是件有风险的事情。管理人员要想十拿九稳，最好的方法之一就是要确保在与出资人交谈时运用对方的语言。 

　　关注价值 

　　 上次我略微谈到过把注意力放在商业价值上来驱动项目的软件开发项目。花费时间和金钱来开发软件的原因仅仅是因为有人要您这么做，这种解释并不是一个好的商业理由（虽然这可能是保住饭碗的好办法）。最终，如果团队所开发的软件并不能为企业提供价值，那么其项目出资人就得不偿失 — 这一点他最终是会发现的。 

　　“价值”可以有两种不同含义。要么是指节省开支 — 省钱，要么是改进运营，从而赚钱。如同我们前面讨论过的那样，计划一个项目时，您应该鼓励团队成员尽其所能为所创建的每个功能部件（更可能的情况是每个功能部件集）增加含金量。这就是软件的商业案例。对于每个功能部件，您都应该尝试回答两个问题： 

　　·该功能部件解决何种价值需求（即，它能降低客户的哪些成本，或者它能增加哪些收益）？ 

　　·达到这些目的又要付出多大代价？ 

　　当然，不见得总是能够回答出这两个问题来，但是也不要没试过就认为这两个问题没法回答。有人为该软件投入了资金，因而他应该知道他会从投入的资金中得到什么。事先知道这些信息将更容易获取启动 XP 项目所需的资金。 

　　要钱 

　　为软件开发项目出资的人在掏钱之前会询问三个问题： 

　　·我将从该项目中得到哪些更新、更好的业务能力呢？ 

　　·什么时候？ 

　　·要花多少钱呢？ 

　　管理人员并不总是都能够详细回答这些问题的，但我相信，项目出资人也并不见得就一定想问个水落石出。而且，管理人员在回答这些问题时也必须综合考虑两种因素，即他们无法预测未来，而又需要对此进行充分的预测以获取预算。对于出资人而言，虽然他们可能将大笔资金花在具有风险的项目上，但他们不可能一时头脑发热把钱花到自己不熟悉的方面。 

　　更为重要的可能是，机构内的成员，包括软件开发团队的管理人员和程序员都需要有目标。必须在地上打上桩，告诉所有人：“这就是我们的目的地。一路上我们可能会改变方向，但就我们现在所知，它就是我们的最终目标。” 

　　大错特错 

　　当提着钱袋子的人（出资人）要求寻求资金的人十分详细地回答上面三个问题时，他们几乎是在询问一些无用的信息。每当管理人员试图做一个“自底向上”估算时，这一点就变得尤为突出。他们试图识别出所有的任务并估算对每个任务所做的努力。您可以想象他们这么做实际上是在构建一幅越来越详细的甘特图（Gantt chart）。这样，全部项目时间就变成了所有任务时间的总和了。结果往往会违背我们的初衷，这就是为什么大量的软件项目不能按时交付的原因。 

　　问题出在详细程度上。如果必须提前数月告诉某人某个软件项目要花费多长时间，而且必须精确到天，那么我几乎不可能做到这一点。这是因为我所做的自底向上的详细估算可能会出错。一个小小的早期估算错误可能会严重地影响我们后面的计划。您知道哪些计划不会造成小的估算错误 — 或者大的估算错误呢？估算只是预测，而不是承诺。设想一下对构建在线商店这一项目进行估算。（简化了的）功能需求可能是： 

　　·允许用户浏览并购买书籍 

　　·允许用户浏览并购买音乐 

　　·允许用户浏览并购买电子制品 

　　和大多数试图对事物进行估算的人一样，您可能先从一些核心需求开始，然后从内向外推进。您可能会假定编写用于浏览并购买书籍的代码将需要 5 个单位（小时、天、星期、人和任何其它单位）的努力，而满足另两项需求则只需要三个单位，因为它们都通过已经为支持售书部分编写了代码而得到了简化。因此，您最终得到了一份看起来类似下面这样的简化计划： 

　　　　任务 　　　　　　　　　　单位 

　　　　浏览／购买书籍　　　　　　 5 

　　　　浏览／购买音乐　　　　　　 3 

　　　　浏览／购买电子制品 　　　　3 

　　典型的管理人员可能会说：“好了，11 个单位，完事了。”但是，如果“浏览／购买书籍”这个环节花了六个而不是五个单位，那会怎样呢？如果我对该环节（所花费的努力）低估了 20％，那么对其它环节，也可能会低估同样的百分比。该误差扩散开来，整个估算会因此瓦解。 

　　计划越详细，也就越脆弱。任何人都可以就任何事做出预测。而所做预测的误差容限是否足够小，从而使得这个预测还算有用，这完全是另外一码事。详细的长期预测通常不能（做到这点）。当上级管理部门询问项目需要多长时间时，简单的回答就是：您无法给出准确的天数或周数。如果您试图（给出确切的时间），那么极有可能出错，因此（提供）这些信息可能不会有任何帮助。 

　　但是，仅仅因为您无法进行精确、详细和长期的预测，并不能作为逃避回答这三个问题的挡箭牌。您还是必须回答这些问题，但却必须以另一种方式来回答。您需要向项目出资人提供的信息只要足以让他做出十分明智的决定就够了。 

　　很好的答案 

　　据说，J. P. Morgan 在被要求就股市进行预测时说：“股市将上下波动。”虽然这可能并不完全是提问者想要的回答，但却也是大实话。这同样也是对于软件开发我们所能做的。当我们开始一个项目时，只有两个细节可以进行可靠地预测： 

　　·我们最终所得的系统必须满足这样的商业需求，即某个拥有资金的人愿意为此出资。 

　　·时间、金钱和耐心将用尽。 

　　时间、金钱和耐心都会悄悄溜走。问题是，您的团队如何在这些东西用完之前开发出能够增值的优秀软件呢？最好在那些东西用完的时候开发出一些能够助我们前进的工作软件，而不是一无所有，并对这样的经历感到后悔。坚持 XP 实践能够帮助您的团队做到这一点。但是作为管理人员，您无法进行很好的预测或太多的控制，这使您受到一定的约束。对可能的项目出资人所提的问题最直接的回答类似于： 

　　我们将开发某个软件。我不知道这要花掉多少钱、花费多长时间以及这个软件最终会是个什么样子。但当我们成功时，就会发行它。我们知道我们应当试着尽早到达这一步，而这正是我们要做的。 

　　这是实话，但实际却行不通。拥有资金的人需要的信息不止于此（尤其是在后 .com（post-dot-com）时代）。所幸的是，潜在的出资人只需要有足够的信息让其在不能完全了解未来的基础上做出明智的抉择。因而，不必做出太多的预测就能回答这些问题。技巧在于要把精力放在目标而不是如何实现这一目标的详细计划上。要顶住这样一种压力，即要求您近乎愚蠢地穷究细节，从而拿出对项目所花时间和所耗资金的估算。这类估算很少是正确的，以致于得不偿失。 

　　相反，更明智的做法是将要参与（或可能参与）所提议项目的人员召集起来。对第一个发行版的功能需求进行讨论。软件第一次交付时，最少且绝对需要哪些功能？将这些信息记在某处。基于团队中已经有一部分人员，现在让团队中的技术人员就以下问题做出估算：每项功能的开发要进行多少重复工作。此时，进行高级别的估算是很好的。仅让有经验的人员就（实现）每项功能所要付出的努力相互交流看法，并记下这些看法。 

　　在此，经验十分重要，因为它将团队所必须做出的猜测减到最小。每项估算至少部分属于猜测，而经验或高智商并不能消除全部猜测。经验能够有助于将猜测降低到某种程度，但是必须明白的是我们无法精确预测将来。 

　　以下是来自我目前正在从事的项目的一个示例（略有修改）： 

　　　　环节 　　　　　　估算的重复数 　　指派的发行版 

　　　　先期准备工作 　　　　2　　　　　　　　 1 

　　　　物理管理 　　　　　　2 　　　　　　　　1 

　　　　逻辑管理 　　　　　　2 　　　　　　　　1 

　　　　用户管理　　　　　　 1　　　　　　　　 1 

　　　　状态维护 　　　　　　2　　　　　　　　 1 

　　　　部署 　　　　　　　　3　　　　　　　　 1 

　　　　外部工具集成 　　　　1　　　　　　　　 1 

　　　　审计 　　　　　　　　1　　　　　　　　 1 

　　　　监控 　　　　　　　　1　　　　　　　　 2 

　　　　总的重复数　　　　　 15 

　　上面的估算假定团队有四名开发人员。这种细节级别足以让我们估算出实现上面所列的全部高级功能部件所需的工作。在那里，我们为每个重复工作标上价格，并用总的重复数（15）与它相乘。这项实践花了不到两周的时间来思考和研究各种技术问题。最终的结果就是潜在的客户需要我们回答的所有三个问题的可接受答案： 

　　1、项目将会提供哪些新的或改进的商业能力呢？您在这里看到的主要功能部件将随着团队在开发过程中所了解的情况的不同而略有不同。 

　　2、项目要花多长时间？大约 15 个单周重复，即四个月不到一点。 

　　3、项目要花多少钱？用单个重复的成本乘以 15。 

　　我们还可以更进一步。我们的客户聘请我们公司开发一个软件产品。通过与营销主管进行一个简单的讨论，团队了解到营销主管希望在头四年里售出多少许可证，售价又是多少。这让我们大致计算出了客户什么时候会使其对我们所提供的服务的投资达到收支平衡。 

　　全部三个问题我们都回答得简洁明了，避免了可能的错误。我们没有绘制甘特图，因为我们并不需要它。仅仅一个多星期，我们就得到了所有所需的信息。 

　　计划 

　　我认为前一节中的计划就是管理人员（和团队）开发软件所需的全部，但对某些项目出资人而言可能太过基本。管理人员可能能够回答出资人所提的三个问题，并且有可能因此而获得某个项目，但有时却不见得能够谈成这笔交易。管理人员可能至少需要一份看起来更加面熟的初始计划。图 1 只显示了内容较清楚的甘特图。 

　　图 1. 甘特图 



　　图 2 中显示的概括表示更加简单。 



　　图 2. 甘特图概括表示 

　　我们的计划需要进行汇总。一根粗线条，两个日期。 

　　大多数管理人员并不绘制这样的甘特图。有些管理人员认为甘特图的变化越详细就越好或者越精确，有些管理人员则有其它一些正面的看法。然而，我非常信任管理人员。我想大多数管理人员会绘制详细程度令人难以置信的甘特图，他们这样做是被迫的，而不是因为他们笨或存心这么做（尽管有些管理人员确实是这样）。他们的有些上司期望得到这些详细的图，没有这些图项目就无法继续得到资金。这是因为有人认为这样的详细计划是物有所值的。 

　　然而，事实是所有计划都只是虚构的。计划只要一落笔就是错的。我们需要开始那么做。我认为大多数管理人员都会对他们过于详细的计划产生一丝疑虑。下面这段话是我的一个朋友给我的电子邮件的开头： 

　　由于我刚刚为我的项目完成了电子表格，该表格根据对下一个发行版所提议的范围的 A&D 估计（按照 6 个月的实现和 60 多个全职雇员（FTE），精确到 30 秒以内）对构建进行了估计，因此我想我会再给您一封电子邮件。 

　　管理人员不会用一个月的薪水为赌注来赌特别详细的计划的正确度。计划不必这么精确 — 多谈些目标，少谈些期望。在 The Innovator's Dilemma（参阅参考资料）中，Clayton Christensen 说，当我们在研究不太明确的技术和市场时，计划应该用于学习而不是实现。这是在未知环境下进行有目的的活动的唯一方法。研究不确定的软件需求以满足不确定的业务需求也是如此：业务需求会随着我们接近它们以及对它们的理解加深而变化。要想制定尊重这些事实的计划，各级管理部门就必须在对失败的看法上有一个大的改变。 

　　Jim Highsmith 是 Adaptive Software Development: A Collaborative Approach to Managing Complex Systems（参阅参考资料）的作者，他说我们对质量的思考是不完整的。我们完全没有考虑出错、失败和试验： 

　　当前的软件质量管理实践状态通常由“一次成功（Do it right the first time）”这句话来指导。但在复杂的环境里，一次成功却是一种会导致失败的指导思想。它实质上是说， 

　　　　·我们不能不确定 

　　　　·我们不会从错误中吸取教训（因为我们不会犯任何错误） 

　　　　·我们不能偏离计划 

　　　　·我们所需的是，乐意刚开始就犯错，以便最后不出错。 

　　我们需要彻底失败，并从中吸取教训。计划应该支持这一点。记住，我们并不完全知道我们要前往何方。采取小的步骤，保持简洁，然后出错，再从中吸取教训，这是探索未知事物的最好办法。要经常地、彻底地并且以较小的代价制造失败。Gary Hamel 在他的 Leading the Revolution（参阅参考资料）一书中写道，要求每个人始终都不会出错只是空想。除非制定计划比计划本身更重要，否则这就是我们的计划要做的。 

　　坚持到底 

　　XP 要求管理人员以不同的方式开展项目，因为对软件项目的传统看法及规划软件项目的传统方法往往不能产生大多数管理人员所希望的结果。一旦您有了资金，项目就启动了，事情需要有些不同。这就是 XP 实践的含义 — 一种不同的项目运作方法，使您的团队在项目结束时更有可能交付出人们真正想要的软件。 

　　下个月 

　　和上个月一样，我将让本专栏的读者来决定下个月的主题。您希望我写些什么呢？您对 XP 最大的疑问是什么呢？您认为什么是十分愚蠢、不明智、不专业或者不可能的呢？最令人混淆的实践是什么呢？请参与本专栏的论坛。告诉我您希望我写些什么。我将调查我收到的请求。如果有一定数量的读者期待我论述某个特定主题，我就将讨论这个问题。如果没有，我将选择写一些我认为值得写的东西。 

　　参考资料　　 

　　阅读 Clayton M. Christensen 的 The Innovator's Dilemma （Harvard Business School Press，1997 年）以理解传统的业务规划为什么对于未开拓市场内的创新产品不适用。 

　　对于 Jim Highsmith 对灵活方法的见解，尤其是他自己的自适应软件开发（Adaptive Software Development），要获取与之相关的更多信息，请查看他所著的 Adaptive Software Development: A Collaborative Approach to Managing Complex Systems （Dorset House，2000 年），该书曾荣获 Jolt 奖（Jolt Award）。 

　　要明白为什么大多数企业都需要一些这样的另类人才：即在通往成功的路上愿意而且会犯错的人，请阅读 Gary Hamel 所著的 Leading the Revolution: How to Thrive in Turbulent Times by Making Innovation a Way of Life （Harvard Business School Press，2000 年）。 

　　看完本文之后您会加入本专栏吗？阅读第一篇 XP 文章，由 Roy Miller 和 Chris Collins 合作撰写的 “XP distilled”（developerWorks，2001 年 3 月），从而搞清楚本专栏的出发点，然后一定要查看本专栏的档案文章 。 

　　阅读An excerpt from "Java Tools for Extreme Programming" （developerWorks，2002 年 7 月）中有关使用 Ant 构建和部署 Java 应用程序的内容。 

　　在用 IBM VisualAge for Java 进行极端编程 中了解为何 VisualAge for Java 是 XP 团队的优秀工具。 

　　在 developerWorks Java 技术专区中可找到关于 Java 编程各方面内容的大量文章。 

　　关于作者 

　　Roy W. Miller 从事软件开发和技术咨询工作将近十年了，最初在 Andersen Consulting（现在的 Aclearcase/" target="_blank" >ccenture）工作，目前则在位于北卡罗莱纳州的 RoleModel Software, Inc. 工作。他使用过重量级方法和灵活方法，包括 XP。他与人合著了 Addison-Wesley XP 系列丛书中的一本（Extreme Programming Applied: Playing to Win），目前他正在撰写一本关于复杂性、紧急情况和软件开发的书（暂定标题为 Growing Software: Exploding the Myth of Prediction and Control）。请通过 rmiller@rolemodelsoft.com. 或 roy@roywmiller.com. 与 Roy 联系。您也可以通过 www.roywmiller.com. 访问他的个人网站。

原文转自：http://www.ltesting.net