敏捷的项目管理

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇敏捷的项目管理范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

敏捷的项目管理范文第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篇

团队向敏捷的转变

向敏捷开发转换，管理层的支持是关键，而团队的认同则决定了敏捷执行的程度和结果。这个转换过程可以分几步、有选择性地在一些项目中开始。

许多企业走向敏捷是从组织培训开始的。培训可以是内部的，也可以聘请外部顾问，最重要的是负责培训的讲师一定要有丰富的敏捷经验。因为敏捷开发是一种经验科学，书本上的知识只能帮助了解，真正的掌握需要在实践中训练。

培训一般从公司的管理层开始，尤其是负责开发或工程的副总裁、经理等。培训的过程是一个认知的过程，也是一个取得管理层支持的重要步骤。开发团队的负责人是培训的重点。这些阶段比较典型的培训是两天的Scrum培训，培训以Scrum为主，但会涉及敏捷的方方面面。

项目实施是敏捷思想落地的过程。一般应选择在小型新项目中实践敏捷开发，这样可以降低风险。也有公司不得不从项目的中间开始实施敏捷开发，同样也有很多成功的例子。一般只要有上层的支持和得力的指导，并完成一两个敏捷周期，团队一般会完全转入敏捷开发的模式并不断提高。

在实施敏捷开发的过程中，团队的组织也是关键环节。敏捷开发团队有以下两个特点:

1. 是跨领域的平行联合团队，团队中应该有来自各个平行领域的人员，包括测试人员，甚至客户代表。目的是让这个团队能胜任开发周期中的所有任务。

2. 团队的职责和功能除了日常的开发任务外，还要完成各种自我管理和组织功能。大多数的管理和决策不再由管理层单独掌握，而是整个团队商议决定。每个成员都要对项目管理中的范围、时间、成本、风险等管理负责，每个成员在一定程度上成为项目经理。

课堂上的培训对团队来说只是个很好的开始，实践中的指导和训练更为重要。项目中的问题各种各样，所以，在敏捷项目的进行中最好能由经验丰富的敏捷顾问指导。由敏捷顾问带团队走完一个或几个开发周期，帮助团队解决、纠正敏捷实施中的具体问题，这样开发团队会更快地进入敏捷的思维和模式。

项目管理过渡到敏捷

开发团队按项目管理类型来分有两种。一类是比较正规、有不同程度的过程和方法管理的团队。由于PMBOK在中国有很多的应用，下面主要介绍如何从PMBOK的方法过渡到敏捷。另一类是无序的或介于有序和无序之间的团队，其管理基本依赖领队人员的经验，并无成型和稳定的套路。

PMBOK定义和描述了一套有关项目管理的知识体系。这套知识体系比较全面，涉及项目计划的集成以及项目的范围、质量、成本、风险、人力和物流等各个方面，与敏捷开发相比，PMBOK的主要不同点体现在以下方面:

1. PMBOK是计划推动的开发，一般来说要求有大量的前期规划和评估，而敏捷是价值推动，靠经验来优化。

2. PMBOK重视文档，每个阶段都有正式的文档要求，敏捷重视结果，文档往往被认为是一种浪费。

3. PMBOK的项目管理是自上而下的命令式管理，而敏捷的管理是团队的自我管理和经理们的服务式管理。

值得注意的是，尽管PMBOK和敏捷有以上原则性区别，但并不等于说PMBOK在敏捷开发中就没有价值。实际上，PMBOK中的大多数知识、概念和过程在敏捷中都被用到。

在PMBOK中，项目开始前要在范围、执行、成本等方面制定出详细的计划。在转向敏捷的过程中，这些计划并不是完全不用，而是被分散到各个短小的开发周期中了。例如，PMBOK要求项目开始前有尽可能详细的需求，并制定正规的需求更改规范和过程。而在敏捷开发中，项目开始前只有一个关于产品的远景规划，产品的功能需求是在开发过程中由用户的反馈和开发团队反馈一起来推动并逐步明确和细化的。正式的需求文档变成了分散的多个需求条目、功能或用户使用案例等。至于需求变动规范，大多数敏捷方法都积极预期这种变化并把对变化的管理嵌入到每个周期甚至每天的开发过程中了。

