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

Posted 2023-05-12

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

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

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

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

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

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

传统项目管理

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

敏捷项目管理

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

敏捷项目管理

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

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

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

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

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

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

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

敏捷项目管理是一种灵活的项目管理方法，强调团队协作、快速响应变化和以价值为导向的方法，以实现更高的客户满意度和项目成功率。

与传统的项目管理相比，敏捷项目管理采用迭代和增量式方法，将项目分解为小的可管理的部分，每个部分都有其自己的目标和交付物。在每个迭代的结束时，团队会回顾和评估已完成的工作，并根据客户反馈和变化情况进行调整。

敏捷项目管理的核心价值观包括：

·个体和交互优先于流程和工具
·可工作的软件优先于详尽的文档
·客户合作优先于合同谈判
·响应变化优先于遵循计划

敏捷项目管理通常采用Scrum、Kanban、XP等方法来组织团队和管理项目。这些方法都强调团队的自组织和自主性，以及迭代和持续交付的理念。

敏捷项目进展迅速，8Manage PM敏捷项目管理工具可以帮助你提高业务敏捷性。系统的可视化和快速重组功能特点可帮助你的团队重新评估他们的计划并调整他们的优先级，从而与更新的目标保持一致。拥有强适应性优势的8Manage系统意味着团队可以始终如一地交付，并有效地管理客户不断变化的需求。

8Manage PM还具有可预测性，使你的团队可以在较短的时间周期内工作。这些固定的持续时间（例如1 周）使管理者更容易衡量团队绩效。

总的来说，敏捷管理更专注于尽早和持续地向企业交付价值。采用敏捷项目管理方法的团队可以提高项目交付速度、扩大协作并培养更好地响应市场趋势的能力。敏捷团队更像是一个划船队，每个人都需要让自己的动作同步，朝着同一方向前进，以确保成功。

敏捷软件开发 VS. 传统软件工程

敏捷软件开发 VS. 传统软件工程

软件工程这一术语1968年被提出，之后美国软件工程专家巴利·玻姆对十多年间研究软件工程的专家学者们提出的一些准则与信条，于1983年对提出软件工程的七条基本定理，将软件工程这一学科具体化，软件工程中开发与管理软件的方法也不断完备。而敏捷软件开发于2001年由Kent Beck和其他16位知名软件开发者提出，敏捷开发是人们对于传统软件开发方式的一种提出的新的挑战。本文将具体介绍软件传统工程与敏捷软件开发两种方法，并对两者进行对比分析。

一、传统软件工程

软件工程的产生与二十世纪六十年代的“软件危机”有很大的关系，由于当时的软件开发人员采取的方式未工程化，软件开发中遇到很多难以解决的问题，如软件生产不能满足需求，开发时间与成本难以估计以及软件可维护性差等。这使得人们开始考虑采用工程化方法来研制与维护软件，于是软件工程这一技术就这样诞生了。软件工程具有多层次，软件工程的基础在于软件过程，软件过程是指软件构建过程中执行的一系列活动、动作与任务的集合。软件工程的过程框架定义五种活动：沟通、策划、建模、构建与部署。只有这些活动并不能确定于过程之间的相互关系，因此需要一些模型来定义这些关系。

常见的传统软件工程过程模型:

1、 瀑布模型

瀑布模型提出一个系统的软件开发方法，通过策划，建模，构建和部署的过程，最终生产一个完整的软件并提供软件维护。瀑布模型是软件工程最早的模型，但是在实际的运用中，出现很多问题。瀑布模型需要客户明确需求，但是不能适应需求的不确定性，客户只有在软件完全完成了之后才能得到能够执行的软件，一些早期错误需要等到测试阶段才能发现，这些问题使得瀑布模型被现代软件工程界所抛弃。软件工程开发过程中经常遇到各种的变化，而瀑布模型往往不能够适应这些工作，但是在工作以线性方式完成时，瀑布模型还是一个非常有用的模型。事实上线性方法是人们最容易掌握并使用的方法，当人们遇到用线性方法解决不了的问题是，往往会考虑将问题分解为一系列线性问题，然后逐个解决。 

2、 增量模型

增量模型实质就是分段的线性模型，增量模型发布一系列称为增量的版本，逐渐为用户提供更多的功能。增量模型在每个阶段使用线性模型，增量模型在每个增量都能运行，这样能够很好的适应变化，客户也能够一直看到软件的开发，早期发生的错误能够得到解决，降低开发风险。增量模型能够解决瀑布模型的几个问题，但是仍然还是有一定的缺陷:软件的体系架构需要保证在新加构件时，能够对原系统无影响。

