|
摘 要：本文首先探讨了敏捷项目管理的起源及其适应性项目框架;并论述了其在软件项目中的应用。然后对适应性项目框架的计划制定对比极限项目管理作了详细的阐述。项目经理博客
关键词：敏捷项目管理;适应性项目框架;极限项目管理
一、引言项目管理者联盟
软件开发中既有高风险、高变化的项目，也有目标明确、解决方案明了的低变化项目。根据不同的项目特点，选用不同的项目管理方式是项目成功的关键。敏捷项目管理是应对经常变化的、具有不确定性的软件项目的管理方法。敏捷即灵活性，是动态的、适应于具体情况、迎合变化和自我完善的。本文针对敏捷项目管理中的极限项目管理和适应性项目框架的软件应用对比传统项目管理进行探讨，并提出了适应性项目框架的改进和计划控制的一些建议。项目经理圈子
二、敏捷项目管理的概念及起源
敏捷项目管理的概念来源于敏捷软件开发。随着敏捷软件开发的发展，极限项目管理(也称为极端项目管理ExtremeProjectManagement或RadicalPro—jectManagement)和敏捷项目管理(也称为灵活的项目管理AgileProjectManagement)的概念和方法被相继提出，并仍在不断发展。实际上，敏捷项目管理只是各种敏捷软件开发方法相应项目管理的统称，只针对于软件项目，并不是一种通用项目管理方法(也有人提出敏捷项目管理的通用概念，但未被广泛接受)。极限项目管理和适应性项目框架皆源于对DougDe—Carlo于2000年发布的弹性项目模式(FlexiblePorjectMode1)的改编。而弹性项目模式又来自于敏捷软件开发中的自适应软件开发方法学的启发。现在二者已经发展成为一个通用的项目管理理论。极限项目管理适合于变化大、复杂程度高的项目。传统的项目管理则适合低变化、低不确定性的项目。而在二者之间是适应性项目框架。虽然所有的敏捷软件开发方法都被认为是属于极限项目管理的范畴，但从最近的敏捷软件开发的发展可以看出有些敏捷方法并不全属于极限项目管理的范畴。而且极限项目管理往往由于过于激进，显得不够实际，并不能被高级管理者特别是CIO所接受，且在大型项目中也无法得到有效论证。现在的敏捷项目管理研究大多有转向适应性项目框架的趋势。所以，虽然敏捷项目管理通常指的就是极限项目管理，但它被认为应是包括极限项目管理和适应性项目框架两部分的软件项目管理的统称，极限项目管理又是适应性项目框架的特例。项目管理者联盟
三、敏捷项目管理的适应性项目框架项目经理博客
通用适应性项目管理框架是以客户为中心、客户驱动的管理方法。极限项目管理是处在比适应性项目框架更复杂，更不确定的高变化情况下的一种管理方法。二者区别在于，适应性项目框架是针对有明确的目标但没有解决方案的项目，而极限项目管理则是针对两个方面都很模糊的情况下的探索式的方法。适应性项目框架只要求客户在每个迭代周期的实施结束后参与项目，而不是全程参与到项目中。转自项目管理者联盟
适应性项目框架主要分为定义项目范围、制定项目周期计划、项目实施、客户检查、项目后回顾五个阶段(图1)。项目管理者联盟
 项目管理者联盟
其中项目范围包括项目满意条件、项目概况说明书、功能要求优先排序、中层WBS等。中层工作分解结构只是分解到功能级，而不是任务级，只要可以比较确信地估计每一段功能所需的时间和资源就已足够。因为对于经常变化无法预计的任务，编写完整的WBS完全是浪费。制定项目周期计划是将要进行的下一个周期的详细计划，是带有依赖关系的任务层次的详细实施计划。项目实施阶段包括制定微观进度计划、实现功能、监督并调整实施进度。在这个阶段，取消当前周期和调整计划都是可以执行的，可以减小和避免损失。通过中间三个阶段的反复进行，最后可以实现客户满意的解决方案。项目管理者联盟
然而适应性项目框架并没有指出当项目出现变化时，如何在时间成本有限的情况下有效完成任务。它还是沿用极限项目管理的方法，制定详细的周期计划，必要时抛弃部分要完成的功能。区别是增加了中层的项目计划。中层项目计划根据时间限制范围内，能够容纳多少迭代周期，并根据特定周期内子功能的数量和质量调整周期时问。虽然也有风险分析，但是并没有在框架内体现并整合到项目周期中。如果根据这个计划确定项目的交付日期，则当变化发生时，很容易陷人传统项目管理的困境，即使采用迭代过程，也很难按期交付。迭代过程唯一能做的就是使变化或风险提前出现，而在以后的迭代周期改进，通常赶进度的方式是加班或者增加资源，这会使成本增加。而且质量的改进也是此类项目的一个不确定因素，这也需要时间和成本。如果低质量的产品延续到项目后期，则由于变化产生的时间和成本的消耗可能是致命的，也会增加维护的成本。适应性项目框架并没有考虑质量改进过程，而且忽视了初始迭代周期的作用。初始迭代周期完成后是调整计划的最佳时期，因为它是实际情况的真实体现，即使以后的迭代周期的实际情况会和初始周期有所偏差，但也不会过于偏离，而且随着迭代的进行，不确定性会减少。所以好的计划是使收益得到保障的首要因素。对适应性项目框架的软件应用改进主要是在过程中强调了风险管理和质量管理，并修改了计划部分，并着重强调了初始周期的作用。影响此类项目完成的最大的风险是需求变更造成的返工成本、时间消耗，需要靠风险缓解和质量控制来共同管理。所以，改进的重点在于适应需求变更。club.mypm.net
软件开发项目的适应性项目框架如图2。项目管理者联盟
 项目管理者联盟