还有一点经常被用来当做敏捷的不足，即敏捷开发不能在一开始给出项目的成本计划，因此敏捷项目似乎无法进行成本的控制和管理，让许多外包性的项目无法采用敏捷。而实际上，PMBOK也无法做到准确的项目成本评估。PMBOK的做法是把所有的需求细化，然后把每个最小单位的估计总和起来。这样看似合理，但由于要对很久以后的开发作出估计，往往有很大的偏差。敏捷项目中的成本预算和管理可以用由上而下的方法。项目开始前，从总体的规划出发，讨论评估出一个大概的范围。在每个周期开始前，团队和用户再对周期的成本进行比较准确的预估和管理，这时PMBOK中的由下而上的方法就完全适用了。此后，在每个周期结束时再次根据当时的状况来调整对整个项目的成本估计。这样的成本控制和管理往往更准确、实用。

PMBOK对时间、质量、风险等的计划和管理可以遵循同样的原则转化为敏捷中的阶段性计划和管理来实施。

管理方式的转变是比较难的一方面。PMBOK中的项目管理风格是由上而下的计划、分配、指定、跟踪、评估和管理; 在敏捷开发中，团队要自我管理，计划的制定、任务的分配、质量的管理、项目的执行等都由整个团队协作进行。项目经理的职责是协调团队完成这些自我管理任务，并帮助团队排除遇到的障碍。项目经理要从命令式的管理思维转换成服务式的思维和行为。换句话说就是，原来PMBOK的项目经理是靠自己指挥一些人完成一项任务，而在敏捷中项目经理可能更需要做的是建立一种机制使所有的人能在其中自我协调完成某种任务，项目经理主要负责维护这种机制的正常运作和不断改进。

从实用主义走向敏捷

实用主义经常被处于无序或半无序状态的团队拿来标识自己。实际上，其中很多团队也并非都没有实施任何有序的方法，很多时候，其技术负责人会凭经验或自己掌握的一些方法来进行管理，有的也会采用敏捷中的一些方法。这些团队如果能和经验丰富的顾问或其他运用敏捷比较成功的团队交流，往往会认识到自己的局限性和离高层次敏捷开发的差距。

这些差距往往不在于敏捷的形式，例如故事或需求条目墙、站立会议等，而在于团队的开发和应变的速度、效率和自我管理能力。一旦决定采用敏捷开发，由于这些团队通常比较小而且没有任何成型的包袱，也没有摆脱固有过程的障碍，可能会更容易地过渡到敏捷开发。

总体而言，敏捷模式继承和发展了以往的软件工程理论和实践，并融入了人们对于软件开发的新的理解和理念。我们相信敏捷是为我国的软件企业带来高效率、高质量并促使开发团队职业化，推动我们赶超世界软件先锋的一个很好的机会。

作者简介

敏捷的项目管理范文第3篇

[关键词] 制造企业 项目管理 敏捷响应

我国已经成为世界级的加工制造中心。在全球化的竞争背景下，面对跨国公司的强势进入，我国制造业的竞争优势和持续发展，仅仅靠低劳动力成本是不够的。目前，我国的制造业整体上在产品的创新能力、成套能力、生产的自动化和优化水平、企业的管理和协作能力及竞争核心技术的开发等方面和国际先进水平方面还存在不小的差距[1]。更为严重的是多数的制造企业缺少现代化管理的理念、方法和手段，众多的企业处于经验管理阶段。小而全、大而全的庄园式企业缺乏快速响应市场的能力，严重制约着企业的生存和发展。企业持久的竞争优势和持续的发展源泉是不断的企业创新，管理模式创新作为企业创新的一个重要方面，对我国制造企业发展具有重要的意义。一个国家如果没有企业管理创新机制和现代化的企业管理模式，就不可能产生具有国际竞争力的现代制造业。为此，我国要适应世界管理发展趋势，探索自己的制造企业管理模式，不断提升制造企业参与国际市场的能力，进一步提高我国制造行业的整体竞争能力。

