瀑布型敏捷型项目管理

本文目录一览：

• 1、传统项目管理VS敏捷项目管理
• 2、瀑布开发、敏捷开发的优缺点是什么？
• 3、.net敏捷开发和瀑布开发的分别是啥意思
• 4、敏捷项目管理相关知识
• 5、敏捷开发与瀑布有那么大区别么，瀑布开发就不能重视
• 6、敏捷项目管理与传统项目管理比较

传统项目管理VS敏捷项目管理

很多人都知道，项目管理领域有两种管理方式：传统项目管理和敏捷项目管理。很多人在团队引入敏捷的时候，会有一个疑惑，传统项目管理和敏捷项目管理的区别是什么？

在1969年以前，不管是制造汽车还是制造轮船，全世界的项目管理都没有太多的章法和规则。

直到1969年美国成立了PMI组织，推出了PMBOK一整套规则、PMP认证后，全世界的项目管理就有了章法、有了规则。

直到现在，绝大部分行业还是使用这套标准项目管理方法——传统的项目管理。

直到2001年，有17个软件行业开发者在犹他州Snowbird滑雪胜地里聚会，他们白天滑雪，晚上喝酒聊天，聊着聊着发现，他们一致认为传统项目管理不适用于软件行业的，然后他们制定并签署了行业最重要的文件之一：敏捷宣言。他们还在这里塑造了许多关于软件的构想、开发和交付的方式，甚至是世界如何运作的方式。

所以敏捷这个概念是非常新颖的，2006-2007年期间，敏捷就被引入中国，腾讯就是最早使用敏捷的企业之一。同时，对于一些要考虑很多问题的项目，例如：“有没有流量？”、“别人愿不愿意来”等等，所以他们需求是不确定的，按照以前传统项目管理方法是行不通的，所以敏捷就诞生了。

传统项目管理

通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。

敏捷项目管理

作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。

敏捷项目管理

声称要摆脱繁冗的流程制度文档，但是对于关键的项目文档，比如需求规格说明书等等，也是要求必须具备的。所以，敏捷项目管理的项目流程制度上的管理可以看作是对一套完善的项目管理流程制度的裁剪，只不过这个裁剪的尺度比较大，从而也对敏捷项目团队成员的适应性，自主性提出了较高的要求。

具体的敏捷方法在每个迭代周期中都存在立会制度，燃尽图、看板监控、计划发布等，这些和PMBOK中对项目生命周期的五个过程组启动、规划、执行、监控和收尾的定义没有冲突矛盾，实际上敏捷项目管理的这些措施可以看作是PMBOK项目生命期五个过程组执行的微缩版，区别在于敏捷项目管理的迭代周期，时间很短，在去执行过程中裁剪了很多规范正式的项目管理流程制度。

1、不同的管理方式适用于不同类型的项目，敏捷更适用于未知、不可知或持续变化的项目；

2、传统的管理方式有如计划经济体制，敏捷有如市场经济体制，适应变化的能力不同；

3、极大地缩短了用户与开发者，预期目标与实施状况，投资与投资回报之间的反馈回路；

4、将小型团队转化为自身命运的管理者，团队接受挑战，找寻应对挑战的方法，发挥创意，避开工作障碍，而这一切都无法由中央控制及调度系统预先安排。

当处于快速发展的社会环境、面临复杂而多变的项目时，传统项目管理方式常常面临进度延期、成本超支、质量不过关、客户满意度低、变更频繁等问题，而敏捷项目管理可以说是在原本完善的项目管理流程制度上进行了尺度较大的裁剪，从而对敏捷项目团队成员的适应性，自主性提出了较高要求，可以使项目经理将最大限度的项目资源和活动用于产生增值结果上。

瀑布开发、敏捷开发的优缺点是什么？

瀑布模型式就是是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

一、瀑布开发

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。

变更代价大：既然叫作瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。

束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。

周期漫长：整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。

二、敏捷软件开发

敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

缺点：

很难进行准确的资源规划

很难准确的定义“轻量的“或必要的文档

很难把握整体产品的一致性

很难预测有限的终点

很难有效地进行度量

希望能帮到你，谢谢！

.net敏捷开发和瀑布开发的分别是啥意思

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

系统开发方式众多，项目管理者只需决定何时采取何种开发模式即可。瀑布开发模式就是一种最常用的开发模型，因为这种开发方式不但简单直观而且大大便利了项目管理的运做。

瀑布开发模式可以令项目管理人员非常方便地把整个项目置于自己的掌握之下。瀑布开发模式限制了开发期间团队间的交互，评估起来相当方便，由于开发计划稳定而且几乎不会发生经常性的变化从而有效地简化了项目开发的管理工作。

