敏捷交付下的项目管理模式研究——以华为公司为例.pdf

．‘；、＂，巧：＇’／鮮警＇运萨Ｐ皆／Ｆ灌％冷；＂．．謹為義離靴１巧密ｒ的減５扭懲ｉ，＾職，聲．１＇－．‘．：式ｖ；＇Ｊ＼．／，；．：．篇＼：．、圭巧於‘苗讀？＾著换＼．；Ｖ－：Ｓ脅Ｊ歌一．、琴．．聲是．’’；护受Ｓ．ｔ？Ｍ－＾女铭．宗考營僅．、：＼、驾＇共一．．－＇／；．．‘為一葺．：；這：：．．‘‘＇Ｉ皆吞苗ｒ觀打单曼．扛槪吊－扣．与，乂ｖ：．．．＾宝Ｖ扭名‘，－、．Ｖ‘、Ｘ．＾＞．１．，．’＂Ｊ；＾；；、《梦终、＇＾公－．鎮．畜．户＾令！．．．態＇Ｈ户；Ｖ４Ｘ‘餐；．论Ｓ：每玄ｍ管齡研苗平－ｉ’．定Ｗ戦，＇Ｍ．ｔｘ．＇．－＇＇；．，．’＾＇＇．．參＾；ｒ．＃、ｖ梦号。Ｗ．卢接；＇、名占／‘：ｗ平ｒ师二／ｖ＞．，．沒ｖ业位类類ｌ離＾ｖ＼’；．，，毅ｃ；．＇Ｐ．：Ａ型輿；巧职／＼：＇心＇；．．满业领域ｋ强■号３文交期ｎ日ｑＢ皆一＼－＼ｉ－Ｖ於Ｔ．＂＂舞卿肖Ｃ与Ｖ編扛：：．．：、；．，§．；．．＾ｖ．’＂：扔＇．；＾卓海嚇攸－Ｌ辦心， TheResearchofProjectManagementModeinAgileDeliveryTakeHuaweiCompanyasanExampleThesisSubmittedtoNanjingUniversityofPostsandTelecommunicationsfortheDegreeofMasterofEngineeringByZhaoSenSupervisor:Prof.ZhangShuangJune2015 摘要当前通信行业竞争激烈，运营商需要快速部署所需业务满足市场需求，传统的软件交付模式已经无法满足运营商的需求，所以敏捷交付应运而生。目前国内对敏捷交付模式的研究较少，尤其是缺少对于敏捷交付过程关键步骤的研究，和项目规范性的评价标准。敏捷交付在国内大部分企业还只停留在理论依据方面，在实际交付中很少应用。本研究的具体目标包括：针对敏捷交付的各种优势进行研究与分析，提炼出敏捷交付的关键流程和关键步骤，并建立敏捷项目交付模型，实现敏捷交付从理论到实践的转变。能够指导软件项目敏捷交付，使得项目团队能够了解项目进度情况，了解项目质量情况，并根据敏捷项目交付模型对项目交付情况有一个实际的评价，让更多的人了解到敏捷交付的实际价值与应用前景，从而被吸引并参与到敏捷交付中来。本文以华为公司的敏捷交付模式为研究对象，通过对敏捷交付中具体措施的研究和分析，建立敏捷项目交付模型，并在实际项目中加以应用，以约束软件的开发过程，减少敏捷转型带来的混乱，减轻敏捷转型的阵痛，也可以减少企业转型的成本。关键词:敏捷交付，项目管理，关键步骤，交付模型I AbstractWiththehighlycompetitivetelecommunicationsindustryincurrentdays,operatorsneedtoquicklydeploybusinesstomeetthedemandsofmarket.TherehasbeenanewdeliverymodenamedAgileDeliverywhichthetraditionalsoftwaredeliverymodelhasbeenunabletosatisfyoperators’demand.However,it’snotverycommonfortheresearchonagiledeliverymode,especiallylackofresearchonthecrucialstepintheprogressofagiledeliveryandNormativeprojectevaluationcriteria.Therefore,agiledeliveryhasrarelybeenusedinrealitydeliveryinthedomesticwhichisjuststayinthetheoreticalside.Thistopicmainlydescribestheresearchandanalysisonavarietyofadvantagesofagiledelivery,andthenextractingthekeyprocessesandstepsoftheagiledelivery.Simultaneouslyestablishingagiledeliverymodeltotransfertheagiledeliveryfromtheorytopractice.Bytheresearch,it’sabletoguidethesoftwareprojectofagiledeliverytomaketheprojectteamtocomprehendtheprogressandqualityoftheproject.Atthesametime,basedonthemodelofagiledeliverywhichcangiveanactualevaluationonthecircumstancesoftheprojectdeliverymakesmorepeoplerealizedthatagiledeliveryhasabrightpracticalvalueandapplicationprospect.Andthenbeamemberoftheagiledeliveryactivity.ThispaperisbasedontheresearchofHuaweicompany’sagiledelivery.Whichisabletoestablishthemodeofagiledeliverytoconstrainsoftwaredevelopmentprocess,reducetheconfusionandalleviatethepainarisingfromtheagiledeliveryrestructuring,andalsotoreducethecostofenterprisetransformation.Keywords:AgileDelivery,keyprocesses,stepsoftheagiledeliveryII 目录第一章绪论.............................................................................................................................................................11.1研究背景....................................................................................................................................................11.2研究目的....................................................................................................................................................21.3研究意义....................................................................................................................................................21.4研究内容....................................................................................................................................................31.5研究方法....................................................................................................................................................4第二章敏捷交付和项目管理理论综述.................................................................................................................52.1敏捷交付概要............................................................................................................................................52.1.1敏捷的起源.....................................................................................................................................52.1.2敏捷的概念和原则.........................................................................................................................82.1.3敏捷交付的特点和价值.................................................................................................................92.2项目管理..................................................................................................................................................102.2.1项目概念和项目的基本特征.......................................................................................................102.2.2项目管理和项目管理的特点.......................................................................................................102.3软件交付项目管理现状分析..................................................................................................................112.3.1软件交付项目管理面临的挑战...................................................................................................112.3.2敏捷交付和项目管理方法...........................................................................................................12第三章敏捷交付的现状与特性分析...................................................................................................................133.1传统的软件交付模式..............................................................................................................................133.2敏捷交付模式及方法..............................................................................................................................153.2.1迭代...............................................................................................................................................173.2.2Story（用户故事）........................................................................................................................183.2.3站立会议.......................................................................................................................................193.2.4结对编程.......................................................................................................................................193.2.5持续集成.......................................................................................................................................193.2.6重构...............................................................................................................................................213.2.7测试驱动开发...............................................................................................................................223.3敏捷交付的SWOT分析.........................................................................................................................223.3.1敏捷交付的优势...........................................................................................................................233.3.2敏捷交付的劣势...........................................................................................................................243.3.3敏捷交付的机会...........................................................................................................................253.3.4敏捷交付的威胁...........................................................................................................................273.3.5完善敏捷交付的建议与对策.......................................................................................................283.3.5.1抓住机会，消除威胁的对策分析...........................................................................................293.3.5.2发挥优势，避免劣势的对策分析...........................................................................................293.4敏捷项目交付模型..................................................................................................................................30第四章敏捷交付在华为公司项目管理中的应用研究........................................................................................334.1项目简介..................................................................................................................................................334.2项目时间管理..........................................................................................................................................344.3项目成本管理..........................................................................................................................................374.3.1项目成本估算...............................................................................................................................374.3.2项目成本控制的手段.................................................................................................................384.4质量管理..................................................................................................................................................414.5项目风险管理..........................................................................................................................................42III 4.6项目人力资源管理..................................................................................................................................434.6.1项目组织结构...............................................................................................................................444.6.2绩效考评和激励方案...................................................................................................................46第五章结论与展望...............................................................................................................................................495.1研究结论..................................................................................................................................................495.2研究不足与展望......................................................................................................................................54参考文献.................................................................................................................................................................55致谢.........................................................................................................................................................................56IV 南京邮电大学专业学位硕士研究生学位论文第一章绪论第一章绪论1.1研究背景软件同硬件产品一样，软件也可以归为产品的一种，不依赖于硬件即可在市场上独立出售。硬件产品的开发过程已高度规范化：首先是完成硬件产品的总体方案设计、详细的图纸设计和工艺设计，然后是产品的生产，产品经质量检验合格后就可以销售出去。软件开发也像硬件一样，在软件分析、设计完成之后，编制程序代码，最终形成软件产品。但是软件的开发有其自己的特点。软件是人们通过智力活动，将自己掌握的知识技术转化为可用的信息的一种新型产品。与硬件相比，软件的开发对开发者的业务素质和能力依赖程度更高，对人员的组织、合作和管理也有更高的要求。软件开发存在的问题主要体现在以下几个方面：1、软件生产的自动化程度不高，需要程序员个人创造与手工编程，生产周期不易控制。2、软件生产成本不易控制，软件开发是一种脑力劳动，所需的开发、测试和维护的工作量不易控制。3、软件的质量难以保证。软件不同于硬件，它看不见摸不着，是计算机系统中一些的代码逻辑的集合，是一种逻辑产品，不可预见。如果软件中存在的某些逻辑错误，必须等到对应的程序执行时才有可能被发现，因此软件中的错误很难发现，维护复杂。电信行业的软件除了对成本和质量的要求外，对客户需求的快速响应也倍受关注。当前移动互联网时代已经到来，运营商在从传统话音业务向电信增值业务转型，而市场需求各异且多变，为了满足市场的这些需求，提升客户满意度，从而提升市场份额，运营商需要快速推出符合市场需求的增值业务，而在传统软件开发模式下，软件的开发周期长，且不支持需求的变化，不利于运营商的快速转型。所以华为公司引入了敏捷交付的方式，并在全公司得到推广。敏捷交付在深入了解客户需求的基础上，采用迭代交付的方式，将客户的需求按重要性分成多个迭代，客户的重要需求不必再等漫长的版本火车，也有助于客户的重点业务快速上线，提高客户竞争力。从项目管理的角度来看，这也是一种理想的方法，使得项目经理以及项目团队得以更好地掌好项目的舵，通过不断的沟通修正，带领项目驶向并不精确的需求。同时在版本开发过程中通过自动化工具持续集成，发现问题及时修复，保证了版本的质量，也可以避免后期返工。由此可见，敏捷交付是应对现代软件交付特性的最好方法，研究敏捷1 南京邮电大学专业学位硕士研究生学位论文第一章绪论交付的方法也就把住了软件交付成功的脉搏。1.2研究目的敏捷交付提高了生产率，缩短了项目交付的时间，提高了项目质量，降低了项目成本，并且由于将项目分成多个迭代交付，每个迭代的交付时间都比较短，客户如果发现实现的需求不如预期可以灵活变化，从而提升了客户满意度。目前国内对敏捷交付的应用和研究较少，很多软件项目还停留在传统瀑布式开发模式上，有的企业想推行敏捷交付，但苦于没有实践指导，也没有一些交付的关键步骤来规范交付过程，这也给敏捷交付的推行带来的阻碍。瀑布式开发的特点是在前期需求调研阶段就把所有需求分析澄清，并通过合同和客户确认，再冻结需求。软件设计完成之后就进行构建，因此在项目的开始阶段，瀑布式开发就能够估算出真实的工作量和成本，对于项目的报价和风险评估具有很高的参考价值。但一般情况瀑布式开发不适合在软件交付的过程中做出大幅度的需求变更，并且修改的代价很高，交付周期也会变得很长。而客户高层虽然了解实际需求所要实现的功能，但并不熟悉具体流程和操作等细节；客户基层人员虽然熟悉所负责的具体模块的流程和操作等细节，但又对全局信息缺乏了解。许多需求是在基础版本演示、使用、甚至业务上线后实际使用过程中才逐步挖掘和确定的，所以在项目开始阶段就想把项目需求完全理清楚根本是不可能的，这需要和客户反复沟通和澄清。而且在传统的瀑布式开发过程中，客户可能要到两三个月后项目最终交付时才能见到软件的“庐山真面目”，而最终交付的系统可能和客户的要求存在较大差距，甚至可能完全不是客户想要的，这对于整个项目组甚至公司都是灾难性的后果，所以传统的瀑布式开发方法限制了客户满意度的提升。而敏捷交付的方法由于在国内起步较晚，鲜有应用案例和方法指导，这也让不少本有心采用的企业由于缺少指导而无奈放弃。在当前通信行业竞争激烈，运营商需要快速部署所需业务满足市场需求的背景下，本研究旨在运用科学的分析方法，探索华为公司敏捷交付下的项目管理模式，为软件企业全面标准化推广敏捷交付提供理论依据，提升软件企业的市场竞争力，实现和运营商的双赢。1.3研究意义敏捷交付已经从最初的概念走向实践，敏捷交付方法也经过不断的迭代在人们的实践中走向普及。但在国内，敏捷交付方式依然只在一些小型项目上才有应用，在大型项目中应用敏捷一直被谈论，却一直被搁置。目前国内对敏捷交付模式的研究较少，尤其是缺少对于敏捷交付过程关键步骤的研究，2 南京邮电大学专业学位硕士研究生学位论文第一章绪论和项目规范性的评价标准。敏捷交付在国内大部分企业还只停留在理论依据方面，在实际交付中很少应用。研究敏捷交付具有以下意义：1、有利于规范敏捷交付的过程，提高敏捷交付的质量。通过对敏捷交付的各种优势进行研究与分析，提炼出敏捷交付的关键流程和关键步骤，并建立敏捷项目交付模型，实现敏捷交付从理论到实践的转变。指导软件项目敏捷交付，使得项目团队能够了解项目进度情况，了解项目质量情况，并根据敏捷项目交付模型对项目交付情况有一个实际的评价，从而提高敏捷交付的质量。2、有利于帮助企业转型，减少转型成本。改变项目交付方式由于推行新技术往往会在推行初期让公司的某些部门限入混乱，敏捷转型也不例外一样会有阵痛期，所以在推行初期通常会遇到很大的阻力。本研究也是为了指导软件交付的转型，通过关键步骤的建立，约束软件的交付过程，减少敏捷转型带来的混乱，可以减少企业转型的成本，从而降低敏捷转型的门槛，吸引更多企业加入敏捷交付的行列。3、有利于电信软件行业交付理念的改变。传统的软件交付模式持续周期长，且不适应市场的快速变化。而电信行业市场变化快，需要软件厂商帮助运营商找到市场突破口，快速推出产品抢占市场。这就要求电信软件行业改变原有的交付理念，更多地运用敏捷交付方法。通过本研究，可以让更多的人了解到敏捷交付的实际价值与应用前景，从而被吸引并参与到敏捷交付中来。1.4研究内容论文内容共分为五章：第一章绪论。主要包括论文的研究背景、意义、目的、内容和方法。第二章敏捷交付和项目管理理论综述。对敏捷交付理论、项目管理理论、以及现有国内外学者相关研究成果进行文献综述。第三章敏捷交付的现状与特性分析。基于传统软件交付的模式，结合运营商当前发展和转型的状况，分析敏捷交付的基本特性，并运用SWOT分析方法，与传统交付方式进行对比，分析敏捷交付发展的优势、劣势、机会和威胁，据此制定敏捷交付未来发展的可选择对策和行动计划。第四章敏捷交付在华为公司项目管理中的应用研究。包括项目中采用的具体方法、运行过程实施效果等应用，以及项目管理方法的应用（时间管理；成本管理；质量管理；风险管理；人力资源管理等）。3 南京邮电大学专业学位硕士研究生学位论文第一章绪论第五章结论与展望。总结本次研究的结论、观点和不足之处，并对未来研究方向提出展望。1.5研究方法本文以华为敏捷项目的管理模式为研究对象，通过对时间管理、成本管理、质量管理、风险管理、沟通管理、敏组织管理、人力资源管理的研究，探讨各个方案所具有的独特管理模式以及成功因素，总结敏捷项目交付的关键步骤，指引企业根据项目实际情况选用适用方法交付敏捷项目。具体的研究方法有：1、文献分析法：在第二章中通过对相关文献进行检索、浏览，归纳和综合有价值的资讯。文献的主要来源有：图书、中国学术期刊网、万方数据库、华为官方网站等。2、案例研究法：笔者根据自身在华为的实际工作经历，在第五章中对敏捷交付的方法和过程进行深入分析和总结。3、对比分析法：在第三章中通过敏捷交付与其他传统软件交付方法横向对比分析，以及在第四章中对华为敏捷交付方法的纵向对比分析，客观科学地分析了敏捷交付的价值和意义。4 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述第二章敏捷交付和项目管理理论综述2.1敏捷交付概要2.1.1敏捷的起源虽然传统的软件开发方法如瀑布式开发等方法曾经帮助软件开发团队度过了历史上的“软件危机”，但是到了20世纪后期，新的危机又摆在了软件开发团队面前，即如何能够快速高效地工作以及如何能够应对快速的需求变化等问题。为了解决这些问题，2001年17位业界专家在犹他州瓦萨奇山脉的一个滑雪胜地举行了一个为期3天的会议，研讨软件过程未来发展趋势，并就敏捷的定义达成了一致意见。随后成立的敏捷联盟以及发布的敏捷宣言标志着敏捷交付方法的正式诞生。这份敏捷宣言是敏捷交付方法的价值和目标的浓缩定义：1、个体和交互胜过过程和工具；项目成功的最重要的因素是人，如果一个团队中缺少优秀的人员，即时交付过程和工具再如何先进也避免不了失败的结局。但是如果不能将项目组成员凝聚成一个团队开展工作，那么即使个人再优秀项目也还是会失败，所以在敏捷项目中团队的构建远远重要于环境的构建，应先构建团队，再根据让团队的实际需要构建环境。2、可以工作的软件胜过面面俱到的文档；团队需要文档来传递软件的设计思想和实现逻辑，没有文档的软件不管是在编码阶段还是维护阶段都是一场噩梦，团队成员不可能通过阅读代码来了解软件的实现方法。但是过多的文档又会导致另一种极端。编写大量的文档需要花费大量时间，而后期如果要修改这些文档又要花费更多时间。软件交付过程中肯定会涉及到软件的修改，这个时候如果文档过多会导致文档改错或者改漏，这种情况下文档和代码之间就不会同步，那文档将会严重误导团队成员，成为敏捷交付的阻碍。所以敏捷团队强调在代码中插入注释，解释该段代码的含义，这样可以记录代码的关键信息和设计思路，也利于后期的维护和同步。3、客户合作胜过合同谈判；在交付之前希望通过合同约定交付范围，然后由交付团队安静独立地完成软件的开发，这是一种理想且不切实际的模式，这种模式会导致实际实现与客户需求的偏离和项目的失败。项目的成功依赖于客户的紧密配合和频繁的反馈。电信软件业市场需求多变，这也导致项目的需求经常会发生变化。项目能否成功的关键在于是否能和客户紧密合作，帮助客户适应市5 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述场的变化，优先实现高价值的功能，而不是通过合同规定项目的交付范围和细节以及具体的工期。4、响应变化胜过遵循计划；软件项目的成败往往取决于我们响应变化的能力。在我们制定计划时，应该充分考虑到计划的灵活性，以及是否易于适应商务和技术层面的变化。5、虽然右项也有价值，但是我们认为左项具有更大的价值。敏捷宣言的提出掀起了全世界范围的敏捷交付热潮，敏捷交付的核心就是将一个任务分成多个迭代，在每个迭代都落实一部分客户需求，并交付可运行的软件，通过一次次的交付演示以及和客户的沟通澄清，逐渐摸清客户的实际需求。敏捷宣言的背后包含了12条准则：1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。通过敏捷交付的实践证明，尽早交付具有部分功能的系统能明显提升最终系统的质量；首次交付的系统中所包含的功能越少，最终交付的系统质量就越高。敏捷交付要求尽早、频繁地交付，在最短的时间内提交给客户一个具有基本功能的系统，然后坚持每隔几周就交付一个功能逐渐增加的系统，通过价值优先级排序的方法，优先为客户提供对于客户来说最有价值的功能。通过频繁的迭代与客户形成互动与合作，及时反馈客户意见，通过不断的修正提高产品质量。2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。敏捷团队在交付过程中不怕需求变化，我们认为改变需求对客户和我们都是一件好事情，因为需求的变化意味着我们更了解最终用户市场的需求。敏捷团队在项目交付过程中需要时刻保持软件结构的灵活性，这样当客户需求发生变化时，可以以较小的代价完成软件的修改。3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。敏捷交付的最终目的是为了响应客户需求变更，提升客户满意度，交付周期越短，客户需求变更的机会就会越多，这样最终交付的产品就会更贴合客户的实际需求，客户就会越满意。敏捷交付过程中更注重交付满足客户需求的软件，不用花大量的时间整理交付大批量的客户文档。只要我们交付的软件可以很好地运行且贴合客户需求，那么交付时间越短，客户就越愿意和我们一块参与软件的改进，产品质量也就会越高。4、项目过程中，业务人员与开发人员必须在一起工作。软件项目由于需求复杂且多变，各环节牵涉的角色众多，如果通过一层层的需求讲解，大家对客户需求的理解、软件的实现方案的理解肯定会有较大的差异，所以项目交付过程中6 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述的各角色需要在一起办公，及时交流和互动，这样在软件开发的初期就能及时发现问题并解决。5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。业务复杂度和技术储备是软件交付的两个重要难点，人员的管理是第三个重要因素。而业务和技术又是由人来创造和实施的，所以人员的激励是解决这三个重要难题的关键。而激励人员，就必须要以人为中心，为项目组成员提供项目所需的必要环境和外部因素，通过物质和精神激励，让团队成员充满干劲。6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。电信软件业目前多采用解决方案的形式交付，一个解决方案包含了多个部件，团队总人数大多在50人以上，如果还采用文档邮件等方式交流，沟通效率低而且容易出现需求传递的误解。所以敏捷交付提倡将项目团队集中办公，方面面对面的交流。7、可工作的软件是衡量进度的主要指标。一般的工作都比较容易衡量任务进展，比如盖一栋大楼，只需要数数盖到多少层就知道已完成了多少任务。但是对于软件来说，在软件没有实际交付之前，都不能通过代码的编写行数或者测试用例的执行数量来判断功能是否实现，判断功能是否实现的唯一依据是包含该功能的代码是否可以正常运行，该功能是否符合客户的真实需要。8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。敏捷交付过程中希望项目组成员能够可持续的进行开发，保持恒定的开发速度，而不是随着迭代的进行而变化。敏捷项目分成了多个迭代，每个迭代之间没有休息的时间，而是一个迭代接一个，持续加班只会让项目组成员感到疲劳，人在疲劳状态下开发的代码质量会大幅下降，后期为了修改这些代码中的错误反而要投入更多的人力，得不偿失。所以在交付过程中我们不希望成员为了赶进度而长期加班，我们更追求恒定的开发效率。9、不断地关注优秀的技能和好的设计会增强敏捷能力。敏捷交付中欢迎引入新技术，新技术能提高敏捷交付的效率和能力，所以在交付项目的同时，也需要关注业界的优秀实践和成果，不断吸收和总结，增强敏捷能力。10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。尽量采用简单的系统架构，在确保软件功能的前提下，尽量简化软件结构，一方面易于编码，另一方面也可以方便后期的修改。敏捷交付不要求在一开始就做出一个大而全的版本，涵盖所有的功能，而是将软件分成多个迭代，每个迭代只关注当前迭代的功能。敏捷团队不会去构建明天的软件，而是先通过最简单的方法完成当天的任务，7 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述11、最佳的架构、需求和设计出自于自组织的团队。敏捷团队是自组织的团队，团队成员分工合作，共同解决项目中出现的问题，所有成员均对项目的整体交付成败负责，而不存在各扫门前雪的问题，胜则举杯相庆，败则拼死相救是对敏捷团队的最好注释。12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。很多不确定性因素都会导致项目计划的变更，比如项目组成员的变更、新技术的运用、客户需求的变化等都需要敏捷团队针对不同情况作出不同的反应。敏捷交付是基于已有经验的交付方式，而不是有一套固定的交付方法。由于经验总是不断总结固化，不断推陈出新，所以项目组需要通过不断的总结和学习来保持团队的敏捷性。2.1.2敏捷的概念和原则DaveThomas（2013）总结了敏捷的十二条原则，敏捷思想就是符合这十二条原则的一些[1]软件开发思想的汇总，而敏捷交付方法就是符合敏捷思想的软件开发方法。DaveThomas（2013）将敏捷交付方法诠释为迭代的，快速应对需求变化的，轻量级的，并且简洁的软件[1]开发方法。KentBeck（2010）提出：“敏捷并不只是一个产品。敏捷的产生，是因为当初我们犯了错误，希望节省以后学习者和实践者的时间。但是，学习敏捷不能模仿，不能复制，[2]更不能抄袭。敏捷只是一种思想，它需要的是行动者。”所以敏捷交付方法并不是指某一种或某一类具体的软件交付方法，而是一种抽象的概念，它是指拥有一致的敏捷原则，能够快速响应客户需求的变化，并能够在短时间内交付高质量、可运行的软件产品的一类软件开发方法的集合，如XP和Scrum等。DaveThomas（2013）认为个体和交互胜过过程和工具，可工作的软件胜过面面俱到的文档，客户合作胜过合同谈判，响应变化胜过遵循计划。从中我们可以总结归纳出敏捷交付方法的三个核心理念：第一，敏捷方法不是固定的，它能不断完善变化。敏捷方法总是能不断适应客户提出的各种需求和变化，在需求的变化中总结完善，并不断发展壮大，所以敏捷方法是支持变化的。第二，敏捷方法注重的是人，而不是软件的过程。传统软件的交付方法会采用严格的过程控制和管理，压抑了人的个性，而敏捷方法强调以人为本，尊重和鼓励人发挥自己的特长，充分发挥了人员的主观能动性。第三，敏捷方法是基于迭代的。敏捷方法在每个迭代周期都能交付可运行的包含了部分客户需求的软件，每个迭代版本都经过了充分的迭代测试，最终交付给客户的软件符合公司的质量要求。8 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述2.1.3敏捷交付的特点和价值敏捷交付方法有两个区别于传统交付方法的显著特点，即迭代和客户的持续反馈。迭代是敏捷交付的基础，一个迭代周期包含了软件开发的全部流程，每个迭代都能交付可运行且包含一部分客户要求的功能的软件。通过多个迭代的开发，产品的功能和性能逐步增强，并不断接近客户的预期。敏捷团队成员之间互相协作，高度配合，保证了不同迭代周期内软件开发过程的稳定和持续，也帮助解决了软件开发过程中各环节之间的依赖性问题。比如在软件测试中，如果采用传统软件开发模式，如果软件不满足转测入口条件，测试人员会一直等待直到软件满足条件，这极大地浪费了时间。在敏捷项目中，测试人员在每个迭代都要求按项目计划投入到项目中，投入后即可快速开始工作。敏捷项目中不允许等待，等待表示项目管理效率的低下和迭代任务执行失败。在敏捷交付过程中需要客户持续不断的反馈，我们需要客户参与到产品的需求澄清中，甚至在开发过程中，我们也希望客户可以参与方案和技术点的研讨，这贯穿了软件开发的全过程。这样能帮助敏捷团队紧密把握客户的实际需求，交付的软件符合客户的预期，降低后期修改的风险和时间，也能极大地提高客户满意度。敏捷交付的方法自从出现以来，经过不断的发展、完善，现在已经成为软件交付的主流方法，并且在西方国家也总结了很多经典案例，供后人学习。随着历史车轮的前进，传统的瀑布式开发方法由于不符合市场需求必然会逐步退出历史的舞台。敏捷交付方法由于是为了应对软件交付新局面所开创的新的应用技术，更适合现代企业，也必将随着更多人的应用产生更多的实践和成功的案例，成功案例的增多也会吸引更多的企业投入到敏捷交付中来，这是因为敏捷交付的方法能为企业和个人带来更多的利益。同传统软件交付方法相比，敏捷交付的方法能为软件交付团队带来更多的价值，这是因为敏捷交付比传统软件交付方法风险更低，也更贴合客户的真实需求。传统软件开发方法缺少与客户的互动，在调研阶段结束后，软件团队的开发过程非常封闭，不去谋求和客户的互动，这可能会导致做出来的软件并不符合客户的要求。而且现在的市场需求变化万千，传统软件交付方法交付周期很长，等软件做出来可能已经不符合市场的预期，结果必然导致项目的失败，团队的努力也白费了。为了规避以上两点风险，越来越多的企业放弃了传统软件交付方式，而改用敏捷交付方式，他们意识到敏捷交付方法比传统软件交付方法能够为企业带来更高的利润和更低的风险。同时由于客户的也参与到软件交付的全过程中，和敏捷团队频繁互动，软件开发过程中遇到的问题可以快速解决。因此，敏捷交付的透明度比传统软件开发方法更大，也使得敏捷交付团队和其交付的软件产品具有很强的生命力和适应能力。因此9 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述只有能够快速响应客户需求变化的敏捷交付方法才能够帮助企业和客户快速占有市场，降低风险。2.2项目管理2.2.1项目概念和项目的基本特征不同的研究角度，不同的行业对于项目的定义不尽相同。美国项目管理协会将项目的概念定义为项目是为提供某种独特的服务、产品或成果所做出的临时性努力。企业内的工作一般可以分为两种：一种是企业的日常运作，另一种就是项目。企业的日常运作是连续且重复的，而项目则具有一次性和独特性。相对于企业日常运作，项目具有如下基本特征：1、唯一性特征。每个项目都是独一无二的，没有两个完全一样的项目，项目具有排它性，即每个项目都提供特定的服务、产品或成果。2、一次性特征。项目的开始时间和结束时间都是明确的。一次性并不代表项目的总时长短，但项目不会无穷无尽地进行，其总时长是有限的。项目的目标与企业日常运作的目标有着根本的区别。项目的目标是要达到已经被明确规定的业务目标，从而结束该项目。而企业日常运作会持续运行并且也是为了持续保持这一业务目标恒定。3、整体性特征。项目是由一系列互相关联的任务构成的一个整体。在按项目需要分配生产要素时，必须追求尽可能高的效益，从而达到投入产出的总体优化。4、逐步细化。项目处于持续不断的增长过程之中。在项目前期，项目的交付范围定义会较为粗略和广泛，而随着团队对项目交付目标的深入理解，项目交付范围也会更加精确和详尽。5、项目有既定目标且会占用一定的企业资源。2.2.2项目管理和项目管理的特点美国项目管理协会将项目管理定义为“项目管理就是在项目过程中通过应用各种知识、技能、技术和工具，从而达到项目的交付目标。项目经理是实现项目交付目标的第一责任人。”项目管理和传统的企业管理相比具有以下几方面特点：1、项目管理的对象是某个具体项目。2、项目管理的思想的基础是系统工程的方法论，它依据先整体再分解再综合的原理，将一个项目分解成多个子模块并指定不同的责任人。10 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述3、项目管理的组织结构十分特殊，它不同于职能部门，项目组成员并不固定，具有临时性、开放性的特点。4、项目管理采用多层次的目标管理方式。项目经理以第一责任人和协调者的身份向项目组中各专家讲解各人应承担的责任，协商项目交付时间、成本和质量要求。5、项目管理采用基于团队管理的个人责任制。由项目经理作为第一责任人对项目结果承担主要责任。6、项目管理的要点是构建和维护使得项目顺利进行的内外部环境。7、项目管理的方法和工具有先进性和开放性。2.3软件交付项目管理现状分析2.3.1软件交付项目管理面临的挑战软件交付项目管理的管理思想和管理方法都属于通用项目管理范畴，但由于其管理的对象是软件交付，和别的项目管理相比又具有全球化、错综复杂等方面的独特问题，这也迫使软件交付团队不断地思考和总结，从而创造出更新更适合当前市场需求的软件交付方法和项目管理模式。当今时代电信软件业飞速发展，国内企业走出国门也带来了全球化软件交付的新局面，这也给软件交付项目管理带来了新的挑战，JimHighsmith（2010）将这些总结归纳为四个方[18]面：复杂性、团队、方法和工具。在软件交付的不断进化过程中，新技术的革新、编程语言的变化、底层平台的演进，常常会给企业留下复杂的系统架构和无法清除的技术障碍。面对多种多样的软件交付方法，软件交付团队也会想方设法寻找适合团队的交付方法，从而提高软件交付过程的敏捷性，增强对于客户需求变化的响应速度。但是企业内部的技术壁垒和部门壁垒会导致在企业内部不同部门存在多种开发工具和方法，而这些工具又无法整合，也就无法拉通统筹管理，这也加剧了软件交付的内部复杂度，这也给软件交付团队带来了前所未有的挑战。软件交付过程和其他产品的交付过程一样，也是由作为交付主体的人或团队，通过项目管理及一系列交付活动，最终交付符合客户需求的软件。在交付过程中软件经历了从早期客户原始需求，到中期的设计方案和代码，再到可独立运行的正式发布版本的不断演进。和生物的成长过程相似，在不断循环的软件交付过程中，会产生许多软件产品的阶段版本，它们代表了软件产品成长过程中的一个个快照，而这些快照的集合又反应了软件从诞生到发展再11 南京邮电大学专业学位硕士研究生学位论文第二章敏捷交付和项目管理理论综述到成熟的完整生命周期。在这个期间，人作为软件交付的主体，以软件开发活动和过程交付件为核心循环往复，不断向满足客户原始需求的软件产品靠近。因此管理好软件交付团队的活动和交付件，软件交付过程就会清晰。而管理好团队的交付过程从根源上需要提高软件交付团队的需求管理、配置管理和变更管理能力，这就是软件交付项目管理面临的首要挑战。在软件交付生命周期中，项目计划不是一成不变，而是动态并不断向着交付目标演进的。出现目标偏差然后再修正，这一循环贯穿了项目交付过程的始终。而如果采用传统的瀑布式开发方法，由于在项目生命周期的最后时刻才进行系统集成，所以项目的风险要到系统集成阶段才会暴露，从而造成项目风险无法在项目前期暴露和消除，项目进度难以真正评估。因此如何正确评估软件交付项目的进度，是软件交付项目管理面临的又一大挑战。2.3.2敏捷交付和项目管理方法敏捷交付方法的诞生解决了软件交付项目管理面临的挑战。2008年IBMRational推出了大型项目的敏捷最佳实践，提出了以迭代式软件交付为基础、两级项目规划、持续集成等方法作为敏捷交付过程核心。这一最佳实践诠释了敏捷交付的执行办法，帮助敏捷团队快速赋能，具备敏捷项目管理的能力，能够轻松面对软件开发过程中所碰到的各种挑战。针对软件交付项目计划的不断变化和进度的难以评估，IBM敏捷最佳实践更加强调迭代式交付，它把软件交付的过程拆分成多个风险可控的迭代，每个迭代都能交付可运行的且包含了部分客户需求的软件，这样敏捷团队可以按迭代向客户展示交付成果，通过互动获取用户反馈，再通过一次次的修正持续改进产品，也使得项目管理团队能够通过迭代的实现以及客户需求偏离程度来度量项目的进度，而不是主观地通过已完成的代码量来评估。IBM推出的敏捷实践的另一个要点是两级项目规划，它包括粗线条的项目级的发布计划和可执行的细化的迭代计划。在项目交付过程中，迭代计划一般保持不变，用于指导敏捷团队快速交付当期迭代所包含的产品需求和特性；而发布计划可以根据项目实际情况不断修改，使项目团队越来越接近项目最终目标。通过执行两级项目规划，软件交付团队能够紧密围绕客户需求并根据实际情况动态调整项目计划，在需求变更和业务快速交付之间通过需求价值的高低达到平衡。12 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析第三章敏捷交付的现状与特性分析3.1传统的软件交付模式传统软件交付模式有很多种，应用最广泛的并且最典型是瀑布模型（WaterfallModel）（WinstonRoyce，1970），瀑布模型顾名思义是指将软件生存周期的各项活动确定为自下而上，按固定顺序而形成的六个阶段，形如瀑布流水，得到最终的软件产品。这六个阶段为：可行性研究与计划、需求分析、设计、编码、测试和运行维护（如图3-1）。图3-1瀑布模型1、可行性研究与计划可行性研究的主要工作是了解客户的要求以及市场环境，从经济、技术和社会因素三个方向研究和论证该软件项目的可行性，输出可行性研究报告，并根据报告制定初期项目开发计划。2、需求分析需求分析是为了更加准确的了解客户对产品功能、界面、特性、性能、维护和安全等方面的具体需求，再进行的分析，来以此确定软件产品最终完成的目标。它是软件开发过程中最重要的一个步骤。3、设计13 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析软件架构设计师根据需求分解的结果，来设计如何在程序上、逻辑上去实现所定义的产品特性、功能等。4、编程编程时使用一种或者多种编程语言和编程工具进行编码，将设计的东西转换为计算机可读的形式。5、测试软件测试的最终目的是为了发现软件本身的内部逻辑路径和外部功能方面上存在的错误，提出并跟踪解决这些错误，来确保定好的软件能够输出和预期结果一样的实际结果。6、维护软件在交付使用后，通常都会存在或多或少的问题，且伴随着用户对软件产品不断深入的认识，用户需求也会跟着不断发生变化，同时提出更为符合市场需求的要求。这样就不可避免地需要对软件产品进行升级、修改等。瀑布模型中心思想是按工序将问题简化，把功能的实现与设计分开，便于分工协作，即采用结构化的分析方法与设计方法把逻辑实现与物理实现分开。瀑布模型提供了软件开发的基本框架。其过程是从上一环节活动接收该环节活动的工作内容作为输入，利用这一项输入实施该环节活动应完成的内容给出该环节活动的工作结果，并作为输出传给下一环节活动。同时评审该环节活动的实施，如果确认无误，则继续下一环节活动；否则就返回前面，甚至更前面的活动。对于市场需求变化多端，交付节奏极快的电信软件行业来说，瀑布模型工期过长且针对需求变化付出的代价太高，并不能满足要求。瀑布模型有两个优点：给项目提供了按阶段划分的检查点；当前一个阶段完成后，仅需要去关注后续阶段。同时瀑布模型也具有如下缺点：1、各个阶段的任务划分完全固定，阶段之间会产生大量的文档，很大程度上增加了工作量。2、由于开发模型是线性的，所以用户只能等到整个过程的末期才能见到开发的成果，从而累加了开发风险。3、前期的错误可能要等到开发末期的测试阶段才被发现，从而带来严重的后果。4、对于整个项目风险的控制能力比较弱。项目风险在项目开发后期阶段才能真正降低，而且通常是经过系统测试之后，才能最终确定该设计是否能真正满足用户以及系统需求。5、通过较多的强制规定完成日期和项目里程碑来跟踪各个项目阶段进度。6、不适应用户需求的变化。当发生需求变更时，重新设计、重新编码和测试，从而造成14 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析项目的延期和开发成本的增加。3.2敏捷交付模式及方法随着时代的发展，软件开发顺应时代变化，从重型过程转向轻量型敏捷。如图3-2所示。图3-2敏捷诞生的历史背景敏捷交付是针对传统的瀑布模型的弊端而产生的一种新的软件交付模式，目的是提高开发效率和响应能力，是一种以人为核心、迭代、循序渐进的软件交付方法。在敏捷交付过程中，软件项目会按照需求的优先级和关联性被划分成多个子项目，也叫多个迭代。每次迭代都包含了需求分析、方案设计、代码编程与测试，具备集成与可运行的特性。使用这种方法，开发工作可以在需求被完全地确定之前启动，并且在一次迭代中能完成系统的部分功能。再根据客户的反馈的意见来细化需求，从而开始新一轮的迭代。换而言之，就是把一个大项目分为多个既相互联系，又可独立运行的小项目来分别完成，在此过程中软件一直处于可运行的状态。敏捷交付中注意要点为：1、注重架构设计和概念，轻详细设计架构设计强调的是产品的规划路线、市场趋势、技术趋势、客户价值等。产品的设计才是一个产品的灵魂，只有设计正确，才能保证产品能真正给客户带来价值，才能吸引客户的购买欲望。2、使用SWOT分析法在敏捷交付中，更加注重客户需求。进行SWOT分析，就可以选出付出最小工作量，但可以获得最大价值的模块。产品先做哪些功能是由市场来决定的，而SWOT分析能帮我们更快更15 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析好地找到市场的需求点。3、市场和需求驱动，而非技术驱动拥抱变化，但不是盲目变化。改动产品需要经过概念设计、架构设计及SWOT分析后，三思而后行。敏捷交付的理念是简单而渐进的设计，并不是剧烈的颠覆式设计，交付刚刚好的软件才是我们想要的最好结果。4、时刻考虑版本兼容性敏捷交付去除了过多繁杂的设计和荣誉的文档，着重强调拥抱变化。但拥抱变化不等于盲目变化。当设计变更，代码重构，配置文件发生变更时，要时刻考虑产品的系统架构、规划的路线图，老版本的兼容性，以及业务迁移是否顺畅。否则，随着版本的日益增多，必然会产生大量的维护工作。5、轻文档，但非无文档敏捷交付注重的是沟通的重要性，而轻冗余的文档。但并不意味着敏捷交付模式是无文档的。敏捷交付精简的只是在设计和开发过程中产生的过多的冗余的文档，过多的冗余文档意味着占用了大量的时间和人力成本。在敏捷交付的过程中，适量的文档是很有帮助的，有助于整理思路，使沟通和讨论更为迅速，比如设计文档，架构图，接口文档等。同时，敏捷交付过程中强调代码注释，这样能让代码的维护人员能更快的搞清原作者的意图，减少学习成本，也不容易出错。敏捷交付与传统的瀑布模型相比，更强调团队成员间的紧密协作和面对面沟通，也更注重软件开发中人的作用。敏捷交付以迭代的方式演进，而瀑布模型是属于最典型的预见性方法，严格遵循预先的可行性计划和研究、需求的分析、架构设计、编码、测试和运行的步骤顺序实施，步骤是衡量进度的方法，例如需求文档、设计规格、测试用例等。敏捷交付过程中软件一直处于可运行状态，所以客户能在很短的时间内直观的体验并根据体验后的结果提出意见。如果是按照瀑布模型，客户可能签订合同两三个月后看到的还只是技术建议书等文档，无法快速地察觉软件实现和市场预期之间的距离。瀑布模型的主要问题是它的严格分级导致的开发自由度降低，项目早期制定的规格和计划导致后期需求变化难以落实，或者代价高昂，有如大象跳舞，难以转身。在采用瀑布模型开发的软件项目中，需求变更的时间点越靠后，那么变更的成本就越高，所以要求需求分析人员在项目初期就能完全识别出客户所有的潜在需求，并且预判出市场发展的动态，而这又恰恰是不可能。由于敏捷交付是迭代式的，且迭代的周期较短，因此可以更加容易的接受新需求或变更原有需求。敏捷交付模式能给企业和客户带来诸多好处，具体如下分析：1、精确。瀑布模式一般会在产品起点和终点之间规划出一条直线,然后沿着这条直线一16 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析直往前走。但当项目到达终点时,客户经常会发现终点已不是他们想要去的地方。而敏捷的方法则采取的是小步快跑,每走完一步就适时调整同时为下一步明确方向,直到到达真正的终点。2、质量。敏捷方法对每一轮迭代周期的质量都有着严格的要求。通过持续集成，测试提前介入测试等方法为敏捷项目的整个周期提供了可靠的质量保障。3、速度。敏捷团队只专注于开发项目中实时最需要的、最具有价值的部分。这样就能很快地投入开发。同时较短的迭代周期可以让团队成员迅速进入开发的状态。4、丰厚的投资回报率。在敏捷交付的整个过程中,最具价值的功能模块总是被优先开发,这样的方法可以给客户带来最高的投资回报率及市场占有率。5、高效的自我管理团队。敏捷交付要求团队的每个成员必须有自我管理的能力和积极主动的态度。在这样的团队里工作,团队每个成员的技术能力、沟通能力、表达能力和领导能力都能得到提升。敏捷交付过程中常采用的方法有迭代、Story、站立会议、结对编程、持续集成、重构和测试驱动开发。这些方法贯穿敏捷交付的全过程，是敏捷交付在项目中实现的基础，研究这些方法可以帮助我们更好地了解敏捷交付的思想，并找到敏捷交付标准化的措施。3.2.1迭代ThoughtsWork咨询公司提倡将一个完整的软件版本划分为多个迭代，每个迭代来实现不同的功能特性。重要的、优先级高的功能特性优先完成，风险高的功能特性优先实现。在项目的初期就将软件的雏形开发出来，然后基于这个雏形在后续的迭代不断地完善。迭代开发的优点是：尽早的编码，尽早的暴露项目技术上风险。提前让客户见到可运行的软件，并根据自己的需求提出优化意见。可以分阶段提前向客户交付可用的版本。JonathanRasmusson（2012）提出敏捷迭代就是在限定的时间（一到两周），选取首要的用户故事，将其转化为可运行的软件。迭代就好比敏捷项目的发动机。我们的目标就是曲柄每转动一次，就可以生产出一些有价值的东西。这也就是说，不管怎样，都要在一次迭代中[3]生产出可运行的、测试过的软件。迭代也可以在必要时调整。如果优先级有所变化或者现实情况出乎预料，可以在每次迭代的结尾进行调整。但是一般不会在迭代中间改变用户故事，因为这样团队会受到很大的干扰。17 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析3.2.2Story（用户故事）MikeCohn（2010）提出，在每个迭代的过程中，系统架构师负责将所有的功能特性分解成多个用户故事，每一个故事可以当做一个独立的特性，每个故事应该能在至多一个星期之内完成开发，交付提前测试（Pre-Test）。当一个迭代中的所有的故事开发完以后，测试团队再进行完整的系统测试。在整个版本测试过程中，依照每日构建原则，测试团队必须都是每天从配置库上获取最新完成的版本进行测试，开发团队根据测试成员提出的问题单随时修改[4]问题，并合入到配置库。JonathanRasmusson（2012）提出敏捷用户故事是对特性的简短描述，我们的客户希望软件具有这些特性。敏捷方法鼓励团队使用索引卡（记录关键词的小便签），为的是提醒大家收集需求的活动初衷不是为了获取所有的细节。只需写下少许关键词，收集特性的要义，然后将其存档以备日后之需。这是因为我们现在无法确定合适可以来开发这些特性，甚至这个特性最终是否需要都难说。因此为了防止现在浪费时间和精力去做而日后又要重做，可以日后[3]再来研究那些细枝末节。比尔•韦克（2009）提出过一个理论，首字母缩写为INVEST，也就是“独立的、可协商的、有价值的、可估算的、小型与可测试的”（Independent，Negotiable，Valuable，Estimatable，SmallandTesttable）。优秀的用户故事第一要素就是要体现出对客户的价值，就是要让客户愿意为之买单。下面就是正反两个示例，右侧的示例明显比左侧更直观地展现了系统会给用户带来的好处，如表1-1所示。表1-1用户故事对比反面示例正面示例C++3天创建用户账号3天用C++来编写系统用户将会以独立私人账号登录系统连接池2天通知用户新列表2天所有的数据库访问都由一个数据库连接池处每当有新的餐馆在用户所在的市场开张，都理要通知他们MVP模式5天取消预订1天系统将会把表示逻辑与业务逻辑区分开来每一封电子邮件中都会嵌入一个注销选项用户故事要对业务有意义。正因为如此，我们在记录时总是尽量使用客户能听懂的语句，避免过多使用技术术语，导致沟通不畅或者沟通的偏差。优秀的用户故事的第二个特征是独立且有始有终。计划赶不上变化，迭代交付中常常由18 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析于客户要求的变更导致需求的变更或优先级顺序的调整，如果所有的用户故事都彼此依赖，那就很难做出快速响应。同时客户也不希望交流时看到的解决方案残缺不全，所以一个优秀的用户故事会从头到尾贯穿系统架构的所有层面，传达一些有价值的东西。交付任何已知的特性总会有多种方式，用户故事也需要具有可协商性。可协商故事的好处在于它给我们留了一些余地，有时我们正是依靠这些余地才能在预算的范围内工作。我们希望用户故事是可测试的，因为我们希望知道一切是否正常。对用户故事测试，可以让开发团队心中有数，让他们了解工作何时才算完成。我们通过将用户故事小型化（1~5天），以确保它们符合1~2周的迭代周期，从而得知用户故事是否符合现有的时间表。综上所述，好的用户故事需要回答三个问题：谁，要做什么以及为什么要这样做。例如：作为<用户类别>，我希望达成<某个目标>，以便于<一些原因>。3.2.3站立会议站立式会议是一种新型的会议方式，为当今一些新兴的科技公司所开创。它提倡一个项目组员工可以选择以站姿来取代坐姿来开会，用身体的放松来带动精神的放松，一方面提升工作效率，另一方面也有助员工身体健康。每天早上，所有的团队成员就地围在白板周围自由站立，开一个高效的会议，通常不超过15分钟，各个成员汇报当前的开发进度，提出遇到的问题和风险，有问题集中讨论，有了解决方案后在会后由相关人员个别沟通解决，不在会上浪费其他人的时间。3.2.4结对编程结对编程的概念来自于极限编程（ExtremeProgramming，简称XP），是由KentBeck在1996年提出来的。结对编程是指两个开发人员结对编码。结对编程的优点是：经过两个人讨论确认以后编写的代码会比一个人独立思考完成的更加完善，而且功能的大方向不至于出现偏差，同时一些细节上问题也能被充分的考虑到。一个经验丰富的开发人员与一个新手结对编程，能促进新手的快速成长，保障软件开发的质量。3.2.5持续集成JonathanRasmusson（2012）提出持续集成就是指不断把开发者对其软件所作出的改变集19 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析[3]成到一起。改动集成的时间拖得越长，集成合并就会越困难。CraigLarman（2004）提出持续集成是一种软件开发的实践，即团队成员会经常集成他们的工作，一般每个成员每天都要至少集成一次，也就是说每天都可能会发生多次集成。每次集成都必须要通过自动化构建（包括编译，自动化测试，发布)来验证，从而来尽快尽早地发[5]现集成的错误，大大减少集成时发现的问题，开发团队也可以更快地开发高质量的软件。它体现的价值是：任意时间、任意地点生成可部署安装的软件；发现的问题第一时间修复，提高项目的可见性；为项目的质量指标和构建状态都提供了及时有效的信息，同时根据数据评价构建成功情况的趋势；在一天中进行多次的集成，通过多次的集成也做了相应的测试，这样利于检查软件缺陷，把握软件的健康状况，降低质量风险；通过自动化的持续集成能将代码的编译、数据库的集成、软件测试、软件部署的等重复繁琐的动作都变成自动化的，不需要太多人工干预，减少重复的工作，节省了时间、花费和工作量，让人们的时间可以更多的投入动脑筋的、更有价值的事情上。持续集成可以建立开发团队对开发产品的信心，这是因为他们可以明确地知道每次构建的结果，知道他们对软件的改动会带来哪些影响，结果会怎样。要建立一个持续集成系统，需要具备源代码库、签入过程、自动化构建和分小段工作。一、源代码库源代码库会存储并记录软件版本，开发团队将其代码签入到库中。作为项目的集成点，它会保存代码的主要副本。二、签入过程典型的签入过程如下所示：1、从库中获取最新代码。在任何新任务开始之前，都需要从库中获取最新构建的代码。2、做出改变。然后开始工作，添加新功能，修复缺陷，完成所有必须完成的工作。3、运行测试。为了确保所做出的改变不会破坏库中的其他东西，需要运行所有的测试用例，以保证代码仍然能顺利通过。4、检查更多更新。为了确信做出的改变没有问题，需要再次从代码库中获取一次签出更新，因为你在添加新特性的过程中可能其他人也在对库进行着改变。5、再次运行测试。20 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析然后再次运行测试，保证你的改动与在此期间别人的改动没有冲突。6、签入。所有的系统都已启动，一切都已构建完毕，所有的测试都已运行，我们使用的是最新的代码，这时我们可以很安全的签入。三、自动化构建自动化构建是形成团队持续集成过程的基石。优秀的自动化构建能够编译代码，运行测试，并且作为项目构建过程的一部分，基本上能够完成所有的常规任务。自动化构建也能够将软件自动部署到生产环境中去，而这种方式能消除很多的人为错误。任何构建的关键都在于自动化，人为干涉的越少，效果就越好。同时，构建越迅速越好，好的团队每天都会多次运行构建。四、分小段工作集成代码如果分成小段来做会比较容易。如果集成代码的间隔很长会引入很多集成问题，比如代码合入缓慢，不同人写的代码有差异，无法合入等等。因此，如果能在早期经常合并代码，就可以避免大型集成的麻烦。3.2.6重构MartinFowler（2010）认为重构就是在不改变软件当前现有功能的基础上，通过调整程序代码来改善软件的质量、性能等，使程序的架构与设计更趋于合理性，提高软件的可扩展性和可维护性。重构的价值在于能够改进软件设计让软件更易于被理解、能帮你找到软件的[6]bug、提高软件的开发效率。JonathanRasmusson（2012）将重构比作按揭买房，软件中也需要定期偿还技术债务。重构不仅能够降低维护成本，而且提供了改进代码质量的通用标准，并能使人迅速添加新功能[3]。一、技术债务我们经常以赶时间和进度为借口，在编写代码时走捷径，写下的代码晦涩难懂，冗赘重复，这些错误就是我们所要背负的技术债务。技术债务有多种表现形式，比如过度复杂，重复以及常见的粗心大意等等。每个代码库中所犯的错误开始时貌似都很小，但是跟所有的债务模式一样，随着时间的不断推移，从而产生的累积效应最后必然会造成危害。随着系统的不断发展，我们需要一种方式来偿还技术债务。这种方式要能逐渐提升和维21 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析护软件的完整性与设计，使之不仅能满足当前的需要，还能让我们在应对明天未知的挑战时处于一个有利的位置。二、通过重构还债在不影响整体外部行为的前提下，不断地对软件进行细微的设计改进，我们把这种渐进式的实践叫重构。在对代码进行重构时，不会增加新功能，甚至也不会去修复缺陷。相反，会通过将代码变得更易于理解和改变来提升代码的可读性。想要积极地重构，就不能将重构工作都积累到一个迭代的末期。它需要每天都坚持不懈。如果方法正确，重构几乎就是隐形的，步伐会非常小，改进也非常细微，以至于当某人对代码进行重构并添加新性能时，几乎无法分辨个中差异。但是对于接近尾声的项目进行大型重构通常得不偿失，因为没有时间能捞回本钱。因此，如果项目接近尾声，最好不要进行重构。3.2.7测试驱动开发LisaCrispin和JanetGregory（2010）认为测试驱动开发的核心思想就是在开发功能代码之前，首先编写测试用例，其次只编写使测试通过的功能代码，从而来达到以测试来驱动整个开发的进行。这样助于编写简洁易用代码，同时代码又有很高的灵活性和健壮性，降低了[2]代码量和代码的复杂性，能够快速响应变化，并加速整个开发过程。测试驱动开发的基本过程如下：1、快速新增一个测试用例，展示新代码的预期作用。此时需要对设计加以仔细考虑。2、运行所有的测试用例（有时候只需要运行一个或一部分）。3、如果发现测试可以全面执行，那就添加新代码。如果不能，再多做些工作，要尽快地让测试用例可以运行。4、执行所有的测试用例，并且全部通过。5、通过重构代码来消除重复的设计工作，更好的优化设计结构。3.3敏捷交付的SWOT分析SWOT分析方法是一种分析目标竞争态势的方法，可为项目管理提供新的思路。SWOT分析包括分析目标的优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）和威胁（Threats）。SWOT分析综合概括了待分析对象内外部条件，从而分析组织具备的优劣势，面22 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析临的机会和威胁。通过SWOT分析，待分析对象可以扬长避短，采取更科学的战略规划，将有限的资源集中在自己的强项和机会点上。3.3.1敏捷交付的优势1、允许变更需求由于电信软件业市场变化十分迅速，为了满足市场的变化，客户的需求也会时时变化，这些变化往往会给项目交付带来很多困扰，它们会导致项目延期交付、客户不满意交付成果、开发人员由于需求的频繁变化而士气低落。采用敏捷交付后我们可以在每次迭代结束后都向客户展示系统的部分功能，客户如果对于实现不满意可以尽早反馈，从而通过不断的修正最终交付出令双方都满意的软件。迭代开发过程中需求变更的最佳时间点是在一个迭代发布之后，在这个时候客户能看到我们交付的软件，也能准确把握实际需求和实现的偏差，软件交付的过程中有多个迭代，所以客户可以通过频繁地小幅修正来准确命中需求。在软件开发过程中也可以变更需求，这时需要我们和客户共同分析需求的优先级和关联性，再考虑通过何种方式实现。2、逐步集成元素在传统的项目交付方法中，由于要在项目集成阶段集成系统中所有的子模块，而由于模块众多集成时的工作量会很大，而且模块越多集成的时候就会越复杂也越容易出错。在敏捷交付的过程中，软件集成贯穿了项目的全过程，每个迭代都会增加一部分新的功能，单次集成的内容比最后集中集成要少了很多，工作量和难度也会大幅度降低。3、尽早降低风险敏捷交付的一个原则是以系统架构为中心，在每次迭代开始阶段就要确定系统架构，通过几次迭代尽快设计出满足客户需求且稳定的系统架构，这样可以迅速降低整个项目的风险。系统架构稳定后，项目的技术风险就比较低且可控。4、有助于提高团队的士气敏捷交付中每个迭代都能交付可运行的软件，这样项目团队成员可以在短期内见到自己的工作成果，并且可以得到公司以及客户对自己工作的正确评价，这也有助于增强他们的信心，提高团队的士气，并能及时发现自己工作中的不足。而在非敏捷交付的项目中，团队成员只有在项目整体交付时才能看到自己的工作成果，在交付之前，大家并不知道自己做的东西到底是什么样，是否符合预期，交付周期如果长了，人容易产生迷茫感。23 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析5、提高质量敏捷项目在每个迭代都会交付一个包含部分需求的可运行的系统，通过对迭代版本的验收测试以及和客户的演示，我们可以尽早发现系统中的缺陷以及偏离客户需求的地方，并及时改正。通过一次次的迭代交付，我们可以不断地纠正错误以及软件开发的方向，这样最终交付件的质量也会越来越好。6、保证项目开发进度每次迭代结束时项目经理都需要评估本次迭代了实现了哪些功能，还有哪些遗留问题未解决，这样项目经理可以清楚地把握当前需求的完成进度，从而准确评估项目风险，并针对项目中的风险及时采取措施，规避风险，按时交付。7、允许产品进行战术改变敏捷交付具有极大地灵活性，由于分成多个迭代交付，每个迭代的交付周期都不长，这样客户可以随时根据市场的变化临时调整项目交付范围，比如提前交付某个功能或者插入某个原先并不存在的功能，这样的最终目的是为了让客户能尽快地占领市场，从而提升客户满意度。8、迭代流程自身可在进行过程中得到改进和精炼敏捷交付要求在每次迭代结束时都召开迭代回顾会议，会上不光回顾交付过程中的优缺点和项目完成情况，还需要总结和分析组织结构和迭代流程中还有哪些可以改进的地方，不光可以在下个迭代中规避这些问题提高效率，也能够在公司范围内推广，提升公司的竞争力。3.3.2敏捷交付的劣势1、开发者害怕暴露能力缺陷迭代开发过程中每个团队成员的工作往往是每天汇报的，例如在开会的时候每个人汇报工作。这样团队的每个成员都会知道你每天花了多少时间做了什么事。假如有一个工作你花了比正常流程更多的时间，那么你会感觉到每个人都在质问你为什么。另外在一块白板前一起讨论设计等问题往往会暴露一个人的能力不足，或者沟通不善。2、要求全能型开发者成为一个成功的敏捷交付者，需要是一个同时具备开发工程师，架构师，测试工程师和客户的能力。很多公司为此去培训员工，但这个代价是很高的，并且不是很有效。3、对沟通的要求过高敏捷交付十分强调沟通的重要性，不管是敏捷岛还是站立会议就是为了能够让项目组成24 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析员能够随时方便地互相交流，所以敏捷交付要求团队的成员都具有较高好的沟通技能，能够清楚准确地表达自己的观点。但并不是每一个项目成员都具有很强的沟通能力，有些人由于不善言辞无法有效地将自己的想法传递其他成员，这样容易使最终项目的实现出现偏差，也容易由于沟通的障碍耽误版本的进度。4、分工过细，传承不足敏捷注重人员的沟通，而忽略了文档的重要性。对于一个大型项目来说，每个人都有自己明确的分工，不可能每个开发者都对项目的所有功能了解，可能每个人就做一小块功能。这样的话一旦某个人休假或者离职，那么顶替上的程序员往往不具有对这块功能的业务知识，给维护带来不少难度。5、每日汇报容易流于形式，变成官僚式汇报敏捷交付的过程中一般会采取口头或者书面形式来汇报项目进度，最常见每日会召开站立会议，本意是每天汇报进度和风险以及工作情况，但是容易演化成思想汇报而流于形式，上交的书面材料也都是千篇一律，表面装订得整齐规范，实质内容空洞虚浮，没有充分反映出真实的项目风险和不足，这种汇报制度严重打折扣。有的员工把写项目汇报当作应付差事，有问题和困难不愿写出来，也不愿讲出来；有的员工认为自己的困难领导组织解决不了，说了也白说，还会被认为是“事情多”“困难户”，怕丢面子，思想偏激；有的领导组织怕麻烦、图省事，不愿给员工排忧解难，把“不汇报”当作“不知道”，把没有发生问题当作“没问题”，寻找借口，推脱责任；有的盲目乐观，认为项目本身基础好，版本交付率高，一般不会出问题，自我安慰，麻痹侥幸，不愿较真。6、缺乏可借鉴的项目经验敏捷交付由于兴起时间不久，在国内应用尤其缺乏，在实际交付过程中常常需要摸着石头过河，容易走入各种各样的误区。根本原因还是人，人的主动性还有在软件开发中的行为受各种各样因素的影响。3.3.3敏捷交付的机会运营商转型所带来的电信软件业的飞速发展，也带来了电信软件业固有开发模式的变革。现在的运营商早已走下昔日高高在上的神坛，为了抢占市场，就要满足市场需求的快速变化，这也需要软件交付企业的快速响应。而这也是敏捷交付方法的机会，这些机会来自于以“运营商＋设备商”为核心的价值链受到严峻的挑战，价值分配向价值链的两端（终端、业务服务）转移。非传统的竞争者将迫使设备和服务供应商改变他们的战略。对于电信软件业，运25 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析营商转型已经迫在眉睫，转型的主要原因如下：用户需求的变化从“网络连通性”向“网络体验性”转变，即从“今天你上网了吗”向“今天你微信了吗”转变；网络成为社会形态和生活模式，而不仅仅是通讯。运营环境的变化业务运营的主角从“网络资源运营”向“信息服务和流程服务”转变，网络成为配角和幕后支持者。语音发展趋势话音需求向数据需求的转移以及话音业务竞价模式的盛行使得运营商话务量运营的利润不断降低。宽带发展趋势固定带宽的价格以每年20-30％的速度下降，带宽的增加只能保持ARPU（AverageRevenuePerUser用户平均收入）；无线宽带由于频率资源的稀缺性，价格维持稍好，但也在下降。而终端用户感兴趣的是具体应用，网络的价值只有通过应用才能被终端用户所感知，但应用的收益属于应用提供商，运营商只能沦为管道，无法参与利益的分成。业务服务的趋势业务服务向“综合化、平台化、门户化”方向发展，比如游戏基地、动漫基地、无线城市等等，都是运营商推出的业务平台或综合服务门户。当前业务开发商很多，但是如何整合这些资源，以一个统一的业务平台对外呈现，并吸引更多的用户和业务提供商使用和参与进来才是关键。业务替代的趋势以微信、QQ、VoIP为代表的软件日趋混淆了电信业和IT业的界限，客户体验更好，价格近乎免费，严重冲击了运营商原有的短信和话音业务，而这些非传统竞争者的迅速崛起也分走了原本属于运营商的一块大蛋糕。而且通讯技术的门槛越来越低，业务实现变得相对简单，导致越来越多的厂商参与这些替代产品的开发，商品一旦有了替代品，其价值就会急剧下降，运营商的利润也会越来越薄。通过以上分析，可以看出当前运营商对整个产业链的支配能力正在大幅削弱，以前那种运营商闭门造车，不考虑市场真实需求的日子已经一去不复返，如果运营商不能快速响应市场需求提供有独特竞争力的产品，则必将被市场所抛弃，这使得运营商迫切需要从传统的网络资源运营商向综合业务提供商转变。即面向最终用户提供E2E的业务服务，面向商业用户提供E2E的ICT（InformationCommunicationTechnology，信息通信技术）服务。运营商需要26 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析以用户和业务为核心，把握市场的变化，针对市场的需求快速响应，能尽快推出符合市场真实需要的增值业务。而软件的敏捷交付方式恰好能适应这种多变的市场需求，与运营商实现双赢。3.3.4敏捷交付的威胁传统交付方式虽然不适合电信软件交付，但由于其门槛低，对人员的技能要求不高，所以在一些小企业中仍然有存在的市场，敏捷交付方式如果想向全行业推广，提高软件从业人员的技能是一件刻不容缓的事情。敏捷交付由于其交付方法的创新性，对组织结构和考评机制有着特殊的要求，如果不加重视，这两项将会威胁到敏捷交付的成功。敏捷交付的最小单位是项目组，在项目的各阶段从各部门抽调合适的员工组成一个项目组集中办公，相关员工在完成各自的任务后又可以回到原职能部门一边培训技能一边等待下一个项目的开始，同时项目分时间段按需投入又可以避免人力的浪费。如果采用直线职能式组织结构，各项目组对于人力的安排权力过小，容易出现无法安排合适的人力按时投入的问题，从而威胁到项目的成功交付。所以一般的垂直形式的职能式组织结构并不适用于敏捷交付，需要在横向增加一条按项目维度划分的组织线，也就是说敏捷交付需要采用矩阵式组织结构。矩阵式组织结构是由职能部门和为了完成某个临时任务而组建的项目组构成，从而兼具了事业部式与职能式组织结构的优点。矩阵式组织结构并不是一个固定的组织，它具有非常灵活的特点，可随着项目的开始而组建，随着项目的结束而解散；由于这种结构是以项目的维度而组建的，所以项目组成员都是挑选的能为项目带来价值的人，成员都清楚自己的任务，也清楚项目交付的目标，大家无需磨合即可向同一个方向努力，促成了项目的早日交付；它还打破了职能式组织结构中不同部门之间厚厚的部门墙，不同部门的人为了一个目标而努力，不会因为与自己的工作无关而不理会别人的求助，促进了公司内部的知识共享；同时还加强了公司内部的横向联系，实现了公司内部的人力资源的共享，避免了人员闲置引起的浪费。但同时矩阵式组织结构由于其组织结构的特点，又具有一些先天缺陷：项目经理的责任大于权力，因为项目组成员都来自不同的职能部门，项目结束后还要回到原部门，人员存在多头领导的情况，而项目经理缺乏足够的奖惩措施，也就无法充分管理项目组成员；由于项目组成员实际归属于各职能部门，考评和奖金的评定都在原部门，而原部门主管由于不工作在一起，并不清楚自己的工作详情，所以会让员工有应付的想法，会影响工作责任心，无法27 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析充分调动员工的工作积极性；员工受双重领导，在两边都有任务下发时难以分清主次，需要两边的领导花费过多的时间用于沟通协调，影响组织运作的效率，也会影响员工工作的积极性。软件交付以人为本，项目组成员如果工作不积极，没有全身心地投入项目会严重威胁到项目的按时和成功交付。针对矩阵式组织结构的缺点，需要改变现有的考评机制。项目组责任人对组员有考评建议权。当一名组员在一个考评周期内为多个项目组服务时，需要按工作量的比例由各项目组责任人协商考核。这样可以解决项目责任人在项目过程中管理困难的问题，也能让项目组成员分清自己的责任，降低无谓的扯皮带来的内部损耗。在改变考评机制的同时设立按项目的实时激励，能更好地激发项目组成员的工作积极性。比如设立项目奖金，奖励那些做的好的项目团队；又或者在项目组内部记录关键事件，作为奖金分配的依据。这样可以更好地完善矩阵式组织结构，也能有效地降低给敏捷交付成功所带来的威胁。3.3.5完善敏捷交付的建议与对策根据上述分析构建敏捷交付的SWOT分析模型见表4-1：表4-1敏捷交付的SWOT分析模型优势机会允许变更需求运营商转型逐步集成元素电信软件业的飞速发展尽早降低风险软件需求的快速响应提高团队的士气提高质量保证项目开发进度允许产品进行战术改变迭代流程自身可在进行过程中得到改进和精炼劣势威胁开发者害怕暴露能力缺陷错误的组织结构缺乏全能型开发者按项目组考评组员的考评机制对沟通的要求过高传统交付方式门槛低，对人的要求低分工过细，传承不足每日汇报容易流于形式，变成官僚式汇报缺乏可借鉴的项目经验28 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析3.3.5.1抓住机会，消除威胁的对策分析针对敏捷交付的机会和威胁分析，交付过程中宜于采取以下对策：拥抱市场变化，每个迭代交付结束后和运营商共同审视需求，根据市场变化及时调整需求；在项目初期与运营商合作，帮助运营商分析市场需求，将市场渴求度高的需求设为高优先级，尽早交付以帮助运营商拓展市场；在公司和项目组内定期开展培训促进知识共享，提高企业员工的整体素质；采用矩阵式组织结构，从各部门抽调精兵强将组成项目组，满足项目交付需要；给予项目责任人考评决议权，保证项目组目标一致，聚焦业务；按项目实时激励，激发项目组成员工作积极性。3.3.5.2发挥优势，避免劣势的对策分析针对敏捷交付的优势和劣势分析，交付过程中适宜采取以下对策：使用迭代交付的方法，根据优先级将客户需求分解到多个迭代，每个迭代周期控制在一个月以内，并交付可执行且满足质量要求的软件，通过给客户演示，使得客户能清晰地知道软件成品是否满足市场需要，从而准确命中客户需求的中心；以客户为中心，从客户的角度审视市场的实际需求，而不是只从技术角度考虑如何实现，更多地考虑软件的可用性以及能给客户带来的价值。同时对于客户临时新增的需求积极应对，帮助客户分析该需求能带来的真正价值，接纳高价值的新需求，帮助客户抢占市场，实现和客户的双赢；每个迭代交付结束后组织全员展开AAR回顾（事后回顾），分析本次迭代做的好的地方以及需要改进的地方，总结出下次迭代要注意的问题，通过一次次的迭代交付总结经验，最终形成一套敏捷交付的交付指导，提升后继项目交付质量，降低摸索适用方法所带来的成本浪费；召开每日站立会议，将时间控制在15分钟，内容只涉及进度，当日计划，问题和风险；定期组织知识共享，培养团队内共同学习和提高的氛围，同时也能让团队成员正视自己的缺点，积极学习和弥补自己的不足；使用即时通讯工具，鼓励不善言谈的组员，通过文字表达自己的想法；29 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析建立统一的配置库，将设计思路形成完善的设计文档，并归档在配置库上，供全组人学习和查阅；两个开发人员结对编程，最好是一个有经验的开发人员和一个新手结对，这样可以促进新手的成长，两个人讨论后的代码也比一个人开发的代码更加完善，提高了代码质量，同时当有人休假或离职时也能快速顶替；敏捷项目要配备敏捷教练的角色，并在启动前做好各项规定，项目启动后全组人员按照约定好的规则交付。3.4敏捷项目交付模型敏捷项目交付模型是一种运用敏捷方法交付的软件项目管理的生命周期模型。建立敏捷交付模型是为了规范敏捷交付的过程，提高软件开发效率，降低项目交付的成本，提高客户满意度。敏捷交付作为一种崭新的软件交付模式，虽然已被广泛应用于软件交付过程中，但由于敏捷交付方法的特殊性以及诞生时间不久，至今业界并没有一个统一的指导模型，很多企业还是在摸索中前行，而不知道什么时候该做些什么事情，哪些活动才是适合自己团队的，这种情况很大程度上降低了敏捷交付的效率，还有可能导致需求与实际实现的功能偏离，也违背了敏捷交付的初衷。作者根据自身工作中的具体实践从项目交付周期和团队成员两个角度建立交付模型，这样可以指导项目交付过程以及各角色在不同阶段按需投入，降低投入成本，提高项目交付效率。根据敏捷项目迭代交付的特点，将敏捷项目分为如下五个阶段，每个阶段的关键动作如下：1、迭代前准备阶段迭代前准备阶段包括技术准备和环境准备两方面。先收集客户的原始诉求，根据客户需求、市场愿景以及公司的技术储备就需要实现的软件与客户达成一致；再根据需求量以及项目交付时间确定迭代交付计划以及每个迭代周期内需要完成的目标，在做迭代计划时要注意优先实现对客户价值高的需求，从而帮助客户抢占市场先机，同时把相关需求集中到一起来实现，每个迭代版本都能交付包含部分客户需求且可运行的软件；最后还需要评估项目交付过程中各环节产生的的工作总量和总成本，向公司申请项目资源，包括人力资源、场地资源、软硬件环境资源等等。30 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析2、迭代开发阶段迭代开发的核心是需求澄清和编码。需求澄清时需要以用户故事的方式体现具体需求能给客户带来的好处，从而指导编码和测试角度更好地贴近客户的原始需求，减少由于需求理解错误带来的返工。敏捷项目中编码时需要运用多种敏捷方法，包括站立会议、结对编程、持续集成、重构、培训等方法，这些方法的运用能够帮助敏捷项目更好地交付。3、迭代验收阶段迭代验收阶段是一个随着版本逐步完善而产生的敏捷交付中的必需阶段。此阶段的目的是方便项目团队通过对各迭代产品质量把控，能对最终产品有个清晰的认识。此举的优点是通过对迭代的产品功能了解，降低了产品没有办法按照既定计划让用户使用带来的风险，及时确定和解决问题；加快整个产品的发布进度，由于迭代验收人员清楚问题的焦点所在，执行效率更高；由于客户的需求并不是最开始就确定完全的需求，是在产品迭代验收阶段不断变化的，这种模式更容易适应需求变化。4、迭代发布阶段迭代发布后需要和客户共同审视交付的可执行软件，以确定交付的内容是否满足客户的实际需求，能否给客户带来价值，从而确定下个迭代的需求是否需要调整。5、迭代结束阶段每个迭代结束时都需要回顾本次迭代的历程，总结并固化已有经验，项目经理根据项目组成员在交付过程中的表现给出客观公正的考评意见，公司也会在这个阶段根据项目交付质量即时激励团队和个人，从而保证团队积极的斗志。而根据敏捷项目组成员，又可以清楚规划项目各角色需要具备的关键技能和项目过程中的关键动作：1、项目经理项目启动阶段分析项目规模，并按需求向各职能部门申请人力。项目开发过程中组织站立会议汇报前日开发进展，提出开发过程中遇到的问题并讨论解决。每个迭代结束后组织回顾，运用AAR的方法引导大家总结迭代中的优缺点，在下个迭代中做的更好。项目结束后能根据项目组成员的表现给出正确考评，并申请项目奖按考评分配给项目组成员。2、软件设计人员分析客户实际运营场景，帮助客户理解市场痛点并提出能满足市场的真实需求。分析客户原始需求列表，根据需求价值和风险划分优先级，输出迭代需求列表。再以用户故事的形式将需求表述清楚，帮助开发人员理解真实任务。3、开发人员31 南京邮电大学专业学位硕士研究生学位论文第三章敏捷交付的现状与特性分析正确理解用户故事，并将自己的理解用软件实现出来。开发过程中两两结对编程，采用持续集成的方式每天查找代码中的漏洞并清除，定期对代码重构降低代码复杂度，减少代码中存在的缺陷。4、测试人员在理解需求的基础上输出测试用例，并驱动开发人员开发对应的代码，分段测试。32 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究第四章敏捷交付在华为公司项目管理中的应用研究4.1项目简介本文以泰国DTACSDP（业务分发平台）解决方案项目为例，介绍敏捷交付在华为公司项目管理中的应用。SDP解决方案是华为公司为运营商量身打造的综合性解决方案，包含了华为开发的多个部件，屏蔽了复杂的底层环境，提供统一的对外接口，能实现业务的快速开发和部署，吸引CP（内容提供商）和SP（业务提供商）将自己的业务快速部署在SDP平台上，满足多变的市场需求，并通过收入分成实现与运营商的共赢。该项目在2012年7月启动交付，2012年11月30日第一个商用版本发布，是公司级重点项目，也是一个从头到尾贯彻敏捷思想的项目。泰国在2012年开始真正意义的3G规模应用，DTAC运营商在各方面积极准备，深入市场调查，期望能推出满足市场真实需求的产品，从而提高在3G市场的占有率。而现网的CPA平台在过去两年智能手机快速普及下，成为DTAC网络的瓶颈和痛点。目前的CPA平台已经不能支持大规模的CP应用，也和现网的计费系统配合存在问题，而在3G时代如何吸引更多的CP建立合作关系，将业务部署在运营商自己的平台上，从而吸引更多的用户，以及扣费的准确性是运营商关注的焦点问题。所以DTAC运营商决定新建SDP平台，并替换现网的CPA系统。泰国DTACSDP解决方案项目选择敏捷交付的原因主要有以下两方面：客观限制：立项之初客户需求不清晰、规格充满变数，标书迟迟未获取；团队刚刚组建，人力缺乏，无法满足同时开发所有已知功能的要求；项目时间紧迫，不允许单纯的等待需求澄清后再开展活动；主观选择：相比于传统的瀑布式模型，敏捷交付具有更为灵活的优势；敏捷交付能够通过迭代的方法循序渐进地完成整个项目，与项目整体计划滚动式制定原则契合，把开发过程分段，渐进明细；第一时间开展可以确定的任务，有效避免了需求不清、人员不足两大限制；在客观因素限制和主观选择的情况下，顺应公司整体趋势要求，泰国DTAC项目组通过对敏捷交付的实际应用，获益良多：1、开发目标明确，测试任务清晰，能够及时响应且接受新需求；2、将项目总体方案尽早的分解到各个迭代中，减少需求变更带来的影响；3、缩短项目测试周期，通过迭代测试，及时发现软件开发中存在的缺陷，减少后期因返工对项目带来的成本的浪费。33 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究4、敏捷交付可以有效的增加项目团队各个角色之间的充分交流，避免因前期未沟通或沟通不畅所带来的需求实现错误，导致后期因项目返工引起的时间浪费。4.2项目时间管理项目时间管理包括项目工期管理和项目进度管理。其中项目工期管理的主要依据是项目时期指标，而项目进度管理的主要依据是项目时点指标。由于DTAC客户迫切想要交付部分可用的功能，从而抢占市场，这也直接导致了项目交付时间紧迫，敏捷交付也成了最适用的交付方式。按照敏捷交付的思想，我们根据客户营销计划的时间点，将泰国DTACSDP项目一期分成三个迭代，如表4-2所示：表4-2项目关键时间点阶段需求冻结时间点调测版本发布时间点商用发布时间点迭代一2012-7-102012-9-15迭代二2012-8-102012-10-152012-11-30迭代三2012-8-242012-11-15每个迭代实现一部分功能，并发布可运行的软件给客户验收，迭代中实现的需求列表排制定时满足如下条件：1、采用SWOT的方法分析客户需求；2、按照价值、风险排序，优先完成价值高的需求，而在价值高的需求当中又优先完成实现风险高的需求，如图4-1所示；3、排序要求有绝对值；4、排序可以根据依赖关系等因素进行调整；5、需求能够细分到Story程度，如果项目比较大也要划分到具体功能模块的程度。34 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究价值高低○3高中○2高高○1中低○6中中○5中高○4低低○9低中○8低高○7风险图4-1价值风险与开发优先级通过价值和风险分析划分迭代范围和时间，华为和DTAC客户就商业目标和自身业务的承载量达成了一致，尤其是迭代一的交付，帮助客户顺利召开了市场大会，在大会上客户展示了SDP平台的能力，从而吸引了大批CP和SP的接入，帮助客户抢占了市场，为客户的服务转型提供了有力的业务支撑，我们的交付成果也得到了客户的高度认可。所以迭代是敏捷交付的基础，而价值与风险分析又是迭代的重要划分依据。迭代计划制定后需要由各部件责任人共同评审，大家在评审过程中达成一致，这也是为了避免后期由于理解不一致而互相扯皮降低开发效率。整个迭代交付流程包括了设计、开发、部件测试、集成测试、发布等完整的软件交付活动，迭代完成后还会与客户对迭代完成的结果进行评估，并以此作为下个迭代交付质量标准和过程标准的重要输入。迭代交付流程如图4-2所示：图4-2迭代交付流程每个迭代版本开始前，华为会由各角色的专家根据专家法估算出项目活动资源，如表4-3所示。35 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究表4-3泰国DTACSDP解决方案迭代一项目活动清单项目阶责任人输入主要活动输出时间点成本段设计解决方案需求文档特性设计，产品设计2012-7-10~210人天设计师/部算法设计文档，接口012-7-20件设计师文档开发部件开发产品设计软件开发可执行的2012-7-20~2300人天人员文档，接口软件，相关012-8-25文档工具部件测部件测试产品设计单部件测部件测试2012-8-25~2100人天试人员文档，接口试报告，测试012-8-31文档总结文档集成测解决方案产品设计解决方案解决方案2012-9-1~20200人天试测试人员文档，接口中所有部测试报告12-9-14文档，测试件拉通测总结文档试发布部件责任可执行的走发布流产品发布2012-9-155人天人/解决方软件，测试程包（由文员案责任人报告，指导上传到公文档司网站上供一线人员下载安装）注：这里的人天是软件开发中的常用计量单位，表示一人投入一天。在验收过程中客户再根据实际验收效果确认是否达到预期目标，如果有目标偏差或者市场需求的变动，华为跟客户再根据工作量和优先级协商软件变更实现的时间：如果是低优先级需求，排入后续计划中，原项目计划不做变更；如果是高优先级需求或者会影响其他功能实现的需求以CR（需求变更）单的形式插入现有的计划中，并将当前计划中部分非重要功能放到后续计划中实现。在项目过程中，客户也由于市场需求的变化提出了一系列的需求变更申请，华为侧在接到变更时除了遵循上述原则外，也使用追加计划法，根据工期计划变动情况去修改原有的项36 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究目进度计划。即先根据需求变化以及当前版本的承载能力找出增加需求后会带来的问题和风险；其次确定应采取哪些措施，是对需求优先级重新排序从而重新圈定交付范围还是变更项目交付时间；再次是根据前面的考虑结果修订迭代计划；最后是根据新的迭代计划重新执行。4.3项目成本管理项目成本管理的实质是在确保项目既定功能的前提下，通过对于项目成本的管理去实现项目价值的最大化。项目成本的内涵可以用下面的公式给出更好的描述：V=F/C或者项目价值=项目功能/项目成本而项目功能在一个项目中相对是固定的，所以项目成本成为了左右项目价值的最大因素。即要在项目过程中降低成本，从而提高项目价值。由于软件的特殊性，成本主要是人力成本，而且人力即是成本又是资本。如何使人力资源投入最小而产出最大，成为敏捷交付的成本管理研究重点。4.3.1项目成本估算要想节约项目成本，首先要对整个项目的成本有一个估算，这样才能知道在什么时候该投入多少资源进项目，估算清单如表4-4所示。表4-4项目成本估算的工料清单项目阶责任人输入主要活动输出时间点成本段设计解决方案需求文档特性设计，产品设计2012-7-10~210人天设计师/部算法设计文档，接口012-7-20件设计师文档开发部件开发产品设计软件开发可执行的2012-7-20~2300人天人员文档，接口软件，相关012-8-25文档工具部件测部件测试产品设计单部件测部件测试2012-8-25~2100人天试人员文档，接口试报告，测试012-8-31文档总结文档集成测解决方案产品设计解决方案解决方案2012-9-1~20200人天试测试人员文档，接口中所有部测试报告12-9-1437 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究文档，测试件拉通测总结文档试发布部件责任可执行的走发布流产品发布2012-9-155人天人/解决方软件，测试程包（由文员案责任人报告，指导上传到公文档司网站上供一线人员下载安装）注：这里的人天指的是每人每天的工作量，在软件行业人天是工作量估计的一个基本单位。从上面的估算表可以看出，在项目的不同阶段需要投入的人员是不一样的，这样就可以制定团队成员管理计划，用来确定在项目中哪些角色需要多少人在什么时候加入团队，在什么时候又可以离开团队。这样可以保证人力资源的重复利用，保证各项目组的正常运作，也可以节约人力成本，避免人力的闲置。项目经理作为项目的直接负责人需要对项目成本负责，需要根据成本估算清单严格控制人力的投入。投入的人少了，任务无法按时完成；投入的人多了又增加了项目成本，影响项目的实际盈利。所以项目经理需要建立成本估算的清单，并和各职能部门经理共同组建敏捷团队。4.3.2项目成本控制的手段软件项目的成本主要是人力成本，控制人力成本的途径主要是三类：第一类是提高开发效率；第二类类是减少工作中的无谓损耗；第三类是建立人力资源池。在泰国DTACSDP解决方案项目，我们采用了培训的方式提高开发效率，通过培训可以提高项目团队的综合素质、工作技能和技术水平。同时有助于提高项目成员的工作满意度，降低项目人员的流动比例和人力资源管理成本。由于项目具有一次性和受时间及成本制约的特点，我们在团队内主要采取一些短期性、针对性强且见效快的培训。培训的方式分两种：岗前培训：对团队成员进行一些常识性的岗位知识和敏捷交付知识的培训，比如培训一38 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究些解决方案基础知识，产品和解决方案的设计规格讲解，或者敏捷交付的成功案例学习；岗上培训：主要根据开发和测试人员的工作特点，针对操作中可能出现的实际问题，进行特别的培训，多偏重于专门技术和特殊技能的培训，比如双机培训，某个产品的故障定位方法讲解等等。在泰国DTACSDP解决方案项目中，除了常规的培训外，还有一种是每周收集一次培训需求。大家根据自己的薄弱点来提交培训诉求，通过分析大家对知识点的诉求，来制定一个培训主题。如果在没有人反馈培训需求情况下，就会轮流输出一个培训主题。这个培训主题可以是工作中遇到的问题分析，又或是自己熟悉的领域知识总结。这种搜集性的培训方法，可以促进大家更为自由的交流，对技能的思维发散，也能鼓励大家讲出自己的不足，引导大家共同学习。通过一次次的培训，项目中的新人得到了快速成长，而老员工也可以通过输出培训不断总结自己的经验，实现了团队经验的共享和继承，也保证了项目组内所有成员对敏捷理解一致，为敏捷交付的顺利开展打下了人员方面的基础。在实际的项目执行过程中有因沟通不畅带来无谓的时间损耗，软件项目中需求或者软件实现经常需要多次讨论才能达成共识，而传统的办公方式中项目组成员还是按照各自所属的业务部门安排座位，沟通起来经常需要打电话或者发邮件，这样沟通效率低下。由此诞生了敏捷办公的概念。在泰国DTACSDP解决方案项目我们将项目组所有成员集中在3个敏捷岛办公，敏捷岛样式如图4-3所示：图4-3敏捷岛敏捷岛的优点是集中办公，大家在工作中如果有问题可以随时集中讨论，避免了组织会议的繁琐，提高了工作效率，减少了人力和时间的损耗。同时敏捷岛办公的形式也非常利于召开每日例会，大家在座位附近即可开会，无需沟通预约时间，也不用在会议室中浪费时间39 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究等人到齐。通过每日例会大家可以了解项目当前的进展和困难，遇到问题也可随时提出集体想办法解决。通过每日例会大家可以清晰地勾勒出今日工作规划，这样工作的劲头和效率都会提高很多，所以敏捷岛和每日例会都是敏捷交付过程中的重要方法。软件项目中需求写的清晰与否关系着项目后期开发的速度，如果需求写的不清楚，那么在开发阶段就很容易造成反复沟通讨论，甚至导致项目后期的返工，这会极大地浪费了人力，所以敏捷项目推荐使用用户故事的方式来描述需求。在泰国DTACSDP解决方案项目中，我们要求先通过鱼骨图的方式分析用户的真实需求，再将需求写成用户故事，用户故事至少包含三点内容：谁，要做什么以及为什么要这样做。用户故事完成后还需要召集会议，由设计人员将用户故事的细节向开发和测试人员澄清。这样我们可以很清晰地把握客户需求的核心，以及需求的实际产生来源。在开发过程中开发人员可以很明确地知道需求的实质，不会做错也不会浪费时间在讨论需求方面。因此在迭代开始前分析该迭代需要完成的需求，并由设计人员输出包含完整用户故事的设计文档且向各角色澄清是敏捷成功的重要基础。还有一种常见的减少成本损耗的方法是将软件开发和测试实现自动化编译。自动化编译和测试也是一种可编辑的程序，项目开发者只需要明确自己的要求和主要思路，而其他的细节，如编写，调试，优化等等，这些可以机械化的细节就可全部交由编辑程序来助其完成，并且自动化编译工具中还附带了一个存储编码逻辑思路的数据库，能将各个高手的思路不断总结到数据库中，使其效率不断提高。这种灵巧的自动化程序为项目开发者和测试者节省了大量的编辑和调试时间，又使得编译出的代码具有一致性和可重复性，从而更为容易地发现软件的缺陷。它可以按照计划在人休息的时候自动运行，这样可以充分利用公司的资源，也避免了开发和测试人员间的互相等待结果。自动化编译工具可以替代人工测试的耗时和繁琐，将有限的人力投入到编码工作中，从而提高软件开发测试的效率，从而实现项目组人力投入的减少，节约了大量的时间，降低了项目成本。建立人力资源池也是一种有效的制约项目成本的方法。人力资源池是非职能部门的虚拟概念。就是将公司内部在项目间歇期的闲置人员，按照不同的技能角色和职级进行拉通管理。建立人力资源池可以促进员工互相交流学习，提高自己多方面的技能，而不是只局限于一块，也能为员工提供换岗的机会，打通员工的职业发展通道。当出现紧急项目和人力不足时，可以直接打开资源池这个通道，实现部门人员紧缺时的互相支援，及时支撑项目中因人力不足遇到的困难。降低了项目风险，同时也节约了成本。40 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究4.4质量管理项目质量管理是指为了保证项目质量符合项目质量要求而开展的一系列项目管理活动，其最终目的是为了保证最终交付的产品能够符合项目质量要求。项目质量管理的内容包含了项目工作过程质量的管理和项目产品质量的管理。为了保证软件质量，华为在敏捷项目中有如下质量保障措施和要求：软件开发过程中两个开发人员结对编程，编码过程中通过两个人的讨论和审视可以降低代码中的缺陷，并完善代码中的细节，从初期也就是软件代码开发阶段中就为项目质量打下了良好的基础。结对编程可以实现在编码过程中所有提交的代码都经过交叉评审，再在提交入库之前自己先做一遍测试以及通过软件的检查，能够最大程度上降低代码合入的风险，也能够减少后期问题定位的时间。使用CI工具持续集成，泰国DTACSDP解决方案项目组要求每天下班前将当天编写的代码提交到配置库，并在晚上12点通过工具自动构建和验证，第二天早上上班时优先修改完工具发现的问题，这样通过测试自动化工具充分查找和修改代码中的缺陷，大大提高了版本质量。有了持续集成，代码就再也不用集中到最后合入的时候再检查修改，经测算，同样的代码量原先合一次版本需要3天的时间，现在只需要半天时间就能够完成，效率提升了6倍，所以持续集成为敏捷交付的成功提供了工具和方法上的保障。项目初期通过项目成本估算来确定所需要的人力和物力资源，再通过任命的方式组建项目团队，确保合格和必要的资源，保障项目实施过程中的稳定运行，降低产品质量风险。测试人员在需求分析阶段就开始投入项目分析需求，并根据用户故事编写测试用例，完成的测试用例需要经过开发人员的评审，最后大家公用一份用例，这样的目的是为了让测试人员接触到最原始的需求，根据需求来测试，而不是根据开发人员实现的功能去测试，也是为了避免由于开发人员理解错误而导致的软件实现偏离，这么做也契合了敏捷交付更好地满足客户需求的核心价值，是敏捷交付的一部分。软件在SDV（SYSTEMDESIGNVERIFY）阶段，解决方案中每个部件发现问题数不能大于5个/千行代码；在验收测试阶段，发现问题数不能大于1.5个/千行代码；在版本发布时所有问题要全部改完。测试过程中发现的所有问题要通过问题单管理工具跟踪闭环。其中迭代SDV是针对当前迭代内所有用户故事的完整测试，主要关注功能特性对应的用户场景，该测试是为了保证迭代交付的特性和相关文档可用；验收测试是部署软件之前的最后一道测试环节，测试时会与上下游真实部件对接联调，并通过部分非功能特性的测试来提高产品质量，比如压力测试、性能测试和可靠性测试等。在软件版本转SDV或者验收测试之前，要求先经41 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究过开发人员的内部测试，只有符合条件的版本才能进入SDV和验收测试，这也是为了避免太多低级问题或者阻塞流程的问题进入测试阶段，从而影响测试效果以及耽误测试时间。测试过程中发现的问题需要在开发人员修改完成后交由测试人员再次回归测试，检查问题是否全部修改完成，实现问题的闭环。软件测试就是软件发布前的最后一道质量保障，做好测试工作就是为了紧守质量的最后一道大门，是敏捷交付的重要动作。针对不符合质量要求的版本组织质量回溯，通过鱼骨图的方式，分析出影响软件质量的根因，并在后继版本中改进，避免项目出现同样的问题。除了质量回溯外，每次迭代结束时我们还会召开迭代回顾会议，在会上分析本次迭代做的好的以及不好的地方，优点固化继承，缺点即时改正。在DTAC项目中我们做了三个迭代，每次迭代结束后都会总结，通过一次次的总结，我们在交付过程中发现的不规范问题呈明显的下降趋势，从第一次的11个问题，下降到最后一次的0个问题，不光提升了本项目组的效率和质量，也为公司经验共享和敏捷交付的全面开展贡献了自己的力量，所以敏捷交付的过程中组织迭代回顾是很有必要的动作。敏捷项目拥抱需求的变化，并快速响应需求变更，但是对需求变更的容忍并非没有上限，而是建立在迭代周期内需求稳定和人员齐整的基础上的。敏捷团队在收到需求变化后需要分析变化对于项目的影响，如果需求变化过大，需要和客户协商通过调整需求范围，增加项目工期，增加人力预算的方式降低风险。在泰国DTACSDP解决方案项目中，客户在迭代一和迭代二的软件交付后通过演示发现了多处和原先构想不一致的地方，并对需求做出了修改，需求变更累计78处，在和客户协商后，我们增加了一个迭代，并将原先商定的需求范围和顺序重新做了审视，满足了客户业务快速转型的构想，也帮助客户实现了40%的用户数增长，超出了客户的预期。同时通过新增迭代的方式，使得每轮迭代的工作量在团队可接受的范围内，降低了由于工作量过大导致人员疲劳带来的质量风险。因此迭代交付的过程中客户可以变更需求，这也是迭代的初衷，但是需求变更实现的方式十分灵活，这也是采用敏捷交付方式必须考虑到的部分。4.5项目风险管理由于项目在交付过程中具有较强的不确定性，所以项目在交付过程中存在风险。敏捷交付采用迭代开发模型，通过持续集成、自动化测试、迭代交付等方式已极大程度上降低了传统意义上的软件交付的风险，但是项目面临的风险依然存在。软件开发可分为开发人员、过程、产品和技术四个维度。交付的风险来源主要有：1、人员风险。人员风险主要包括项目组成员之间沟通不顺畅，相互间缺乏协作，对敏捷42 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究缺乏理解，人员变动频繁，人员对业务缺乏理解等。2、技术风险。技术风险主要包括系统架构不稳定，设计不佳，基础版本代码质量过低等。3、产品风险。产品风险主要包括产品最终交付的功能和客户的实际需求不符，软件质量低，工期延误，成本超支等。4、过程风险。过程风险主要包括缺乏详细的迭代计划，迭代需求规划不合理等。从以上四个维度，泰国DTACSDP解决方案项目中采用了如下方式来规避风险：1、人员风险。在敏捷交付的过程中通过在敏捷岛集中办公、每日召开站立会议等方式解决了沟通不畅，缺乏协作的问题；通过引入敏捷教练和学习先进的敏捷实践，加深项目组成员对敏捷的理解；通过开发人员结对编程、内部成员轮流输出培训等方式促进团队成员间的互相协作，并能提高项目组成员的技能素质，通过关键技能的普及也能降低人员变动带来的风险；通过每日构建和迭代发布的可运行的产品让项目组成员能看到自己的劳动成果，从而提高人员的成就感和士气。2、技术风险。敏捷交付通过迭代开发的方式适应技术的变化和演进，避免了传统的开发方法在项目交付初期就完成架构设计，后期无法引入新技术，而且即使设计存在缺陷也无法修改的风险；通过软件重构的方式解决了基础版本代码质量过低的问题。3、产品风险。敏捷交付在每个迭代都能交付可运行的软件，通过给客户的演示和验收，发掘客户的真实需求，避免了软件适合和市场真实需求不符；通过用户故事的编写，确保每次迭代开发的都是客户真正想要的需求；通过持续集成和自动化测试保证软件质量；项目前期输出项目计划，并将项目计划贴在敏捷岛旁边的白板上，以时间墙的形式提醒大家工期是否延误；通过项目成本估算确定项目资源和投入时间，降低项目成本。4、过程风险。敏捷项目在项目初期根据客户的要求和项目组的承载能力制定项目计划，并将客户需求按优先级排序，将重要的和有关联性的需求优先交付，通过迭代交付给客户验收，再将客户反馈的需求变更点排入下一个迭代计划，这样通过一次次的修正和深度挖掘，最终交付客户满意，贴合市场需求的软件。4.6项目人力资源管理项目人力资源管理的主要任务为根据项目的目标并结合项目当前进展和外部环境的变化，采用科学的方法，对项目团队成员的行为、思想和心理进行有效的管理，充分发挥他们的主观能动性，实现项目的最终目标。43 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究4.6.1项目组织结构项目团队是由一群个体为实现一个具体项目的目标而组建的协同工作队伍，项目团队具有临时性的特点，项目团队随着项目的成立而组建，也随着项目的完成或终止而解散，项目成员也会回到原来所属的职能部门。常见的项目组织结构有职能型、矩阵型和项目型。职能型组织结构有着清晰的上下级关系，项目团队易于提高专业技术，但是跨部门协作时非常困难，项目经理对于项目没有足够的控制权，无法协调周边部门共同会战，不适合客户需求多变的复杂场景，也就不适合当前电信软件业的行情。矩阵型组织结构促进跨专业团队的建立，对客户需求反应迅速，但是职能部门和项目组之间容易有资源和任务优先级的冲突。项目型组织结构中项目经理对于项目组有足够的控制权，团队中各成员职责清晰，不同部门间沟通顺畅，且对客户需求反应迅速，但是组织缺乏稳定，成员缺少归属感，且容易忽视技术的传承。软件项目中常常存在用户需求不明确，时间紧迫、复杂度高等特点，需要项目组能够快速响应客户需求的变化，对于关键问题责任清晰，能够快速推动解决。所以我们在DTAC项目中采用了项目组型组织结构，具体项目中的组织如图4-3所示：E2EPMQARDPMTTLOthers产品交付团队，交付团队包括：USEUTEUDE产品SE、产品PM、产品TE图4-3项目组织结构敏捷交付的实际执行者是项目中的各角色，所以这些角色在日常工作中都需要落实敏捷交付的思想。各角色工作职责如下：QA：质量标准和要求的传达和管控，辅助项目经理细化适合项目的质量措施，促进项目的持续改进。44 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究敏捷项目的交付周期相对较短，质量保证活动需要提前并贯彻整个项目交付过程，而项目成员对于敏捷项目中的质量要求往往并不熟悉，需要有人指引，所以QA的职责也需要发生转变，从类似警察的角色转变成教练的角色，帮助团队或个人采用和提升敏捷方法和实践，同时帮助人们重新思考和改变他们以往的开发方式。在实施敏捷交付之前，QA更多的是一个类似警察的角色，主要的工作职责是用质量规范的检查标准、报告之类的材料衡量项目过程以及最终交付文档，从而评估项目交付质量。引入敏捷之后，QA的工作职责也发生了转变，更多情况下是充当敏捷教练的角色，指引团队成员更好地交付项目，比如指导项目团队该如何召开站立式会议，该怎么去做迭代的计划，该如何做持续改进提高质量等等。而且QA往往负责多个项目，还可以提炼各项目中的有益因素，在公司层面推广。RDPM（解决方案项目经理）：RDPM对研发版本的成功交付责任，不用参与软件的实际开发和测试，根据需求制定版本计划，将软件根据需求优先级分解成多个迭代实现。监控、协调解决现场反馈的问题风险等工作，也就是要在对的时间交付出对的产品。所以RDPM需要掌握并管理软件开发所需的资源、时间及功能特性，并在这三个变数互相影响时依据当时的情况判断优先顺序并作出最佳抉择。RDPM负责管理整个团队，协调项目组各角色之间的沟通问题，协助项目组成员解决项目交付过程中遇到的难题。同时在项目的交付过程中，还需要不断地跟踪项目进度，有风险及时协调资源解决。UDE：主要职责是扮演好团队和客户之间的沟通桥梁，输出FRS（技术建议书）向客户传递团队的想法，又能向团队推广客户的理念。任何一个软件项目都是起源于客户的某种需求或者期望，所以UDE的核心价值就是向客户澄清软件的前景以及能给客户带来的价值。同时还要注意识别客户需求的价值以及实现的风险，控制需求范围和节奏，优先实现高价值以及高风险的需求，从而提升客户竞争力，提高客户满意度。该角色最了解客户的需求，并能将需求以技术语言表达再传递给项目组成员，确保交付的软件能满足客户的需求，解决客户的难题。USE（解决方案架构设计师）：组织各产品评审FRS（技术建议书）和BOQ（报价清单）等文档，输出总体技术方案。实现需求到技术实现的转换，并分解到各产品。UTE（解决方案测试经理）：负责组织部件两两联调和联合测试，对项目综合解决方案进行验证，对验证结果负责，从解决方案整体实现的角度对软件拉通测试。测试过程中使用自动化测试工具，提升测试效率。作为质量把关的最后一道关卡，不光检查软件功能是否实现，还需要关注功能实现的合理性。部件PM（部件产品经理）：负责领导本产品的交付团队，对研发项目组的目标负责，做45 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究好产品内部事务协调工作。作为解决方案中的最小团队责任人，需要在团队中落实敏捷交付中的多种措施，比如组织站立会议、推行结对编程、落实持续集成等等。并在每个迭代结束后组织回顾会议，总结项目中做的好和不好的地方，在后继迭代中注意推广或规避。产品SE（软件设计师）：参加FRS和BOQ等文档评审，对产品的技术方案和需求质量负责。根据总体方案分解出部件需开发的详细功能，并输出Story（用户故事），用于指导开发人员开发满足实际需要的软件。产品的TE（测试经理）：监控产品内各部件的测试进度和质量，对产品的交付质量负责。测试过程中协助开发在开发功能代码之前，根据功能点快速新增一个测试，展示新代码的预期作用，找到代码中的方向性问题，从而以测试来驱动整个开发过程的进行。4.6.2绩效考评和激励方案绩效考评与激励是调动项目团队成员积极性与创造性的重要手段之一。绩效考评通过对项目团队成员工作绩效的评价反映员工的实际能力及其对岗位的适应度，并通过科学的理论和方法评价项目成员需求的合理性，再给予满足或限制，从而激发员工不断挖掘自己的能力，充分发挥主观能动性，为实现项目目标而奋斗。员工工作绩效的优劣不是由单一因素决定的，而是公司对员工的激励，员工自身的能力水平和内外部环境因素相互作用的结果。用函数表示如下：P=f（M，Ab，E）其中，P（Performance）为绩效，M（Motivation）为激励，Ab（Ability）为能力，E（Environment）为环境。激励是指员工的激励状态，也就是他们的工作积极性，是员工达成绩效目标的心理基础。激励本身取决于员工个人的需要结构、性格、价值取向等个人特点，其中需要结构影响最大。华为在敏捷项目中多采用长期激励和即时激励的手段。长期激励主要是通过让优秀员工持股的方式，让员工享受到公司发展的红利，能激发员工更好地做好项目。即时激励又可细分为物质激励和精神激励两种：物质激励的主要表现是设立项目奖金，实时激励做得好的团队，并按贡献分配到个人。精神激励表现为在项目实施过程中对表现突出的人员进行通报表扬，并记录正向关键事件提交其考评责任人，作为绩效考评结果的评价依据之一。即时激励最重要的是即时，让员工能在完成项目的同时感受到公司对自己的认可，也能以更饱满的热情投入到下一个项目中去，同时也可以以此牵引没有达成目标的员工继续努力，46 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究在项目中通过努力实现自己的价值，所以即时激励是提升项目组成员士气的一个重要手段。能力是指员工在工作中展现的工作技巧和能力水平，要想提高能力就需要通过培训和交流的方式对项目组中的员工赋能。华为在培训的建设上一直走在业界前列，几乎每周都有各种培训，包括技能培训，敏捷培训，公共基础知识培训等等。同时还为每个新员工配备了思想导师，通过导师们的经验帮助新入职的员工快速融入集体。环境是影响员工绩效的外部因素汇总，包括企业文化、领导作风、组织结构、办公条件等等一切外部因素。为了适应敏捷交付，华为公司采取了如下措施：采用矩阵式组织结构，从组织结构上为敏捷项目的发展提供便利；设立道德遵从委员会，如果员工对领导的做法有任何不满，随时可以匿名举报；公司内推崇奋斗者文化，各项奖励也向奋斗者倾斜，鼓励大家多奋斗；采用敏捷岛的方式办公，在敏捷项目中有问题可以随时交流。敏捷项目绩效考评需要以项目结果为考核依据，存在许多考核难题，华为公司在考评中采用了PBC牵引、半年度考核、集体评议和关键事件法来解决，如表4-5所示：表4-5敏捷项目绩效考评问题及解决方法考核难题解决方法缺乏完整的绩效管理体采用PBC（PersonnalBusinessCommitment个人业绩承诺）的方系来管理和引导员工，从式评价员工个人，员工在考评周期刚开始时确定这个周期内要参而使得考评和激励无法与的项目和完成目标，将项目执行结果和员工在项目中的贡献作正确开展。为员工绩效考核目标的主要组成部分，通过这些承诺牵引员工在项目中做出自己的贡献。由于项目周期有时较长，将考评分为上下两个半年分开考核，同时结合全年考评结果对员在绩效考核周期内有时工施以奖金、配股等激励方式。无法体现出员工的绩效成果。考评结果容易受领导情采用集体评议方式，将相同职级的员工拉通评议，多位主管根据感关系影响，而且碍于情员工在不同项目中的表现使用分级法将员工排序以此给出员工面不容易拉开考评差距。考评结果。使用强制分配法在考评前确定各考评区间比例并严格执行。敏捷项目对于项目成员RDPM对项目成员有考评建议权和一票否决权，员工的考评结的考评约束过少，容易导果发布前要向RDPM公示，RDPM如有异议可以一票否决。致员工在项目中出工不项目关闭时会对项目组的每位成员在项目交付过程中的表现给47 南京邮电大学专业学位硕士研究生学位论文第四章敏捷交付在华为公司项目管理中的应用研究出力。出客观公正的评价，并提交给各职能部门相关的领导和主管。职能部门主管根据员工参与项目的数量，质量及贡献大小进行全面评价，确保员工最终获得公平感而满意最终考核结果。使用关键事件法，对项目实施过程中表现突出的人员进行通报表扬，并提交其考评责任人，作为绩效考评结果的关键依据之一。48 南京邮电大学专业学位硕士研究生学位论文第五章结论与展望第五章结论与展望5.1研究结论本文根据作者本人在工作中的实际应用，分析实际项目的敏捷交付特点，描述在华为软件交付项目中的实际应用，并从中提炼出敏捷交付的关键步骤和实际流程如下：敏捷项目在收到原始需求后需要先根据需求的价值和风险分析需求的优先级，优先完成高优先级高风险的需求，并将需求分为多个迭代，每个迭代都交付一部分可执行的软件。确认需求范围后，设计人员根据需求输出设计文档，供开发人员实现，同时测试人员同步输出测试用例，以此来指导测试。编码完成后开发人员先要完成内部测试，通过后才能转给测试人员验收，测试通过且所有问题单改完后还需要项目组所有成员对软件再一次验收，通过后才能发布版本。项目过程中如果客户要求变更需求，先要识别需求是否属于高价值需求，如果价值不高或者不紧急，可以和客户协商放到后面的迭代实现，；如果价值高且紧急，需要加入当前迭代需求列表并重新排序，再和客户确认是延期发布或是减少当前迭代的需求量。敏捷项目交付流程用流程图来体现如图5-1所示：图5-1敏捷交付流程在确认需求范围后，项目组根据需求规模向公司申请人力，从各职能部门抽调精英，组建项目组，并采用敏捷岛的方式集中办公。开发人员在编码时采用结对编程方式，确保每段代码都经过交叉检视，并使用CI工具自动化构建，每日清理当天发现的问题，这样在后期就不用大范围返工。开发过程中项目组每49 南京邮电大学专业学位硕士研究生学位论文第五章结论与展望天执行站立会议，通报项目进展以及计划。敏捷项目的RDPM需要有考评建议权和一票否决权，这样才能解决员工的考评在职能部门，从而不能全心投入项目的顾虑，同时公司需要设立项目奖金，在项目结束时奖励那些做的好的项目和成员。敏捷交付项目模型表5-1所示：表5-1敏捷项目模型项目主要工需采取行动责任人交付件质量标准阶段作描述敏捷培安排必须的培训，保证项目组部件PMNANA训内所有成员对敏捷理解一致。迭代需根据项目团队开发效率和交部件迭代需NA求分析付时间分析客户原始需求，根PM、USE求列表据需求价值和风险划分优先级，输出迭代需求列表。团队组根据本轮迭代需求规模确认RDPM、项目成NA建团队需要的人员角色和数量，职能部员任命并组建项目团队。门经理项目经理需要具有项目成员迭代的考评建议和一票否决权。前准环境准准备敏捷岛和项目所需的单RDPMNA软硬件环备备板等软硬件环境。境准备就绪。需求分每个迭代开始前分析该迭代USE、SE设计文评审通过析需要完成的需求，输出设计文档档包含完整的story。测试需测试人员进行测试需求分析，测试人关键模评审通过求分析如果团队没有敏捷测试人员，员块测试需要安排开发人员充当测试方案角色，完成此工作。迭代评检查上述的步骤是否已经落部件PM评审结所有交付50 南京邮电大学专业学位硕士研究生学位论文第五章结论与展望审实，质量是否满足标准。否则，论件经过评针对问题制定改进计划，明确审；责任人跟踪落实。团队组建及软硬件环境准备就绪。Story澄开发、测试人员一起，对StorySE、开发Story澄NA清的细节进行澄清，澄清需要包人员、测清的过迭代括：需求实现的所有细节点、试人员程记录开发关键设计、测试方法、关键方（如有法等；必要）编码&走入库之前，代码必须通过工具开发人代码评评审通过读检查和交叉评审。员审记录、CI清零记录持续集每天至少执行CI工具一次，部件CI报告CI问题及成有专人对检查CI工具执行结PM、CI时解决。果，遇到阻塞问题必须第一时专员间解决。每日例项目组每天固定时间召开站所有项会上反NA会立会议，一般不超过15分钟，目组成馈问题项目成员轮流发言，汇报内容员风险等不限于：昨天做了哪些工作，的记录今天要完成哪些工作，遇到哪些问题和困难。技能培找出团队成员技能短板，定期部件PMNANA训组织培训，帮助成员提高效率。记录关在项目实施过程中对表现突部件PM关键事NA键事件出的人员进行通报表扬，并提件51 南京邮电大学专业学位硕士研究生学位论文第五章结论与展望交其考评责任人，作为绩效考评结果的关键依据之一。需求变先分析新接收的需求价值和RDPM需求列NA更紧急程度，如果是高价值的紧表、迭代急需求，重新审视当前迭代工计划作量，采用延迟交付或者变更需求列表的方式优先满足高价值的紧急需求；如果是低价值需求或者非紧急需求，将该需求放到下个迭代实现，并和客户达成一致。自测试开发过程中完成Story所有用开发人自验报达到自验例的测试；员告质量标准转测试时，提供自测试报告，否则不能转测试用例编测试人员根据Story澄清的结测试人测试用评审通过写果，编写Story测试用例，开员例发人员对用例进行评审；开发、测试共用一份测试用例。SDV测测试人员根据开发人员提供测试人SDV测Story级试的自测试报告，确认软件质量员试报告别的基础符合转测试要求后，接受开发用例90%人员提供的版本，进行SDV通过；测试；没有致命测试范围只需要覆盖本次迭严重问代的功能；题。测试发现的问题通过问题单工具跟踪修改完成情况。问题回SDV测试过程中发现的问题测试人DTS报NA52 南京邮电大学专业学位硕士研究生学位论文第五章结论与展望归需要开发人员及时修改，并提员告交测试人员回归测试。验收测迭代版本开发完成，软件会生所有项验收测NA试成一个待发布的版本，自验通目成员试报告过后交由测试人员进行验收测试；测试重点关注问题回归和迭迭代代级别用例的测试；验收测试发现的问题，需要在本轮迭代完成修改，遗留的问题，需要软件经理和测试经理评估确认影响和风险，且必须把这个问题放到下一轮迭代的计划中优先解决。版本发迭代验收通过后版本启动发部件软件、版软件没有布布流程，将满足质量要求的版PM、本特性质量问迭代本发布到现场。RDPM说明题。发布刷新需求列表，确定下个迭代需要实现的需求。迭代回迭代发布后，团队成员召开迭部件PM迭代回NA顾代回顾会议，运用AAR(After顾会议ActionReview)的方法，总结这纪要个迭代过程中做的好的地方和不好的地方。通过预期与实迭代际的比较，找出差别的原因，结束落实具体责任人，加以改善，并在下个迭代加以改进和推广。即时激项目结束后如果项目完成质RDPMNANA励量较高即时发放项目奖金，由53 南京邮电大学专业学位硕士研究生学位论文第五章结论与展望RDPM根据团队成员贡献分配奖金。5.2研究不足与展望1.研究不足（1）首先在实证方面，由于是以自己参与的一个华为大型项目为例进行的研究，敏捷交付的关键步骤梳理更多的是从大型项目的角度考虑，对于快节奏交付的小版本考虑的不是十分充分。（2）在敏捷项目组织结构上更贴近于华为公司这样的大型公司，忽略了小型企业的特点，对于小型企业在敏捷交付中的管理模式研究较少，在一定程度上可能会影响研究结果。（3）对于传统交付模式的研究更多地停留在理论阶段，没有从实际参与的角度来研究和比对其与敏捷交付方式的差异。2.未来研究的建议（1）本次只研究了交付过的一个项目，研究结果的稳定性还需要在更多样本中检验，后继可以适当增加样本数量，并涵盖大中小型项目。（2）可以多分析处于创业期的小公司，针对这类公司研究适合他们的组织结构的敏捷交付方法。3.对敏捷交付未来的展望敏捷交付的发展是一个积累的过程，好的交付方式是需要经过不断的验证和实践，并且不停的持续完善。“物竞天择，适者生存”，世上万物基本定律决定了敏捷交付的发展历程。没有哪一种开发的方式是可以放到任何一个领域都适用的，只有不断的被实践才能有更好的发展。同时这种开发方式要求项目管理者也要不断的积极创新、进取。在通信软件行业激烈竞争和充满无限可能的今天，响应市场变化的能力已成为软件企业的核心生存能力。因此敏捷对于软件企业是一个必然的选择，而非一个可有可无的选项。要真正实施敏捷，从而构建灵活响应的组织，却绝非易事，需要在实践中不断总结，提高，同时更需要从大师们的敏捷实践中获取宝贵的总结经验。敏捷并非灵丹妙药，但会让你成功的机会大增，同时会让你的团队交付更棒的软件。54 南京邮电大学专业学位硕士研究生学位论文参考文献参考文献[1]ScottW.Ambler，MarkLines．规范敏捷交付：企业级敏捷软件交付的方法与实践[M]．机械工业出版社．2013[2]LisaCrispin，JanetGregory．敏捷软件测试：测试人员与敏捷团队的实践指南[M]．清华大学出版社．2010[3]JonathanRasmusson．敏捷武士：看敏捷高手交付卓越软件[M]．人民邮电出版社，2012[4]MikeCohn．用户故事与敏捷方法[M]．清华大学出版社．2010[5]CraigLarman．敏捷迭代开发管理者指南[M]．电子工业出版社，2004[6]MartinFowler．重构：改善既有代码的设计[M]．人民邮电出版社．2010[7]ScottW.Ambler，MarkLines．规范敏捷交付[M]．机械工业出版社，2013[8]王立杰．敏捷交付一千零一夜[M]．电子工业出版社，2013[9]RobertC·Martin．敏捷软件开发——原则、模式与实践[M]．清华大学出版社，2003[10]AlanShalloway，ScottBain，KenPugh，AmirKolsky．敏捷技能修炼：敏捷软件开发与设计的最佳实践[M]．机械工业出版社，2012[11]MikeCohn．Scrum敏捷软件开发[M]．清华大学出版社．2010[12]AlanShalloway，GuyBeaver，JamesR.Trott．精益-敏捷项目管理：实现企业级敏捷[M]．电子工业出版社．2012[13]RachelDavies，LizSedley．敏捷教练:如何打造优秀的敏捷团队[M]．清华大学出版社．2013[14]CraigLarman．敏捷迭代开发：管理者指南[M]．人民邮电出版社．2013[15]EstherDerby，DianaLarsen．敏捷回顾：团队从优秀到卓越之道[M]．电子工业出版社．2012[16]LyssaAdkins．如何构建敏捷项目管理团队:ScrumMaster、敏捷教练与项目经理的实用指南[M]．电子工业出版社．2012[17]CharlesG.Gobb．敏捷项目管理决策：平衡控制和敏捷性[M]．电子工业出版社．2012[18]JimHighsmith．敏捷项目管理[M]．清华大学出版社．2010[19]中国敏捷软件开发联盟ADBOK编写组．敏捷交付知识体系[M]．清华大学出版社．2013[20]MicheleSliger，StaciaBroderick．软件项目管理与敏捷方法[M]．机械工业出版社．2010[21]JamesShore，ShaneWarden．敏捷交付艺术(影印版)[M]．东南大学出版社．2008[22]戚安邦，张连营．项目管理概论[M]．清华大学出版社．2008[23]丁昱．如何提高敏捷交付的响应能力[J]．金融科技时代,2012(6):31-42．[24]王玉芳．应对软件敏捷交付技术探析[J]．数字技术与应用,2012(2):7-40．[25]RexBlack．敏捷方法对测试的挑战[J]．信息技术与标准化,2012(5):14-21．[26]宁德军．敏捷软件交付项目管理及相关工具[J]．项目管理技术,2009(10):3-9．[27]林鑫瀚．敏捷方法与小型团队的软件开发[J]．软件导刊,2009(1):11-26．[28]黄维勇．软件项目范围的敏捷管理模式[J]．项目管理技术,2009(11):13-16．[29]彭志楠．敏捷交付在软件开发中的应用研究[D]．电子科技大学．2009[30]张林，刘德永．敏捷交付在软件产品项目中的应用实践[J]．硅谷．2011[31]张涛．敏捷交付项目的风险管理[D]．成都理工大学．2013[32]周莹莹．敏捷软件开发技术研究[D]．长春理工大学．200655 南京邮电大学专业学位硕士研究生学位论文致谢致谢论文即将完成之际，我首先要感谢我的导师张爽教授。感谢张老师在我攻读工程硕士期间在学术上给予我的悉心指导。张老师认真精心指导我完成论文，并提出许多可贵的修改意见。其一丝不苟的工作作风，渊博的知识，敏捷的思维，开阔的事业及严谨的治学态度和对工作的无私奉献精神，深深地影响了我，也使我受益匪浅。在此，谨向培养、关怀和帮助我的张老师致以由衷的敬意和诚挚的谢意。感谢所有授我以业的老师，没有这些年知识的积淀，我没有这么大的动力和信心完成这篇论文。感恩之余，恳请各位老师对我的论文多加批评指正，使我及时完善论文的不足之处。感谢华为公司给我提供了在公司工作的机会，使我有机会亲身参与敏捷项目的实际交付，并体验敏捷交付的优越，也使得我对本论文的写作有了更深刻的感受。感谢我从事软件测试工作的爱人，从测试人员的角度为我的论文提出了很多专业而有价值的建议，在我三年学习的期间对我的生活和学习给予的帮助和支持。最后再一次感谢所有在毕业设计中曾经帮助过我的良师益友和同学，以及在论文中被我引用或参考的论著的作者。56