一、制造企业敏捷响应模式

1.企业生产经营体制的转变

近十几年来，信息技术的发展和企业组织结构的变化冲击了原有的生产经营体系，推动了制造企业生产经营体制的变革。制造行业买方市场的形成，使企业由单纯的经营管理领域逐渐地向服务拓展，产品越来越受到消费者个性化需求的影响。消费需求个性化增加了产品的复杂性，功能的多样化，单一或者几个企业难以通过简单的联盟来完成产品的生产。制造企业要想实现竞争中的持续性发展，必须在生产经营体制上实现一种转变。越来越多的企业意识到实现由传统的物流体制向先导物流与供应链管理方向的重要性。物流（Logistics）和供应链（Supply Chain）如今已经成为企业寻求长远发展，提高竞争力的主要源泉。企业在充分利用电子商务和现代物流管理的成果，增加生产的快速响应能力。从企业的战略角度上重视物流的再构筑和供应链体系上的联盟活动，在企业发展战略的基础上，实现企业生产经营体制的转变。

企业的生产体制实现了推式经营（Push Marketing）向拉式经营（Pull Marketing）的转变。从本质上讲，推式经营体制通过大量生产、伴随大规模物流体制而实现的批量商品处理和商品的运输，实现单位成本的下降。推式经营体制利用大规模集中生产、物流和流通库存达到规模经济效应。但是，在交易过程中产生的交易费用却很大。

随着竞争的加剧，推式经济体制的制度安排出现了较为严重的缺陷，同时，市场环境在消费者需求行为的变化、流通格局的变化和产品生产线的融合与经营网络的形成等几个方面的变革催生了企业生产经营理念从强调以正确的价格提供正确的商品过渡到提供正确的价格（right price）、提供正确的商品（right commodity）、在正确的操作成本（right cost）前提下，以正确的时间（right time）送到正确的地点（right place），实现依靠的是商流、物流、信息流和资金流的完美结合的拉式生产经营体制。拉式生产经营体制强调市将销售地点信息同步的传输给商品策划、设计、生产以及库存地点，通过销售地点的信息设计、生产、物流和经营决策。

2.业务外包格局的出现

实现项目产品的大批量和个性化，关注质量、完工时间和缩短项目的生命周期是制造企业现阶段的重要任务。在这种情况下，制造企业的规模趋于小型化，在保证核心及增值流程事业领域的基础上，减少非核心业务，增加对于市场的敏捷响应。

业务外包已经成为制造行业的一种重要的形式，其特点是业务流程中的动态联盟和供应链上的协同。从系统的角度来看，动态联盟实质就是一个系统，通过系统的优化实现供应链上成本的不断降低。通过信息化平台实现跟踪消费的个性化需求，提高敏捷响应的能力。系统的动态性决定了制造企业敏捷的特性。

3.敏捷响应模式

生产经营体制的转变使企业的视角转向销售导向，业务外包格局的出现加强了企业之间的协同，实现发展战略和灵活生产经营形成敏捷响应模式。制造企业的市场敏捷响以核心竞争能力为基础。通过信息化平台，总装项目产品在虚拟企业范畴内进行。制造企业敏捷响应实现的基础――项目团队在不同产权主体形成的动态联盟中成为基础的单元。敏捷模式的核心――项目团队不仅仅是制造计划的执行者和制造信息的快速响应者，还是大量制造实时信息的集散地。这些制造实施信息的快速采集、传递和利用的效率体现敏捷能力，在很大程度上决定了企业的生产进展、上市时间、生产成本、生产质量等关键目标，决定了企业对于市场的整体响应能力。

