敏捷的项目管理十篇

敏捷的项目管理篇1

论文关键词：敏捷项目管理；适应性项目框架；极限项目管理

一、引言

软件开发中既有高风险、高变化的项目，也有目标明确、解决方案明了的低变化项目。根据不同的项目特点，选用不同的项目管理方式是项目成功的关键。敏捷项目管理是应对经常变化的、具有不确定性的软件项目的管理方法。敏捷即灵活性，是动态的、适应于具体情况、迎合变化和自我完善的。本文针对敏捷项目管理中的极限项目管理和适应性项目框架的软件应用对比传统项目管理进行探讨，并提出了适应性项目框架的改进和计划控制的一些建议。

二、敏捷项目管理的概念及起源

敏捷项目管理的概念来源于敏捷软件开发。随着敏捷软件开发的发展，极限项目管理(也称为极端项目管理ExtremeProjectManagement或RadicalPro—jectManagement)和敏捷项目管理(也称为灵活的项目管理AgileProjectManagement)的概念和方法被相继提出，并仍在不断发展。实际上，敏捷项目管理只是各种敏捷软件开发方法相应项目管理的统称，只针对于软件项目，并不是一种通用项目管理方法(也有人提出敏捷项目管理的通用概念，但未被广泛接受)。极限项目管理和适应性项目框架皆源于对DougDe—Carlo于2000年的弹性项目模式(FlexiblePorjectMode1)的改编。而弹性项目模式又来自于敏捷软件开发中的自适应软件开发方法学的启发。现在二者已经发展成为一个通用的项目管理理论。极限项目管理适合于变化大、复杂程度高的项目。传统的项目管理则适合低变化、低不确定性的项目。而在二者之间是适应性项目框架。虽然所有的敏捷软件开发方法都被认为是属于极限项目管理的范畴，但从最近的敏捷软件开发的发展可以看出有些敏捷方法并不全属于极限项目管理的范畴。而且极限项目管理往往由于过于激进，显得不够实际，并不能被高级管理者特别是CIO所接受，且在大型项目中也无法得到有效论证。现在的敏捷项目管理研究大多有转向适应性项目框架的趋势。所以，虽然敏捷项目管理通常指的就是极限项目管理，但它被认为应是包括极限项目管理和适应性项目框架两部分的软件项目管理的统称，极限项目管理又是适应性项目框架的特例。

三、敏捷项目管理的适应性项目框架

通用适应性项目管理框架是以客户为中心、客户驱动的管理方法。极限项目管理是处在比适应性项目框架更复杂，更不确定的高变化情况下的一种管理方法。二者区别在于，适应性项目框架是针对有明确的目标但没有解决方案的项目，而极限项目管理则是针对两个方面都很模糊的情况下的探索式的方法。适应性项目框架只要求客户在每个迭代周期的实施结束后参与项目，而不是全程参与到项目中。

适应性项目框架主要分为定义项目范围、制定项目周期计划、项目实施、客户检查、项目后回顾五个阶段(图1)。

其中项目范围包括项目满意条件、项目概况说明书、功能要求优先排序、中层WBS等。中层工作分解结构只是分解到功能级，而不是任务级，只要可以比较确信地估计每一段功能所需的时间和资源就已足够。因为对于经常变化无法预计的任务，编写完整的WBS完全是浪费。制定项目周期计划是将要进行的下一个周期的详细计划，是带有依赖关系的任务层次的详细实施计划。项目实施阶段包括制定微观进度计划、实现功能、监督并调整实施进度。在这个阶段，取消当前周期和调整计划都是可以执行的，可以减小和避免损失。通过中间三个阶段的反复进行，最后可以实现客户满意的解决方案。

然而适应性项目框架并没有指出当项目出现变化时，如何在时间成本有限的情况下有效完成任务。它还是沿用极限项目管理的方法，制定详细的周期计划，必要时抛弃部分要完成的功能。区别是增加了中层的项目计划。中层项目计划根据时间限制范围内，能够容纳多少迭代周期，并根据特定周期内子功能的数量和质量调整周期时问。虽然也有风险分析，但是并没有在框架内体现并整合到项目周期中。如果根据这个计划确定项目的交付日期，则当变化发生时，很容易陷人传统项目管理的困境，即使采用迭代过程，也很难按期交付。迭代过程唯一能做的就是使变化或风险提前出现，而在以后的迭代周期改进，通常赶进度的方式是加班或者增加资源，这会使成本增加。而且质量的改进也是此类项目的一个不确定因素，这也需要时间和成本。如果低质量的产品延续到项目后期，则由于变化产生的时间和成本的消耗可能是致命的，也会增加维护的成本。适应性项目框架并没有考虑质量改进过程，而且忽视了初始迭代周期的作用。初始迭代周期完成后是调整计划的最佳时期，因为它是实际情况的真实体现，即使以后的迭代周期的实际情况会和初始周期有所偏差，但也不会过于偏离，而且随着迭代的进行，不确定性会减少。所以好的计划是使收益得到保障的首要因素。对适应性项目框架的软件应用改进主要是在过程中强调了风险管理和质量管理，并修改了计划部分，并着重强调了初始周期的作用。影响此类项目完成的最大的风险是需求变更造成的返工成本、时间消耗，需要靠风险缓解和质量控制来共同管理。所以，改进的重点在于适应需求变更。

软件开发项目的适应性项目框架如图2。

图2中主要增加了风险缓冲后的基准计划、功能需求变更周期和质量改进周期。功能需求变更周期和质量改进周期是历时比较长的足够影响进度的活动。功能需求变更周期是由于业务需求变化导致的，可能是特定功能完全重新实施或者改进的过程。质量的改进周期区别于在功能需求变更周期的工作，这是在一定时期后，内部人员根据已完成项目功能的学习和经验总结进行的重新设计，改进已完成工作的质量，或为了适应变化所做的技术改进。风险缓冲后的基准计划是在中层计划基础上增加了风险缓冲的时间，包括功能需求变更周期和质量改进周期的预估时间。分离实施周期和修改周期是因为实施周期的时间和成本的预估是比较准确的，但修改周期的时间和重复次数却难以预测。在两个迭代周期的是个质量改进周期，表明在多个功能周期后进行质量改进。在改进前，需要评估改进的风险，作出权衡。这个周期结束后的产品被认为是一个非完全功能的版本。每个迭代周期还是和适应性项目框架中的一样，包括周期计划、实施和客户检查。另外一个区别是适应性框架只要求客户在客户检查点上参与，而这里要求全程参与，至少应在项目的前期阶段全程参与需求分析，目的是在一定程度上稳定需求，如果已经完成的功能再出现需求修改，付出的成本和时间将会大得多。如果出现了范围的变更则和客户协商调整基准计划。

四、基于敏捷方法的软件项目管理的计划与实施

(一)项目计划与风险

由于项目过程由传统的详细的需求计划的单一过程变成短的时间区间的具有反馈的多次迭代过程，并且为了对变化具有适应性，敏捷项目管理的计划方法分成详细周期计划与风险计划和质量计划结合的两种分层计划。

项目中的风险分为两种，一种是必然要发生的常规风险，一种是不确定的致命风险。前者可以通过风险缓解解决，后者则需要风险缓解和风险转化共同解决。在变化陛比较强的软件项目中，需求变更必将发生，这是软件项目所面临的主要风险，计划中加入需求变更周期的缓冲时间可减小项目的成本风险。

(二)极限项目管理计划与时间预测

极限项目管理是一个无基准计划的过程，没有时间和成本的限制，利用数量不定的短周期不断迭代，最终完成项目，或者在完成前，项目就被取消。传统的项目管理计划方法在此时起不到太大的作用，一般采用跟踪团队的开发速度和剩余的功能点来进行管理，只制定迭代周期内实施的计划。

图3是Bum—down图，显示的是每个月后剩余的功能点数目。虚线1是要在12月完成的项目的计划线，虚线2是实际工作后的趋势线，这表明可能完成的日期。2月剩余的功能点多于初始点，是因为增加了新的功能。可以看到这并不能确定交付的日期，只能作为参考。．

(三)基于敏捷方法的软件开发计划

极限项目管理在某些极端的情况下确实很有效，比如新技术产品的研发。但是大多数软件项目的技术复杂度不是很高，或者曾有过类似的项目经验，项目的主要不确定性是业务需求的变化等，并受到时间和成本的限制，这些项目的重点是得到反馈并改进。

在这种情况下还需要预估时间，并制定相应的计划实施。软件项目由于成本与开发人员的多少和开发持续周期密切相关，所以时间通常是软件开发项目的一个重要衡量指标。使用改进后的自适应项目框架，利用需求优先级的功能排定和需求成熟度分析进行时间缓冲，可以很好地适应这种状况。

1．需求的优先级

根据客户的要求排定功能的优先级。将有则更好，没有也不影响系统实用性的功能放在最后实现，是时间紧迫项目通常采用的方法。在进度延期的情况下，舍弃这些浮华的功能，可以确保项目按期完成，也可避免项目因增加了一大堆客户要求的功能而陷人遥遥无期的悲惨境地。

2．需求的成熟度(见表)

需求的成熟度指的是需求的稳定程度。由于软件项目的范围通常是变化的，与客户洽谈并确定各个功能的需求成熟度并列表，既可以了解客户对新业务需求的理解程度，也是在需求变更时和客户谈判的依据。需求的成熟度越高，需求的变化程度越低，对需求变化的缓冲也就越小。变化的时间损耗指的是相对于功能实施时间的百分比。因为对原有功能的变更通常会利用已有的模块，相对时间较短。变化的次数是指决定变更迭代周期的实施次数。

3．需求缓冲的计算

变化的权值=变更的时间损耗比x变化的次数；

功能的需求变更时间缓冲RAT=功能的实施时间x变化的权值；

每个功能变化的权值为变更的时间损耗比乘以变化的次数。用此功能的实施周期预估时间乘以变化的权值则得出每个功能的需求变更的可能损耗的时间。将每个迭代周期内所包含的功能的需求变更时间相加，则得出了此迭代周期的需求变更时间，即需求变更周期的时间之和。

4．计划的制定

