知行合一： 实现价值驱动的敏捷和精益开发.docx

《知行合一： 实现价值驱动的敏捷和精益开发.docx》由会员分享，可在线阅读，更多相关《知行合一： 实现价值驱动的敏捷和精益开发.docx（247页珍藏版）》请在课桌文档上搜索。

1、知行合一：实现价值驱动的敏捷和精益开发1 .第1章从“先知后行”到“知行合一”一从传统开发模式到敏捷开发模式2 .第2章敏捷开发方法一摸着石头过河的智慧3 .第二部分建立以SCrUn）为框架的软件开发管理体系4 .第4章布好自己的局确定SCrUm中的角色、文档和活动5 .第6章把握好敏捷的度一敏捷工程及质量控制实践6 .第三部分CMMl框架下的敏捷实施7 .第7章盲人摸象关于敏捷和CMMl的错误偏见8 .第8章建立敏捷的保护网CMMl架构下的敏捷实施9 .第四部分新一代精益软件工程10 .第9章敏捷不是解决软件开发问题的银弹11 .第10章软件开发的新模式一新一代精益软件工程第1章从“先知后行

2、”到“知行合一”从传统开发模式到敏捷开发模式北大西洋公约组织的科技委员会在1968年10月组织了一次会议，在那次会议上，出现了“软件工程”这个词。50位来自11个国家的软件用户、软件生产者和高校从事软件教学的教授一起讨论了下列一些软件工程中碰到的突出问题。 随着数据系统不断渗透到现代社会日常活动中，如何保证这些系统的可靠性成了一个日益突出的问题。 大的软件项目的进度及特性需求难以控制。 软件工程师的再教育。.软件的定价是否要和硬件分开。除了第4个问题外(今天软件的价格常常已经超过了硬件的价格)，其他3个问题在今天依然是让我们头痛的问题。随着互联网变成公众生活中不可缺少的部分，软件系统的应用比当

3、年多出了百倍，而质量成本依然是软件项目的杀手。软件产品的需求比以往更加难于控制，需求蔓延(requirementcreep)是软件开发中最常见的风险之一QIT行业技术变化之快远超其他行业，学习新的技术、方法是软件工程师常态工作的一部分。根据这些问题，在这次会议上首次提出了“软件危机”的问题。会后不久，WinstonRoyce(1970)博士根据制造业的实践，提出了一个至今依然影响软件业的开发模式一瀑布式软件开发生命周期，希望能够借鉴其他行业的经验，解决软件开发中的问题。但40多年后，危机并没有消失，依然威胁着软件公司的生存发展。近20年来，越来越多的软件工程实践者开始了深层次的反思：问题出在哪

4、里？解决问题的方向又在哪里？在反思的同时，一些有勇气的软件工作者开始了新的探索。他们在软件开发过程中，尝试了新的实践，并不断总结交流，形成了我们今天看到的敏捷宣言、敏捷原则、敏捷实践以及敏捷方法与传统方法结合的实践。今天我们比以往任何时候都更接近找到解决软件危机之匙。我们首先审视下列4个问题。(1)什么是成功的项目？项目中的决策应该由什么来驱动？(2) RoyCe博士提出的瀑布开发模式真的适用于复杂软件产品开发吗？(3)复杂软件项目的特点是什么？(4)根据复杂软件项目特点，我们需要建立一个什么样的开发模式？通过对这4个问题的讨论，希望读者能意识到为什么“先知后行”的传统开发模式会让我们在原地踏

5、步，很难走出软件危机的圈子。走出瀑布模式，拥抱“知行合一”的敏捷方法才可能是解决软件危机的正确思路。在这里我虽然借用了王阳明的核心理念，但要表达的意思远远没有达到王阳明先生表达的深度。在本书中，“先知后行”指的是确定了实现目标要走的路再开始行动，也就是在项目前期，确定产品范围、实施方法后，才开始软件开发活动。“知行合一”指的是明确了愿景后，尽管我们不完全清楚到达目标的路径，但我们先往前走，边走边看边调整，在开发中学习、总结、调整、提高，逐步实现客户需要的产品。1.1 重新审视项目成功的标准在预算范围内，按期向客户提交需求范围要求的产品是长期以来IT企业判定项目成功以否的标准。这个著名的项目管理

6、铁三角（需求范围、成本、进度）直到今天仍定义着大部分软件项目的实施目标。多年来我一直觉得这个铁三角有一个致命问题：它们到底是项目追求的终极目标，还是项目实施的约束条件？项目的价值似乎没有在这3个度量指标中明确体现。我看到很多项目为实现不合理的进度目标辛苦努力，其他很多重要的东西被忽略，特别是没有关注项目要获取的价值，似乎价值这个东西随着进度目标的完成自然就会实现。也有些项目沉迷于具体的需求项，而看不见这些需求项到底给用户带来什么价值。一个令软件业同行不得不面对的事实是超过50%的软件产品功能基本没有被用户使用过，换句话说，对软件项目团队辛辛苦苦实现的一半以上的功能，客户并无兴趣使用，它们没有给