图1显示了联盟制造企业与项目产品对应的结构图。项目团队在项目办公室的领导，既要符合动态联盟，又要符合制造企业公司层面战略需要，具有虚拟性和继承性[4]。美国著名的科学家David I. Cleland指出，在应对全球化的市场变动中，战略管理和项目管理将起到关键性的作用[2]。在20世纪90年代提出的企业项目管理和项目组合管理正是项目管理理论和方法在企业中应用的一种体现。结合图1，在动态联盟中，以项目团队运作的方式把项目订单当作项目进行运作形成制造企业项目管理运作模式，在一定程度上实现敏捷响应。

制造企业项目管理是一种敏捷模式下制造企业运作的基础，它拓展了传统的项目管理理论，集成其他先进管理模式形成的面向整个项目产品供应链的战略，以提供客户个性化需求产品为宗旨，通过跟踪虚拟产业链上主制造企业总装项目产品的生产计划，实现企业对于需求的敏捷响应，通过按项目进行管理，实现产品成本、交货期和质量等因素的集成以及项目组合资源分配，以达到资源的优化、降低成本、缩短功能集成单元的生产周期，从而整体上提高总装项目产品上市的时间。

二、制造企业敏捷响应模式框架与知识体系

1.敏捷响应模式框架

制造企业的敏捷响应，就是企业建立能够对外部市场环境能够做出快速响应的组织结构和战略规划，通过改造传统的生产模式来增加对于市场的快速响应能力。敏捷响应不仅仅是一种战略上的敏捷，更是一种作业层面的敏捷，这两种敏捷通过柔性化的组织结构实现。如图2所示：

从战略层面，从企业发展的战略出发，通过项目的优选评价，确定项目的优先级。

从企业作业层面上，实现项目时间、成本、质量、设备利用率和员工安全度等目标的集成控制。

从企业作业层面上，进行项目的组合管理实现企业多项目资源分配的优化。

通过以上的分析我们可以看出，制造企业项目管理围绕作业层面展开，通过改善生产流程，优化过程管理，提高企业敏捷响应能力，实现敏捷响应战略。

2.敏捷模式知识体系

敏捷模式下制造企业项目管理注重人的因素、顾客、柔性、变革。本文认为，敏捷模式下的制造企业项目管理知识框架包含以下五个要素：项目管理目标、项目管理组织、项目管理信息系统、项目管理系统方法和项目管理文化。

(1)项目管理目标

项目管理目的是在企业敏捷战略指引下制定企业项目管理目标，即企业项目管理者的着眼点应以企业战略目标的达成为指导，而非局限于作业层面的“项目交付”。企业的战略目标是一种成果性的目标，比如持续的发展和企业绩效的提升等等。

(2)项目管理组织

项目管理组织是维持持续不断的企业管理活动，是项目成功实施的必要条件。项目管理组织的重要特征是柔性化。

(3)项目管理信息系统

信息系统通过优化整个信息流程，在合适的时间把合适的信息传递给需要信息的人员，这些信息包括项目管理理论与方法的管理支持信息，企业自身及其外部可以提供支持的信息，是一种全方位立体性的信息网络。

(4)项目管理系统方法

制造企业的发展需要关注各个利益的相关体、接近顾客群体，影响企业经营的因素越来越多，系统的观念对于企业经营的影响日渐显著。分析研究各要素之间的相互联系，需要从系统整体的角度进行优化经营。

(5)项目管理文化

企业文化要做相应的调整以适应企业战略项目管理的要求，形成统一标准化的语言，以使企业项目管理融入企业战略、战术决策及各项活动之中，成为员工一项自觉的行为。

敏捷模式下制造企业项目管理知识框架如图3所示。

三、制造企业敏捷响应模式关键技术

图2可以看出，制造企业敏捷响应模式解决、作业层面的单项目多目标集成、项目组合资源优化和公司战略层面的项目优选评价。

1.单项目多目标集成