计划时首先确定出项目范围后，创建出中层WBS(工作分解结构)，并以此确定项目功能的优先级，并根据风险分析确定每个功能的变化权值。确定好每个迭代周期时间，并根据总时间、成本的限制和功能优先级制定好功能的实施迭代周期数量及相应完成的功能制定计划。将功能需求变更周期和质量改进周期也考虑到计划中。由功能变化权值、功能实施周期时间和迭代实施周期内的功能数量决定的总的功能需求变更周期的时间，将时间缓冲合并人计划中。

确定功能周期及修改周期重复的次数定期进行质量改进，一般是3到6次功能周期后进行一次质量改进，改进的具体内容则是实时制定。如果采用的是全程客户参与的方法，则需求成熟度会随着项目的进行趋于稳定，后期实现的功能可不设定需求变化的缓冲时间。由于大多数软件应用开发的变化没有在极限项目中的剧烈，即使增加了新的功能，修改非任务级的中层计划也比较容易，而且变更只在用户检查阶段实施。大多数情况下，在项目缓冲允许范围内的延迟不需要调整计划。Bum—down图可作为一种辅助的管理方法。在短的时间周期内(一般是两周到五周)，项目可以认为是低变化的，所以可以制定好将要进行的下一个迭代周期的详细计划。周期详细计划由于时间周期比较短，可不用关键链法。

由于软件开发项目的大多数模块都可以并行开发，并行的限制只受限于开发人员的数目，并且周期的时间都很短，所以在周期详细计划中使用关键路径并不能收到预期的效果，在项目实施中可应用的是关键链的项目缓冲机制。

由于敏捷项目管理的迭代性，根据已执行完的第一个迭代周期或前几个周期，可测量出比预估更有效的开发速度，可判定预估的准确度，从而调整基准计划。

敏捷的项目管理篇2

关键词：敏捷项目管理 适用性分析 匹配

敏捷项目管理的概念与发展

“敏捷”（Agility）（高歌等，2008）是一种敏锐、快捷的适应发展变化，集模块化与智能化于一体的一门社会工程学。它旨在提高对快速变化、不确定程度高的研发过程的掌控力，强调可运行成果的快速交付而不那么看重中间产品，以客户需求为核心来达到项目管理中“供需一致”的目标，消除以往项目实施过程中的沟通不畅、团队合作缺乏共识的问题，使得项目实施过程数字化、模块化、标准化、流程化及灵活化，促进项目目标得以完成。

“敏捷开发”（Agile Software Development）源于软件开发方法，是具体通过项目模块化、人员交互和迭代付实现项目进行的高效性，是在采用循序渐进的开发思路过程中提炼出来的一种管理理论和方法。

随着“敏捷开发”在软件行业的成功应用，学者们相继提出了敏捷项目管理（Agile Project Management）、全面项目管理（TQM）及极限项目管理（Extreme Project Management 或Radical Project Manage ment）的概念和方法。然而部分极限项目管理的思想偏于激进和脱离实际，促使适应性项目框架更顺应CIO的选择，利用其协助项目团队的独特优势与当今这个需求多样化、竞争激烈化的环境进行“对抗”。敏捷项目管理发展过程如图1所示。

敏捷项目管理可行性探讨

在敏捷项目管理理论的深化发展及广泛适用的同时，其通用概念也被提出。而关忠诚等（2005）在《基于敏捷方法的软件项目管理研究》中提到，“敏捷项目管理只是各种敏捷软件开发方法相应项目管理的统称，只针对于软件项目，并不是一种通用项目管理方法”。极限项目管理起源于Doug De-Carlo定义的对敏捷软件开发中的自适应软件开发方法学的更深层次的运用弹性项目模式。现阶段，一种结合两者的通用管理思路在多种项目管理中已取得显著的成效。基于上述两种观点的分歧与矛盾，本文主要针对这两种对立的观点进行了分析，探讨有关敏捷项目管理的适用性。

哲学视角下的敏捷开发

敏捷项目管理作为一种针对解决项目复杂度高、稳定性差以及风险强度大的项目管理理念，其在本质上论证了必然性和偶然性的统一。敏捷项目管理中的必然性与偶然共存于同一系统之中，即存在于标准化与灵活化之间的辩证关系，在关系中执行者能够发现偶然中的必然，并实现两者之间完美的转换。在新产品的研发中，以适应性项目框架为基础的敏捷项目管理将新产品研发的偶然性与必然性紧密结合以提高其研发的成功率正是敏捷项目管理哲学意义的完美体现。因此，笔者倡导敏捷项目管理是一种理念，而不仅仅是一种新产品开发或项目管理方法。它在贯穿于项目实施的过程之中，并起到了指导性的作用。

敏捷项目管理的实践可行性研究

（一）项目管理的生命周期

管理的过程通常是由五个不同的项目管理具体工作过程构成的一个完整的项目管理生命周期（田政，2001）。图2给出典型的项目生命周期阶段以及具体管理工作过程为：起始阶段亦即需求识别阶段，进行项目活动的定义以及决策，制定切实可行、高效的进度管理计划，探索项目实现的价值和意义；计划阶段，界定项目具体实施的各个阶段的起始时间、工作内容、工作目标；完成阶段性任务的策略与方法以及所需要各种资源，例如保持项目实施在整体战略上的优先权、人才的挖掘及获取、物资条件的供给、财务政策的支持，及具备高效、合理的应急措施等，是制定完整方案的阶段；实施阶段，组织与协调团队的人力资源，做到人岗匹配、人尽其才，采取有效的激励措施以达到既定的工作目标；控制阶段，在项目的控制过程中拟定、编制并审核项目进行情况的测量标准，客观的认识项目进行实际状况与目标要求的差异，发现问题的所在，探求问题的根源，最终找到正确的方法解决问题并提出相应的控制机制，以达到防止在后续的项目实施过程中重复出现影响项目顺利进行的目的；结束阶段，通过制定项目交付阶段性成果的审核制度实现对项目各阶段以及交付成果质量的把控，促使项目顺利结项。

（二）敏捷项目管理的五大模块

构成敏捷项目管理的重要的五个阶段概况为如图3所示。

构思阶段：完成对新产品的需求分析、产品形象及功能的构思。这个阶段，我们要回答如下问题：客户对产品的功能及形象的要求是什么；项目进行过程中会遇到的阻碍有哪些；如何选择参与项目的执行人员；阶段性成果交付的内容与模式。

预测阶段：指定产品，指定的条件是基于功能的计划、进度标杆和迭代流程的确定。 敏捷项目经理应该鼓励团队成员不断学习，对成员进行绩效评价和激励。可以把推测活动划分为两类行动：

一是功能分解结构（FBS），包括产品功能规划、功能模块说明书、功能检测制度。二是迭代计划：计划、进度标杆和迭代流程。功能导向的规划使团队与客户可了解产品。当迭代和标杆交付成果结束时有更加切实的规划，以保证计划与产品能够与项目进行中得到的反馈信息相呼应，从而不断地优化项目实施过程。

探究阶段：主要实现在短期内对项目进行的可交付成果进行测试的功能，通过不断地检测与改进，减少项目的不确定性，达到降低风险的目的。同时利用新尺度，帮助团队成员清楚地表明和理解目标与限制、团队的有效沟通、决策流程的顺利推进是项目经理的重要目标，这样才能确保获得适当的反馈信息并将信息融入到下一阶段中，以便于再减少项目偏差的出现。

适应阶段：在关注产品、项目以及团队的评价的同时，也应采取适当监控措施，包括项目、人员、产品等进行团队的绩效评价。对项目进行的实际进度、交付结果的质量、团队配合的默契度进行考核和相应的调整。

结束阶段：按照项目初期的计划及时的终止项目，就项目成果与客户进行沟通，在必要时对项目成果进行修改直至客户满意为止。最后，在项目团队内组织交流学习并举行项目竣工庆典。

（三）敏捷项目管理的适用性

通过对一般项目管理和敏捷项目管理的进行深入实质分析发现，敏捷项目管理可以完成对一般项目管理进程中的“对接”（见图4）。

“推测-协作-学习”模式是敏捷项目管理发展的根源。敏捷项目管理经过发展形成由构思、预测、探究、适应、结束五大模块所构成科学的管理流程，其重点在于及时交付和灵活调整。“构思”对应传统中的“起始”部分，为项目制订了正确的方向，是项目顺利完成的指明灯。“预测”替代了传统的计划阶段，所表明的不确定性对于风险大，不确定性高的项目起着关键作用，其暗示着的灵活性是必不可少的。“探究”替代了传统的管理模块阶段，体现了其非线形、平行的模式特点。因为不能对结果进行完全的确定，探索阶段更多的表现的是探索性的而非确定性的结论。通过迭代交付的方法保持项目进行的推动力，增强了项目对外界环境的抵抗力。“适应”阶段是对团队的人力、物流进行密切关注，从而适应当前情况，充当了在一般的项目管理过程中的控制职能。最后，敏捷项目管理的“结束”阶段系统的完成收尾工作，传递知识并进行庆祝。从管理过程中各个方面的相互联系来分析，如图5所示。

项目最大的特点是一次性，每个项目都不会完全相同，因此针对具体项目管理的方法会有所不同。但项目生命周期模型向我们证明了项目管理的共性，即先以简单的方式分析项目，从全局角度把握项目，并在项目管理的过程中强调沟通与合作。这一点与敏捷项目管理的核心思想相吻合，形成了敏捷项目管理作为一种普遍的项目管理理论的基础。此外，通过对项目生命周期各个阶段具体工作以及对敏捷项目管理实施的一般过程进行分析和解释，明晰了项目管理的实质。同时，也充分证明了项目实施过程与敏捷项目管理的阶段理论在项目管理上可以实现“对接”。

结论

本文认为，敏捷项目管理在软件开发应用过程中的敏捷性主要体现在周期性、模块化和迭代交付等方面，其主要原因是软件开发过程具有的特性。但本文从敏捷项目管理的实质出发，认为敏捷项目管理是一种针对复杂多变的项目的管理理念，通过这一理念所发展而来的方法有许多种，在具体的项目管理过程中，可以根据各行各业所具有的特征来选择运用敏捷项目管理的方法和手段。敏捷项目管理是价值、原则和实践的结合，是规划和指导项目流程的迭代方法，在测试阶段之前经常直接与最终用户对话，从产品用户获取反馈得以实现递增式的交付方式。