7、用户带来什么价值。这就应了一句老话：每条需求都有成本，但并不是每条需求都有价值。推想一下，又有多少没有完成的项目，因为追求一些没有价值的需求，导致了过多延期和预算超支，使得企业只能放弃它们。1.1.1 传统的三要素不一定能客观度量项目的成功与否图1-1定义了传统项目管理铁三角：需求范围（特性、功能）、成本（资源、预算）和进度（时间）。成功的项目应该依据客户需求（范围）,在不超出预算的前提下，按时提交项目。“传统铁三角”定义的项目成功三要素有两个重要隐含假设。项目定义的需求范围真正反映了客户的真实需要，通过使用这些需求功能，用户可以实现其价值目标。项目计划是正确的，实际和计划不符意味着错误。在这

8、两个假设下，和计划不符的都会被视为问题，项目管理工作就是消灭计划的偏差。让我们认真思考一下上面的假设，它真的总是正确吗？按时完成，没有超出预算提交了需求范围的功能，一定就意味着项目是成功的吗？如果这3个目标没有实现，项目就一定是个失败的项目吗？需求范固图1-1项目管理“传统铁三角”请你回顾一下以前你们公司发布的产品，在这3个目标方面都做得好的产品中，有多少卖得好，为公司带来了价值？有多少用户并不买账，产品并未对扩大市场占有率有任何正面贡献？而在没有按时完成，没有实现所有项目计划阶段定的需求范围，预算有超出的项目中，有没有卖得好、客户喜欢的产品？这其中有没有为公司带来新的机会的项目？我们看几个例

9、子。如果微软的ViSta符合这3个要求，你能认为这是个成功的项目吗？如果你用过这个系统的话，相信你的体验不会很好。另一方面，你很有可能没有机会用过这个系统，因为它的市场寿命很短，WEdoWS7很快就替代了它。多年前，我开始为一家国际知名企业内部IT部门做过程改进的咨询工作。作为诊断工作的一部分，我列席了内部IT部门的年终管理会议。这个由公司Clo主持的会议只有一个议题：如何向董事会展示IT部门一年的贡献。度量内部IT部门的贡献要稍微复杂一些，因为这个部门不挣钱、只花钱。让我吃惊的是，超过30%项目由于完成后无人用，很快就停止维护了。这些项目就算是按时完成、不超出预算又有什么意义呢？我看到完成的

10、项目中包含了不少重复实现的功能，这些功能的成本又该怎么算呢？虽然在这次会议上，他们做了一个看起来还是不错的部门年度贡献列表（其中包括所有项目），ClO不久以后还是不自愿地离开了这家公司。泰坦尼克号是一部国内观众熟悉的电影。也许有些内幕你可能不太清楚，它的预算严重超支（整个电影的制作费用超过2亿美元），进度一再延期，剧情有无数的变化调整。如果按传统三要素来度量的话，这绝对是个非常失败的项目。但面对全球20亿美元左右的票房，导演和演员地位火箭式的蹿升，你能说这是一个失败的电影项目吗？“传统铁三角”的致命问题是前面的两个假设。因为对一个软件项目来说，一开始我们往往不完全清楚用户真正的需求，产品需求的

11、理解有个逐步演化的过程。哪怕在项目结束时，很可能我们还不能完全确定实现用户价值的需求集合，这也是产品需要不断升级的原因之另一方面我们如何看项目初期制订的计划呢？我们能假设它的正确性吗？几乎无一例外，答案是否定的。在做计划时，你要面对很多不确定的东西，如需求范围、实施技术、团队能力、外在制约等。虽然你参考了组织提供的团队效率数据，但考虑到影响效率的各种因素及具体团队的特殊性，估算出的进度计划的准确性是让人质疑的。更让人头疼的是，在开发过程中，很多影响项目进度的因子（如需求、人员、环境等）会发生变化。把符合一个不靠谱的计划作为项目的主要目标之一，恐怕不是一件很明智的事。明确成功项目的标准意义十分重

12、要，它是软件开发方法的纲。借用一句老话，“纲举目张”，这是理解敏捷方法的一个很好的切入点。在本章里，我们一起重新审视项目成功要素，对旧的项目管理铁三角做必要的修正。1.1.2新的项目管理铁三角那么究竟什么应该是衡量项目成功的终极标准呢？我们在前面已经提到了它一价值。JimHighsmith（2011）提出了敏捷铁三角的概念，他提出了3个新目标。 价值目标：开发出可发布的产品。 质量目标：开发出可靠、易更改的产品。 约束目标：在特定的约束条件下实现价值目标和质量目标。我十分认同敏捷铁三角的核心理念，这和我多年在咨询、教学中推荐的原则高度一致。对其略做修改，图1-2显示了新的项目管理铁三角。考虑到

