作者：(美)Ken Schwaber Jeff Sutherland
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
30天软件开发：告别瀑布拥抱敏捷试读：
前言
我们俩在软件行业的打拼史加起来已有 70个年头了。我们曾经在 IT组织和软件产品公司担任过软件开发人员和经理，也曾创办过自己的产品公司和服务机构。20多年前，我们发明了一套能够让组织更好地交付软件的流程。自那以后，我们用这套流程帮助了数以百计的组织。这项发明的广泛应用程度远远超出了我们的想象，现在已经有数百万人在使用它了，它就是Scrum。Scrum的广泛应用让我们深感谦微，大家使用Scrum所获得的成就让我们颇感惊叹。
关于软件开发我们之前写过一些书，不过为那些不亲身参与软件开发的人员写书还是第一次。本书专门写给其所在组织依赖软件保持生存和竞争力的领导者。他们的组织能够从快速增量式的软件开发中获益，从投资中获得最大回报，并需要解决由于业务和技术的复杂性使得软件交付困难的难题。我们写作本书的目的就是让这些领导者能够帮助他们的组织实现这些目标，增强其内在能力，改善其产品，等等。
本书是写给想用更短的时间、更低的成本、更好的可预测性以及更低的风险，交付更好软件的首席执行官、高管以及高级经理们的。我们想跟这些人说：在过去，你也许有过不愉快的软件开发经历，但是这个行业已经今非昔比，软件行业的策略和业绩已经有了彻底的改观。现在我们可以欣慰地说，你习以为常的不确定性、风险和浪费已经不再是必须付出的代价了。我们帮助众多软件企业和组织转危为安，现在也希望能够助你一臂之力。
在本书中，我们会介绍如何利用一套流程来创造商业价值，这套流程能保证至少每 30 天就交付完整的软件功能模块；如何对你所需要的功能进行优先级排序，然后一一交付；如何根据期望功能跟踪已交付功能，以此来了解其商业价值，以及软件开发流程和组织整体上是否健康。用本书中介绍的工具及理念来武装自己，你将可以帮助你的软件企业快速掌握现代工程实践，开始交付你期盼已久的成果。
这就是30天软件开发。
致谢
感谢Arlette Ballew出色的编辑加工、 Richard Narramore的整体指导以及CareyArmstrong的倾情关注。如果没有他们的贡献，本书不可能付梓出版。第一部分 为什么说每家公司都能在30天内开发出软件
我们渴望帮助每一位希望创造出更具价值和可预测性的软件的组织领导者。软件行业正在经历巨变并日臻完善。过去软件开发具有很高的不确定性，风险大，浪费严重，这些司空见惯的情况现在已有所改观。在过去的20年里，我们帮助众多组织起死回生，获得了丰富的经验。在此，我们也想助你一臂之力，帮助你开发出风险可控、可预见、有价值、高质量的软件。
这么做的原因有两个。首先，你已经饱受软件行业的折磨长达40年了，并非心甘情愿，而是无可奈何。我们希望恢复那让人愉悦的良好合作关系。其次，软件不再默默无闻，它已无处不在，在现今社会发挥着越来越重要的作用。我们希望你能制造出可靠的软件。
希望能通过本书达成我们的目标。恳请你无论如何都不要放弃，因为你不再需要面对以前那样糟糕的软件结果，请持之以恒坚持下去。
在本书的第一部分，我们先研究一下软件开发为何曾如此糟糕。然后看看它是如何逐步改进的，以及推动改进的两个潜在动力是什么。接下来会展示如何试行我们的流程，怎样正确运作。第二部分将会介绍如何用更严谨的步骤使用我们的新流程，当然前提是你对试行结果满意。第1章 软件危机：错误的流程导致错误的结果
无论是商业组织、政府机构，还是非营利组织，都可能需要通过开发、定制和使用软件来创造价值。假如没有软件的帮助，作为商业领导者，你很难甚至无法实现自己设定的业务目标。尽管软件如此有用，但是一直以来，软件开发都广受诟病，被认为不可靠、高成本、易出错。这就使你陷入了一个两难的境地：你需要软件，但无法及时得到成本可接受、质量又可靠的可用软件。
实际上，斯坦迪什组织（Standish Group）在2011年的CHAOS报告中指出，2002年至2010年期间，超过半数的软件项目都被评定为存在缺陷或者是彻底失败，只有37％的项目是成功的（如图1-1所示）。斯坦迪什组织对成功项目的保守定义是：能够按照既定的预算，在承诺的期限之内交付所有需要的功能。而软件适应变化的能力、管理风险的能力以及软件的固有价值均未纳入评估范畴。
软件项目的成功率如此之低，你很可能会为那些牵涉到软件开发的重要项目忧心忡忡。软件行业耗时、成本高，又不可预期，早已让你大失所望。如果不是软件那么重要的话，你很可能早就停止在软件上的投资了。图1-1 传统软件开发存在风险
不过，面对这些问题的并不只有你一个，很多机构都有同样的困扰。例如，联邦调查局（FBI）的“哨兵”（Sentinel）项目最近也遇上了麻烦。结果，他们运用本书中描述的理念和流程，使项目起死回生。
这里关于“哨兵”项目的资料均来自美国司法部的检察长报告，并且对外公开。如果你认为这只是一个基于政府工作特性的个案，不具有普遍性，那么试想一下：如果一个庞大的政府机构都可以这样彻底地改进软件的开发方式，你的组织同样可以做到。1.1 案例学习：FBI的“哨兵”项目
FBI针对每一项调查都建立一份档案，其中包含所有创建或者调用的调查记录。2003年，FBI决定将这些档案数字化，并对相关的流程进行自动化管理，这样探员们就可以迅速地比较各个档案，从中找到它们之间的联系。这个项目的名字叫做“哨兵”。
2006年3月，FBI启动了“哨兵”项目，目标用户是3万多人，包括FBI探员、分析师和行政人员。“哨兵”项目的最初预算是4.51亿美元，预期在2009年12月完工。根据FBI的最初计划，“哨兵”项目的开发工作会分为四个阶段。这个项目外包给了洛克希德马丁（Lockheed Martin）公司，这家公司建议使用传统的软件开发流程。
到2010年8月，FBI已经花费了总预算中的4.05亿美元，但是项目只完成了四个阶段中的两个。虽然完成的前两个阶段的确帮助FBI改进了档案的管理系统，但是没有达到他们的预期效果。于是，由于成本和时间的超支，2010年7月，FBI决定停止洛克希德马丁公司在“哨兵”项目剩余两个阶段的开发工作。
到这个阶段为止，FBI一直在使用传统的开发流程，而现在，他们尝试引入新的流程来获得更好的成效。这个新的流程就是我们在20世纪90年代初创立的Scrum。那份指出只有37％的软件项目成功的CHAOS报告，同时论述了采用传统开发流程和采用敏捷（即Scrum）流程开发项目的结果会有什么区别（如图1-2所示）。从图中可以看出，采用传统开发流程（瀑布式）的项目中只有14％成功了，而采用敏捷流程的项目成功率则有42％。这些敏捷项目不仅满足斯坦迪什组织对成功项目的定义，而且能够更好地适应客户需求的变化，更有效地降低风险，并最终交付更高质量的软件。图1-2 敏捷项目的成功率是三倍
2009年，FBI聘请了新的首席信息官和首席技术官，他们都管理过使用敏捷流程进行软件开发的组织，于是决定看看敏捷流程能否带来帮助。2010年，首席技术官向司法部提出他希望改变“哨兵”项目的开发流程，声称新的流程将精简决策过程，并且能够在预算内完成剩余的开发工作。FBI告诉当时的司法部检察长，他们相信可以在12个月内，利用剩余的预算完成“哨兵”项目。根据MITRE的审计显示，如果FBI继续沿用传统开发流程的话，他们将需要额外的3500万美元和6年时间来完成该项目。
于是，FBI将整个“哨兵”项目搬到了位于华盛顿特区的FBI大楼地下室，并且将项目的人数从400人减少到45人，其中15人是程序员。项目重新启动后由首席技术官亲自运营。他要求团队以30天为一个周期，每个周期交付一部分功能，每次交付的功能必须满足最终的功能性和非功能性需求。这是一个“一次发布”的软件。此外，每三个月FBI就将最近三次迭代的功能部署到一个现场试点上。
2011年11月，“哨兵”项目在重新启动新的流程后用不到一年的时间就全部完成了。软件首先部署到FBI的一些试点办公地，其余的办公地将在2012年6月前完成部署。事实是，FBI用了3000万美元和不到12个月的时间完成了“哨兵”项目，并且节省了90％以上的开支。
虽然FBI在“哨兵”项目的前期阶段投入了大量的人力物力，但是开发流程严重阻碍了项目的进展。而实施了本书所介绍的流程以后，虽然工作强度跟以前一样，回报却丰厚得多。如果FBI能这么做，为什么你不可以呢？1.2 错误的方法：预测性流程
FBI在“哨兵”项目初期所使用的流程，就是我们所说的预测性或顺序式的设计流程。实际上，在2005年之前，大多数软件项目仍然使用预测性流程。并不是说这种预测性流程就一定不好，它在特定场景下会更适用，并能取得成功。然而，这些场景只是特例而非常态。例如，已经建立了完整的愿景，愿景中的所有需求已经定义，并且已经策划出实现愿景的详细计划，这时就可以使用预测性流程。但是，只要与原始愿景、需求或者计划略有偏差，就会为项目带来巨大的风险。然而由于商业需求和技术的日新月异，可以说这些因素的变化都是不可避免的。于是，就像斯坦迪什组织在其报告中所述的，86％使用预测性流程的软件项目都未能成功。实际上可以认为，预测性流程的使用是导致软件项目失败的最常见原因。
与我们合作过的组织都在想尽办法提高软件项目的成功率。他们担心软件项目失控，来向我们求助。现有的流程让他们尝到了失败的滋味，却无计可施。这些软件开发流程浪费了他们大量的人力物力。但由于软件是其主要竞争力来源，他们不得不继续这些项目。
下面是高管和经理们经常遇到的问题。（1）版本发布所需时间越来越长。“提交给客户的每一个版本，其发布所需要的时间、人力和成本越来越多。几年前，一次发布可能需要18个月。现在，同样的一个版本发布需要24个月来开发、打包和部署。尽管如此，我们仍然感觉时间仓促，压力很大。我们觉得投入越来越大，而产出却越来越少。”（2）无法按时发布。“在我们向客户和市场承诺之后，客户或者潜在客户都按照我们承诺的发布时间制订商业计划。他们需要我们在承诺的时间点，及时交付承诺的功能。然而，我们通常在最后时刻让他们大失所望。他们的计划被打乱，损失了金钱，失去了客户的信任。结果是，我们可能再也无法从他们那里拿到新的项目，他们显然也不会为我们介绍新的客户，他们自己也会寻找新的开发商。”（3）在版本发布的最后阶段，软件达到稳定状态需要的时间越来越长。“我们和软件开发组织有明确的约定，确定了固定的交付日期。虽然他们在设定的日期之前达到了他们所谓的‘代码完成’或‘代码冻结’状态，但是软件根本不能用，无法实现所需的功能和性能，让人完全无法接受。我们甚至无法将‘测试版本’交付给小样本客户试用以获得反馈，因为软件中的缺陷实在是太明显了，试用客户拒绝参与测试。我们需要额外的九个月时间来完成版本发布。即便是那样，我们还是没有十足的把握，仍然需要很多帮助，并为各种事情向客户道歉。”（4）制订计划的时间太长，而且计划得不准确。“我们发现，由于我们没有在项目开始之前把计划做得足够好，导致发布版本的时间过长，错过了发布日期。我们没有完全确定并分析清楚需求，而且我们的预估包含了过多猜测。为了解决这些问题，我们不得不花费更多的时间来做计划。在这期间，我们不断产生新的想法，评审计划的过程中也会发现需要重做或澄清的地方。结果是，现在我们花在计划上的时间更多了，然而进度落后和软件难以达到稳定状态的问题仍然非常严重。尽管我们为做计划大费周章，但在开发期间仍会遇到计划期间未能或无法预见的变化。”（5）在版本发布中期很难做更改。“目前的开发流程无法适应变化。我们在开始开发时投入了大量的时间做计划，并且断定所有需要的工作都列入了计划中，但后来经常会发现有些非常重要的部分或新的特性必须添加到当前版本中。为了进行这些更改，我们不得不调整已经完成的部分。而这种调整是非常困难的，因为在软件中引起的连锁反应是难以想象的。尽管调整是必要的，但在版本中调整比在一开始调整要多花一百倍的时间。但是我们又能怎么做呢？如果不在当前的版本或者项目中做出调整，恐怕就要等到两年后的新版本才有机会了。”（6）质量持续恶化。“我们知道不该向开发人员施压要求按期交付原定和更改后的功能。但是当我们的业务遭受计划、延误、变化问题的三重打击的时候，我们只能告诉开发人员，必须咬紧牙关在限期内交付所有计划中的东西。每当开发人员听到这种指令时，他们通常会用降低软件质量或者减少软件适用性测试的方式来应付我们。结果可想而知，要么回到版本稳定化阶段，要么交付质量差的软件，使组织的声誉受损。”（7）“死亡行军”损伤士气。“我们现在管理员工的方式很严苛，但这也是不得已而为之。我们必须完成组织的目标和业务，因此项目中的每个人都需要加班，而且周末也要上班。这会使他们的家庭关系和健康受损。后果是，我们很难招到顶级的开发人员，而且眼睁睁看着公司最优秀的开发人员跳槽到其他组织。此外，现有的员工士气低落，工作效率随着工作时间的延长而降低。”
这些例子已经足以让高管和经理们垂头丧气。尽管整个软件行业在20年间投入了大量的努力和金钱，但截至20世纪90年代初，仍然未在软件项目的成功开发上有所突破。我们在本书中介绍的流程，正是解决这些问题的良方妙药。1.3 错误的结果：项目失败
传统预测性软件开发流程的使用是导致如此之多项目失败的罪魁祸首。预测性流程也叫瀑布式流程，其可行性依赖于项目计划的准确性和执行的严格性。它必须满足以下条件。（1）需求不会变更，而且被完全理解。需求的任何变更都会使计划改变，从而产生连锁反应，最后的结果通常是导致已经完成的工作作废。不幸的是，在典型的软件项目中，35％以上的需求都会变更。一开始，客户会尽力确定所有需求。但商业环境瞬息万变，加上客户对自己实际需求的理解不完整，而且很难在成品完成前完整地描述预期系统，因此需求的变更就不可避免了。（2）技术能够正常使用。在软件中使用的所有技术都能按照最初计划的那样可靠地工作。不幸的是，项目中经常会引入做计划的人从未使用过的技术。可能是单独使用，也可能和其他技术组合使用，或者是不同技术用于同一用途。另外，技术标准有时也会在项目期间改变。（3）员工像机器一样可预测并能可靠地工作。计划中包含一系列相互关联的任务，每一项任务都需要专业技术人员根据特定的输入在给定的时间完成。然而一旦需求发生变化，就会产生连锁反应，所有任务都有可能受到波及。更重要的问题是，人并不是机器！人有情绪起伏，有技术水平差异，还有态度和智力的差别，不可能完全按照定义执行任务。因此到了最后，任务的执行情况可能与计划差异较大。
软件行业已经意识到上述这些困难，而且多年来一直试图增加计划方面的投入以解决这些问题。有时做计划的时间甚至和实际开发的时间一样长，在搜集需求、定义架构以及细化工作计划方面做了大量的工作。
只有计划基于精准且保持不变的信息，前期的所有投入才有价值。因此，这种方法只有在需求完全清楚而且相对稳定，计划也不会变化的情况下才是有效的。假如实际情况并非这样，预测性流程就会失败，因为预测性流程并不适合解决未知和意外的问题，而是用于优化约束问题的。
很多传统制造企业成功地实施了预测性流程模型。这些前期的研究工作对后续重复性地执行计划是有好处的，如生产出一辆辆汽车或者一个个烤箱。然而，对于软件开发来说就不一样了，因为软件开发的计划只执行一次。预测性流程适合制造业的原因是一个流程会制造出大量的产品。而这恰恰是它不适用于软件行业的原因，因为软件开发的一个流程只会生产出一个产品。
斯黛西图（Stacey Graph）是用来评估工作中的确定性和可预测性的有效工具。斯黛西图用于度量不同维度的工作的确定性和不可预见性，并标示出工作范围。我们用它来为软件开发中的三个维度建模，这三个维度分别是需求、技术和人，如图1-3所示。
我们可以把软件开发项目划分成下面三个方面。
需求。无变更风险时确定性最高。随着不明确因素、涌现式描述和可预见性变更的增多，确定性降低。
技术。所用技术为人熟知时确定性最高。随着开发及运营技术复杂度的提升，不同的技术在不同的软件开发和发布阶段通过接口交互，确定性随之降低。
人。确定性随着人员数量的增多而降低。当人员数量超过4个或者5个，甚至达到上百个并经常改变时，确定性不断降低，因为不同的人有不同的意见、态度和情绪。以团队或分组方式工作时，成员间的互动和工作的不可预见性是巨大的。图1-3 斯黛西图
使用斯黛西图，可以看到软件开发项目是复杂的，有时甚至是混乱的。瀑布式开发和传统软件开发所基于的预测性流程只适用于简单的重复性工作。现在你可以根据收益率（成功率）明确地判断你的流程是否符合需要。如果预测性流程适合你的项目，那么收益率（或者说项目的成功完成率）将高达99.99％。然而，根据斯坦迪什报告，使用预测性流程的软件项目的成功率只有14％。大多数公司无法在如此低的成功率下生存。试想一下，如果通用汽车生产的每七辆车中就有一辆报废，就是14％的成功率。
预测性流程并不适合解决软件开发中的问题，因为软件开发是复杂的，而不是简单的过程。我们可以断定，将预测性流程用于软件开发项目是令我们失败的根本原因。依据是，自从开始应用Scrum以后，软件开发项目的成功率提升了。
人们有时候将工程或桥梁建造等同于软件开发。桥梁建造等工程规范在斯黛西图中位于简单和复杂之间的区域。标准化流程只能使这种工作变得更复杂。工程建造中一共有三种类型的标准化。首先，牛顿定律解释了物体间是如何相互作用的。其次，采用的标准化材料，如木梁、金属支柱和扣件，都有标准的大小以及已知的特性。最后，所有类型的结构都有官方规范和检查标准。而在软件开发中却不存在如上这些标准。而且，随着软件行业的日新月异，这种没有标准的情况将不会改变。1.4 案例分析：PTC
PTC（Parametric Technology Corporation）是一家拥有5000名员工的跨国公司，从事产品生命周期管理软件的开发。其产品基于CAD/CAM（计算机辅助设计/计算机辅助制造）系统，帮助像雷神、BAE系统、空中客车等世界顶级的工程组织管理大型系统的开发，例如空中客车A380的开发。其主要是通过监控所有部件、配件和子配件的配置来进行管理。
2005年，PTC遇上了使用预测性流程有可能遇上的所有麻烦。（1）版本发布所需时间越来越长。发布一个版本的时间从18个月增加到24个月，而且看起来当前版本可能需要更长的时间。（2）无法按时发布。交付延误长达9个月，而且情况逐步恶化。那些依赖于重要功能准时交付的客户为此感到很不高兴。（3）在版本发布的最后阶段，软件达到稳定状态需要的时间越来越长。软件稳定花费的时间至少占了延误期的三分之二。（4）制订计划的时间太长，而且计划得不准确。每个版本的计划期都长达6个月，但计划仍然不够准确，经常需要改变。（5）在版本发布中期很难做更改。尽管无法确定项目延期以及软件的稳定和质量问题是由项目开始之后的变更引起的，但是大量的变更确实发生了。（6）质量持续恶化。这是相当严重的问题，而且情况越来越糟。（7）“死亡行军”损伤士气。 PTC很难招聘到高素质的人员。
PTC的开发部门使用的是瀑布式流程。为了使其更好地工作，他们尝试把需求弄得非常清楚。需求都被记录在一个详细的功能规格说明书里，只有在最终确定后才会让开发部门知道。在确定需求的这段时间里，开发人员并没有什么事情可做。他们要么修复程序错误，要么就因为极度无聊离职了。而测试团队在整个产品完成之前无法进行测试，因此能够进行测试的时间很短。由于发布日期的压力，测试团队被迫发布没有经过充分测试的产品。
Jane Wachutka是PTC Windchill产品开发部门的新任副总裁。刚入职时，她尝试了PTC的瀑布式流程，结果碰到了所有常见的问题。在以前的工作中，她曾引入很多类似帮助FBI完成“哨兵”项目的非瀑布式流程。在这种流程中，一个项目包含一个或多个迭代工作，每一个迭代不超过30天。开发人员被分成多个小组，在每个迭代中选择高价值的需求进行开发，然后将它们作为增量集成到可用的软件中。所有团队开发的增量集成为一个完整的可用增量。在接下来的每个迭代中，都将开发新的增量，并添加到之前的增量中。
Brian Shepherd是PTC产品开发部门的执行副总裁。当Jane在2007年引入新的软件开发流程的时候，Brian曾经有过顾虑。当时，Jane承诺如果Brian允许她引入新的流程，她保证能让开发人员更早地开始工作，降低开发人员的流失率，让测试人员更早地参与工作，在产品未经过完整测试且质量过关之前绝不发布。Jane还强调，可以让开发人员在需求文档还没完善的时候就开始开发，这样产品管理团队可以在开发期间经常检查和试用开发完成的部分，并给予开发团队反馈。于是，Brian同意引入了一套新流程——Scrum敏捷流程，但是同时他也警告Jane：“别搞砸了。”
当Jane第一次告诉她的团队要使用新的流程进行开发的时候，他们也有所顾虑，尤其是开发团队的成员。他们仍然希望开发过程的每一步都是精准的，能够确保满足需求。然而，随着对新流程的日渐熟悉，产品经理们不再试图将完美的需求文档交给开发团队，而是允许开发期间涌现新的需求。由于PTC现在能够在30天内开发出完整的功能，因此开发人员能够在任意适合的迭代中和客户直接交流。他们能够更直接地了解需求，以及如何更好地实现它们。客户也发现了这样的改变，开始在每个迭代中和开发团队一起工作。他们积极参与定义功能，得到了真正想要的功能。
产品管理团队拥有持续变化的三个需求集，分别是为三年、两年和一年的需求集。三年的需求集包含了总体愿景，描述了重要功能。两年的需求集中定义了这些愿景将在哪些版本中具体实现。本年度的需求集中包含了前6个月中每个30天迭代的需求，以及后6个月的目标路线图。每年的需求集都比前一年拥有更多细节。开发人员依照当年的需求集进行工作。他们和PTC的客户协作定义需求细节。整个组织变成了一个富有创造力和生产力的智囊团。
两年之内，Jane对Brian的所有承诺都兑现了。版本发布时间从之前的24个多月降到了12个月，而且交付的产品质量很高。到2011年，PTC已经发生了翻天覆地的变化，无论是对内部还是客户都是透明的。意外情况很少发生，客户知道在什么时候能够得到什么。到了2012年，缺陷率已经几乎降低为零。新的特性、用户界面和工作流功能都被加入到了产品中。整个产品也经过了彻底检查，安全性足以抵御外来的风险。最后，预算和人员需求都降低了超过十个百分点。Brian为软件产品开发部门建造了新的办公室。新的办公场所满足了新流程所需的透明度。现在每个人都在一个开放的空间里，没有独立的办公室，而且所有的墙都是玻璃的。
最近，PTC的首席执行官Jim Heppelmann听取了下属经理们关于提高年度预算的讨论。最后，他打断了他们，并让每个人感谢Jane的部门在提升质量和增加功能的同时降低了软件成本。正因为这样，才为其他部门腾出了提高预算的空间。
有一次，一个以色列客户与Jane和Jim进行电话会议，评估PTC公司的产品。Jane告诉对方的首席执行官，雷神公司正在其全球的子公司中使用PTC的产品，并建议他向雷神的高管咨询，因为她清楚地知道，雷神公司不仅对PTC的产品非常满意，还惊叹于PTC新的流程能够避免意外情况的发生。他们能够与PTC实时合作，随时调整自身的计划，甚至还采纳了PTC的软件开发流程。Jim插话说，Jane忘记提及上一次发布的版本，那是PTC交付的最漂亮的一个版本，并且主要归功于Jane改变了开发流程。1.5 小结
软件开发在过去非常容易失败，其根本原因就是使用了预测性流程来做复杂的工作。当Scrum这样的经验型流程被采用后，软件项目的成功率会大幅提高。
因此，在30天内开发出可用的软件功能是完全有可能的。不要听你的开发人员说这不可能，因为从21世纪伊始，已经有成千上万名开发人员成功做到了。也许软件产品仍然很庞大，但它可以被切分为几个小模块，以30天为周期逐个开发。第2章 Scrum：正确的流程产生正确的结果
在上一章中，我们发现正确的软件开发流程是经验型流程。现在，让我们来看看经验型流程是如何工作的，应该如何运用它进行软件开发。本章我们将运用多年来研发的敏捷软件开发流程Scrum来探索经验型流程。2.1 经验型流程实战
在经验型流程中，信息是通过观察而不是预测获取的。经验型流程是解决复杂问题的良方妙药，在这种情况下，未知的事情比已知的事情多。经验型流程可行的前提条件有下面两个。（1）检视和调整。我们必须经常检视当前的进度，这样才能够调整下一步的计划，从而得到最好的结果。检视和调整的频率取决于我们愿意承担多少风险。未知的事情越多，我们就越容易偏离目标。偏离目标越远，就会浪费越多的资源来重新定位目标，放弃无用的工作，重新开始。（2）透明性。我们必须从最终目标的角度进行检视。比如我们需要开发具有某些特性和功能的系统，那么我们要检视的对象一定是某种特性、功能，或者是两者各自的子集。
假如使用预测型流程，规划的需求可能需要花费数年才能实现。但是我们知道，在软件项目开发中，开发时间如此之长将增加过多的风险，并造成巨大的资源浪费。因此，我们将开发周期缩短至30天或更短（我们将在后面讨论缩短周期的意义）。在第一个30天后， 我们可以检查结果，并据此决定下一步的工作，适时地调整路线，实现既定的目标。
在开始开发之前，需要先有一个如何利用软件创造价值的想法或者愿景，知道如何有效地运营，如何开发出有价值的软件，还可以清楚地描述出软件需要实现的功能及必须满足的需求。相对于这些而言，其他事情可以暂时放到一旁，以后再考虑。我们需要知道的，包括至关重要且明确理解的内容，也包括一般相关且不甚明确的内容。
接下来列出包含所有想法的清单，这个清单叫做需求待办列表（如图2-1所示）。我们按照优先级对需求进行排序，把最重要的需求排到最顶部。这个列表记录了我们的想法，可以随时更新，根据需要增加、修改或删除其中的项目。图2-1 根据业务操作划分的需求待办列表
首先，需要确定我们的想法是否可行，能否在30天之内开发出有用的软件，并验证后续的工作。
我们召集一个软件开发小团队，与其分享我们的愿景和初始需求。我们和这个团队协作确定最重要的需求。虽然整个系统可能是非常庞大的，但是我们只关注我们正好能够可能和需要完成的部分。同时，我们也希望能够尽快将部分愿景变成可用的软件。
我们会问开发团队，在接下来的30天之内他们可以交付多少个可使用的完整功能。我们从最重要的需求开始讨论，而开发团队可能会带入其他的问题，如软件的稳定性问题。我们会详细讨论这些需求，帮助开发团队找到最好的开发方法。虽然我们不是开发团队成员那样的专业开发人员，但能够帮他们澄清需求，做出选择。
让我们来定义一下本书中提到过的一些术语。
迭代。所谓迭代，就是重复一系列步骤或某个流程，一般是为了实现一个预期目标或者结果。流程的每一次重复就叫做一次迭代，一次迭代所产生的结果被用作下一次迭代的开始。对你来说，第一个30天就是第一次迭代。
频率。频率指的是迭代的长度。高频率的迭代通过持续检查进度来有效控制浪费、降低风险。频率的范围最好在一个星期以上，一个月以内。
增量。增量就是不断增长的整体的一部分。开发流程中一次迭代所产生的功能结果就是增量。增量随着迭代的增加不断增长，直到变成我们所需的有价值的系统。
透明性。增量必须是完全完成并可用的，不能有任何工作落下。未完成的工作或原形都不具有透明性，因为我们无法判定其完成度是多少，剩余的工作还有多少。
迭代增量式开发。这是通过一系列迭代进行软件开发的方式。每个迭代都会基于之前的所有增量产生出新的功能增量。迭代会持续进行，直到完成目标，实现最大价值。
于是，我们开始了第一次迭代。开发团队将我们的需求转化为功能增量。每次迭代都从做计划开始，之后开发团队按照计划进行开发，最后所有人共同检查这次迭代产生的软件增量。
可能需要若干或者很多次迭代才能开发出满足我们需求和愿景的系统。每次迭代的时间都是固定的，也就是说，我们为每次迭代分配和使用的时间长度是相等的。每次迭代都会产生潜在可用的软件增量（如图2-2所示）。每个软件增量必须是没有任何遗漏的完整功能。每次迭代产生的软件增量都会作为下一次迭代的起点。图2-2 一次迭代产生一个透明的增量
在一个迭代完成之后，我们就可以根据实际情况指导开发团队，甚至改变最初确定的方向。实际上，这种情况发生的概率很高。最初，我们拥有一个愿景或者好的机会。然后我们让开发团队创造软件来实现其中的重要部分。一次迭代后，我们得到了第一个增量。于是我们开始思考如何利用它，向其中添加什么使其更加实用。在某些学科中，这被称做“中期修正”。而在经验型流程里，这种修正在每次迭代都会发生。
在愿景的激励下，开发完每个增量后，我们都会思考更具创造性或更独特的方式实现愿景。有时候，这会引发我们和开发团队的对话，讨论如何在下一次迭代中获得最大价值以及下一次迭代应该做什么。我们乐于拥抱变化。
也许我们会发现我们的愿景并不现实。在实现愿景的最佳时机来临时，技术手段还没准备充分。也许我们对结果不满意，或者觉得成本太高了。这些情况有可能迫使我们在这时停下前进的脚步。在找到更可行的愿景之前，我们不再花费一分钱。杜绝浪费也是成功项目的要素之一。
有时侯只需要一次迭代就能够开发出可用的软件，在这个基础上我们让开发团队开发更多的功能。我们充分利用机会，通过一次次迭代开发出越来越多的功能。每次迭代开发出来的增量都构建在之前所有增量的基础上。一旦开发出的产品满足了我们的需求，就可以发布供人们使用了。图2-3展现了包含多次迭代的版本发布。
我们将经验型流程作为软件开发流程。在每次迭代结束的时候决定下一次迭代要做的事情，并且持续将实现愿景作为目标。我们会评审已经完成的任务，并根据推测的成本和交付日期决定是否继续。这种流程叫做“迭代增量式流程”，也就是Scrum的基础。到目前为止，我们已经描述了这种流程是如何工作的，以及它为什么被称为30天软件开发。现在，来看看它是如何解决瀑布式流程（或者说预测型流程）中的问题的，它能否解决之前提到的问题，甚至更多的问题。图2-3 多次迭代产生一个叠加功能增量2.2 经验型流程真的能够解决问题吗
经验型流程真的能够解决瀑布式流程中的问题吗？让我们来逐项分析瀑布式流程中的痛点吧。
瀑布式流程问题之一：版本发布所需的时间越来越长。在经验型流程中，版本是由一系列增量集成在一起组成的，这些增量通过一次次迭代按顺序开发。我们还可以在任意时间停止迭代。一旦发现产品的价值已经达到最大，尤其是发现软件里过半的功能很少被使用的时候，就可以停止迭代。我们还可以在到达交付期限或者预算上限的时候，停止迭代并发布软件。我们只会开发并积累有价值的增量。
瀑布式流程问题之二：无法按时发布。在经验型流程中，版本的发布最多延迟30天，因为每次迭代的最长期限只有30天。当到达交付期限的时候，我们就可以交付累积的增量。由于我们不会在迭代中开发低价值的功能，因此可以比以往更早地发布完整的系统。在传统开发流程中，常用功能的数量还不到功能总数的一半。而在经验型流程中，我们根本不会在不常用的功能上花时间。
瀑布式流程问题之三：在版本发布的最后阶段，软件达到稳定状态需要的时间越来越长。在经验型流程中，每次迭代所产生的增量都是完整和可用的，并且接下来的增量都会包含之前所有的增量，因此所有增量都是完成且可用的。也就是说，没有软件发布之前的稳定化阶段，因为软件一直保持稳定。
瀑布式流程问题之四：制订计划的时间太长，而且计划得不准确。在经验型流程中，初始计划简化成为设定目标，并确定达到目标所需的高价值功能和特性。然后预测交付日期和成本。第一次迭代之前的计划时间通常只有瀑布式或预测型流程的20％。我们只为即将开始的迭代做详细的计划，这被称为“适时计划”。另外值得注意的是，需求是涌现的。我们在检视每个增量结果的时候，都会为下一次迭代调整最佳需求。
瀑布式流程问题之五：在版本发布中期很难做更改。版本发布中期的概念在迭代增量式项目中已经不复存在了。在每次迭代开始前，都能够以最小的代价发现和提出需求。
瀑布式流程问题之六：质量持续恶化。在经验型流程中，每次迭代产生的增量都是完整且可用的，因此必然已经通过质量要求。而后续的增量同样要达到相同的质量要求。也就是说我们再也不必在项目最后的稳定化阶段为了赶上交付期限而牺牲质量，因为在开发过程中质量已经得到了保证。
瀑布式流程问题之七：死亡行军使员工士气受挫。版本最后的稳定化阶段已经不再需要，因此加班的“死亡行军”也随之而去。
正如我们所看到的那样，基于经验型流程的迭代增量式开发有效地解决了传统软件开发中的种种问题。为了满足所有企业的需要，我们需要懂得如何管理这些项目。接下来我们将探讨这个问题，并在第6章详细分析。
要管理这样的项目，只需要用到三个变量。首先是（A）需求，也就是预想中软件所需要的功能。其次是（B）时间，我们使用30天作为时间单位。最后是（C）完成的工作，用已交付的可用功能来度量，也可以看成是在任意30天内累积完成的（A）。
你可以创建如下图表来进行项目管理。（1） 以需求待办列表作为y轴即垂直轴。每个需求所需要的工作量都用单位工作量来衡量。假设我们有5个需求，它们分别需要2、3、5、3、8个单位工作量。这些需求在y轴上达到了21个单位工作量。你可以根据需要对这些需求进行排序。我们暂且假设自上而下的顺序仍然是2、3、5、3、8。（2）以时间作为x轴即水平轴。以一次迭代的长度，即30天作为单位长度。（3）根据过往的经验，我们预期开发团队能够在每次迭代完成5个单位工作量。一旦团队正式开始工作，就能够知道其实际工作效率，当然这种预测是基于过去的经验的。我们预期团队可以在前4次迭代（5，5，5，5）完成20个单位工作量，然后在第5次迭代完成剩下的工作量。（4） 在每次迭代结束时计算已经完成的工作量和可用功能总量。我们计划在第一次迭代里完成前两个需求，分别是2个和3个单位工作量。然后在第二次迭代里完成工作量为5的下一个需求。在这之后，我们通常会改变下一步的计划。通过检视前两个增量，我们经常会发现一些未曾预料的新需求，需要在下一次迭代里实现。如果没有新需求的话，就继续按原定的计划进行。然而，就算需求或者计划在迭代结束的时候改变，也不会带来什么损失。增量的度量单位和y轴上的需求一致。（5）开发团队在前三个迭代中分别完成了3、5、5个单位需求。图2-4展示了这三个迭代的成果。图2-4 发布燃尽图
根据最初的计划或者预测，项目需要21个单位工作量，预计每次迭代完成5个单位工作量。图2-4中的虚线表示预测的工作计划。可以看出，在计划中，第五次迭代开始不久之后，就能够完成所有功能。
然而，实际的情况是，第一次迭代完成了3个单位工作量，第二和第三次迭代分别完成了5个单位工作量。在图2-4中用实线表示实际的工作进度。如果我们按照当前的实际进度预测接下来的工作进展（如图2-4中实线的延长线），如图所示，我们将在第五次迭代的中期而不是开始完成所有工作。当然，这仍然是我们的预测，无法确定。经验理论就意味着在工作实际完成之前，无法确定我们究竟可以完成多少工作。我们预期在第一次迭代能够完成5个单位工作量，却只完成了3个，因为所用的技术没有预期的可靠，有一个需求不够清楚，还有一位开发人员休了几天病假。我们在第一个迭代结束时检视了实际进度，发现投资回报率依然可观，而且在第一次迭代中发生的问题应该不会再出现了。基于这样的预期，我们冒险进行了下一次迭代。在每次迭代结束时，我们都会进行检视和调整。
经验主义对于以下方面大有裨益。（1）管理。在每次迭代结束时，能够准确知道有多少需求和哪些需求已经完成，以及哪些功能已经可用。可根据以往的进度制订将来的计划，并估算出可能完工的日期。在制订计划的过程中，可以清楚地意识到计划有可能在下一次迭代结束时改变。（2）控制。如果信息显示当前的进度比预期要慢，可以减少剩余功能的数量或者范围。例如，在第二次迭代结束时，还有13个单位的需求要完成，可以将剩余需求减少到10个单位。如果在接下来的两次迭代中，开发团队都能够保持5个单位需求的开发速率，那么将在第四次迭代结束时完成所有的功能。（3）可预期性。有时候预测有可能是错误的。实际完成工作的日期有可能比预期晚几个星期。你有可能在第一次迭代结束时有延期的担心，在第二次迭代结束时觉得可能性更大了，在第三次迭代结束时基本可以肯定了。这时候，任何需要使用这些功能的人就可以开始同步调整他们的计划。类似地，项目的预算也应该尽早地修改并确认。（4）风险管理。开发团队在前3次迭代中分别只完成了2个单位的功能需求。在第三次迭代结束时，可以预测所有工作将会在第十次迭代的中期完成。如果原来的预算是10万美元的话，根据新的预测，预算将超支15万美元。如果25万美元的投资回报率过低的话，就可以在第三次迭代结束时取消该项目。2.3 人类实践源于经验主义
由于经验型流程使得什么工作可行、什么工作不可行变得透明，我们能够快速地学习这种开发方式，并为其制订一系列最佳实践。这些实践部分来自学术准则，部分来自团队自身的体会和实践。
总的来说，我们发现小团队最适合进行这种迭代增量式的软件开发工作。这里所说的小团队，一般来说应该由3～9人组成。团队总体应该拥有将需求转化为功能增量所必备的技能，从而实现你的愿景。根据开发的软件类型，团队中的成员应该具备编程、测试、设计、分析、编写文档、设计架构等技能。我们希望通过调整团队结构、提高工程实践能力和建立规范来塑造团队特质，提高团队的生产率、质量、创造力和持续改进的能力。
我们对高效软件开发团队的见解，大量地参考了竹内弘高和野中郁次郎的研究结果。他们曾经在哈佛大学进行关于团队流程的研究。他们调查了拥有较高目标的自主团队，其团队成员积极地相互学习，以短期迭代为主要工作方式。这些团队之间紧密的协作能够缩短知识更新周期，从而有助于创新和更快地响应市场，获得高质量的结果。这些团队让他们想起了英式橄榄球，于是他们把这种项目管理方式叫做Scrum——英式橄榄球中球出界后重新开始比赛的仪式。
基于竹内弘高和野中郁次郎的研究，我们发展了以下实践来补充经验型软件开发流程的结构。这些实践能够打造出拥有出色创造力、质量、工作效率和士气的高效团队。
尊重每位员工。在一些公司里，员工被当成孩子。他们的创造力会被削弱，每天只能被动地接受别人指派的工作。如果要让员工对自己的工作拥有自豪感以及参与感，必须营造一个充满鼓励和尊重的工作环境。Scrum的设计能确保员工受到尊重和赞赏。当然，我们不是第一个想到在Scrum里运用这种实践和想法的人。行业中已经存在很多最佳实践了。而Jeff非常关注Scrum软件开发环境中“人”的因素。
营造宽松氛围。开发流程开始时，管理层制订富有挑战性的宽泛目标或者战略方向。管理层不应该制订详细的产品和工作规划，而应该留给开发团队充分的自由和发挥空间。制订富有挑战性的需求能够有效地在团队内部创造动态张力。
自组织项目团队。由团队自己决定如何实现管理层的目标。这么做的目的是为了防止团队依赖于外部的意见，从而培养团队自我组织和管理的能力。当团队展现出自我管理、自我超越、相互学习这三方面能力的时候，就证明他们已经成为了真正的自组织团队了。团队中需要自我管理是因为管理层只提供指引、资金和支持，而不会对团队进行过多的干预。从某种意义上来说，管理层扮演的更像是风险投资人的角色，只提供金钱的支援而不会对团队指手画脚。在这种情况下，团队会不懈努力做到更好，并且为达到极致而不断探索。
相互学习的团队。不同职能的团队在同一地点工作，能够培养更高的效率、质量和创造力。团队成员互相协作，专业技能的界限渐渐地变得模糊。实际上，有些公司规定每个团队成员必须拥有两项专长（例如能运用两种或以上编程语言进行编程和测试）以及两个不同领域的知识（例如设计和市场营销）。团队成员间的紧密互动使团队开始形成自身的脉搏和节奏，产生韵律性的创新和效能。
开发阶段之间的重叠。由于取消了“线性”顺序的工作方式，团队可以适应开发过程中各种障碍带来的“震动”或者“噪音”干扰。当遇到瓶颈的时候，团队应该能够绕开它，而不是突然就中断工作了。重叠开发阶段的理念 废除了传统部门分工的概念。团队工作的速度和灵活性得到了提升，同时，共同的责任和合作还激发了成员的参与感和使命感，以及对市场的敏感度。而这种做法的代价是，你需要管理一个具有可见度、需要沟通、有紧张感甚至是冲突的流程。
多层次、多功能的学习。团队中的学习是多维度的。例如，3M公司鼓励每位工程师花大概15％的工作时间来追求他们的梦想。如果一个团队在本田公司遇到了障碍，就有可能被派遣到欧洲一探究竟。也就是说，学习通常没有固定的方式和场所。最重要的是，学习源于管理者所培养和激发的员工主动性。
微控制。虽然开发团队是自我管理的，但这并不意味着他们就完全不受控制了。我们的目标是既要让团队有足够的空间自我管理，又要设定足够的检查点，防止不稳定、不明确以及紧张因素带来混乱。使用同伴的无形压力以及“关爱和控制”的方法是微管理的基础。团队的这种活跃状态会使团队的隐性知识慢慢浮现，并且创造出以软件方式呈现的显性知识。这种活力只有在管理层营造的关爱氛围下才会出现。选择团队领导要小心翼翼。团队依靠引入变革及恰到好处的活力来保持其动态均衡，确保成员间能够相处融洽，协同工作。团队成员之间应该拥有相同的价值观。激励机制应该以团队为单位。团队成长过程中犯错不可避免，我们要对其有耐心。
知识传递。在团队中获得的知识并不足以保证在市场上成功。来之不易的知识应该在整个公司范围内积极分享。公司依靠有经验的员工来培养新的团队，把工作中积累的项目实践提升为整个公司级的标准流程。与此同时，摒弃过去的做事方式和学习新的东西同等重要。市场日新月异，从前的方式过时了，用旧的方式做事不可能满足管理者提出的新要求。
我们发现下列要素同样能够帮助改进软件开发。
人。人在自我管理的时候效率最高。与其让别人替自己许下承诺，人们更重视自己许下的承诺。人在非工作时间会有很多更好的创意。人们总是尽力把事情做到最好。然而，如果在高压下高强度工作的话，人们通常会自觉地逐渐降低工作质量。
团队成员。团队成员在没有外界干扰的时候效率最高。团队在自己解决问题时成长最快。面对面的深入交流是团队工作最高效的方式。
团队组成。团队比同等数量的个人的工作效率更高。具备所有工作必需技能的跨职能团队能够创造出更强大的产品。团队中人员的变动时常会在一定时间内降低团队的效率。2.4 尽管我们知道该如何做
虽然我们都知道预测型或者瀑布式流程有诸多弊端，但是仍然有很多人和组织继续想方设法用这种流程获得成功。2005年，我们和玛莎百货（Marks &Spencer）的首席技术官以及他的工作人员一起讨论经验型流程以及Scrum。那时候，他刚刚升级了整套开发流程，从国际咨询顾问公司普华永道（PWC）那里引进了整套的方法、工具、培训和实施服务。而当时PWC采用的流程正是预测型或者说瀑布式流程。
当时玛莎百货的首席技术官对经验型流程感到好奇，听起来似乎挺熟悉，于是想了解更多这方面的知识。随着我们向他进一步解释，他开始流露出激动的神情。他打断我们，说他的组织也在使用经验型流程。他说，一旦使用PWC流程的项目陷入困境，他们就会中断项目，然后开始使用经验型流程直到项目回到正轨，有时甚至直到项目结束。他说那是他们的“杀手锏”，也就是说他们的这一绝招能够帮助他们摆脱困境。
当我们询问使用经验型流程摆脱困境后他们会怎么办时，他却毫不顾忌地说他们会回到原来的PWC流程上。由此可见，尽管他们知道该怎么做，但并不意味着被允许这样做，除非遇上紧急情况。2.5 敏捷性
随着我们生活的世界变得越来越复杂，商务人士和组织面临越来越多的商机。每位企业家或者梦想成为企业家的商务人士需要抓住机会，发现什么是可行的、成本会是多少以及会有哪些风险。一旦发现风险是可以接受的，企业家就会尽快付诸行动以把握机会。然而，尽管我们尽力控制风险，事情仍很容易失控。大胆和谨慎缺一不可。我们把掌控机会的能力定义为“敏捷性”，它用来衡量成功把握机会的能力。我们能够迅速灵敏地大胆采取行动，并有效地控制风险。我们能够取悦新的客户，也能让竞争对手在早晨醒来时为他们的失败而垂泪。
敏捷性是在一定风险下把握机会的能力或着说是勇于面对挑战的能力。它是现今最重要的竞争优势。我们利用了这种优势，并通过把项目控制在30天以内的方式来控制风险。
按照这种方式，我们就能够大胆尝试新的想法，不畏惧失败。我们能够在早期就知道这些想法是不是成本太高、不现实或者根本无法实现，这样就可以在投入更多金钱之前“刹车”。2.6 小结
我们需要把握机遇并有效地响应挑战。我们也需要探索很多新点子，然后变换思路，找到最好的解决方案。如果看到机会或者想干一番事业，你不仅可以实现目标，还能够完善目标以提供最有价值的功能。拥有了更可控、更快、风险更低的流程，你就可以在30天内开发出有价值的东西并持续改进。
迭代增量式的经验型软件开发方法也已经存在20多年了。有了它，就可以在严格控制风险的同时，限时开发出软件功能增量。它在每30天（甚至更短）完成整个业务功能增量交付的同时提供了极高的透明性，因此避免了浪费。它的敏捷性和灵活性有助于软件的调整，以适应涌现的需求，从而大大地提高了软件的适用性。我们再也不用担心软件的开发进度，再也不用担心承诺无法兑现，再也不用担心预算的增加，再也不用依赖甘特图和模型等抽象工具来分析进度，因为我们能够准确地知道至少在每30天中完成的功能和进度。第3章 你也来试一试：创建试点项目
如果读到这里你仍对经验型流程感兴趣，那么可以开始尝试用它来解决问题和实现需求了。现在你可以建立一个试点，进行小规模的初步研究来评估可行性、时间和成本，并找出不利影响。本章将介绍：（1）如何为这种新的软件开发流程运营试点。（2）从这个试点中可以获取什么信息。（3）别人是如何使用这些试点的（他们发现的问题以及需要解决的问题）。
你是试点运作的主角，本章将会一步一步告诉你如何成功运营试点。此外还会提供全面的介绍以及一些案例，可以在试点开始运营以后再读。
建立试点非常简单，只需要遵循下面的步骤就可以了。（1）组建一个团队。（2）确定想要为之创建试点的项目。（3）完整地实现软件的一小部分。（4）确定下一步想做什么。（5）评估可以改进的方面并付诸行动。（6）重复步骤（3）到步骤（5）直至达到目标。
开始之前，最好先考虑如果试点项目失败或者成功会发生什么。在放弃一件不可行的事之前，你愿意为之投入多少时间和金钱？如果已经以增量形式开发出有价值的功能，要如何继续下去？在试点项目结束后，你将会决定是否更大规模地应用经验型软件开发。当然，除此以外你还获得了在试点项目期间开发出来的软件。3.1 经验主义已经在组织中使用了
在创建试点之前还需要意识到的一点是，经验型流程很有可能已经深植在组织的其他地方了，只是没用在软件开发中。例如，在一个典型的销售组织里，经验型流程的使用贯穿整个销售年度。首先，它制订一个年度计划，确定全年销售额，并列出新老客户渠道，表明销售额的来源。在销售年度的前几个月里，有明确的潜在客户，并能具体地推算出销售额。那些已知潜在客户可能产生的订单将放在第二季度的销售计划中。客户的想法、联系方式和购买理由都被确定。下半年的销售计划通常是不确定的，比如销售机会、目标客户和续签客户。
随着时间的推移，销售经理不断更新销售管道。接下来两到三个月的销售额会大致确定，而这之后的计划仍然无法确定。每个月要审查已经完成的销售、接下来的销售计划变更以及对未来销售的预测。之后的销售工作和公司的经费预算会根据评审的结果进行调整。整个流程如下。（1）组建团队。把销售团队召集到一起，讨论公司的现状，评审竞争格局，及时向销售人员更新产品信息。（2）规划要做的事。按照随时间递减的准确度设定年度销售管道、目标和销售额。分配销售区域和配额。（3）完整地完成一小部分销售。进行一个月的销售活动，看看会发生什么，以及对将来的销售管道会有什么影响。（4）评估下一步要做什么。更新销售管道，集中精力为下一个月的销售做准备。（5）继续行动并评估。每个月重复上述步骤。
销售组织从来不会考虑使用预测型流程，因为可以预知的事情实在太少，会改变的事情实在太多，不可能在销售年度的第一天就对整个年度的销售额和销售源做出计划。3.2 一个试点范例
正如之前所述，创建试点项目是进行小规模的初步研究，对项目的可行性、时间、成本以及不利影响进行评估。你可以切身体会到经验型流程是否有助于你的软件开发。我们建议在有严重问题的项目上建立试点。这个项目最好是棘手的、困难的、使你缺乏信心的。
接下来的试点项目范例可以供你参考。有家位于俄亥俄州的金融组织为不同行业和客户提供共同基金，大多数客户都通过在线的门户管理自己的账户。共同基金部门的一位副总裁有一部智能手机，一直以来他都在使用一些手机应用软件，例如某个支付软件。他想知道如果客户能够通过智能手机软件对自己的基金进行大部分的管理，对于客户来说是否会很方便。他认为，这样一款软件能够使现有的客户进行更多的交易。如果能够在竞争对手发布同样的软件前占得先机，就有可能吸引更多的客户。
于是，他带着这个想法来到了IT部门，以寻求他们的帮助。IT部门的同事对他的想法很感兴趣，也很想进行尝试，因为他们一直都希望能够进入移动技术领域。于是IT团队建议他们从研究软件的需求开始，需求分析完成大概需要5到6个月。需求确定之后，就能够计算出成本并制订开发的时间表。接下来，5位分析师和1位项目经理要首先进行需求分析。
这位副总裁认为项目第一阶段需要50万美元的预算，而这笔预算仅仅用于确定需求，不得不说是一笔巨款。也就是说，开发软件的成本仍然是未知的，但是很有可能会是第一阶段成本的数倍。对于这么大的开销，他需要向他的老板、资本审核委员会、IT部门（为了开发日程表）提出申请。如果没有足够的理由来证明这个想法的合理性，公司就不会拿出这么多资金来冒险。
要证明这是不是成本合理的风险投资，最好的办法就是建立试点。使用经验型软件开发流程，这位副总裁就能快速地得出结论。此外，他还能够在试点运营过程中开发出该软件最重要的部分功能。他预计这个试点项目只需要3次迭代、3位软件工程师以及12.5万美元的预算。
为了获得对试点项目的批准，这位副总裁准备了一个演讲。利用这个机会，他向老板、所属部门的经理以及IT指导委员会介绍了他想要做的事。演讲文档的首页介绍了该试点项目的目的，即确定这款智能手机软件对组织来说是否值得投资。他阐述了该款软件与组织的商业策略相一致的原因，然后概括介绍了经验型软件开发流程，描述了其工作方式以及为什么他要采用这种流程。他解释说，这与组织的技术策略并不冲突。最后，他介绍了项目的其他部分。他说，试点项目的结果有可能是实现一款可行的软件，并可以进一步对其进行开发。而整个软件的开发成本可以从3个月的试点数据中推测出来。除此以外，这位副总裁和组织还能够了解经验型开发流程在组织内是否可行。
演讲之后，这位副总裁根据大家提出的异议对计划进行了调整。其中一项就是向开发团队中加入了一名拥有迭代增量式软件开发经验的IT项目经理，于是预算增加到了17万美元。但是这位经理的加入有助于IT部门对经验型软件开发流程进行评估。他可以成为试点项目的经理，如果有时间的话，甚至可以帮助团队进行软件测试。
最后，这位副总裁获得了对该试点项目的批准，但有一个条件，就是他所在业务部门以及IT部门的相关人员需要每个月和他以及开发团队一起评审项目的进展。
3.2.1 组建团队
一旦试点项目得到批准，这位副总裁的首要任务就是要在IT试点经理的帮助下组建团队。他们首先决定，团队的成员应该来自IT部门内部，而不是外面请来的承包商。接下来开始评估谁适合参与该试点项目。他们认为，如果招募水平不高的工程师，其能力可能不足以开发出增量式软件。虽然不会像使用瀑布式流程那样要12个月以后才能发现，但这仍然会阻碍试点项目目标的实现。如果招募最优秀的工程师，虽然他们能够开发出增量式软件，但是并不足以说明经验型流程的好处，因为无论在任何环境中这些优秀的工程师总是能够找到成功的方法。因此，为了让试点项目具有普遍性，他们决定从IT部门挑选满足以下条件的工程师。（1）懂得如何运用试点项目中的技术进行软件开发。（2）作为整体，拥有开发完整软件模块的所有必需技术。（3）对迭代式软件开发有一些了解。至少有一位工程师拥有相关开发经验，能够指导其他团队成员。（4）自愿参与项目。（5）充满热情。
试点经理帮助副总裁找到了一个适合试点团队工作的宽敞环境。开发团队需要按照这位副总裁的想法开发软件，因此在他的办公室外设立了工作区。此外，试点经理还提出了以下建议。（1）工作区的设计便于所有团队成员直接交流，紧密合作。这样的设计让他们的沟通更有效率，一旦发生误解也能够快速地发现并补救。整个工作区是开放式的，中间没有隔墙。（2） 工作区内配有白板纸和白板，这样团队成员就能够将自己的想法涂鸦出来，进行分析。工作区并不需要非常花哨，但是必须要有足够的设施让团队成员在项目期间存放自己的私人物品。（3）团队成员必须是全职的，因为兼职的成员无法随叫随到。即使他们有空，因为是兼职也可能被其他工作分心。（4）所有人都应该在正常的工作时间内工作。将需求转变成可用的软件增量需要有实际解决问题的能力。在正常的工作时间结束后让团队成员回家，能够激发他们的潜意识，从而想出新办法，找出错误。
最后，这位副总裁组建了一个由他本人、试点经理以及3位软件开发人员组成的团队。
3.2.2 向团队成员传达有吸引力的消息
有时候，要吸引优秀的软件开发人员是非常困难的。如果他们不理解这份工作对自己意味着什么，则很难被吸引。团队中的所有人都应该清楚试点项目的目标以及前景。
Curaspan的信息吓跑了应聘者。下面是一个例子。Curaspan的在线软件被医院社区用于对病人档案进行有序管理，档案覆盖了病人从出院到康复的记录，或者是长期的院后治疗。然而Curaspan遇上了麻烦。它的软件已经用了10年多了，性能差得让人无法接受。投诉电话源源不断地打来公司。
于是，Curaspan聘用了Edwen Miller作为产品管理的副总裁。他曾经利用经验型软件开发流程帮助数家公司起死回生。Curaspan的高管希望他同样能帮助他们。于是，Edwen开始为开发下一代产品招兵买马。在此过程中他使用了常规套路，包括找老朋友、行业内的知名人士以及猎头公司。在筛选过简历之后，他邀请了合适的候选人前来面试。然而，在他发出大量的录用通知之后，却没有任何人愿意上岗。
问题就在于，Curaspan的高管和工程师都不相信经验型流程真的能够让他们起死回生。他们没有真正地理解这种流程。他们缺乏战略性的承诺，轻视即将从事的工作，并反感经验型流程，这些吓退了应聘者。即使在经济衰退的时候，优秀的工程师也会找到别的工作机会。
人们能够感觉到好的事物。就算打算要做的事情是之前从来没有做过的，也要向应聘者（无论是来自内部还是外部）传达清晰的信息。告诉他们所有可能性，你会为他们做些什么，有什么风险和机会。
Iron Mountian协调团队成员。Iron Mountain Digital是一家市值31亿美元的数据管理公司。他们的LiveValut产品提供远程的计算机数据（电子）存储。2006年， LiveValut的团队陷入了困境，因为他们已经超过12个月没有发布新版本了。尽管LiveValut团队的成员对经验型软件开发流程Scrum有所了解，但是他们当时仍然在使用老的开发流程。由于没有意识到风险，Iron Mountain的市场部门在2007年6月和微软洽谈了一份合同。微软为客户提供一种定期备份服务器的软件，但是这些备份都保存在本地服务器里，微软希望能够利用LiveValut为客户提供远程备份方案。
产品经理Paul Luppino与微软商议后，决定为微软开发新版本的LiveVault。根据合同，微软需要在2008年2月为其客户提供远程备份方案。Paul被Iron Mountain任命为这次新版本开发的项目经理。这次开发由分布式团队负责，Iron Mountain的开发人员在位于马萨诸塞州的绍斯伯勒，微软的开发人员在位于印度的班加罗尔，微软的产品经理在华盛顿州的雷德蒙，而Paul则在绍斯伯勒。所有的工作需要在6个月内完成。
Paul已经无路可退了。各个团队和组织所在地不同的问题一直困扰着他。他要面对的是多个合作伙伴、一个对公司的承诺、一个交付的限期、一个意志消沉的开发团队以及12个月的失败记录。
Paul听说过Scrum，所以马上为项目组所有的Iron Mountain员工报名参加了培训课程。与此同时，他启动了项目的迭代。尽管Paul并不清楚会遇到什么问题，但他觉得如果等到把所有东西都调查清楚，再制订计划，可能要花费几个月的时间。因此，他决定马上启动项目，他认定随着项目的进行能够找出问题所在。通过迭代，他和Iron Mountain会在30天内发现是否存在问题，以及项目是否可行。
项目组中的每一个人都因地理位置的问题而倍感困扰。视频会议成本太高， Skype的通话质量不够好，差旅费又太高。每个人利用每日例会（通过成本非常高的视频会议、电子邮件、Wiki等社交工具）协调工作，对当前进度进行评估，并为接下来的工作重新制订计划。所有团队成员都会参加每日例会，包括马萨诸塞州的Iron Mountain开发人员、印度的微软开发团队以及华盛顿州的微软产品经理们。所有经理每30天都会对增量开发的进度进行检查。首先，每个地方的成员都会评审已完成的增量，然后所有人一起进行电话会议讨论当前的进度和问题，最后计划下一次迭代的工作。Scrum的培训使每个人做事都变得更有条理，也制订了参与工作的规则。Paul改善了Iron Mountain的工作环境，使开发人员变得更高产和高效。由协调不力导致的重复性工作被消除了，不必要的重复手工测试也被自动化测试所取代了。Iron Mountain的高层对LiveValut的未来充满了信心，并启动了新一轮的市场计划和销售活动。在接下来的6个月里完成了3次版本发布。
3.2.3 找出你想要做的事
回顾前面提到的位于俄亥俄州的金融组织，那位副总裁将开发团队安置在离自己办公室不远的开放空间内。他和团队分享了自己对这个软件的想法，表示希望借此机会看看经验型软件开发流程是否能够帮助他们快速地开发软件。团队成员之间花了一天时间互相熟悉。然后他们开始讨论这款软件可能会是什么样子，并初步选择了一款用户界面的外观。接下来，他们对软件的安全性、性能、稳定性等需求进行了评估，记录下软件完成时可能会有的功能，以及他们觉得能够在3个月内完成的部分。
团队得出的结论是：如果要知道项目是否可行，就必须在一次迭代（一个月）之内找到以下问题的答案。（1）团队能够使用这种技术开发软件吗？（2）这款软件能够在绕开原有门户网站用户界面的前提下，有效地连接到各个功能上吗？（3）这款软件大体的外观应该是怎样的？
于是，团队确定了要解答这些问题需要完成哪些工作，也就是需要开发哪些功能。他们制订的最低目标是至少能够显示登录界面，并拒绝用户的登录请求。如果可能的话，他们希望登录界面能够正常工作，并对新软件开放门户网站的功能接口。
团队里的5个人从未在同一团队里共事过，也都没有使用过类似的技术，开发过类似的软件。他们各自都有很多想法和意见，交流得越多，越感到在一起工作很困难。而要在一次迭代里完成一个增量给他们带来了更多压力。
关键对话指的是关于某些重要事情，带有强烈感情的讨论。这种对话只有在每个人都感觉安全的情况下才能够进行，也就是说每个人都应该感觉到自己受到尊重，能够尽情地讨论和反对，能够为寻求最佳方法而畅所欲言。试点经理曾经参与过这样的对话。他谈到了尊重和安全感的重要性。他帮助建立了团队密切合作的礼节规则，其中包括不贬低别人的想法，不蔑视别人，以及不称呼别人的外号。如果没有预先制订和后期形成的规则，团队很难在一个开放空间里协同工作。
3.2.4 完整地完成一小部分工作
在确定软件应该是什么样子以后，下一步就是计划如何让团队把设计变成现实。
团队决定每天暂停手上的工作，检查工作进展如何。他们会评估完成的任务和遇到的问题，然后决定第二天要做的最有价值的工作是什么。
随着时间的推移，团队化解一个个难题，软件开始初具规模。开发团队通过智能手机的操作统将应用软件连接到了门户软件，还确定了交互的通信协议，以及如何调用门户的登录功能。副总裁和试点经理提醒他们，软件必须具有良好的安全性和稳定性。于是，团队制订了相关测试对安全性和稳定性进行评估，然后为满足这些需求对软件进行了修改。
顺带提一下，有时候来自IT组织的其他人希望团队成员帮忙做一些别的事情。他们会直接来到团队的工作区内并打断团队的工作。这时候试点经理会挺身而出，让他们离开，到别的地方寻求帮助。
值得注意的是，有时不显眼的几次打扰，都有可能使团队的效率下降50％以上。副总裁知道他要借此机会观察经验型软件开发流程是否可行，他不会让外界的干扰破坏了他和团队的这次机会。
3.2.5 评估你的下一步计划
在第一次迭代结束时，团队已经完成了软件的部分功能。任何人都可以将这款软件下载到智能手机上。运行软件的时候（这时会连接到门户软件上），会看到跟门户软件相同的登录界面。到目前为止，这款软件运行稳定，并且满足了所有需求。由于良好的代码质量，团队能够方便而安全地对软件进行提升。尽管团队成员希望能够在登录界面开发出更多功能，他们仍然为现有的成果感到高兴，副总裁也不例外。
在迭代结束之后，副总裁安排了一次为时4小时的会议，对这次迭代中的工作进行评审。来自共同基金部门的其他同事以及几位IT部门的经理也参加了会议。在他们的帮助下，副总裁和团队评估了经验型流程的可行性。他们对“禁止干扰”的策略进行了讨论，并且确认了其必要性。此外还检视了软件的设计，以及软件连接到门户的工作原理。同时还提出了几项改进的建议。其他的业务经理也对门户的外观提出了一些建议。
会议将要结束的时候，试点经理提醒大家，需要决定是否进行后续的两次迭代。有几个人认为已经得到了足够的信息，可以终止试点项目了。但基金经理不这么认为，他和大多数人都同意继续。他们想知道经验型流程是否还能继续工作，也希望能够进一步开发这款智能手机软件。
会议中有几个非常挑剔的人。他们说开发人员计划使登录界面正常工作，却没有实现，所以对开发人员感到非常失望。这个时候，副总裁提醒他们，这是一个全新的领域。开发团队在不断进行实验和探索，已经在迭代中尽了最大努力，并且学习了新的技能和知识。
接下来讨论的重点转移到了传统或预测型软件开发流程与经验型流程的区别上。在试点经理的支持下，副总裁提出，经验主义的重点在于找出什么是可能的以及什么是可行的。一旦得到了一次迭代的结果，就能对下一次迭代的工作进行规划。他提醒大家，仅完成了第一次迭代，他们就拥有了一个可以工作的软件。除此以外，还获得了这个软件可行性方面的重要证据，以及能够和客户分享的信息。他们已经得到了一个可以不断往其中添砖加瓦的软件架构。如果按照最早提出的预测型流程进行开发，现在只能够得到部分需求的文档而已。
副总裁决定开始向一些客户展示这款软件。他想搞清他们是否真的会使用这款软件，以及它对他们的意义有多大。他还打算在每次迭代中和客户保持沟通，也计划让客户参与下一次评审会议，以便他们能够提出意见。
3.2.6 评估可以改进的方面并付诸行动
试点经理提议团队举行一次回顾会议，讨论这次迭代进行得怎么样。他希望团队成员可以坦诚地表达感受，并提出怎样才能做得更好。以下问题都有可能在迭代中发生，需要进行讨论。
开发的功能太少了。作为一个开发团队，他们总是努力在每次迭代中都完成至少一个业务功能，无论这个功能有多么小。然而，有些时候团队有可能在迭代中只开发出了很少或者是不可用的功能。这有可能是团队需要在迭代中掌握大量新技术、进行架构设计或自动化测试，占用了开发功能的时间。也可能是因为开发人员本身不够出色，无法按时按量完成任务，需要重新接受培训或者被替换掉。
交付的功能与实际需求差距太大。副总裁可能会发现团队并不能理解他想要的东西。他需要和团队更加紧密地工作，才能更好地向团队传达愿景和澄清需求，从而保证对方完全明白他的想法。如果团队对这款软件和基金管理了解甚少，他可能需要花更多的时间和他们交流，或者寻找新的团队成员。
团队成员在迭代中感到不知所措。试点团队的成员可能感觉迭代工作像是在学习一种新的舞蹈。他们需要找到不同的工作方式，既让大家都感觉良好，又能产生更好的结果。
团队成员之间完全无法一起工作。团队成员之间的工作方式需要检视。这个时候也许需要从外部引入一位引导者，帮助他们更好地沟通或者做出更好的决定。有时可能需要重组团队。当然，在这种情况下，之前所获得的经验也就丢失了。
根据讨论的结果，试点经理要求团队成员提出一些建议，即在接下来的迭代中应该如何改变才能提高工作效率。
3.2.7 继续工作和评估直到目标达成
一个试点项目能够带来一样甚至是两样好处。一是可以评估组织的迭代式或增量式开发流程，二是开发出可以使用或有利用价值的软件。
评估的内容并不局限于经验型流程的可行性，因为这不言而喻。关键问题是，经验型流程在你的组织里是否可行。随着一次接一次的迭代，你可以观察到团队工作得如何，其生产效率提高了多少，在一次迭代里可以创造多少价值，还可以了解组织和开发人员对迭代增量式开发的适应程度。你能够了解开发人员的技术水平，其掌握的技术能否在一次迭代内开发出有价值的东西，还可以知道他们能以团队的方式协同工作并创造价值，还是会被这些挑战压垮。
另外，迭代增量式开发还会引起组织内部门间的摩擦。有时候掌握某种技术的人凤毛麟角，其他地方也亟需。有时团队成员在团队之外的工作占用了太多时间，以致无法专注于试点的工作，最后导致整体的生产率下降。
尽管如此，使用迭代式流程开发软件通常还是比使用那些旧的流程快。你会希望解决这些问题，开发出可用的东西。
随着迭代的结束，在组织内实施迭代增量式开发流程所需工作的深度和广度已经在你脑海里形成了一幅蓝图。在瀑布式流程中，上面提到的这些问题并不明显，其对软件开发整体价值的影响被隐藏起来了。而采用了30天的开发周期后，所有在瀑布式流程中不可行的和造成浪费的情况都暴露了出来。这显然是个好消息，但通常意味着组织内部需要协同改进。本书的第二部分将对这方面进行探讨。3.3 这对团队成员来说可能是全新的工作方式
3.3.1 自我组织
在经验型流程里，开发团队的成员需要自己找到将需求转变成可用功能的方法。经理不会直接告诉他们应该怎么做。团队成员之间需要互相协作共同制订工作计划。他们每天进行一次短会重新计划工作，因此可以每天做出调整以优化产出。
有些人觉得自我组织是有风险的，认为如果团队花费在自我组织上的时间太长，就无法专注在实现愿景上。然而，由于迭代的周期只有30天甚至更短，团队通常都能够保持专注。别忘了，即使需要确定团队可以做的事情，其承担的风险也不会超过30天。
在预测型软件开发流程中，计划是由“专家”制订的。项目经理确保每个人都能完成自己负责的任务。人们不需要进行协作和创新，只要完成自己的本职工作就可以了。当工作计划和每个人的任务都由经理一个人敲定的时候，整个团队就会受制于经理自身的智慧、眼界和组织能力等。当遇到问题或者意外情况时，团队成员无权独立思考来解决问题。过去，他们可能曾经因擅自采取行动而受罚，尤其是当行动失败的时候。因此，他们不愿意承担创新所带来的风险。
自我组织的基础是对软件开发人员能力和智慧的信任。既然在日常生活中，他们有足够的能力解决各种复杂的问题，例如驾驶、组建家庭、购物等，那么有理由相信，他们能够在固定时间的迭代内，自觉且尽职尽责地工作。产出就是他们的集体智慧以及协作创造的增量。
下面是另外一个例子。Sylvain Moussad是PTC软件开发的副总
试读结束[说明：试读内容隐藏了图片]