参考文献：

1.高歌，王天勇，杨晔.敏捷项目管理及实施方案研究[D].吉林大学博士学位论文，2008

2.关忠诚，程刚.联合品牌战略研究[J].重庆大学学报（社会科学版），2005（6）

3.柯闻秀，曲红.敏捷项目管理哲学思考[J].科技管理研究，2009

敏捷的项目管理篇3

敏捷开发在软件开发中已经被越来越多人接受、应用,越来越多开发者享受到了敏捷开发带来的软件开发效率的提升和软件质量的提高。在云计算和虚拟化技术日渐普及的今天,敏捷开发也开始向这些新技术靠拢。

基于云平台的敏捷开发

所谓敏捷开发,是一种以人为核心,迭代、循序渐进的开发方法,能够降低开发成本、提高软件可靠性、缩短开发时间,并且确保应用软件真正有助于用户。敏捷开发方法强调适应性而非预设性,还强调面向人而非面向过程,完全颠覆了传统软件开发方法。

关于ThoughtWork敏捷开发的好处,一位开发者这样说:“ThoughtWorks教会了我用敏锐的眼光去观察身边日复一日的软件开发活动,在平淡之中追寻软件开发的乐趣,在惯性思维之外取得突破。”致力于推广敏捷开发的IT咨询服务提供商ThoughtWorks总结出了一种高效的项目启动方式――QuickStart,用以确认在项目开始之前理解项目的关键驱动因素。

谈到敏捷开发的新的发展趋势,Thoughtworks创始人Roy Singham在接受本报记者专访时指出,云计算和虚拟化技术对敏捷开发产生重要影响,正成为敏捷开发的重要发展趋势。

Roy Singham认为,这一趋势源于客户的需求。他解释说,尽管采用敏捷开发可能把软件开发过程从6个月减少到3个月,但是对一些大型企业来说,它们还需要再花3~4个月去测试和部署。它们认为,整个项目的实施过程还应该缩短。

与此同时,有调查显示,76%的CEO认为IT管理和维护人员对企业的技术创新和客户价值没有任何贡献,现在有了虚拟技术和云计算,他们不仅非常希望将开发环境迁移到基于网络的云平台,还希望将后期的集成部署、安全管理和测试也外包给云平台。

Roy Singham透露,Thoughtworks正在帮助企业将项目整体迁移到云平台。考虑到在云平台上业务和安全的复杂度,Thoughtworks在这方面开始的尝试可能会是一些偏互联网性质的项目。

中国市场还需培育

遗憾的是,尽管我国软件产业普遍存在对大型软件项目管理不善、项目不能按时交付等问题,但是我国软件企业对敏捷开发的认知度和接受度却并不高。作为敏捷开发的倡导者和实践者,Thoughtworks中国的业务主要是针对海外的。

谈到敏捷开发在中国的发展,Roy Singham指出,他了解到中国软件企业中的一些开发人员已经认识到了敏捷开发所能带来的种种好处,但是企业的管理者却往往对敏捷开发缺乏了解。这就很大程度上影响了敏捷开发在中国软件企业的推广。因此他认为,在中国,首先要让管理者充分认识敏捷开发的好处。

敏捷的项目管理篇4

推动敏捷开发普及

应该说，敏捷开发方法的流行与各种各样的咨询和培训机构的工作密不可分。

Scrum Alliance是敏捷开发发起人之一Ken Schwaber创办的一个Scrum咨询公司。除了组织会议和提供关于Scrum的相关咨询服务外，Scrum Alliance公司最大的特点是开创了Scrum认证系统，用以对Scrum人员进行认证。该系统分别有培训和认证两个过程。它有五种类型的证书: Scrum专家（CertifiedScrum Masters）、产品所有者（Product Owners）、Scrum行业者（Scrum Practitioners）、Scrum教练（Scrum Coach）和Scrum培训师（CertifiedScrum Trainer）。Scrum培训师证书是提供Scrum顾问给团队进行Scrum培训和认证的。Scrum专家产品所有者和Scrum行业者证书则是侧重于对团队进行Scrum项目的实际应用培训和认证。这些证书已经获得软件行业的广泛接受，每年有成千上万的人在培训和认证过程中获得提高并为公司带来效益。

另一个重要的组织是敏捷联盟（Agile Alliance）。敏捷联盟是一个由对敏捷开发感兴趣的个人和公司组成的联盟。该组织的主要活动包括出版刊物、组织讨论小组、组织会议等。其中一个比较重要的会议是一年一度的敏捷会议（Agile Conference），每年都会吸引世界各地从事敏捷开发的研究人员、项目经理、开发者、公司和顾问团等前往参会。 许多在会议上提交的文章会被收入并发表在IEEE相关刊物上。

此外，商业巨头关注敏捷开发也带来了示范效应。Google、 Yahoo、IBM 和Microsoft 使用敏捷开发已经很多年。他们通常选择某几个开发团队来试用敏捷开发，然后将开发经验推广到其他的开发团队中去。

在相关组织和大公司的带动下，很多中小型软件公司开始把开发团队完全转型到敏捷开发模式下。根据Forrester公司调查，在美国和欧盟对敏捷的认识和采用率以每年50%左右的速度增长。可以说，敏捷方法已经过了创新（innovators）和初期采用（early adopters）阶段，进入早期多数（early majority）阶段。很显然，敏捷方法将在早期多数阶段加速采用率的增长势头，并被更广泛的企业所接受。

敏捷在中国

敏捷开发在中国进展稍慢一些，中国的软件开发群体在近几年才开始使用敏捷方法，而且大部分使用敏捷方法的公司都集中在外资跨国企业如IBM、Sun以及一些软件外包公司（如文思创新）等。同时，也有一些比较前沿的国内公司（如腾讯）等率先采用敏捷开发。总体来看，中国的敏捷开发还处初期试用阶段。尽管如此，我国的软件工业中仍然存在着敏捷方法迅速发展的契机．

首先，在中国大规模的软件公司较少，大多数开发团队都不会超过200人。这些团队大多采用手工作坊的工作方式，开发方法往往取决于技术领导的个人风格，这种方式有几个缺点。首先，这样的团队绩效和产品的质量不稳定。其次，这样很难形成有凝聚力、自我管理的团队。特别是一旦团队的核心人物离职，整个团队可能就要去适应另一种开发风格。第三，这种团队往往也缺少一种有序自觉的学习和自我提高机制，而开发效率的停滞就是对人才的浪费和不负责任。总之，这种方式的最大缺点就是质量和效率的随机性和不稳定性，很难和职业化的软件开发竞争。不过，这种开发团队在转向敏捷开发的过程中反而更容易，因为他们没有成型的模式，没有过多的包袱， 采用敏捷开发风险更少。

其次，由正在发生的经济危机引发的大规模的裁员和人事的冻结让这些公司感觉到资源的有限。在这种情况下，对现有资源效率的提高将对提高公司的竞争力和长期的发展起到更为至关重要的作用。而敏捷开发会为中国的软件服务和产品带来我们最需要的质量和效率的提高。

第三，中国文化中存在许多适合敏捷开发的元素。《敏捷宣言》的第一条便把人的协作放在了规程和工具的前面。在中国文化中，管理是以人为核心而非规程和条例，这符合敏捷重视人多于过程的精神。还有，敏捷开发对传统的西方式由上至下、多层次的职业管理提出了挑战，敏捷要求管理层更简洁并更注重服务于团队。而中国企业的项目管理并不是很职业化，从这种起点转向敏捷可能更直接、简单。另外，中国的很多软件开发人员习惯于几乎无计划、随心所欲的代码编写。这在西方被称为牛仔编码（cowboy coding）。这种风格离敏捷的距离似乎比应用瀑布模型或CMMI标准的专业开发风格更小。许多其他的中国文化因素，比如关注细节、节俭以及面对变化的适应能力等都为敏捷开发在中国软件业的发展提供了有力的支持。

可以说，独特的中国文化和管理现况为敏捷开发的发展和实施提供了先天的条件。如果中国的软件业界能够在敏捷开发的理论与实践方面迎头赶上并有所创新，敏捷开发一定能为中国的软件产业效率和质量的提高，和进入甚至领先国际市场起到决定性的推动作用。我们相信，敏捷在中国很快就会迎来一个迅猛的发展时期。

链 接

敏捷开发的有关工具

为方便敏捷项目的管理，许多公司推出了针对敏捷开发的项目管理软件。其中比较流行的商业软件有ScrumWorks、VersionOne、 Rally等。这些工具遵循传统的软件产品发展模式因而积累了众多的功能，大多数敏捷团队可能只会用到其中少数的一些功能。其他还有很多类似的工具, 比如ExtremePlanner、 TargetProcess、Scrum For Team System、 JIRA等等。在开源工具方面，比较流行的有XPlanner、 XPWeb、Trac等。这些工具本身和敏捷开发并无直接联系，但进行敏捷开发时可以应用。笔者所在的合络众成公司也开发了GScrum，这是一个基于WEB和RIA (Rich Internet Application) 的敏捷项目协作平台，侧重于团队的合作和沟通，它把Scrum和精益（Lean）开发结合起来，团队可以针对不同的项目调整使用不同的方法。它的功能集中而不繁杂，简单易用。同时，GScrum还能让有协作关系的不同公司和不同地域的团队在同一个项目中安全方便地合作，这对软件公司和客户以及伙伴公司的协作会有很大的帮助。（文/刘松）

作者简介

敏捷的项目管理篇5

敏捷开发到底是一座丰碑还是墓碑？凭什么让高层管理者相信这次敏捷能推成功，给公司带来价值？怎样推敏捷才能更符合事理，不让自己成为先烈？

方法是大家都知道的方法，人还是原来的那些开发人员，但确定了正确的目标和定位，制定合适了实施策略后，加以变革，辅以激励，广联达的敏捷故事告诉我们，好拳法很重要，但会出招更重要。

