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

Posted 2023-05-12

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

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

1.管理流程差异

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

(1) 传统项目管理

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

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

(2) 敏捷项目管理

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

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

图2-9洋葱计划图

2.风险控制环节

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

(1) 传统项目管理

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

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

(2) 敏捷项目管理

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

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

从找女朋友就可以体会出，敏捷与传统的区别

敏捷软件开发与传统软件开发的比较

敏捷软件开发与传统软件工程比较，我们可以化简一下，“开发”与“工程”这两个部分只是一个类似的名词，在我们的比较中可以先不以与考虑，所以我们要比较的其实就是是“敏捷”与“传统”的区别。

所以何谓敏捷，何为传统？

首先我们给出传统软件开发主要有以下步骤

　　可行性分析和项目开发计划

　　↓
　　需求分析
　　↓
　　概要设计
　　↓
　　详细设计
　　↓
　　编码
　　↓
　　测试
　　↓
　　维护

 

这就是我们平时学系的软件开发流程，在此不再过多分析了。

而敏捷在字面上首先理解的就是速度快，节省时间，这确实也是敏捷开发产生的原因。

敏捷软件开发的定义是：一种应对快速变化的需求的一种软件开发方法。基于迭代和增量开发，通过自组织，跨团队，沟通协作完成开发工作。

定义中与“敏捷”对应的就是“应对快速变化的需求”。看似我们看字面上首先的理解是错了，但是真的是这样吗？

我认为不是的，我们认真考虑在我们传统的软件开发中，我们会遇到快速变化吗？我们在最开始经过了漫长的可行性分析和项目开发计划、需求分析。然后我们才开始设计我们的软件。

难道我们分析了那么久，做了那么久计划，没有任何作用吗？

难道我们做了那么久计划还会仅仅在后面的软件开发接下来的几个部分中就在计划上又发生很大变化吗？

要是那样的话岂不是软件工程师在自己啪啪啪打着自己的脸＝。＝

所以笔者认为我们在传统软件开发中时是很少会遇到快速变化的项目的。但在定义中，“敏捷”又是对应着“应对快速变化”，这就说明敏捷软件开发从最初始的动机上就与传统软件开发存在着差异。

敏捷开发主要在最开始的时候是只有很少成型的计划的，在开发的过程中，不断跟着客户的需求变化，要求变化，对软件的功能进行着更改。

于是我想问大公司、成型的企业会不清楚自己想要的是什么吗？对于在市场中已经摸爬滚打这么多年的企业家会不清楚自己需要的是什么样的软件吗？我觉得他们是不需要再软件开发过程中不断对自己的需求进行更改的。

同时对于一个成型的大公司，他们的工作流程是固定统一的，同时上层的决策人物是没有那么多时间来不断处理软件方面的问题的，所以我认为已经成型的大企业是不需要这种再软件开发过程中需要快速变化的，他们需要的是有效率的，正确的，产品开发流程。

所以什么情况需要我们敏捷开发呢？

那就是当我们项目只有一个大的方向，一个最主要的功能，还没有规划好更多的细节以及分支，这时我们在一边软件开发的同时，我们的项目也在同时发展，所以这时我们的软件开发需要应对项目不断变化的需求。

我觉得值得注意的是，我们这时的变化，不是由我们软件开发这边引起的，而是项目的延伸发展引起的。

所以这时对于一个刚起步的项目来说，敏捷开发是极为适合的。

敏捷开发的特点是：

人与人的交互优先于过程和工具

可以工作的软件有限欲求全责备的文档

客户协作优先于合同谈判

随时应对变化优先于循规蹈矩

这样的特点、加上不断对用户的需求变化产生快速应对，所以我们的敏捷开发也就是为了快速而生的。

它有益于我们最初始的项目快速占领市场，有益于我们逐渐了解我们的项目所踏入的领域，更是有益于我们的逐渐晚上我们的产品。

所以我们所谈到的敏捷开更加适合我们正在逐渐发展的项目。

讲到这里我们可以对这两种开发的使用情况举一个例子。

试想一下我们现在大家苦苦寻觅男女朋友。

对于还没有过另一半人们我们找寻找另一半时，更多的是抱着试试的心里，是想要在谈恋爱时，逐渐了解自己的需求，逐渐形成自己对另一半的要求。

在不断的深入感情发展中，我们会有不同的要求，不同的矛盾，我们会不断地解决，不断的找到崭新的方法来解决问题，最终形成一对完美的情侣！

但对于那些已经很成熟的，曾经有过女朋友的人来说，在和之前的另一半分手后，会有很多已经规划好的条条框框，会知道自己想找到的另一半死什么样子，所以他不会急急忙忙开始一段感情，而是要经过我们的可行性分析以及需求分析，才能决定我们需要的另一半是不是眼前的这个她，或者是不是心中想的那个她。

到此我们已经到该知道了敏捷开发与传统开的区别了，就像我们男女盆友一样，没有绝对的好坏，在不同的时候，都会起到很好的效果。

最后在此希望我们同学们都能找到适合自己的另一半，希望已经找的，可以敏捷的“应对快速变化”，磨合出幸福的一对  :p