3、 螺旋模型

螺旋模型是一种演化过程模型，它结合了原型的迭代性质与瀑布模型的系统性与可控性的特点，能够有快速开发完善软件版本。螺旋模型最大的特点是具有其他模型不具备的风险分析，使得软件在面临重大风险时能够停止，减少损失。螺旋模型从圆心开始顺时针方向演进，第一圈一般开发出软件规格说明，在接下来的每次迭代中逐步完善，最终得到最终版本。螺旋的没圈都会跨过多个区域，需在每个迭代的每个区域中不断调整项目计划，直到迭代结束。螺旋模型适合开发大型的系统级应用。螺旋模型每个迭代都植入软件测试并累计开发成本，使得软件质量得到严格保证，而且开发成本容易掌握。但是螺旋模型的风险管理支出可能会过于庞大。           

二、敏捷软件开发

敏捷开发是一种新型的软件开发方法，具有应对快速变化的需求的能力。敏捷开发方法来源于2001年的一次软件开发者的集会，他们在会上成立“敏捷联盟”并签署了“敏捷软件开发宣言”，其中包括以下要点：

1、个人与这些个人之间的交流胜过了开发流程与工具

2、可以工作的软件胜过了详尽的文档

3、客户合作胜过了详细的文档

4、对变化的响应胜过了严格地遵循计划

敏捷联盟定义了12条原则：

1、对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。

2、我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

3、经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

4、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

5、 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

6、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

7、可以工作的软件是进度的主要度量标准。

8、 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

9、对卓越技术与良好设计的不断追求将有助于提高敏捷性。

10、简单——尽可能减少工作量的艺术至关重要。

11、最好的架构、需求和设计都源自自我组织的团队。

12、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

敏捷开发相比于其他方法更强调软件的适应性，而不是预见性。从本质上来讲，敏捷软件开发是为了克服传统软件工程中的弱点而形成的。在现实生活中，用户需求不断改变，很多情况下，完全无法充分定义需求。

极限编程是敏捷开发使用最广泛的一个方法，。极限编程包括策划、设计、编码、测试4个阶段。极限编程有12个实践原则：

1.计划的制定：包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。 

2.小版本：用最少的代码工作量带来最大的业务价值。 

3.简单设计：通过所有测试，没有重复和费解的逻辑代码，简单的设计能保证代码的简单。

4.测试：一个功能存在的前提是有一个测试能够验证它，任何有被破坏的可能的代码就必须有一个对应的测试。 

5.持续整合：大量减少在整合中耗费的时间，减少团队开发问题。 

6.重构：确保加入新功能后代码仍保持简单，从而保证简单的代码仍然能够运行所有的测试。 

7.配对编程：提供持续的信息反馈和确保正在编程的人进行重构、测试和遵守编码标准，实现代码共享目的。 

8.代码共享：在通过测试的前提下，任何一个人都能够对系统做出修改。

9.每周只工作40小时：充分利用你的时间，一个星期工作40小时已经足够了。 10.现场客户：讨论，使用程序员和客户都能够的语言描述功能。

11.隐喻：普通语言和术语的集合，用来预见项目中的功能。

12.编码标准：遵守编码标准，让其它程序员明白代码，减少不必要的沟通。

所有敏捷过程模型中使用最广泛的就是极限编程，当然也有很多其他模型，比如自适应软件开发、Scrum、动态系统开发方法等，这里就不加以讨论了。

三、传统软件工程与敏捷软件开发的对比

敏捷软件开发相对传统软件开发的优势：

1、 敏捷开发强调适应性，因此软件开发适应性更加强。就拿软件变化的成本来说，敏捷开发比传统软件工程少得多，这就是因为敏捷开发适应性更强。

2、 敏捷开发交付周期短，强调尽早将可用的功能交付使用，这样有利于软件在整个项目中持续改善。

3、 敏捷开发的工作效率更加高，人力资源得到更充分使用。

敏捷软件开发相比传统软件工程的劣势：

1、敏捷开发文档也传统软件工程相比显著减少，因此团队之间的交流就需要增加，而一旦工程很大的话，团队之间的交流会变得很困难。

2、对个人能力要求很高，团队人员要求开发能力强，团队之间沟通能力也不能弱。