做软件开发的圈里流传着这样一句话：刚进项目的时候，每个开发人员都想把项目树立成一座丰碑，但做着、做着却发现那是一座墓碑。在敏捷开发日益盛行的今天，到底应该如何推行企业级的敏捷开发？广联达软件股份有限公司（以下简称广联达）推行敏捷开发的故事，告诉我们丰碑和墓碑往往就在一线之间。而老板支持、员工买账、适时分步变革、沟通与激励配合则是跨越成败交界线的关键要素。

加班似华为 合唱《满江红》

广联达是一家致力于建筑信息化的软件公司，成立于1998年，聚焦于行业客户，经过十多年发展，产品的种类和数量从单一的预算软件发展到工程造价管理整体解决方案、工程项目管理整体解决方案、招投标管理整体解决方案、教育培训四大业务的30多个。

2008年，全球遭遇国际金融危机的时候，广联达的年产值2亿多元，有3条产品线（2条工具软件、1条管理软件），4个主要产品，有28万多使用者，有160名研发人员。

“那时，我们产品的BUG比较多，稳定周期相当长，一般正式的产品的稳定周期为两到三个月。产品开发完了，测试人员却不敢懈怠，得不断测试，不然不敢交付用户。而且，需求变化快，产品后，马上面临修改。答应客户的产品交付时间一推再推。公司第一次实施 IPD （集成产品开发方法）后，没有收到明显的效果，大家对开发方法不再有信心，研发能力已经无法支撑公司去把握新的市场机会。我们的程序员很难有休息的时候，加班强度非常大。”广联达研发副总裁卢旭东向记者回忆说。

即使程序员满负荷地加班加点，广联达当时的产品发版情况还是很糟糕。“当年我负责一个产品推迟了一年才上市！这给公司经营带来的影响是难以想象的。”因为不能保证在可预知的时间内发版，研发部和开发部的冲突非常激烈，当时研发部承受着非常大的压力，卢旭东笑称自己现在稀松的头发就是当时严重掉发所导致的。心情有多悲壮？卢旭东回忆，年底公司年会上他们项目组表演的节目就是合唱《满江红》，唱到一半项目经理就哭了。

“当时我们能承受的压力已经到了极限。普通的激励已经不起作用了，开发的兄弟跟我说‘让我睡觉就行了’。可想而知，当时的环境多么迫切地要求我们必须做出改变。”

但到了2010年，广联达的这种情况却发生了翻天覆地的变化：公司5月在深交所成功上市，预计年产值4亿多元，主要有四条产品线、7个主要产品，种类涵盖管理类、工具类、互联网类，有33万使用者、 280个研发人员，产品的周期稳定，能全面满足市场营销计划。“从2009年开始，我们全面按100%计划交付，并且有的工具类产品甚至做到了提前交付，甚至还有27 个研究、孵化类产品项目积极探寻市场机会。”

是什么让广联达的软件研发发生逆转？

答案就是敏捷开发。

“敏捷不仅在产品研发管理中实施，其核心价值观更进入了公司日常管理的很多环节包括产品孵化、流程改进等。”卢旭东说。

关键是定位 其他都是浮云

推行敏捷开发的企业很多，但成功的却寥寥。老板支持、员工买账是成功推行敏捷开发的重要前提，广联达是怎样做到的呢？是如何说服所有人愿意“冒险”变法的呢？

“目标和定位是最关键的，其他都是浮云。出发点不同，想的办法就是不一样。我们并没有盲目地去学习、推行敏捷，而是先研究敏捷与所有人的关系。”卢旭东说，“我们用市场营销的思路，认真研究了对我们的最终客户（软件用户）公司高管、产品线人员（研发人员）而言，推行敏捷对他们到底意味着什么，他们会得到什么、要付出什么。”

敏捷推进小组分析，最终客户大多不愿意参与产品的研发，只关心产品能否按时按量交付，认为提供高质量的产品是广联达的份内事；公司管理者关注的是公司的整体运营，如何开源、节流，如何实现企业运营高效率，但比比皆是的失败案例也让他们对推行敏捷心有余悸；产品线的人关注的是单个产品的准时交付，要推行新的工作和管理方法，他们担心会因为改变工作习惯而降低生产力，会产生抵触；而从研发管理的角度看，敏捷推进小组他们并没有实施敏捷、推进自动化测试的经验。

“用户的需求不断地在变、一直在变，甚至快于开发，而且，用户自己也不清楚他要什么，那怎么办？我们必须快速满足客户，甚至牵引用户的需求。要做到如此，必须推行敏捷，具体的实施步骤是……”计算机专业出身，大学课程只有软件工程得了90分，其他课程只是及格的卢旭东用自己对敏捷的理解，用管理者听得懂的语言来解释敏捷――它是应对激烈竞争和快速需求变化的一种商业模式而非产品开发方法。

“我们将所有利益相关者都视为客户，把敏捷推进小组定义为一家为客户提供敏捷咨询的商业公司，最高目标就是通过尽早和持续地交付有价值的软件来满足客户，总体规划、分步实施、持续交付价值。我们认为敏捷的核心思想就是精益，以保证目标和客户价值为基础，不断追求最佳的投入产出比，将优秀管理实践和开发实践相结合，以人为本，持续优化。”卢旭东说。

清晰目标 量化需求 先试点

看得懂燃烧图、会极限编程、知道Scrum，即便是敏捷开发的“大牛”，也并不意味着能带领整个团队做到企业级的敏捷开发。后者除了需要有对敏捷的正确认识，更重要的是有正确的实施方法和策略。

广联达的一套做法是，先分析客户（所有利益相关者）的需求，并具体化、量化成可衡量的目标，慎重选择试点，通过学习和实验建立对敏捷的认知，通过测算投入产出比说服客户接受试点，推进小组全力参与，形成结果后进行总结并与客户确认价值，之后再进行小规模推广，同时持续对其他团队进行辐射影响（分享方法和经验），持续交付价值并持续与客户确认，巩固成果，最终促成客户产生自适应团队，进入持续优化的良性循环。

“我们首先要清晰地了解客户的需求：最终用户要什么，公司想要什么，产品线想要什么，程序员要什么，把答案列清楚之后，再去跟他们确认，问这些是不是他们想要的，能不能量化。这样实施的目的和目标就很清楚了。”卢旭东说。

广联达有一个负责持续推进公司开发方法改进的固定组织――PMO（项目管理办公室）。他们以PMO为基础组成3～5人的敏捷小组，选择一个小的项目为试点。“我们做第一个敏捷实验时，我和4个部门经理，扎到一个项目里做了4个多月，最后成功了。”卢旭东介绍说。

广联达的企业文化很开放，敢于变革，这对他们推进敏捷开发非常有利。对于文化不那么开放的企业，卢旭东建议要首先保证项目成功，让最直接的客户受益，再跟公司说应该怎么推广敏捷，以点带面，发散辐射，激发不同产品线的员工的内在驱动力，从而产生规模效应。这个过程中数据、知识的积累很重要，方法要可传承、可复制、可持续优化，而且最重要的一点是坚持，坚持变革，坚持共赢。

从变革与我何干到全部买账

广联达是如何试点第一次敏捷，并推广变革的呢？广联达的方法是搞一次目标统一行动，用‘意义’来领导，让大家关注目的。

现在做软件开发方法有很多派系，有人支持传统瀑布式，有人支持敏捷，有人支持CMMI，有人支持ISO9000。程序员都各有所好，各持己见。“我们的做法是用变革管理的思想来指导，关注目的，用“意义”来领导。首先，明确我们共同的目的是什么，哪种方法能实现目的。没有哪种方法是绝对最好的，互补的和适合的是最重要的。我们在公司内部做了关注目的和目标统一的活动，不管你是敏捷派、我是CMMI派，到公司就是一个派。不管是什么派，只要能融合在大平台下，解决问题就成。”

还有一个重点是找到目的和敏捷的契合点，做真正需要的，而不是自己感兴趣的。有的程序员对敏捷非常热衷，对某些具体实践活动（比如自动化测试）非常感兴趣，只做他喜欢的，并不关注项目目的。卢旭东提醒说，这样的人和想法其实是非常危险的。因为企业推行敏捷不是某一个人的事，必须要结合客户需求做产生价值的事情，做支持企业成功运营的事情，才能让大家觉得靠谱，而不仅仅依靠某些人的个人兴趣做事。

推行敏捷是个不断变革的过程。在变革管理方面，卢旭东深有体会。他认为只要按照正确的方法，任何变革都可以慢慢让所有人接受。广联达的实践将变革管理分成选择变革、准备变革、为成功变革做计划、实施变革以及测量和持续变革五个阶段。

做变革准备有两个重点：一是消除“与我何干”的想法，让所有人都知道变革对自己的意味着什么；二是“买账”，让大家从心理上认可变革的风险和影响，达成共识――即使失败我们也认了，那就干吧！

变革是一个过程。广联达有其推行变革的变革曲线模型。卢旭东提示，如果宣布变革之后，马上开始推动变革是不可行的，应该有一个沟通、倾听、反馈的过程，而且要挖掘被动变革者担心的问题，寻求共赢，逐渐把被动变革者从关注损失转变到考虑共赢的状态上。“这是一个很细微的人性的变化，但不关注它，你就可能失败得很惨。”

对于这个环节中沟通的重要性，卢旭东用两个程序员做结队开发的实际例子向记者做了说明。小张和小丁两人做结队开发，但一天小丁却来和卢旭东哭诉说小张欺负他，说小张自己不写程序，天天让小丁写，小丁写完小张还挑刺。卢旭东找小张谈过之后发现了问题所在，原来小张有自我保护意识，认为小丁来跟他结队是领导对他有意见，派人来跟他学完之后要开掉他。听完，卢旭东哭笑不得，跟俩人说明了实际情况，解决了问题。虽然这是一个很小的例子，但却铁铮铮地说明了沟通的重要性和变革过程的复杂性。当人们从变革中得到收获，就会不再对抗，而是会主动、持续推进变革。

关注客户价值，辅以有效激励

为了更好地推进敏捷，广联达还调整了激励方式，奖金的一部分放到年底来发，将外部客户满意度作为考核的主要指标，不再用传统的方式，用按时交付的指标拿开发来衡量需求、拿测试来衡量开发。这样整个开发团队的目标一致，才能发挥更大的合力。