瀑布开发也有一些缺点，但是，在你初履新职，刚刚接手管理一个新的团队，同时获得了一种支持瀑布开发模式的解决方案的情况下，这种开发模式可以令你很快进入角色把工作开展起来，从而为将来采用更高级的开发方式做好了准备。

瀑布开发过程在政府项目中特别受到欢迎，在这样的软件开发项目中，其规划阶段超出了大多数企业部署阶段的时间和力度。采用这种方式的其他用户包括那些理解比较全面和深入的软件项目，相关的解决方案对团队而言非常熟悉，或者只需要小小的改动。

敏捷项目管理相关知识

客户对持续创新和降低试验成本的需求，标志着从预见性开发方式到适应性开发方式的重大转变。不确定性、不断缩短的进度以及迭代研究的需求不仅限于新产品开发。但只有创新和更快的开发还不够，公司必须给客户交付更好的、更符合需要的产品。虽然公司需要从高强度的产品开发工作中获得成果，但不应该以质量为代价。 敏捷开发强调速度、机动性和质量 ，要创造高质量的产品且速度要快。为了实现这个目标，个人和团队必须要有高度的纪律性，这里说的是自律而不是被迫遵守纪律。

构建创新产品、流程和商业模式需要有一个新的通用的管理方法和有针对性的项目管理方法。一个良好的敏捷项目管理需要实现5个关键的商业目标：

敏捷 是制造并响应变化从而在动荡的商业环境中创造利润的能力。

敏捷 是平衡灵活性和稳定性的能力。

制造变化需要创新：开发新产品、建立新的销售渠道、缩短产品开发周期、为日益变小的细分市场定制个性化产品。此外，公司还必须能够迅速响应竞争对手和客户制造的可预见和不可预见的变化。

敏捷强调的是 态度 而不是流程，它是 氛围 而不是方法。

团队为何存在、要创造什么产品、为谁而创造以及如何共同工作，这些组成了敏捷项目管理的核心原则。 “在业绩优良的团队中，领导管理原则，而原则管理团队。” 想要创造优秀的产品，就需要优秀的人才，想要留住优秀的人才，就需要有优秀的原则。

任务管理团队管理：

团队管理者 鼓励团队成员自我管理，通过完成拆分任务从而实现产品功能的开发。而 任务管理者 只关注任务的完成情况，并用其评估团队是否遵循计划行事。 团队管理者 是帮助团队（或者更广泛意义的项目组）成员协同有效的工作从而保证他们能够成功的完成任务。而 任务管理者 只是监督其成员，以确保他们在工作并能跟上计划进度。

敏捷项目管理者应该具有的 核心价值观 ：

提供客户价值涉及三个重要话题：一是将重点放在 创新和适应性 而不是效率和优化，二是专注于 执行 ，三是 精益 思维。

传统瀑布式开发方式在项目结束时交付价值，而敏捷项目可以快速并递增地在整个项目期内交付价值。采用迭代、基于功能的交付方式，能在早期捕获价值，而且通常可以极大地提高项目的投资回报率。

敏捷的 迭代 组成部分主要有：迭代、基于功能、时间框和增量。迭代开发是指要建造产品的部分版本，然后通过连续的短期开发以及评审和修改，拓展该版本。时间框强制迭代的结束，强迫在充分准备之前，制造出部分实体。增量开发是指建造的产品，在经过一次或者多次迭代后可以及时的被调用。

迭代长度分为三种——每周、每月和每季度。每周的迭代目标是维护和微小改进工作，每月的迭代目标是专项改进，每季度的迭代目标是重要的新功能的开发。

敏捷领导者领导团队，非敏捷领导者管理任务。“敏捷”是社会技术运动，它有两个推动力：一个是愿望——创造一种特定的工作环境；另一个是信念——适应性强的环境是向客户提供创新产品目标的关键。

自我组织团队 是敏捷项目管理的核心，他们结合了自由和责任、灵活性和结构。在自我组织的团队中， 个人负责管理自己的工作量，根据需要和最合适的原则轮班工作，并对团队效率负责 。

敏捷领导管理团队，敏捷团队管理自己的任务。敏捷领导阐明团队目的和目标、产品构想、关键性能和约束，然后激励团队成员交付——团队人员自己弄清楚如何完成任务的细节。这种方式赋予团队灵活性和适应性，而不是盲目遵循既定的任务，而且这种方法可以鼓励团队自我组织，找到最好的方式实现目标。

传统的项目管理者注重按计划行事，尽量做到和计划没有出入；而敏捷项目领导者关注如何成功地去适应不可避免出现的变化。 适应性原则 可以概括如下：

有效的团队在进行回顾时往往涉及四个领域： 产品 ——从客户角度和技术质量角度； 流程 ——团队正在使用的优秀流程和做法； 团队 ——作为高绩效团队的工作情况； 项目 ——项目按计划进行得如何。