13、不同的软件企业的差异性（例如，并不是每个软件企业都是在开发产品）这里有必要对3个目标做深入说明。价值+傕力图L2新的项目铁三角1 .价值+能力目标将项目的价值最大化是项目管理的主导因素，不同类型的项目追求的价值目标会有差异。其度量指标可能是： 销售额及市场占有率的增加； 公司品牌及竞争力的提升； 客户忠诚度的提升； 技术创新带来的新机会。不同类型的项目会有不同的价值目标，但它们有一个共同点，就是项目价值是站在组织而不是项目的角度来看的。另一方面，在考核项目时不能忽略人的能力的提升。这也应该是一个项目后评价中的重要指标。在项目结束后，软件工程师设计、开发、测试各环节的能力是否得到了提升？需求架构

14、人员是否对产品的价值、合理的架构有了更好的理解？管理人员对团队能力是否更加了解？客户或用户是否对后续产品方向更加清晰？过程人员，如质量保证（qualityassurance,QA)人员，是否对过程的适用及执行难处有了更好的认识？对于许多软件应用服务开发商来讲，人会是企业的最重要财富，人的能力成长对公司的发展至关重要。2质量目标我们不应忽视敏捷对质量管理的贡献，它从实践上强调质量不仅是清除缺陷，不仅是功能正确。它提出了技术债务(technicaldebt)的概念，将其作为后期软件维护隐患的指标，并作为迭代开发的重要质量评估项。敏捷领军人物也提出了许多经过验证的有效实践来管理技术债务，所以敏捷质量

15、目标不仅是可发布(功能正确)，同时也是可维护的！3.约束目标约束目标主要是进度和成本，约束不应该是目标，它是前提。例如，刚性的进度要求，应该理解成在按期交付的前提下，团队将尽可能实现最大的价值。我对新的项目管理铁三角的解读是：在特定约束条件下，控制产品遗留隐患对交付产品的使用及维护的影响，关注人员能力提升，尽可能将项目/产品价值最大化。旧的项目管理铁三角有时会让团队追求错误的目标，如片面追求按时交付，而忽略了是否交付了客户需要的产品。DonaldReinertsen(1997)指出很少有人考虑延期成本，他认为这是个非常重要的度量项，每个组织都应该考虑。在某一特定时间提交产品固然很重要，但提交的

16、产品是可以发布的，也就是说它已经实现的功能特性对客户和用户是有价值的，这一点应该是更重要的。顾名思义，延期成本度量的是产品不能按期提交的代价。如果它小于通过延时实现的功能带来的价值的话，项目延期应该是顺理成章的事。如果延时带来的后果是组织不能承受的，在规定时间发布一个新的版本就是必须要做到的事了。当然在这种情况下，需求范围往往是可调整的变量了。至于将需求范围作为项目的主导目标就更不合适，项目前期用户很难对需求有全面、充分的理解。如果项目开发周期较长，用户的想法在开发期间发生变化也是一件很正常的事情。在美国IT行业有个说法：有生就有死，工作就要交税故软件，需求一定会变。如何衡量项目价值呢？应该看

17、它对自身企业的贡献、对客户的贡献，以及对开发的产品用户的贡献。如何度量价值不是件容易的事，我们可以从这几个方面来考虑：产品的销售额、对品牌及竞争力的影响、对客户忠诚度的影响、通过创新给企业带来的新的机会等。实现价值目标一定意味着你发布了一版为客户解决问题、实现了用户一定需求的软件产品。价值必须是项目管理的主导因素，如果值得，为什么不能延时提交？如果不会增加价值，一分钱也不应该投入。IT业对人的要求比制造业高得多。学校教的东西和业界需要的技能有很大的差距，这个问题估计在相当长时间不可能解决。同时IT技术的生命周期比其他行业更短。持续更新提升软件管理人员、工程人员的能力是每一个IT企业面临的挑战。

18、对一个软件人员来讲，在工作中学习是最主要的能力提升方式。每个项目结束后，相关人员能力的提升也应该是考核一个项目的指标：开发人员的编程能力、工具使用能力是否有提升？设计人员的设计能力是否有提升？管理人员对自身团队的能力是否更清晰？对项目的风险点是否更加清楚？产品经理、客户、用户代表对产品的理解是否更清晰？关注团队能力的提升是每一个管理者的责任，而每一个软件工程师都有学习提高的义务。项目相关人员能力的提升应该是项目评价的因子之一，它也应该是项目价值的考虑因素之一。新的项目管理铁三角的质量目标明确了更高的软件质量要求。仅仅将通过验收测试作为目标的话是不能接受的。质量更应该关注的是项目遗留的技术隐患对