同时在推敏捷的伊始，广联达就定义了内部客户的概念，按照价值链排序，公司内部在自己后面的那个人就是自己的客户，因为他更靠近外部客户，那个人满意是自己重要的考核指标，所以这就使得所有人都主动去想客户为什么不满意。在外部目标统一的情况下，很容易形成一个很好的自适应团队。例如，开发人员为让自己的客户――测试人员满意，就会提前不断与做测试人员和做需求人沟通，提前进行很多开发阶段的质量风险控制活动，如此一来，很多BUG在开发阶段被修正，提高了整个开发过程的效率和质量，让产品开发更敏捷。

“我们没有因为实施敏捷做任何的人员调整，还是原来那拨人，但敏捷小组的交付效率要比对比组高2.63%。原来我们做一轮回归测试需要10.5人天，而现在用自动测试加一些手工探索一天就可以快速回归15轮。”

一天，卢旭东在跟董事长做一个专项工作的汇报时，出乎他的意料，董事长竟然对他说：“你应该再敏捷一点，尽早地迭代交付价值。” 在广联达，敏捷已经逐步成为一种价值观，深入人心，越用越顺。

记者手记

敏捷的隐忧

敏捷的项目管理篇6

关键词：敏捷开发；JavaEE框架；持续集成

中图分类号：TP311.52 文献标识码：A 文章编号：1007-9599(2011)22-0000-02

Agile Development Research and Application Based on JavaEE Architecture

Du Feining

(China University of Mining&Technology,School of Computer Science&Technology,Xuzhou 221116,China)

Abstract:The traditional approach to software development is hard to deal with the often changes of the user’s demand,this paper studies in agile development method and application based on JavaEE framework,and building agile development platform.Using JavaEE lightweight framework of good technologies and tools combined with agile thoughts can quickly and flexibly adapt to the development requirement changes,thus in the shortest possible time to get the biggest customer satisfaction.

Keywords:Agile development;JavaEE architecture;Continuous integration

一、敏捷方法概述

XP（eXtreme Programming―极限编程）是敏捷开发方法的代表，由Kent Beck在1996年提出,它是一个混乱而有序的、基于实践的方法，它通过非常短的迭代周期来应对需求的变化;敏捷模型驱动开发（AMDD）是模型驱动开发（MDD）的敏捷版本，它的核心是构建足够简洁的模型，同时通过迭代和小增量建模包容需求的变化。

二、基于敏捷思想的轻量级JavaEE平台架构

（一）生命周期模型的描述

首先是顶层视图，把源自需求与迭代设计作为本架构设计的第一层次。其中需求提供了框架设计的基础，需求的变化将会导致设计的不稳定，而需求的复杂性又会导致简单架构设计的困难，采用迭代的方法，将问题分割为多个子问题，问题的围度和难度都降低了；其次是底层视图，它是敏捷型Web架构的详细实现，整体上遵从顶层视图中需求与迭代的模式。架构过程借鉴Scott的AMDD，分为系统设计阶段和系统开发阶段。

（二）基于JavaEE框架的通用架构

敏捷开发平台主要用于开发基于JavaEE轻量级框架的web应用程序,架构主要由开发环境、源代码仓库、构建服务器、Web服务器等几部分组成。图 1给出了敏捷开发系统流程。

图1 敏捷开发流程

从源代码仓库中获取全部最新的源代码，然后编写程序的代码和相应的单元测试代码, 以保证所有的代码能够被编译并且所有的单元测试通过检查，提交代码，检入到源代码库中。持续集成工具 Cruise Control的源代码监视及管理模块监测到源代码仓库中的代码发生变化后，由Maven执行任务，首先初始化目标目录，将目标目录清空后，创建源程序目录、测试程序目录和class目录，接着从源代码仓库中检出源代码到源程序目录，检出测试代码到测试程序目录，然后调用代码检验工具Check Style检验源代码是否符合事先配置好的代码规范，再编译源程序生成目标类，并调用Junit测试框架进行测试，如果测试全部通过，即可将整个Web应用打成 一个WAR包，并将这个WAR包到Web服务器。

三、敏捷开发架构在JavaEE项目中的应用

（一）项目框架结构

为提高高校科研管理水平、工作效能，科技处的主管部门需要研发一个信息管理系统，实现对该校科研业务管理的信息化。该系统包括项目管理、基地管理、成果管理、门户网站等四个子系统，以及用户与系统管理、统计报表分析、业务协同组件等基础模块。规模适中，开发周期在两个月左右，适合使用敏捷开发方法进行开发。

该信息管理系统使用Web应用框架和敏捷开发流程，整个系统的体系结构分成三层, 分别是表现层、业务层、持久化层，该体系结构图如图所示。

表示层将Struts动作管理委托给Spring，通过在struts-config.xml中注册一个来实现。负责在Spring环境中查找Struts动作，由于动作在Spring的控制之下，所以它可以填充动作的JavaBean属性，并可以应用Spring的AOP拦截器的特性;持久化层设计的目标是为业务层提供一个统一、安全和并发的数据持久机制。Hibernate除了提供对象和关系数据库之间的映射之外，它还提供了数据查询和恢复机制，可以减少开发人员使用SQL和JDBC处理数据的时间。

（二）测试驱动开发

测试驱动开发的前提是要有成熟的测试工具，否则将会拖累项目的进程。JUnit是针对JavaEE平台的一个成熟的回归测试框架，提供了基于API的自动测试方法。用户可以通过在测试代码中调用这个框架来检查条件是否满足，并报告错误的数量和类型。这种方案非常灵活，大多数情况下它大大减少了测试代码的维护时间，并且使应用中的复杂功能测试成为可能，还可交替使用白盒测试或\盒测试。因为JUnit提供了单元测试和功能测试都必须用到的两项功能：断言检查和结果报告，其它测试工具常常在其基础上创建。

（三）持续集成

Cruise Control是一种持续集成过程的框架，它的Build Loop就是为了支持自动化而设计的，也是Cruise Control的核心。Build Loop过程中所做的工作如下访问源代码仓库，检测源代码仓库中代码是否发生变化，如果发生变化，获取源代码的最新版本，并根据配置信息对代码进行一次构建，包括自动化测试，创建一个日志文件，最后向项目组所有人员通知构建的结果。在敏捷开发平台中，对于每个项目需要配置的内容主要包括以下两个文件，一个是位于项目目录下的build.xml文件，Maven根据此文件进行构建，另一个是Cruise Control 安装目录下的config.xml文件，该文件指定的相关的参数设置，包括日志的路径和名称等。

四、结束语

在研究敏捷开发流程与持续集成技术开发思想的基础上，分析迭代开发的实现方法，并提出一个集成现有JavaEE框架和相关技术的敏捷开发平台，目的是运用该敏捷开发平台快速地开发基于此架构的应用项目，从而提高开发效率,适应需求变化，降低项目成本，提高软件质量。

参考文献：

[1]王建阳.基于Spring+Hibernate框架的敏捷软件开发的研究[J].电脑知识与技术,2008,(S2)

敏捷的项目管理篇7

【关键词】敏捷项目管理敏捷软件开发快速启动 QuickStart用户模型场景模型用户故事交付计划

1 敏捷开发及项目管理方法体系

1.1 敏捷方法介绍

敏捷方法诞生于2001年初，当时，由于看到开发团队陷入越来越沉重的软件过程当中。业界专家们总结出了一套使团队具有快速工作、响应变化能力的价值观和原则。基于这一套价值观和原则的软件开发方法，被称为敏捷软件开发方法（Agile Software Develop-ment），而这类方法也发展出相应的敏捷项目管理体系（Agile Project Management）。敏捷开发方法及项目管理体系统称为敏捷方法（Agile）。

1.2 敏捷方法的优点

敏捷方法是一种以人为核心、迭代、循序渐进的开发及项目管理方法。该方法使用了迭代、增量等方法来优化可预见性并控制风险。它灵活、高效、可持续，可以帮助软件开发团队有效地应对复杂的适应性问题。

该方法受到拥护和流行是因为采用了该方法后，团队得到的收益：据统计，敏捷方法可以让团队的效率提升3～10倍；软件的质量也更有保障；团队成员有良好的发展机会；技术能力和团队协作也得到了提高。

2 敏捷项目的快速启动

2.1 什么是快速启动？

敏捷软件开发项目通常会通过1～4周的快速启动（QuickStart）工作，制定出迭代开发计划，然后在开发过程中逐渐完善需求。QuickStart是一种高效的项目启动方式，主要用以在项目开始之前识别关键的驱动因素，这种方式能够让关键干系人认可并理解即将交付的产品。如图1所示。

3 QuickStart的前期准备

3.1 邀请相关参与人员

QuickStart过程中需要邀请参与的人员包括：核心团队、领域专家及用户代表、关键干系人（受益人、高层领导等）。核心团队一般包括产品负责人、需求分析人员、项目负责人及核心团队成员。这些人需要全程参与整个QuickStart，他们是成果的主要贡献者。领域专家及用户代表主要在用户建模、场景建模等环节为团队提供专业的意见和建议。他们可以在某些阶段时参与到QuickStart中来。关键干系人主要参与QuickStart的启动和展示汇报的环节，并对产出成果进行确认，特别是需要对产品目标和计划进行确认和授权。

3.2 拟定QuickStart的计划

在QuickStart正式开始之前，项目负责人和产品负责人需要拟定QuickStart的整体计划。以一个2周的QuickStart为例，整个QuickStart计划可以这样安排：

QuickStart启动及业务目标识别（0.5～1天）

参与人员包括：核心团队、领域专家及用户代表、项目领导

产出物：产品目标

识别主要角色及场景（3～5天）

参与人员包括：核心团队、领域专家及用户代表、项目领导

产出物：主要用户角色列表、核心场景及流程、页面设计及原型

需求列表梳理（1～2天）

参与人员包括：核心团队、领域专家及用户代表

产出物：用户故事清单

规模及成本估算（0.5～1天）

参与人员包括：核心团队

产出物：估算结果

迭代/计划制定（0.5～1天）