项目订单中涉及成本、质量、交货期、设备利用率和员工安全度五个方面的目标构成一个系统，目标的完成是一个系统集成优化的过程。作业层面的多目标集成管理包含主动控制、被动控制和项目评估三个方面的内容。本质上看，多目标集成管理是一种多目标决策，由于目标的不可公度性，可以通过多极模糊评判法找到各因素的相对权重实施控制。

2.项目组合资源优化

资源的有限性促使企业不断的提高资源利用的效率。项目资源的优化通过释放关键资源，降低项目组合中单个项目占用资源的无效时间。

3.项目优选评价

在敏捷响应模式下,保证项目的组合能够综合有效的利用企业的资源。因此，确定项目执行的优选次序是制造企业项目管理的关键工作。项目评价标准直接影响到项目的优先顺序，进而影响到项目执行的顺序。对企业待选项目进行评价排序将保证实施的项目与企业敏捷战略紧密相连，项目优选顺序的确定也将影响到企业的持续发展。因此，科学实用的项目组合优选评价体系将是项目组合管理和制造企业项目管理成功的重要保证。一般地，需要从与企业战略的协同程度、竞争优势、降低运营成本、满足客户的需要或期望和对企业的价值贡献几个方面出发进行评价。

四、结语

项目管理作为一种近些年发展起来的一种新的管理模式，已经成为制造企业应对激烈竞争的市场环境的一种有效的方法。从战略的角度，通过战略管理和项目管理的结合的制造企业项目管理将成为企业实现持续发展，保持核心竞争能力的必经之路。这一模式的深入研究和应用将有助于实现组织、技术和人三者的有机结合，有效的应对制造企业面临的激烈竞争。

参考文献：

[1]戴勇马万太:生产过程数字化管理[M].科学出版社，2004年第一版

[2]Yang Xiaoyuan，Song Guanxing. On the intelligent evaluation system for agility of enterprises. In∶Proceedings of 1st International Conferenceon Engineering Design and Automation,EDA’97,Bangkok Thailand,1997, KY40026 USA∶Integrated Technology Systems Inc,1997

敏捷的项目管理范文第4篇

敏捷开发强调以人为本，认为面对面沟通是软件项目成功的一个重要因素。

当我询问一个研发经理关于敏捷开发所需的工具时，他开玩笑地说，一张白板和两杯咖啡。这也反映出开发人员对于敏捷方法的普遍认知。

事实上，许多开发项目主管虽然认同敏捷开发所强调的快速反应和沟通的理念，却担心它的“杂乱无章”带来的“不安定因素”。因为它极度地强调人的因素，使得人员的素质对敏捷团队的影响，远比对其他团队更大。

举例来说，配对检入是个保证代码质量很好的方法。但编程人员不了解其重要性，可能为了进度，常常一个人草草就检入了。因此，在采用敏捷方法时，若能适当地使用工具来保存累积的知识并固化关键过程，必能使敏捷项目更加成功。我们试以敏捷开发的几个主要特点为例，探讨工具在敏捷开发中扮演的角色。

特点一:测试驱动开发

传统的瀑布方法先编码再测试，等到发现需求和设计上的问题，为了节省费用，常常不了了之。测试驱动开发是在需求产生后，设计模块和其之间的接口，并将单元测试代码完成。在此过程中，需求和设计上的偏差将会被发现。由于编码尚未进行，只需更改需求和设计即可，避免造成太大浪费。

特点二:简单设计

敏捷开发崇尚简单的渐进设计，而不是剧烈的颠覆式设计。其目标是首先只设计我们所了解的那些部分，然后使该设计随着时间的推移而逐渐改进，这有助于提高灵活性并将变化导致的成本最小化。

特点三:配对编程

尽管两人一组的配对编程从理论上看使眼前目标和长远目标都得以保证，这却是敏捷方法中备受争议的做法，反对者普遍认为它会导致耗时加倍。广义的配对编程也包括前面提到的配对检入(Pair Check-in)，也就是由两人一起检验代码的正确性，然后才检入。