19、客户使用和后期维护的负面影响。如果开发团队为追求速度，走了很多捷径，由此植入的隐患有时是不能通过测试发现的。但随着代码的增长，这些隐患会对产品的使用特别是维护有很大的负面影响。有时借一些技术债是必需的，但这些债是需要及时偿还的，不然它们会严重损害产品的价值。在产品开发过程中有效管理这些技术债务，应该是团队的一个重要责任。技术债务也可以是一个变量，可接受的债务多少和项目的质量目标应该是一致的。需求范围、成本和进度要求可以作为项目约束条件，项目的实施一定是在一个鸟笼子里面进行的，我们需要逐步了解这个笼子的空间、自由度。一般来讲约束条件可以有3个度的度量：刚性、部分灵活、灵活。刚性就是绝对的约束条件

20、，部分灵活意味着有一定的自由度，而灵活则表示更大的自由度。把握了解这个鸟笼子的自用空间是项目管理的一个关键活动。新的项目管理铁三角要求我们用投资回报分析(retunioninvestment,ROI)作为管理者的决策方式。如果追加了投入，回报是什么？回报大于投入吗？如果延时，延期成本是什么？追加时间完成的工作价值大于延期成本吗？追求价值最大化应该是每一个项目的管理目标，也是所有重要决策的依据。在整个开发过程中，管理决策都应该围绕着价值目标的实现来进行。从简单常识来讲，价值驱动不光应该是企业层面和部门层面的决策方式，也应该是项目层面决策方式。所有的管理者应该习惯这种管理思路：不论项目中需要做什么

21、大小决策，都应该做投资回报分析，可是传统开发模式常常不能有效支持价值驱动管理模式。1.13敏捷让我们实现价值驱动管理实现价值驱动管理不是一件容易的事，我们通过下面这个简单的例子来说明其难度。收视率是每部电视剧追求的目标。高收视率对投资人意味着高额广告费，对导演意味着在影视圈中的地位，对演员意味着职业生涯的飞跃。所以电视剧在制作过程中，每个重要的决策都是价值(收视率)驱动的，如剧情、演员的选择、布景等。每个电视剧的预算都不完全一样，这应该是最大的约束条件。如果预算的限制使得导演不能请到他认为合适的演员，而导演认为请到合适的演员是成败的关键因素之一，那么是否追加预算请出导演心仪的演员，制片人必须做

22、个对收视率的影响分析。如果被考虑的演员有几千万的粉丝，请到他就是收视率的保障，只要追加的预算不是很离谱，相信预算会被调高。如果制片人选的演员和导演喜欢的演员对收视率的影响没有明显的差别，而换演员的代价超过数千万，估计预算追加的可能性会很小。在前期规划阶段，剧组会估算出电视剧的大概播出时间。如果在制作后期，剧组发现某些剧情有明显不合理的地方，而如果重拍将导致播出时间的延迟，相信大部分制片人会通过延期成本分析做出决定。如果重拍投入不大，延时几个月不会对收视率有很大的影响，延时重拍就是顺理成章的事。但如果制片人了解到有一个类似题材的电视剧也在拍摄中，很快要杀青。如果电视剧播出时间落在它的后面，收视率

23、就会受很大影响，这时延期成本会大于重拍带来的效益，重拍就不是一个好的选择。什么剧情能打动观众？什么样的演员能塑造出深入人心的角色？在电视剧播放之前，谁也没有完全的把握，谁也无法准确预测能够达到的收视率，这是应用新的项目管理铁三角（价值驱动管理）面临的最大挑战。中国电视剧制作模式就不能有效地支持这种管理模式，一部80集的电视集，要全部拍完开始播放后，才会第一次得到大众的反馈。那时的反馈已经太晚了，因为钱已经都花出去了。2013年年初推出的楚汉传奇是一部80集的电视剧，制作成本接近2.5亿元人民币，号称有史以来最昂贵的电视剧。它的导演演员阵容都是国内一流的，请来了国内最好的男演员（我个人认为陈道明

24、是国内最好的男演员），制作团队也是一流的。但是播出后，收视率大大低于期望，远远没有实现预期的价值。美国电视剧的制作模式就能够有效支持价值驱动管理。一部几百集的电视剧，是一集一集地拍，一集一集地播。他们电视剧的播放是每周在固定时间播放一集，第二天就能看到收视率的数据。如果电视剧播出后，收视率达到或超过预期，那么投资人会继续投资下去。如果收视率没有达到目标，制片人有两个选择：一是分析原因，在拍下一集时做出调整，等下周播放时再看调整是否有效果；二是取消这个电视剧的制作，有时放弃很可能是最好的选择。不做任何变动不是一个可选项。哪怕我们选了个错误题材，损失还是很有限（也就是几集的成本）。国产电视剧模式就