参与人员包括：核心团队

产出物：迭代/计划

QuickStart的成果汇报（0.5天）

参与人员包括：全体团队成员

产出物：成果汇报材料

4 引入的各种流程建模及分析技术

4.1 识别业务目标及愿景

业务目标的识别和确定需要符合SMART原则；需要了解问题的背景及上下文信息；需要定义验证问题成功的标准；需要界定问题的范围，例如规模指的是数量还是金额，或者单品规模；需要明确并逐步完善关键干系人信息；需要明确关键资源，例如领域专家或者关键信息等等；还需要明确该问题的各种约束条件。

4.2 识别角色及主要场景

用户识别从头脑风暴的形式开始，尽可能识别出更多的用户，然后挑选出主要的用户和角色，并且为用户进行用户画像，并建立用户模型。通过理解用户的目标需求和痛点，梳理出更多的细分用户场景，之后对用户场景进行优先级排序、分析，以发现其中的问题或隐含的机会。

对问题和机会进行结构化的分析可以通过这几个方面来进行：

（1）进行问题/机会的原始描述；

（2）通过事例来说明问题/机会的现象；

（3）对问题/机会进行定量的分析；

（4）对问题/机会进行定义并明确对于问题解决的期望；

（5）将问题和机会的相关分析及描述标识在用户场景描述的周围。

业务流程梳理的过程中可以将之前识别出来的用户场景在进行串联。较高层级的业务流程将各个场景串联起来之后，就可以在场景中进行场景流程的细化和展开，分析出流程步骤和各个步骤的细节。业务流程场景中的步骤细节需要包含这些信息：场景名称、场景入口的背景说明，本场景中需要跟进解决的问题，场景中事件步骤，某个步骤的细节说明，还需要有场景的出口目标。

4.3 a出Product backlog

根据上一环节中梳理出来的用户模型、场景模型、业务流程以及场景细节，开始进行用户故事的梳理，并建立用户故事列表。用户故事是为了方便与用户沟通而记录的信息，它不是需求文档，它需要以用户能理解的方式来进行描述。它的目的是要将用户的关注点从“写”转移到“交流”上，让开发团队做用户真正需要的东西，而不是用户写的东西。

一个用户故事的描述样例是：“作为一个，我想要，以便于”。一个用户故事是否成功可以从以下几点（INVEST）来判断：是不是独立的（Independent），是不是可协商的（Negotiable），是不是有价值的（Valuable），是不是可以估算的（Estimable），是不是大小合适、粒度相似的（Sized appropriately），是不是测试能够测试、业务能够验收的（Testable）。

4.4 梳理依赖、估算及优先级排序

核心开发人员对已经梳理出来的用户故事进行初步的技术解决方案分析，确定用户故事的技术实现可行性和一些可能的实现方案。然后从逻辑层面和技术实现层面，对用户故事列表中的故事进行一次检视，对于一些无法避免的用户故事之间的相互依赖，需要在故事卡片上标识出来。对已经梳理出来的用户故事进行估算，估算内容包括故事规模估算、工作量估算等。

估算完成后可以根据用户故事的价值、重要程度、依赖等信息进行用户故事优先级排序。排序的原则是优先考虑那些最有价值的故事、最关键的故事、被其他关键故事依赖最多的故事。

4.5 制定交付计划

经过以上各个环节，团队已经得到了了一份标识了优先级、依赖关系、工作量估算等信息的用户故事列表，此时可以开始来制定交付/计划了。根据已经排序的优先级选择并整理每个迭代/版本需要完成的用户故事，使用每个故事上之前已经完成的规模或工作量估算，加上功能联调和集成可能增加投入量的buffer值，整理并安排出整个交付计划。

对于最近的一个交付周期的安排是团队应该投入最多时间进去分析和做进一步估算的。确保第一个交付周期的所有用户故事清晰且被团队理解，并且该周期中的所有用户故事都已经有较明确的技术实现方案，可以在QuickStart结束之后马上进入开发实现。如图2所示。

4.6 汇报QuickStart的成果

QuickStart的最后一个环节是召开QuickStart成果汇报的会议，该会议的邀请人员包括项目团队全体成员、项目领导、相关干系人。会议上向项目相关人员汇报QuickStart的成果产出，包括确定项目产品目标及愿景、需求列表及交付计划。在展示项目团队QuickStart成果的同时也获取相关领导及干系人对成果的认可和支持，统一项目团队人员的认识，为汇报结束后立刻投入到需求的_发实现奠定基石。

5 结束语

敏捷项目中的QuickStart是一种高效的项目启动方法，帮助项目快速确立目标、梳理需求并排定计划。它是一种敏捷的项目管理方式，强调共享、合作与包容，业务与IT关键干系人全程共同参与，注重群体决策。它是一种经过反复实践验证，效果较好的项目快速启动方法。

参考文献

[1]（美）John C.Goodpasture，陈秋萍译.敏捷项目管理：企业级实践与案例[M].电子工业出版社，2012.

[2]（美）Robert C.Martin，邓辉译.敏捷软件开发原则模式与实践[M].清华大学出版社，2003.

[3]（美）Michele Sliger Stacia Broderick，李晓丽，李虎，赵华译.软件项目管理与敏捷方法[M].机械工业出版社，2010.

[4]（美）Mike Cohn，石永超，张博超译.用户故事与敏捷方法[M].机械工业出版社，2008.

[5]（美）Jeff Patton，李涛，向振东译.用户故事地图[M].清华大学出版社，2016.

[6]（美）Mike Cohn，宋锐译.敏捷估计与规划[M].清华大学出版社，2007.

作者简介

梁瑾（1978-），女，广东省深圳市人。学士学位。现为平安科技（深圳）有限公司项目副总监。主要研究方向为敏捷软件项目管理。

敏捷的项目管理篇8

软件开发项目管理从最早的传统项目管理软件工程期到近年的迭代模型时期，最后到目前的敏捷软件开发时期。敏捷软件开发的成功五项因素分别如下。

（1）建立自组织团队。传统的管理方式具有命令和控制的特点，经理制定目标和计划，团队负责完成，发挥不出员工的创造力，影响了企业的效率。软件开发的敏捷开发要求员工自我管理，个人控制时间和目标，员工能参与流程和项目决策。

（2）用户故事在需求管理中的应用。软件开发企业最大的敌人不是用户，而是变化。瀑布模型难以适应目前软件市场需要，因此软件开发工作要取得用户的参与，顺应市场的变化。

（3）用户故事的度量，它能为产品投资收益提供估计结果，辅助产品决策。对故事点大小讨论时，能鼓励团队成员重复讨论，充分理解需求。故事点度量方式一致，提高统计团队工作效率。

（4）持续集成。它能提高项目构建自动化程度，将人力成本更多投放到开发任务。项目更有可见性，构建结果更加丰富，一目了然。团队对开发产品更有信息。

（5）掌握迭代，为员工提供稳定的生活节奏，保持一致的周期循环流程，沟通过程中控制时间。

（6）坚持反馈和改进，了解自身情况，改善团队效率。

精益生产的目标为提高质量和消除消费。看板原则要求生产降低库存量、降低生产周期、生产基于交叉培训和单元并对过程进行持续改善。如同超市进货一样，当货架上货物少于设定值，供货商会及时将其填满。将看板管理与敏捷软件开发结合起来，能够达到效率和质量的有效结合，软件产品周期频繁，能达到按天级别。

2.项目看板方法流程设计

增量迭代开发开发流程存在着三点问题。

（1）每个迭代的用户故事较多，产品经理和开发工程师认为很多功能没有价值，而项目经理认为需要跟踪的项目较多。

（2）对于为期四周的迭代观念不统一，部门不同，期望值不同，测试人员认为时间不充分，产品经理认为需要等待太长时间。

（3）部门之间缺乏协作，缺乏透明的项目进展和进度，太多时间花费在流程上。敏捷软件开发有三个典型流程，分别XP、Scrum及看板，经过比较，看板原则可以解决迭代用户故事较多的情况，对于规模小及优先级别高的用户故事能够迅速完成，并满足产品经理对产品的预期。

2.1 基于看板管理的敏捷软件开发流程方案设计

看板一般应用于汽车生产等工业领域中，在敏捷软件开发中看板管理只是理论上行得通，但是在实际上还缺乏经验。而且其受到产品特点、客户差异及企业文化的影响。其流程主要为，（1）定义并可视化流程；（2）限制WIP数量，流程可视化于物理板能够让项目透明，让团队对目前的任务充分明确。限制WIP数量则能让团队在思考时排除千扰，提高个体效率，项目工作不以来时间计划，而是取决团队能力；（3）拉动式生产，每个团队成员只需要对自己环节加以关注，等待任务-完成工作-到下一环节等待区^这种方式推动了产品开发前进步伐。

2.2 看板流程准备和实施

（1）是动员和人员培训，先获取领导层的理解和信任，再向所有员工培训敏捷开发和看板方法，最后，每个部门进行讨论。

（2）制定需求管理环节，产品经理提出产品需求，创建用户故事，技术团队估算用户故事工作量。通过需求分析，工程师能够获取信息，完成研发工作，产品经理全程辅助开发和测试，解答相关问题。

（3）开发流程改造，主要变化在对程序代码的管理方式进行改变，主要有主干和分支两种。

（4）测试流程改造，主要表现为两个方面，一方面提高系统自动化测试率来加快回归测试的进度，另一方面增加测试环境满足功能测试需求。

（5）项目管理流程的建立。

2.3 看板流程的实施

当所有准备工作完成之后，看板方法第36增量迭代之后，可以正式实施。产品经理将用户故事进行排列再制成任务卡，贴在用户故事一列，完成需求分析会议。开发组建立功能分支进行开发，测试组应用功能测试环境对用户故事进行测试，直到产品。团队成员每天早上聚集看板附近，明确自己的任务，下班前，项目经理将每天的任务卡状态变化汇总。敏捷流程要求强调团队自组织和员工自我管理，但是不可忽视项目经理的作用，项目经理能够组织人员，梳理工作节奏，保证沟通流畅，促进项目进展。

3.看板方法效果分析

敏捷的项目管理篇9