特点四:小型

周期短可使对项目的评估提前，进而降低了风险性。但这所带来是大量的可执行文档，造成管理上的困难。

工具所扮演之角色

现在让我们以一个典型的敏捷团队DevAgile为例，看看该如何用工具实现其敏捷过程和设想（图1）。Smart先生是DevAgile团队的项目经理，他被要求在开发过程中体现我们以上所列的几方面特点，在配对编程方面还要求配对检入。

图1 工具对敏捷开发的支持示例

角色1:需求管理的利器

对项目需求和设计文档的管理是DevAgile必须首先面对的问题。他们要完成的，恰恰是一个需求变更很快的项目，这也是他们选择敏捷开发的重要原因。在敏捷开发中，需求的变化常常是为下一次迭代提供信息和进度计划的依据。

因此，DevAgile的大多数成员认为，记录下每一次关键的需求变更很重要，尽管最初有些人坚持敏捷开发并不需要文档。

同时，他们也注意到，要遵循简单设计的原则，并非意味着设计文档不需管理。相反，文档的数量和版本都会比采用其他开发方式更多。这些设计文档及其历史应该被妥善地管理，也要和相对应的配置项链接。

另外，小型意味着整个生命周期中有更多的，如何对这些进行系统化管理也是DevAgile团队必须解决的问题。

综合以上这几点考虑，Smart先生认为，应该找到一种需求管理的武器。DevAgile团队在进行了一番市场调研后，决定尝试TechExcel DevSpec这种需求管理工具。它不仅提出“以知识为核心”的概念，满足需求和设计文档管理的要求，还实现了真正的“功能驱动开发”。

尽管DevAgile目前没有清楚的看到后者如何实现，但DevSpec对产品需求、产品功能及知识文档的系统管理还是吸引了他们。

它成全了设计团队的敏捷性，支持简单设计，并对他们经常修改设计的做法提供了管理上的帮助。一些成员还指出，在敏捷开发的道路上，太多的不确定因素和灵活性难免会影响大家对最终产品的认识，有一个这样的工具能够时时刻刻描绘出要产品的清晰轮廓，记录下产品需求和功能变更的每一步，实在是很令人欣慰。

另外，为了配合数量多的小型，DevSpec还有整理功能点的能力。也就是说，将和某一有关的新功能、功能变更，以及缺陷修复，全都进行统一组织和管理。

例如，要完成6.1的，他们只需把6.1功能文件夹里所有的新功能、功能变更，以及缺陷修复全都做完，6.1版本也就可以了。为了更大程度上提高开发效率，Smart先生还别出心裁的对这些功能及缺陷设定了优先级，优先级低的任务可能被延缓执行。实践证明，这种具灵活性且针对来管理的系统使小型越发容易。

角色2:项目规划的利器

Smart先生发现敏捷的项目管理要能做到随机应变，应付各种可能出现的情况，也是建立在对任务的细分，并对任务的状态采取高频度的探测并及时调整的基础上。DevAgile选择了TechExcel DevPlan作为项目规划工具，因为它能够围绕DevSpec中管理的功能点进行迭代计划，对人力资源进行管理，既把握了正确的宏观方向，又能对任务细分。任务若被耽延，还可以反馈回来。

Smart先生认为，作为敏捷团队的项目经理，他应该从传统项目经理的“工头”身份中解脱出来，发挥他的领导力，去监控和协调开发过程。虽然项目经理还是必须定义和初始化项目，作项目计划，执行计划，监督并控制结果。

但是完成这些步骤的方式却是不同的。具体来说，敏捷项目的计划不再是详细的完整的项目实施步骤和资源分配，而更多的表现为一种迭代计划。在开发人员与客户或其他团队沟通的每一次迭代中，计划和资源分配随时可能被调整，以不断适应项目进展的需要。在DevPlan的帮助下，这种调整变得方向明确、清晰和有据可查。它将每一次迭代的框架确定下来，剩下的工作就是根据这个框架实施了。

