第Ⅰ部分问题与目标
第1章计划的目的
在介绍敏捷估算和计划方式之前，首先需要理解计划的目的，这非常重要。本部分第1 章的主题将覆盖此内容。 很多按照传统方法进行计划的项目并不能及时交付令客户满意的产品，第2 章中介绍了一些最常见的原因。这一部分的最后一章介绍了敏捷方法的概要视图，它将贯穿本书其他部分的介绍。
“planning is everything. Plans are nothing.”
—— Field Marshal Helmuth Graf von Moltke
无论一个软件开发项目的规模与结果如何，估算(Estimating)1和计划(Planning)2对于项目的成功都是至关重要的。计划可以指导我们的投资决策：如果估算某个项目需要花费6个月的时间和1 000 000 币3，我们可能就会启动它；反之，如果我们认为同样的项目需要花费2 年的时间和4 000 000 币，也许就会放弃这个项目。计划可以帮助我们了解在项目特定的阶段需要哪些人参与其中。计划还可以帮助我们了解项目是否在正常进行，从而可以交付用户所需要和期望的功能。没有计划的话，项目就可能面临无数问题。
但是，计划又是困难的，而且做出的计划常常会出错。面对这样的问题，开发团队往往会走向两个极端：要么根本不作任何计划，要么因为认为计划必须尽善尽美而在计划中投入大量的精力。不做计划的团队对一些最基本的问题——例如“你们什么时候能完成？”以及“我们可以在6 月份发布产品吗？”，都无法回答。而过度计划的团队会自欺欺人地认为任何计划都可以“完美无缺”。他们的计划或许更全面，但这并不一定意味着它更准确或更有用。
估算和计划难早已不是新闻。我们早就知道这一点。1981 年，Barry Hoehm 就绘制出后来Steve McConnell 称之为“不确定性锥形(cone of uncertainty)”的第一个版本。图1-1显示了Boehm 最初所考虑的不确定性在顺序开发(“瀑布式”)过程不同点上的分布。不确定性锥形显示出在项目的可行性分析阶段，对进度估算的偏差往往可能达到60％～160％。也就是说，一个预期需要20 周的项目实际上花费的时间可能在12 周～32 周之间。而在写下需求后，估算的偏差仍可能达到﹢/﹣15％。这时预期的20 周意味着实际上会花17 周～23 周。
1 译注：为了区分“估算”一词的动词语义和名词语义，本书涉及动词语义时，将一概使用斜体格
式的“估算”，普通格式“估算”则代表名词语义。
2 译注：为了区分“计划”一词的动词语义和名词语义，本书涉及动词语义时，将一概使用斜体格式的“计划”，普通格式“计划”则代表名词语义。
3 请记住本书采用“币”来作为通用的货币单位。
项目管理协会(Project Management Institute，PMI)也对估算的渐进准确性具有相似的看法。不过，与图1-1 将不确定性锥形看成是对称的不同，PMI 认为它是不对称的。PMI 建议首先建立数量级估算(order of magnitude estimate)，误差范围为﹢75％～﹣25％；然后建立概算估算(budgetary estimate)，误差范围为﹢25％～﹣10％；最终建立确定性估算(definitive estimate)，误差为﹢10％～﹣5％。
1.1 为何要进行估算和计划
如果估算和计划很难，而且只有到项目的后期才能得到准确的估算，那为什么还要进行估算和计划呢？一个显而易见的原因是我们所在的公司通常要求我们提供对项目的估算。出于很多合理的原因，如准备市场推广、安排产品发布活动、对内部用户进行培训等，计划和安排可能必不可少。这些都是非常重要的需要，我们必须为所在的公司提供可用于达成这些目标的计划或进度表，对项目进行估算的难度并不能免除我们的这一责任。然而，在这些例行公事的需求之上，有一个更为本质的原因要求我们去进行困难的估算和计划活动。
估算和计划并不仅仅是决定一个恰当的最终期限和进度表。计划——尤其是持续进行的迭代式的计划——是对价值的探求。计划就是尝试给产品开发的总体问题——“我们要构建什么？”找到最佳答案。要回答这一问题，开发团队必须考虑功能特性、可用资源和时间进度。这个问题不可能一下子就完全回答，只能通过迭代的、渐进的方式来回答。在项目的开始阶段，我们可能会决定产品需要包含一组特定的功能，并在8 月31 号发布。但到了6 月份，我们可能会决定稍微增加一些功能，并推迟一点发布。抑或我们也可能会决定减少一些功能，提早一些发布。
好的计划过程通过以下活动来支持这种对价值的探求：
● 减少风险
● 降低不确定性
● 提供更好的决策支持
● 建立信任
● 传递信息
1.1.1 减少风险
计划通过提供对项目风险的认识而提高了项目成功的可能性。有些项目的风险如此之高，以至于我们在了解到这些风险后可能决定不启动这些项目。在其他一些项目中，可以通过早期的防控措施来控制某些功能可能包含的风险。
估算活动时的讨论所提出的疑问，能够揭示出项目可能存在的黑暗角落。假设有人要求你估算将新项目与一个你根本就不了解的遗留系统进行集成需要多少时间。这会揭示出集成功能是一个潜在的风险。项目团队可以选择马上就对该遗留系统进行学习以消除这一风险；抑或记下这个风险，通过增加工作量的估算值，或者用一个范围来表示工作量，以描述更大的不确定性和风险。
1.1.2 降低不确定性
在整个项目的过程中，团队在不停地增加产品的新特性。他们也在不停地产生新的知识——关于产品、关于所使用的技术，以及关于他们团队本身的知识。接受这些新的知识，并将其融入迭代式的计划过程是非常重要的。迭代式的计划过程能够帮助团队优化产品的愿景。大多数项目所面临的最关键风险是开发出错误的产品，但在绝大多数项目中这一风险都被忽视了。敏捷计划方法可以显著降低(希望可以消除)这种风险。
人们经常引用的CHAOS 论文(Standish 2001)将成功项目定义为：按时、符合预算、包括了最初设定的所有功能。这是一个非常危险的定义，因为它没有认识到在开始进行开发后，一个在项目启动时看起来不错的功能可能不值为之付出的开发代价。如果让我来定义失败的项目，其中一个标准一定会是“项目中没有人提出比最初的需求列表更好的想法”。我们希望鼓励项目团队定期对项目投资、进度表和功能决策进行重新评估。交付了最初计划中所有功能的项目未必就是一个成功的项目。如果仅是为了符合最初计划而实现普通的想法却放弃奇妙的新想法，产品的用户和客户很可能不会感到满意。
1.1.3 提供更好的决策支持
估算和计划可以帮助我们进行决策。如果公司没有对某个项目的价值和代价进行估算，又如何决定是否值得对它进行开发呢？估算除了可以帮助决定是否启动某个项目，还可以帮助我们确保正在开发可能具有最高价值的项目。假设有一个公司正在考虑两个项目，其中一个预计可以获得100 万币的收入，另一个预计可以获得200 万币。首先，该公司需要对进度和花费进行估算来判定这些项目是否值得推进。项目是否会需要太长的时间以至于错过市场窗口？项目的花费是否会超过它所能获得的收入？其次，该公司还需要项目的估算和计划，来决定推进哪个项目。最终，他们可能会决定推进其中一个、两个都推进，或者由于两个项目的代价都太高而都中止。
除了是否启动某个项目，公司还需要用估算来对其他问题进行决策。有时，项目成员的配备规格比项目的计划安排更为重要。例如，如果项目计划要求公司中已经完全被另一个项目所占用的首席架构师的参与，启动这个项目可能就不值得。但是，如果这个项目的计划不需要该架构师的参与就能完成，也许就值得启动它了。
项目计划时所做出的许多决策都是折中后的决定。例如，在每个项目中，我们都会在开发时间和费用之间进行折中。开发一个项目的最廉价方法往往是雇佣一个优秀的程序员，然后给他十几二十年的时间来编写这个系统，让他可以有不少的时间来做周边性工作，掌握领域知识、成为数据库管理专家等。但是，我们显然不太可能花二十年的时间来等待一个系统，于是我们就会建立团队。一个30 人的团队可能花1 年的时间(30 人年)来完成一个程序员在20 年中能够完成的工作。虽然开发成本上升了，但是提前19 年获得这个应用程序所带来的价值足以抵消增加的成本。
1.1.4 建立信任
频繁地、可靠地交付承诺的功能可以在产品的开发人员和产品的客户之间建立信任。可靠的估算使得可靠的交付成为可能。客户需要估算来做出关键的优先级和折中决策。估算还可以帮助客户决定功能特性开发到何种程度。与其投入20 天时间完全实现，或许只花10 天时间就能达到80％的效果。除非开发人员的估算被证实为可靠的，否则客户不会愿意在项目开发的早期就做出这种折中。们经常在功能特性与投入的精力、成本和时间之间进行类似的折中。是否值得为某个特定的功能推迟发布？是否应该为了在即将到来的发布中包含一个特定的功能而再雇佣一个程序员？是否应该在6 月发布，还是推迟到8 月以便提供更多功能？是否应该购买这个开发工具？要做出这些决策，就需要对成本和收益进行估算。
可靠的估算允许开发人员以可持续的节奏进行工作而使他们受益。这将使得代码质量更高而且缺陷更少。反过来，由于花在诸如除错这类高不确定性工作上的时间更少，估算变得更为可靠。
1.1.5 传递信息
计划可以传递针对项目的期待，并且描述完成项目的可能路径之一。计划并不能保证在特定日期和特定的成本之内完成一组精确的功能集合。但是，计划可以展示和传递一组对于项目预期的基线。不过，计划在太多的时候被减少到了只剩下一个日期，而所有导致这个日期的假设和期望都被遗忘了。
假设你问我什么时候能完成一个项目。我告诉你需要7 个月的时间，但并不解释我在这个期限内如何完成。你应该对我的估算感到怀疑。没有额外的信息，你就无法确定我是否充分考虑了这个问题，又或者我的估算是否现实。
再假设，我给你一个计划，估算会在7～9 个月内完成项目。计划显示了最初的一、两个月内会完成哪些工作，记录了关键的假设，并建立了我们协同对项目进度进行度量的方法。在这种情况下，你在看过我的计划后可以得到对它应有的信心。
本文选自《敏捷软件开发实践 估算与计划》第一章，本站经清华大学出版社和作者的授权。
版权声明：51Testing软件测试网获清华大学出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