25、类似于以瀑布模式为代表的传统软件开发模式，它要求我们“先知后行”。需要有明确的计划，只有整个电视剧杀青后，才会第一次收集到观众的反馈及收视率的数据。很明显，这种模式是很难支持价值驱动的管理模式的C因为在实际场景下，价值的判断是需要用户的使用反馈的。而美国电视剧模式则是“知行合一”的方式，这也是本书讨论的敏捷开发模式。它能通过不断收集反馈，支持价值驱动管理的开发模式，这个例子也告诉我们知行合一的敏捷模式能够有效支持新的项目管理铁三角的实施。1.2 重新审视瀑布模式为代表的传统开发方法40多年前WinSIOnROyCe（1970）博士提出的瀑布开发模式（ManagingtheDeVelOPment

26、OfLargeSoftwareSystems,19708）对软伴欣爰展起初了一定的好的作用。这个开发生命周期识别出了软件开发需要做的重要活动以及除代码外的中间产出物。它对需求明确、开发技术成熟的项目确实有很好典指导作用。令人遗憾的是，40多年来绝大多数人忽略了ROyCe博士在他的文章里面的一句话“Ibelieveinthisconceptbut,theimplementationdescribedaboveisriskyandinvitesfailure.”这句话的意思是：“虽然我相信提出的概念，但是要注意，具体实施这个开发模式时会有很大的风险，它也可能带来失败。”瀑布模式到底适用于什么样的项

27、目呢？如果下面这些假设是对的话，瀑布模式会是一个非常合适的软件开发方法。（1）客户在项目开始时，可以准确描述他们真正需要的产品需求；而且开发团队在整个开发过程中不需要客户的任何反馈，仅需要客户在项目结束时对实现的功能进行确认。（2）开发团队在项目开始时已经很清楚为完成开发工作所需要的一切：人、技术方法和工具等。（3）项目的进展状况可以通过里程碑完成的文档（而非通过测试的代码）来评估。我们也可以有效地将团队分成4个不同的组：分析、设计、编码和测试。虽然前面组的输出是后面组的输入，但这个接力过程不会有信心的流失。(4)仅在项目结束时对代码进行测试就能保证产品质量。1.2.1 来自制造业的接力式开发

28、模式工业革命带来的流水线生产模式极大提高了生产效率，同时通过对生产制造过程的持续完善改进，产品质量也得到了保证。虽然软件瀑布开发有一条看不见的流水线，但它基本采用了生产线的思路。图1-3是大家熟悉的瀑布式开发生命周期。图13瀑布开发模式很明显这是个接力过程。让我们考虑一个最简单的场景：我们需要在一个已有系统上追加一个功能特性。首先系统分析员会写好一个描述需要实现功能的需求文档，开发人员没有机会和这些功能的使用者有任何沟通，他们将仅仅依赖于这个文档完成代码编写。写好的代码被提交给测试人员，通过测试后，当刚刚实现的功能特性第一次展现给客户时，如果客户的反应是“这不是我要的！，相信你不会太意外吧！那

29、么这是谁的错呢？你可能会抱怨客户一开始没讲清楚，也可能指责分析师没有把需求写清楚，程序员有可能成为替罪羊，测试人员也可能是主要的责任人。如果我们好好反思一下，也许真正的问题出在我们的方法上：在这个接力过程中，每个人只负责一段，没有必要的反馈环，以保证及时发现问题、及时调整。任何阶段出现的问题都会继续被传递下去。同时在接力过程中，信息流失是经常发生的。记得看过一个5人参与的电视节目，第一个人做个动作给第二个人看，然后第二个人努力将看到的做给第三个人看，直到最后一个人做给观众看。往往最后一个人展示的动作已经和第一个人的原始动作相差很大了。正是这些差距让观众哈哈大笑。当这些差异在软件开发过程中出现时

30、，就一点也不好笑了。这些差异正是让客户、管理者、团队头疼的问题。软件产品开发由一系列互不相交的阶段组成，瀑布模式要求上个阶段所有工作完成并通过了出口检查评审后，下个阶段才可以开始。如设计工作应该在明确定义了所有产品需求，这些需求通过了相关评审后才会开始。实际情况是什么呢？如果读者做一下调查，会发现95%的调查对象会承认设计工作在需求活动完成前已经开始了。这应该是业内公开的秘密，所以很少有团队真正在100%执行瀑布模式。制造业的生产过程是高度重复，其过程明确定义了每一个生产步骤。而软件开发中的不确定性，导致了过程重复度是有限的。任何两个项目都不会完全一样，不可能走过同样的开发步骤。这个差异是“明