关键词：Scrum，敏捷，持续集成，测试驱动

 

1引言

随着软件行业的发展，基于详尽的需求分析、系统设计和把需求变更作为梦魇的瀑布模式已经逐渐被开发者们所丢弃了，而能够更快地面向市场、更好地响应客户需求变更的敏捷开发模式深得开发者们的青睐。正如敏捷宣言所述：个体和交流胜于过程和工具；可以工作的软件胜于综合的文档；客户协作胜于合同谈判；应对变化胜于遵循计划[1]。敏捷开发模式更重视软件的生产率，且适用于解决需求模糊或快速变更的问题。现今已经有很多种敏捷方法被付诸到实践中了，广为人知的有极限编程（ExtremeProgramming，XP）、Scrum、动态系统开发（Dynamic System DevelopmentMethod，DSDM）、自适应软件开发（Adaptive Software Development，ASD）、水晶方法（CrystalClear）、特征驱动开发（Feature-Driven Development，FDD）和测试驱动开发（Test-Driven Development，TDD）[2]等。敏捷方法在实践中取得了巨大的成功。很多数据和实例告诉我们，敏捷是提高软件生产率不争的事实。然而过程本身不是敏捷的，但人可以敏捷计算机毕业论文，团队或者组织可以敏捷。如果只是做敏捷而不是敏捷地去做，就会导致敏捷方法应用的失败[3]。在敏捷开发方法实践中需要去体验、分析思考以及进行必要的方法改进，以切实获得采用敏捷方法所带来的最大效益。

2 Scrum简介

Scrum是当今被广泛应用的敏捷开发模式之一。它有着自己鲜明的优势：客户成为开发团队的一部分、能够频繁提交可以工作的中间增量产品、可以不断更改项目的需求以适应用户需求的变化、不需制定详尽的不切实际的计划和编写冗长的文档使得团队更加灵活自如，自由地自我组织和自我管理使得团队积极主动、敏捷创新[4]。Scrum也有着区别于其他模式的特质。它拥有特定的成员角色：产品的负责人PO（ProductOwner），Scrum主管SM（ScrumMaster）和团队（Team）（适宜的人数是5到10人）。它拥有独特的实践方式：冲刺（Sprint），计划会议（SprintPlanning Meeting），评审会议（Sprint Review Meeting），回顾会议（SprintRetrospective），每日例会（Daily Meeting），产品订单梳理（Product Backlog grooming）。它拥有着特殊的工件：产品订单（ProductBacklog），燃尽图（Burn Down Chart），完成标准（Definitionof Done），产品增量（Product Increment）[1]。

Scrum开发过程是以Sprint为增量的迭代开发过程，一般一个Sprint适宜的迭代周期是1到4周。Sprint开始时，团队从已按优先级顺序排列好的产品订单中选择适合本团队的项目，与PO澄清需求并生成同样按优先级顺序排列好的Sprint订单，并且保证在本次Sprint结束前做完论文格式范文。每个工作日团队都要收集汇报彼此的任务进程和余下的任务量。Sprint结束时小组展示最终的项目成果，并收集来自团队之外的反馈，用以下一个Sprint的自我提升。图1描述了Scrum的开发流程。

图1 Scrum的迭代过程

3 Scrum方法在实践中的灵活运用

3.1 项目背景

本文的项目背景是某知名通信设备公司研发中心的开发和测试工作。研发团队具有多年Scrum开发经验，团队任务是研发和测试该公司某一产品线上的几个功能模块，其中包括基于底层Linux操作系统和顶层应用层的中间件模块：启动管理和内存文件管理。

3.2Scrum方法的改进

3.2.1改进每日例会的模式

按照Scrum倡导的每日例会形式，每个成员应轮流回答三个经典问题，这使得我们小组的日会在很长一段时间内基本沦为一场激烈的辩论会，而这些讨论往往是徒劳的。对此，我们决定对这种已经背离Scrum宗旨的日会进行改进。改进的主题就是转变角色计算机毕业论文，让项目任务成为会议的主角，因为Sprint订单原本就是对项目任务的细化。于是新的日会改变了模式：仍然由主管主持，所有成员群视白板，但变成了一种问答形式。如图2所示，主管会按优先级顺序遍历项目，针对细化了的每个项目的每个任务提问三个问题：今天花了多少时间、做到了什么程度（日会安排在下班前一小时）？遇到了什么问题？明天怎么解决、继续做多少？相关负责成员回答问题，其他成员洗耳恭听。如此下来效果非常明显，首先是会议时间平均不超过10分钟，节省的时间等效于一笔宝贵的财富。再者是大家对各项任务的进展一目了然，同时不同项目之间不同任务之间的成员的付出、进度、成果也一目了然。这样改进后完全达到了日会目的，对这种简单高效的会议方式，团队成员是乐此不疲。

图2 改进后的日会模式

3.2.2 采用事半功倍的结对编程方法

Scrum提倡团队配置精英成员，即每个团队成员都可独当一面、技术过硬、开发经验丰富。然而在软件行业起步晚、开发技术还相对落后的国内，鲜有具备十年研发经验的开发人员仍奋战在第一线的情形，一般开发人员都仅具有2到5年的研发经验。我们的团队就是一个典型的例子，8人组成的团队平均开发经验不到3年，其中还有2个新手。因此，团队出现了的产品缺陷（Bug）多、生产率低、新手进展慢、一些模块过于依赖某一个人等许多问题。针对这样一个低效局面，我们尝试使用了结对编程方法，每个功能模块都至少由两人负责，这样就避免了因某一人缺席而导致一些模块的研发进展停滞的情况。结对编程的过程就是一个连续代码评审的过程，这无疑会提高代码的质量，并且结对编程可促进成员相互学习、彼此提升，特别是加速了新员工的成长，从而提高了整个团队的工作效率。

3.2.3 重视必要的开发文档

Scrum轻文档重开发的敏捷理念并不是杜绝所有的文档书写。文档可以帮助新人快速熟悉小组项目计算机毕业论文，也有利于当前项目结束后的维护工作，或者是后续项目的跟进。将客户的体验形成几页纸的说明文档，可以使开发人员对客户的体验有清晰的了解。这样在每次Sprint开始之前，有了定义好的产品订单，本次Sprint便可以持续、平滑地过渡到下一次Sprint[5]。

3.2.4 避免流于形式的回顾会议

按照Scrum宗旨，回顾会议是团队用以自我提升的一大法宝，其重要性是显而易见的。对于软件开发来说，若不能够高效、进步和创新，则无疑是在走向灭亡。然而在实际的软件开发中，很多时候回顾会议往往变得无所回顾，无可总结。渐渐地流于形式，甚至被一部分开发小组所抛弃，这样的例子屡见不鲜。我们团队也无例外地经历过这样的尴尬处境。对此我们采取了改进措施：回顾会议期间之所以无所回顾，究其原因是每个成员对一个月内的众多细节根本无法一一回忆。所以我们在燃尽图旁新增三栏：Good、Bad、和Ugly。团队成员在每个Sprint期间，可以就无论是技术、沟通还是管理方面的问题在这三栏中以即时贴的方式添加自己的意见，提倡的意见放在Good栏，改进意见放在Ugly栏，揭露弊病的意见放在Bad栏。即时贴所写的内容包括事件简述、日期、意见发表者。这样改进后，在回顾会议中就不会再无所回顾了。

3.2.5 坚持应用持续集成和测试驱动方法

对于敏捷模式之一的Scrum，持续集成（ContinuousIntegration）和测试驱动（TDD）同样是其两大基石[2]。在大型复杂项目实施中，软件集成无疑是一个重要的问题论文格式范文。要降低项目的风险、确保产品的质量，尽早且频繁、持续地集成是一种事半功倍的方法。图3是我们持续集成的流程图。

图3 持续集成流程

使用测试驱动可以避免像传统方法那样对测试文档的依赖。通常用户需求的变更会使维护测试文档的成本与日俱增，这样的结果显然不够敏捷，也不符合Scrum方法的宗旨。如果使用测试代码来代替测试文档，就会使问题变得简单多了。测试驱动通过对测试代码不断地重构来推动软件功能代码的编写和完善计算机毕业论文，不断增加软件新特性，直至实现全部软件功能，如图4所示。这种方法不仅保证了代码的正确性，也体现了灵活适应需求变更的敏捷性。

图4 测试驱动流程

3.3Scrum方法的改进成效

经过改进Scrum之后，不但团队的生产效率得到了很大的提升，并且团队成员的积极性、工作效率、创新思维都得到了显著的提升。图5和图6是改进前后某两个Sprint的燃尽图。图表中的基准线表示最理想的情况下每天应按时完成的确定等量任务，这时每天的生产率都是5。燃烧线是实际工作的情况。从图中不难看出，改进前团队的生产率平均不超过5，并且Sprint结束后还有部分任务完不成。改进后，不但按时完成任务而且生产率基本在5之上。

图5 改进前的燃尽图

图6 改进后的燃尽图

4结论

公司的文化、管理模式不同，开发者的经验不同等等都决定了Scrum方法不能被按部就班地套用。Scrum宗旨是提倡灵活，因此在实际运用中的灵活改进并不有悖于Scrum的原则。相反一味的借鉴模仿只会形似而神不似，导致适得其反的结果。“敏捷”本身就意味着适时地变化，应该在敏捷和不敏捷之间寻找一种合理的折衷方案[3]。在实践中对敏捷模式进行适当的改进和灵活的运用，能够帮助我们更好地抓住敏捷开发方法的精髓，最终达到预期的目标和效果。

参考文献

[1]Ken Schwaber, Mike Beedle. AgileSoftware Development with Scrum[M]. PrenticeHall, 2001

[2]Dean Leffingwell. 可伸缩敏捷开发：企业级最佳实践[M]. 李冬冬，译. 北京：电子工业出版社，2009

[3]Scrum中文网 [OL]http://www.scrumcn.com/index.php

[4]RobertC Martin. 敏捷软件开发———原则、模式与实践[M].邓辉，译. 北京:清华大学出版社，2003

[5]敏捷方法需要文档吗？[OL] http://www.infoq.com/cn/news/2007/07/agile-methods-documentation