图2中主要增加了风险缓冲后的基准计划、功能需求变更周期和质量改进周期。功能需求变更周期和质量改进周期是历时比较长的足够影响进度的活动。功能需求变更周期是由于业务需求变化导致的，可能是特定功能完全重新实施或者改进的过程。质量的改进周期区别于在功能需求变更周期的工作，这是在一定时期后，内部人员根据已完成项目功能的学习和经验总结进行的重新设计，改进已完成工作的质量，或为了适应变化所做的技术改进。风险缓冲后的基准计划是在中层计划基础上增加了风险缓冲的时间，包括功能需求变更周期和质量改进周期的预估时间。分离实施周期和修改周期是因为实施周期的时间和成本的预估是比较准确的，但修改周期的时间和重复次数却难以预测。在两个迭代周期的外围是个质量改进周期，表明在多个功能周期后进行质量改进。在改进前，需要评估改进的风险，作出权衡。这个周期结束后的产品被认为是一个非完全功能的发布版本。每个迭代周期还是和适应性项目框架中的一样，包括周期计划、实施和客户检查。另外一个区别是适应性框架只要求客户在客户检查点上参与，而这里要求全程参与，至少应在项目的前期阶段全程参与需求分析，目的是在一定程度上稳定需求，如果已经完成的功能再出现需求修改，付出的成本和时间将会大得多。如果出现了范围的变更则和客户协商调整基准计划。项目管理者联盟
四、基于敏捷方法的软件项目管理的计划与实施项目管理者联盟
(一)项目计划与风险项目管理者联盟
由于项目过程由传统的详细的需求计划的单一过程变成短的时间区间的具有反馈的多次迭代过程，并且为了对变化具有适应性，敏捷项目管理的计划方法分成详细周期计划与风险计划和质量计划结合的两种分层计划。项目管理者联盟
项目中的风险分为两种，一种是必然要发生的常规风险，一种是不确定的致命风险。前者可以通过风险缓解解决，后者则需要风险缓解和风险转化共同解决。在变化陛比较强的软件项目中，需求变更必将发生，这是软件项目所面临的主要风险，计划中加入需求变更周期的缓冲时间可减小项目的成本风险。项目管理者联盟
(二)极限项目管理计划与时间预测项目管理者联盟
极限项目管理是一个无基准计划的过程，没有时间和成本的限制，利用数量不定的短周期不断迭代，最终完成项目，或者在完成前，项目就被取消。传统的项目管理计划方法在此时起不到太大的作用，一般采用跟踪团队的开发速度和剩余的功能点来进行管理，只制定迭代周期内实施的计划。项目经理圈子
 项目管理者联盟
图3是Bum—down图，显示的是每个月后剩余的功能点数目。虚线1是要在12月完成的项目的计划线，虚线2是实际工作后的趋势线，这表明可能完成的日期。2月剩余的功能点多于初始点，是因为增加了新的功能。可以看到这并不能确定交付的日期，只能作为参考。.项目管理者联盟
(三)基于敏捷方法的软件开发计划项目管理者联盟
极限项目管理在某些极端的情况下确实很有效，比如新技术产品的研发。但是大多数软件项目的技术复杂度不是很高，或者曾有过类似的项目经验，项目的主要不确定性是业务需求的变化等，并受到时间和成本的限制，这些项目的重点是得到反馈并改进。项目管理论坛
|