31、确定义的过程”不适用于复杂软件项目管理的重要原因。1.2.2 瀑布开发模式的不合理之处从项目立项开始到产品发布，什么时候我们对所开发产品了解得最少？答案很清楚：项目的起点是我们对产品需求、所需技术、团队人员能力等关键信息了解最少的时候。瀑布模式要求我们在这个时间制订出并承诺项目目标和计划，包括实现产品范围、功能、性能、进度和成本。那么在信息最少时做计划的最可能的后果是什么？一个字：变。需求会变，人员会变，技术方案会变。可令人沮丧的是，瀑布模式同时会惩罚变更，因为变更的代价往往是团队不能承受的。在瀑布模式下需求变更一定是坏事吗？请你稍微考虑一下再回答这个问题“比较恰当的答案是：视情况而定。那么视

32、什么情况呢？答案是变更的时机。前期变不是坏事，因为变更成本不高，很可能就是改一下需求文档并和相关人员澄清而已。需求变更时机越靠后，变更影响范围越大，变更成本就越高。在验收时客户提出大的需求变更的话，对项目组来说更是灾难性的。接力模式也大大增加了技术变更及人员变更的成本。看一下软件项目管理中著名的七大恶： 不稳定的需求； 不靠谱的计划； 不切实际的项目进度及预算； 项目失控； 项目投入不当； 永远的借口一“我们特殊”； 缺乏对质量的真正关注。如果我们认真做一下根源分析，瀑布开发模式及在对所开发产品了解最少时做出对产品功能、性能、进度、成本的承诺并惩罚变更，是一个重要的原因。1.3 复杂软件项目的

33、共性：需求的不确定及技术的不确定决定项目复杂度的因素很多，其中最重要的是两个不确定性一需求的不确定性以及团队所用开发技术的不确定性。这两个不确定性决定了我们是要“先知后行”还是“知行合一”。项目需求稳定度及开发技术的稳定度都可能会有一个很大的范围：需求可以从非常清晰到极为模糊；技术可能是团队熟练掌握的技术，另一个极端可能是第一次使用的全新技术。图1-4展示了需求和技术的稳定度和项目复杂度的关系。图1-4需求和技术的稳定度和项目复杂度的关系需求和技术都很稳定的项目(图L4中“简单”部分)不会给我们带来什么挑战，传统开发模式可以有效地实现项目目标。可惜大部分软件项目的需求和技术都不那么稳定，属于图

34、L4中的“困难”和“复杂”类。瀑布模式不适用于这类项目，敏捷给出了有效的开发手段。至于混乱的项目，任何方式都不会特别有效。你需要祈祷你有一个极其强大的团队。令人庆幸的是，大部分软件组织碰到这类项目的机会不会很大。1.3.1 客户对自己真正需要的产品需要一个认识的过程产品需求有个进化的过程，这个过程将产品的愿景(vision)逐步细化到产品特性。在这里需要明确两个重要概念：需求的自然进化(requirementevaluation)和需求失控蔓延(requirementcreep)o需求的自然进化是很正常的，重要的是将变更成本控制好。在这个过程中需求提供者(客户、用户等)和产品开发团队需要不断沟

35、通，在追加新需求特性时平衡好约束条件。需求进化意味着产品管理团队和开发团队一起做需求管理，一起加深对产品的理解，一起完善产品。需求失控蔓延往往是由缺乏客户和开发团队的沟通造成的。客户单方面随意追加需求，不做必要的价值分析，不考虑实施成本，是需求失控的主要原因之一。同样，开发团队随意假设用户意图来变更追加需求，有可能是做了吃力不讨好的事。需求蔓延的后果是极大增加了需求变更成本，造成大量的返工和浪费。这里我用一个例子说明需求进化和蔓延的区别。假设团队在开发一个报税软件，在第二个开发迭代中，通过演示，客户发现在准备当年报税时，需要参考去年报税信息，所以需要追加一个能导入去年报税信息的功能。产品经理和

36、团队一起细化这个需求，开发出用户故事，并按其重要性纳入产品需求列表。产品经理调整了版本计划，初步确定在第四个迭代中实现这个功能，并做出了项目交付延期的决策。这是个典型的需求进化的例子，因为通过演示已开发的功能，我们及时识别出了重要的遗漏需求，并给开发必要的时间完成开发工作。如果在这个需求的基础上，产品经理自作主张，扩展了需求范围，将旧的报税信息追加到前5年。他想当然地认为追加的功能会对客户有用，会增加客户满意度。由于没有和客户充分沟通，他没有意识到其实前面数年的报税信息对当年的报税计算帮助非常有限。从另一方面来讲，他也没有和开发团队讨论开发难度及成本。在需求细化的过程中，大家才发现前面5年有3

37、个不同的税表格式，将这些不同的表格串起来，追加了实现难度，导致了进度的延期。在客户验收时，团队才发现这个需求并没让客户开心，需求蔓延是不会有赢家的！不存在完美的产品，因为所有软件产品都是在一个动态的环境中被使用的。从商业角度来讲，这其实是一个好事。不完美意味着机会，它能给我们带来商机。微软的利润很大一部分来自于WindoWS系统的升级，而苹果产品的不足给三星带来了很好的发展契机。客户对产品需求的认知程度不会完全一样，也就是说需求不确定度不会一样。我们可以将这个不确定度分成下面几类。模糊的产品需求：产品愿景清晰，但很多产品特性不清楚。随着开发工作的展开，客户对需求的理解会不断明确。在这个场景下，