敏捷的项目管理篇10

软件项目管理 瀑布模型 敏捷开发 Scrum 挣值法

Research on Measurement of Software Project Management Process Based on Scrum Method

YAN Jing

（China Electronics Technology Group Corporation No.7 Research Institute， Guangzhou 510310， China）

By analyzing the shortage of earned value method commonly used in traditional waterfall model of software project management， the Scrum method of agile development is introduced into the project practice to solve the problems in order to better carry out the software project management and improve development efficiency， which achieves to control the project progress and product quality.

software project management waterfall model agile development Scrum earned value method

1 引言

软件项目管理能力的高低是软件项目最终能否成功的关键因素。目前软件行业所面临的最重要的软件开发问题莫过于如何用一种有效的方法来管理软件过程，确保软件开发的高效率和产品的高质量。随着软件开发复杂性的日益增大以及软件行业规范管理经验的逐渐积累，软件项目管理无论是在理论上还是在实践中都取得了很大的进展。CMMI（Capability Maturity Model Integration，软件能力成熟度模型集成）中的项目监控、项目策划、测量与分析这三个过程域，也对如何规范有效地开展项目管理有所指引。

本文对软件业界常用的瀑布模型和配套的挣值法的不足进行了分析，并引入敏捷开发中的最佳实践Scrum方法，通过全周期和阶段两层跟踪方式来实施软件项目管理。

2 Scrum方法简介

敏捷开发（Agile Development）是以提高软件开发效率和响应速率为目的，针对传统瀑布模型开发的弊端而研发的一种开发模式，是以人为核心的多次迭代循序渐进的开发方法。敏捷方法试图通过小型的、自我管理的团队使用短小的合作周期来鼓励迭代式软件开发方法。软件的质量贯穿敏捷软件开发的每一个阶段，并提出很多关键的规则来保证能在每一个迭代周期内及早地发现并及时消灭开发过程中出现的错误。敏捷开发将软件开发划分为多个迭代开发的过程和阶段，通过迭代式的增量开发，保证软件一直处于可使用的状态。

Scrum是敏捷开发的方法之一，也是目前软件业界的敏捷最佳实践之一。Scrum通过可视化、检验和适应来管理复杂、不可确认和变更。Scrum思想将工业过程控制中的概念应用到软件开发中来，认为软件开发过程不是确定性过程，而是将传统软件开发中的分析、设计和编码等子过程视为一个黑箱，充分发挥软件人员的创造力，使项目组工作在一种模糊状态增强适应力，以此来替代传统瀑布模型将经验性过程按确定性过程来处理所缺乏的适应力。

Scrum是一种工作管理的方法，它不仅仅限于软件开发，也可以用来管理硬件开发、系统工程等各种开发活动。Scrum开发模型图如图1所示。

（1）依据需求的优先级确定项目的需求列表，依据需求列表对工作量进行估算；

（2）假设每次的迭代周期为4周，确定单次迭代的工作目标，并对任务进行细化形成迭代任务列表，子任务的跟踪粒度小于2天；

（3）迭代中进行每日例会，每次会议控制在15分钟左右，并且每个成员要向团队汇报昨天完成了什么、今天要完成什么，同时遇到不能解决的问题也可以提出，汇报完成后更新迭代任务的燃尽图；

（4）当一个迭代的功能完成时，进行迭代演示也称为评审会议，会议中演示本次迭代所完成的软件产品。

3 项目管理过程度量

软件项目管理是为了使软件项目能够按照预定的成本、进度和质量顺利完成，而对人员（People）、产品（Product）、过程（Process）、项目（Project）进行分析和管理的活动。软件项目管理的目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，了解软件项目进展，以预定成本按期、按质的完成软件并交付用户使用。当项目绩效明显偏离计划时，能采取适当的纠正措施。

软件度量是对软件开发项目、过程及其产品进行数据定义、收集和分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。

软件项目管理的过程度量能够帮助项目经理等人员掌握软件过程的状态，提供软件项目管理受控所需的数据和信息。

4 瀑布模型的不足

软件开发中传统的瀑布模型是一种较为理想化线性的开发过程。其强调文档的作用，以文档为驱动，在整个开发过程中各阶段的划分完全固定，阶段之间产生大量的文档，一切以文档为依据，并要求每个阶段都要仔细验证。由于瀑布模型具有线性的特性，用户往往只有等到项目的末期才能见到开发成果，早期的错误可能要等到开发后期的测试阶段才能发现，这样既增加了开发的风险，也给项目带来了严重的后果。

具体到瀑布模型的项目管理方面，项目通过跟踪里程碑和阶段完成日期的方式来跟踪项目进度。通常使用挣值分析法的计算来显示和分析项目是否在按计划进行，但挣值的绩效指标可能带有误导性，并经常掩盖掉某些进度延误。在进度、范围和财政预算上，比起为传统瀑布项目提供的“挣值（EV）”和“进度绩效指标（SPI）”，Scrum能为项目利益相关方提供更为准确的预测。

例如，一个项目周期为12个月，某阶段的计划工作量为1 000人时，项目在跟踪频率为双周时对项目的SPI进行度量。当实际工作量为800人时，SPI=800/1 000=0.8，意味着SPI小于1即延迟于原计划20%；当实际工作量为1 200人时，SPI=1.2，意味着项目比原计划超前20%。在对项目的跟踪分析数据进行分析时会发现，这样的延迟或超前对项目进度本身的影响并没有太多的实际意义，只要不影响阶段的周期进度就是可行的。假设还是这个项目，前期的系统分析和软件需求分析占用了全周期工作量的20%，但因为瀑布的线性特性，这个阶段项目的输出仅仅是大量的研制任务书、软件需求、讨论记录、会议纪要等，并没有可使用的软件产品的雏形。上述的项目管理跟踪方式往往掩盖了项目的实际问题，有可能造成项目在临近结束时才暴露出开发过程中产生的问题。即使从挣值分析的数据来看，项目能够按照预定的计划稳步开展，并不能确保最终能够生成预期的软件产品。如果此时出现了颠覆性的重大设计问题，但从挣值分析数据来看并不一定能够发现，对项目的影响也许只能通过调整计划等决策来进行挽救。

综上所述，挣值分析这样的项目管理方法虽然有着光鲜的外表，但对软件产品开发过程度量的实质意义不大，不能较好地通过对软件项目管理过程度量达到对项目进度和软件产品质量监控的目的，促进项目的最终成功交付。

5 引入Scrum方法来解决问题

Scrum方法能更快、更高效地交付可工作的软件产品，并提供更准确的进度、预算和范围的预测。使用Scrum方法将范例12个月项目分成12次迭代，即每次迭代周期是1个月。在第3个迭代完成时，完成了3个可交付软件产品，而不是瀑布模型的一堆文档和记录表。Scrum方法也写文档，但只写有必要且尽量少的文档和记录。Scrum注重的是人与人之间面对面的交流，强调以人为核心，例如每日例会中当场记录项目成员的工作量数据，就可以替代挣值分析法中的个人工作日志、工作周报等。

Scrum相较于传统的挣值分析法，度量数据的数量和种类有了大幅度的减少，约占挣值分析法度量数据的50%，同时也大大降低了数据统计分析的难度。主要的度量数据包括：任务计划工作量（人时）、任务实际工作量（人时）、迭代次数、迭代周期（工作日）、计划总工作量（人时）、计划剩余工作量（人时）、实际剩余工作量（人时）和工作量偏差（%）。

采用Scrum方法，项目仍然需要按照传统的方式划分软件里程碑，从而把控项目阶段的全周期进度，防止由于迭代次数过多或是迭代内容的更改以至于对项目的整体进度造成影响。项目采用全周期进度和每次迭代阶段任务两层跟踪的方法，同步对全周期进度和阶段进度进行管理。

范例项目周期12个月，每个月1次共12次迭代，每次迭代的任务计划总工作量为620人时，项目全周期计划总工作量为7 440人时。

表1和图2是项目全周期项目管理过程度量的数据及跟踪图，其中的度量数据有偏差百分比、计划剩余工作量和实际剩余工作量。计划剩余工作量是由计划总工作量开始递减的等差数列，偏差百分比=（计划剩余工作量-实际剩余工作量）/任务计划总工作量* 100%。数据及跟踪图使用Excel工具来定制，跟踪图可以通过数据自动刷新生成。这里的跟踪图使用了Scrum常用的燃尽图的表达形式。

表2和图3是项目一次迭代阶段的项目管理过程度量的数据及跟踪图。数据的类型和计算方式与全周期的记录表类似，只是偏差百分比的分母基数替换为这次迭代阶段的计划总工作量。从跟踪图的数据分布情况来看，当实际剩余工作量小于计划剩余工作量时，进度提前；当实际剩余工作量大于计划剩余工作量时，进度延期。为了增强与CMMI标准的适应性，增加偏差百分比这个度量项，偏差可根据项目计划中制定的阈值范围采取措施进行纠偏。每次迭代的跟踪保证了度量数据与软件产品实现间的直观性，全周期跟踪图中尤其是对里程碑节点的重点把控，从而实现了对全周期的各个阶段的监控。

6 结束语

基于敏捷思想的Scrum方法，能够改善传统瀑布模型和挣值分析法的项目管理方法数据分析的误导，针对项目进度和产品质量无法准确预测、项目重大问题容易在项目后期才暴露等问题，通过迭代、增量式的开发，加强项目各种角色间的沟通，提高开发效率，简化项目的文档和过程记录。通过对迭代目标和迭代进度的把控，每次迭代生成可提交用户的软件产品，从而把控全周期进度，迭代增量式完成软件产品的开发。当然，Scrum在项目实践中可能还存在不足，需要软件从业人员不断深入地探索和研究。

参考文献：

[1] Schwaber K. Scrum敏捷项目管理[M]. 李国彪，译. 北京： 清华大学出版社， 2007.

[2] Mike Cohn. Scrum敏捷软件开发[M]. 廖靖斌，吕梁岳，陈争云，等译. 北京： 清华大学出版社， 2010.

[3] Robert C Martin. 敏捷软件开发（原则、模式与实践）[M]. 邓辉，译. 北京： 清华大学出版社， 2003.