角色3:测试管理的利器

有了DevPlan，测试计划和开发计划开始制定，项目在一种既有序又敏捷的机制下运有序地转着。为了实现“测试驱动开发”，DevAgile不可避免的遇到了测试管理的问题。他们注意到，需求管理工具DevSpec内的需求，可被直接导入测试管理工具TechExcel DevTest，并自动生成测试任务。所有测试任务可以遵照既定的工作流执行，保证测试工作的有序开展和管理，并在编码之前发现设计偏差。

另外，他们以往是用光盘来存储可执行版本，文件柜的每一个抽屉里都装满了光盘。在进行敏捷开发以后，光盘的数量更是与日俱增，要找某版本的光盘时，多半是很困难的。

DevTest能够保存和管理的软件版本，而且和DevSpec内的功能及缺陷文件夹相对应。也就是说，若在需求管理工具DevSpec内有个6.1功能文件夹，那么在测试管理工具DevTest中也有个相对应的6.1文件夹。这显然比用其他方式来存储软件版本更加科学和方便。

角色4:任务执行的利器

有了以上这些项目管理的利器之后，DevAgile团队的工作并非一帆风顺，因为新的问题又出现了:一些成员片面的认为敏捷开发是一种松散型开发模式，也就是不需要遵守固定的流程。这直接导致了很多开发任务的执行效果糟糕，有些任务被提出以后就失去了踪迹，就连Smart先生也难以追踪每一个任务的结果。

于是，DevAgile团队又引入了与DevSpec和DevTest可以集成的DevTrack。这是一个开发任务的跟踪管理工具，提供既固化又可灵活更改的流程，对每一个任务的生命周期进行严格管理。它保证该走的过程一定走过;该反馈的一定反馈;该提醒的一定提醒;若任务需被升级，那就一定会被自动升级。更令人兴奋的是，当任务完成之后，其结果会自动返回需求管理工具DevSpec或测试管理工具DevTest。Smart先生可以轻易地由DevSpec看到针对6.1版本的所有功能和开发任务是否全部做完，对的管理省时省事。

直到实施了任务执行管理工具DevTrack，Smart先生才逐渐认识到由DevSpec引导的“功能驱动开发”是如何实现的。DevPlan中的迭代计划、DevTest中的测试任务和DevTrack中的开发任务，都是围绕DevSpec中的功能展开的。这不仅使整个敏捷过程都严格围绕最终产品进行，而且其中的可追溯性和可核查性，也正是敏捷开发思想的有益补充。

现在，当项目成员在会议室和用户讨论得热火朝天的时候，Smart先生可以悠闲地在电脑前喝咖啡了，他知道整个过程都是可以控制的，需求和设计变化再多再大，经历再多的迭代和小型，只要所有功能都按照计划被开发和测试，项目还是会如期完成。

敏捷团队的成功案例总结

毫无疑问，DevAgile团队最终用敏捷开发方式取得了项目成功。让我们再来总结一下，他们是如何具体做到的呢？首先，需求被搜集和整理，产品功能和简单设计产生，将这些结构框架和相关文档存入DevSpec之后，开始制定迭代计划，并定义模块接口。紧跟着，针对接口做出测试代码。这些知识文档全由DevSpec来管理，因此DevSpec中形成了由需求、功能和知识文档组成的“概念产品”。

最后，功能点被导入DevTest而产生一个或多个测试任务，每一个测试任务都能按照DevTrack中定义的工作流（图2）进行。

图2 DevTrack中定义的测试任务工作流示例

图2的工作流被启动之后，编码人员在第一状态负责编写代码、重构和白盒测试。项目经理为了实现配对检入，把第二状态设为需有A和B两人一起检入的“配对检入”。每一个状态都有明确的负责人。A可以是第一状态负责人，而与A配对的人员则可以是跟A 所做的任务有关的人员。第三状态负责人可以是测试人员，在单元测试成功后便完成了整个流程。反之，则重新回到第一状态。