38、需求变更更多来自客户对产品需求理解的不断完善。 波动的产品需求：产品愿景清晰，核心特性基本明确，部分特性较模糊。在这个场景下，在开发过程中，需求变更率会比第一类少一半。 常态的产品需求：项目前期通过需求收集分析形成的需求基线基本可以作为后期工作的基础。需求变更率一般少于15%。 稳定的产品需求：产品需求稳定，变更很少，如业界通用的通信协议，一般不会发生变化。既然客户对自己真正需要的产品有个认识的过程，自然我们希望对应的产品开发过程能有效地支持这个认知过程，降低不确定带来的成本。这本书的主要目的之一就是展示敏捷（如SCrUm、极限编程等方法）和精益（如看板、新一代软件精益）就是这样的开发过程。1

39、.3.2 实现每个客户需求都有代价，但不是每个需求都有价值在后面章节中我们还会更深入讨论需求价值的问题。考虑一个你经常用的软件或系统，问自己一个问题：你常用的功能有多少？你偶尔用的功能有多少？你从来没有用过的功能有多少？你很可能会发现大部分的产品功能你从来没有使用过，这个答案是软件业的一大悲哀。统计调查显示近60%的软件产品功能基本不被使用，只有20%的功能经常被用户使用，另外20%左右的功能偶尔被使用。看到这个调查结果，我的第一反应是：原来很多项目的延期、预算的超支是由用户不用的功能导致的，如果能将那些对客户没有价值的需求从产品中踢出，而将客户真正用的功能做得精益求精该有多好。理想的情况是我

40、们认真把20%的功能做好，确保质量；而在开发另外20%用户不太常用的功能时，质量要求也许不一定那么高。美国洛杉矶有家游戏软件公司最近发布了一款现在非常流行的游戏。这个游戏有9级，自然能玩到9级的人非常少。在开发过程中，团队花了大量时间设计、实现9级的功能。测试发现了一些很难修复的缺陷，完全修复需要花大量时间，一定会导致游戏上线时间延期。其中一个开发成员是我的学生，在上我的敏捷项目管理课程。他问我对这个问题的处理有何建议，我出了个简单的点子：如果用户玩到9级后，当游戏出现问题时，让屏幕上出现一个电话号码，告诉用户，打这个电话号码可以领取一件奖品。这样做有两个好处：可以马上发布这个游戏（公司可以赚

41、钱了）；短期内不会有很多人能玩到9级，团队有更多的时间修复缺陷。这样做的性价比最好，如果9级的功能特性真的只有个别人用，那么我们也没有必要花大的代价精雕细琢这些功能。但是如何识别出对用户价值最大的20%的需求往往不是这么容易的，如何判断对用户没有价值的40%的需求同样也不那么简单，以瀑布模式为代表的传统开发模式更是阻碍了这两个判断，因为它要求我们在项目前期，在对产品理解最差的时候识别出产品需求范围。我相信这句话：看到错误的才知道什么是正确的。开发团队和需求提供者不断评审实现的部分功能，完善调整需求，知行合一，不断总结积累是解决这个问题可行的办法。敏捷（如SCrUm）为我们提供了实现这个方法的架

42、构。1.3.3 技术平台的不确定性技术是另一个决定项目复杂度的因素。IT技术平台的不断创新既是机会也是挑战，在开发过程中，团队对新的技术也有个从生到熟的过程。这个过程也会对项目的不确定性有一定的影响。在项目前期我们很难准确估算出所用的技术对项目的影响，也不一定能完全判断出哪个技术方案是比较好的选择。创新和复用也是一个重要的平衡。我们可以把技术平台的不确定性分成下面3个度。 全新技术：团队基本上没有人熟悉这个技术，边做边学是唯一的学习方式。在项目中使用一个全新的技术，极大地增加了项目风险，但创新也为公司带来了机会。 领先技术：少量的团队成员对技术有一定的了解，但很多成员还没有掌握相关技术。在项目

43、中使用领先技术也会增加开发风险。 常用技术：团队使用常用技术开发产品，大部分成员已经掌握了相关技术并且有使用经验。从技术实现角度，项目风险不大。在有一定规模的项目里，团队很可能在开发不同模块时碰到这3类技术。管理好前两类技术使用，是团队缓解技术风险的必要活动。有时候找到正确的技术实现方案，我们也需要摸着石头过河。需求的不确定性加上技术的不确定性很大程度上决定了产品开发的复杂度以及适用的敏捷度。当需求和技术都完全不清楚时，什么开发模式都会有问题。但当需求或技术有一定的不确定性时，敏捷应该是开发模式中的一个重要元素。1.3.4 团队一开始不了解自己的效率人是另一个不可忽略的不稳定因素，团队并不一定