开发优质的产品需要探索，而不是遵循计划。探索和适应是创新的两个特质——拥有探索未知世界的勇气、拥有承认错误并适应形势的谦逊。

一个组织要想保持快速增长，就必须明确绩效评估方法。

传统项目管理绩效评估铁三角 ：范围、进度和成本。许多情况下范围被认为是首要要素，而成本和进度是可变的。

早期衡量敏捷项目铁三角 ：进度是固定的，范围可以有变化。实质上，跟前一个评价方式是一样的。

敏捷三角形 ：考量指标是价值（向客户交付价值）、质量（需要向客户交付可持续的价值）、约束（范围、进度和成本）。这里，约束仍然是重要的项目评估参数，但不是最终要实现的目标。价值是目标，为了提升客户价值，这几个约束可以随着项目的进展适时做出调整。

因此 敏捷项目评估 的3个目标为：

敏捷项目管理交付方法包括五个阶段：构想、推测、探索、适应和结束。

敏捷开发与瀑布有那么大区别么，瀑布开发就不能重视

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

系统开发方式众多，项目管理者只需决定何时采取何种开发模式即可。瀑布开发模式就是一种最常用的开发模型，因为这种开发方式不但简单直观而且大大便利了项目管理的运做。

瀑布开发模式可以令项目管理人员非常方便地把整个项目置于自己的掌握之下。瀑布开发模式限制了开发期间团队间的交互，评估起来相当方便，由于开发计划稳定而且几乎不会发生经常性的变化从而有效地简化了项目开发的管理工作。

瀑布开发也有一些缺点，但是，在你初履新职，刚刚接手管理一个新的团队，同时获得了一种支持瀑布开发模式的解决方案的情况下，这种开发模式可以令你很快进入角色把工作开展起来，从而为将来采用更高级的开发方式做好了准备。

瀑布开发过程在政府项目中特别受到欢迎，在这样的软件开发项目中，其规划阶段超出了大多数企业部署阶段的时间和力度。采用这种方式的其他用户包括那些理解比较全面和深入的软件项目，相关的解决方案对团队而言非常熟悉，或者只需要小小的改动。

板BIOS被破坏的故障，可以插上ISA显卡看

敏捷项目管理与传统项目管理比较

传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响项目的交付质量。

敏捷项目管理作为新兴的项目管理模式，简化了传统项目管理的烦琐流程和文档。以Scrum为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入项目继续迭代需求池，丰富项目的产品功能。

1.管理流程差异

完整的项目管理流程可以分为5 个过程组: 启动、规划、执行、监控、收尾。

(1) 传统项目管理

传统项目管理要对项目的所有过程进行管理和风险把控，并要求在不同环节都要有文档输入和输出。例如，PMBOK对项目整合管理的过程组做了文档输入和输出的整理。但是，项目管理主要是对范围、进度、成本、质量、人力资源、沟通、风险、采购和利益相关者进行管理，每个环节都存在启动、规划、执行、监控和收尾过程。

如果采用传统的项目管理模式，每个环节都必须进行严格的规划，一旦出现规划以外的变更，则需要经过批准后才能执行。

(2) 敏捷项目管理

敏捷项目管理简化了烦琐的流程和文档管理，主张团队内部的面对面沟通和交流。以Scrum为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得十分友好。

在敏捷项目中，项目管理计划分为不同的等级，可以用洋葱图来表示，也就是洋葱计划图，如图2-9 所示。战略和投资规划在敏捷项目管理的最外层，由更广泛的组织管理系统来处理。由外往内，不断切分项目计划，最后，实现最小周期的可行性版本迭代。对复杂或不明确的客户需求进行合理的分割，最终实现总体上的统一。

图2-9洋葱计划图

2.风险控制环节

项目风险是指在任何项目中都存在的不确定性，一旦发生，会对项目造成积极或消极的影响，如范围、进度、成本和质量。

(1) 传统项目管理

    传统项目管理要求项目在规划过程中规划风险管理、识别风险，并且对风险进行定性/ 定量分析，给出风险应对方案。虽然对已知的风险可以在被识别和分析后采取应对措施，但正是因为风险的不确定性，要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的资源储备。

所以，传统项目管理会要求提供风险登记表，并且记录风险应对措施在处理已识别风险及其根源方面的有效性，完成风险再评估和风险审计，直到风险被降到最低。

(2) 敏捷项目管理

敏捷项目管理不同于传统项目管理，开发评估是以工作量为导向而非以时间为导向。所以，在进行开发任务评估时，采用的是相对估算而不是绝对估算，为风险留足了应对空间。同时，Scrum集合了一线人员，分享经验，集思广益，将小型团队转化成独立的管理者，更有利于问题的解决。

敏捷项目管理在项目正式结束前交付的可用软件是允许风险存在的，并且是根据风险的优先级来进行排期修复的。