以上的案例中，对所提到的四个敏捷特点都有所注解。当然，这是一个可行的方案，而绝非唯一。

另外，面对面沟通也是个很好的敏捷操作，但是实际上却不易实现。客户或熟知商业逻辑的同事通常是无法长时间和开发设计人员在一起工作的。若一定要面对面，很可能会以高昂的费用为代价。更实际的方式是通过一定的沟通平台（如一些即时语音或视频通讯工具）来达到类似面对面的沟通。

无论采用何种方式，沟通后的结果都要能妥善地记录下来。知识的分类和历史的记录会使清晰度达到最高，进而使后来的一切活动，包括编码、测试、分析等，都变得容易。

敏捷的项目管理范文第5篇

1.1方法

对照组行传统护理，观察组行项目管理法，具体措施如下:

1.1.1科室中组成“智能团队”:由疗养护理经验丰富、反应迅速、思维敏捷的护理人员为团队成员，通过有效沟通对老年疗养院住院期间的安全隐患进行沟通，制定项目管理计划并对各部门、相关人员责任加以明确，制定详细实施方法［2］。经讨论，老年疗养院住院期间的风险因素包括疗养员因素、环境因素、护理人员因素、护理管理因素等内容。

1.1.2制定管理目标与具体实施:

①制定并不断完善规章制度:以老年疗养员特征与护理工作特点制定合理到了管理目标，积极探寻存在的风险并制定护理质量评价标准，对考核标准予以细化。建立疗养员跌倒坠床评估表和疗养员意外风险评估表，及时填写评估表，对于评分高者，护士给予重点关注、重点巡视，制定护理质量监督机制并加强监督、考核，实行弹性排班制度。

②不断增强专业素质:定期展开专业知识培训，通过板报、观看宣传片、标语等加大护理安全宣传力度，鼓励护理人员参与学术交流，不断提高其专业理论知识掌握程度，增强其安全意识。新上岗护理人员应给予充分岗前培训，增强其和疗养员沟通的技巧，待各项考核均合格后才可上岗。

③创造舒适的疗区环境:疗养房间应保持整洁、舒适温馨，温度及湿度应适宜且应保证空气流通］，为疗养员营造家的氛围。入院时详细介绍疗养房间内的设施，房间设计合理，物品摆放整齐。卫生间设有安全扶手，做好防滑标识张贴、防滑垫安装等，为疗养员安全提供最大限度保障］。

④对疗养员展开全面健康教育:护理人员保证仪容整洁大方，以亲切和蔼的态度主动为疗养员讲解医院环境，根据疗养员性格、家庭背景、职业、学历展开针对性的健康教育，同时给予有效的心理干预。护理人员要对随员介绍疗养员用药指导、饮食指导、运动指导、养生保健知识及疗养期间的注意事项等，增强其养成健康的生活方式和行为。

⑤提高护理人员责任意识:护理人员应主动引导疗养员逐步熟悉医院环境，耐心讲解各项设施使用方法及效果，建立和谐的护患关系，给予疗养员充分的尊重与关怀。对疗养员疑问应耐心解答，同时应针对老年疗养员不安全因素制定意外风险防范措施、预防跌倒措施，减少突发事件，在应对突发事件时具备相应的应急能力。

1.2观察指标

设计护理满意度调查表对疗养员关于护理工作的满意情况进行分析，包含6项内容，分为满意、很满意、需改进3个等级，同时记录两组护理纠纷、跌倒等发生情况。

1.3统计学方法

以SPSS16.0软件对数据进行分析，计数资料行χ2检验，等级资料采用两独立样本的Wilcoxon秩和检验检验水准=0.05。

2.结果

2.1两组护理效果比较

2.2两组疗养员对护理服务满意度比较。

3.讨论