44、了解自己的开发能力。每个人的强项在哪里？内部沟通效率如何？开发瓶颈在哪里？每个人还有多少潜力可以挖掘？相信每一个管理者都希望知道这些问题的答案。一开始团队并不清楚自己的开发效率，每个团队都需要经历一个磨合期。软件开发团队是一个跨职能团队，需要需求、设计、开发、测试等相关人员配合工作，只有经过从开发需求到完成测试，团队才有完整的磨合。一开始，团队生产率不会很高。只有通过几次这样的磨合后，团队内部才会形成自己的默契及节奏，团队生产率会有明显上升，并逐步趋于稳定。生产效率是决定项目工作量及进度的主要因素之一，如果不了解团队的效率，就很难确定产品的发布进度。一个采用瀑布开发模式的软件项目，只有在项目结

45、束时，团队中不同职能小组才会有一次完整的配合经历。如果这个项目采用敏捷迭代开发模式，团队的磨合周期也会大大降低，两周的迭代周期意味着每两周团队会有一个完整的磨合。对一个未经过足够磨合的跨职能软件团队来讲，预测其生产效率不是一件很靠谱的事，以此排出的计划也不会是一个很靠谱的计划。1.3.5 传统方法不能高效解决这些不确定性带来的问题需求的稳定度及技术的成熟度在很大程度上决定了项目的不确定性。对于不确定性高的项目来讲，采用“先知后行”的传统实施策略显然不是高效的办法，大量返工是不可避免的结果。先知后行要求在项目一开始就明确需求，确定实施技术方案。瀑布模式下，用户或其代表第一次看到可演示的软件是在验

46、收测试时。通常在这个时间点，项目已经接近尾声，产品需求调整的代价很高。“百闻不如一见”，看到了屏幕上显示的功能，用户更容易认识到自己真正需要的是什么。让瀑布模式项目团队紧张的一件事，就是验收时客户看到了演示功能后，又提出新的需求变更。当团队决定选用不成熟的技术方案时，他们一定希望在较短的时间内对方案的可行性做个验证。在传统开发模式下，常常只能在系统测试阶段，才能对技术方案进行验证（特别是对产品性能的验证）。如果这时才发现技术方案需要做大的修改，变动影响会非常大，甚至有可能做架构的重新设计。这些变动意味着重新设计，重新编程，重新测试，以及更多的机会植入新的缺陷。瀑布模式也不能有效支持跨职能团队的

47、快速磨合：系统分析员主导需求阶段的工作；设计人员只在设计阶段忙碌；开发人员在实现阶段唱独角戏；测试人员是在代码提交后才开始全面介入。也许大家会一起参加一些例会及技术评审会，但讲话的基本是当前阶段忙碌的小组。虽然几十年来瀑布模式一直是软件开发的主导方法，但其致命弊端从它被提出时就已经被指出。ROyCe博士本人就指出瀑布模式仅适用于简单的项目，迭代模式更适用于开发复杂项目。到了20世纪80年代末，BarryBoehm(1988)提出了螺旋开发生命周期。同一时期，其他迭代开发模式(如演化模型、快速原型法等)也不断被提出，给了软件开发团队更多选择。随后各类敏捷方法(如本书重点讨论的SCrUm、极限编程

48、等)从20世纪90年代的星星之火，逐步形成燎原之势。到今天，敏捷方法得到了业界广泛的接受，已经成了最主要的开发模式。虽然中国敏捷的推广比美国滞后10年，但让我们欣喜的是，越来越多的软件团队和企业开始了他们的敏捷之旅。1.4从“先知后行”到“知行合一”瀑布模式在很多复杂项目上的失败是诱发敏捷运动的最主要原因。任何一个新方法的提出一定是为了解决旧方法中的缺陷，敏捷弥补了以瀑布模式为代表的传统开发的不足。从另外一个角度来讲，敏捷又是我们习惯的做事、学习方式。还记得小学二年级老师如何教你写作文的吗？他会帮你先写个提纲，然后你写出第一稿，他会告诉你哪些地方写得好，哪些地方写得不好，然后你再写出第二稿，重复这个过程，直到老师满意为止。我们从小就知道，想把任何一件事做好做精，就需要不断重复实践，不断完善。和瀑布模式不一样，敏捷模式是人类的自然做事方式。1.4.1 知行合一是自然的结论当你开始开发一个需求模糊或技术不成熟的产品时，知行合一的模式是自然的选择。敏捷方W中有4个核心元素。 迭代开发：在每次迭代中，团队开发出部分产品功能，并通过功能演示对产品进行评审，并做必要的调整。 特性驱动：在敏捷过程中，大的产品需求特性被分解成多个