敏捷的项目管理方法论

本文目录一览：

• 1、acp和pmp哪个好
• 2、PMI-ACP 敏捷项目管理10——干系人分析与管理干系人参与
• 3、Agile敏捷管理
• 4、ACP和PMP有哪些区别？
• 5、pmp和acp哪个含金量高知乎
• 6、敏捷项目管理相关知识

acp和pmp哪个好

PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会（Project Management Institute(简称PMI)）发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。

ACP(Agile Certified Practitioner)敏捷管理专业人士资格认证,它是由美国项目管理协会（Project Management Institute(PMI)发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证。

PMP认证和ACP认证，一个是项目管理的标准和框架体系最佳实践，一个是以“为用户提供价值”为核心价值观的方法论实践；一个是计划驱动，一个是价值导向。这两种相辅相成的项目管理方法，它们应用于不同环境下，相互补充。

PMP与ACP并不是相互独立或对立存在，而是做事方式的不同选择。在项目管理实践中将他们结合起来能更好地达成利益相关方的诉求。ACP特别验证了从业者在项目工作中理解及实施敏捷管理原则与实践的能力。PMP则认证了从业者所表现出的领导和引导项目团队的能力。

PMI-ACP 敏捷项目管理10——干系人分析与管理干系人参与

干系人分析是系统地收集和分析各种信息，以便确定在整个项目中应该考虑那些人的利益。通过干系人分析识别出干系人的利益、期望和影响，并把它们与项目的目的联系起来。干系人分析也有助于了解干系人之间的关系，以便利用这些关系建立联盟和合作伙伴，从而提高项目成功的可能性。在项目或阶段的不同时期，应该对干系人之间的关系施加不同影响，所以，要基于干系人的价值进行分析。

故事地图是客户价值优先级排序的工具，提供了一个关于功能合适交付的产品路线图。故事地图解释哪些会纳入第一个版本、第二版本或者子版本。故事地图还可以用作和跟干系人沟通的工具，把地图放在墙上作为一个项目计划的信息发射源。故事地图鼓励大家用不同的凡是参与，通过可视化的展示引发干系人的关注。

把干系人和用户的优先级纳入到项目的优先级中并且执行，结合干系人的优先级来进行项目优先级的排序，让干系人价值具体化，确保不要做一些干系人不支持或者没有价值的功能。

管理干系人的参与是指在整个项目中，与干系人进行沟通和协作，解决过程中出现问题，促进干系人合理参与到项目的相关活动。管理干系人的参与可以帮助项目经理提升来自干系人的支持，并把干系人的抵制降到最低，从而显著提升项目成功的概率。管理干系人的参与有多种方法，但是不管采用哪种方法，都要确保管理干系人的参与是可视的并且是可监控的。另外，要鼓励干系人参与计划会和回顾会，从而提高干系人的参与。

有效沟通是敏捷的奠基石，沟通是在不同部分传递信息。沟通管理是敏捷的一个知识领域，PMI除此之外有几个关于沟通的定义。

从敏捷的角度而言，团队间的沟通建立在过程中，通过写作、信息发射源、日常站会、回顾会、等得以促进。敏捷中的沟通倡导可视化，希望产品负责人、顾客、用户能高度参与项目并使用沟通技巧。

在敏捷中，最好的沟通方式就是面对面沟通。面对面沟通是沟通中最高带宽的沟通，所以面对面沟通也可以称为"高带宽沟通"。面对面沟通在同一个时间内可以传递的信息最多，并且能够获得一些及时的信息。而静态的沟通方法，例如文档，就不能做到这些。

项目通常需要很长时间才能完成，但是客户经常在描述他们期望的东西后希望可以尽快获得。因此，频繁地给干系人展示项目已经实现的东西就显得很重要。这些模型或者展示并不是单单让我们检查我们正在构建的东西，还可以给客户或者发起人进行一些过程展示。因此，需要及时跟干系人沟通，确保他们被及时告知当前项目的状态。

与客户密切联系并且给他们展示已经构建的项目的一些组件，保证项目过程的实际速度是可视的。过程的实际速度并非发起人或者客户所听到的，有时候会存在偏差，甚至对干系人来说是坏笑话。如果这些信息能够被尽早交付，即使坏消息也是有价值的。通过监控和讨论这些信息，可以做出更好的权衡。

速度是每个迭代中对团队能力的一个度量。这个度量帮助我们基于上一个迭代完成的故事点数评估团队后续的工作能力。当我们想跟联系人沟通已经完成什么功能，将要完成什么以及我们期待什么时候完成项目，速度就是一个很好的度量方式。团队可以在任何工作单元去测量其的速度，所以，这些单元可以是小时数、天数、点数。

敏捷建模涉及敏捷项目中常用的建模技术。模型在敏捷方法中非常重要。敏捷经常聚焦在模型的讨论和创建，而不是最终的产出物上。敏捷模型经常需要在白板上画出来，然后通过拍照记录下来。

不管你创建的是什么模型，目标都是为了交付价值而不是无关的文档。所以，要保持轻量级，快速移动以适应变更。

知识型项目的产出经常是无形的，为了减少彼此理解的偏差，把项目中出现的每一个新的想法或观点尽早地且频繁地展示出来，对于干系人之间的连接非常重要。如果团队想减少一些沟通中的隔阂，减少受到低质量的产品，那么其就要去频繁地讨论什么是"完成"。创建一个共同认可的"完成"的定义在管理干系人期望时非常重要。对软件项目来说，在声明什么事是"完成"时候之前，可以参考诸如以下常规的说法。

授权团队进行自主管理，了解如何通过最少的管理参与解决问题，是敏捷方法论的基石。这与传统项目管理者的观点不同，传统项目管理者控制所有决策同时委托任务给团队，几乎无反馈。敏捷团队决策必须包含所有成员和干系人且决策方便。因为客户参与到开发中非常重要，所以需要鼓励客户通过集中/现场支持与敏捷团队密切融合。当敏捷团队承担产品传递的责任时(即拥有所有权)，团队自身感受到授权。

谈判在敏捷项目中会出现，尤其是在讨论需求或者功能的优先级以及完成的定义的时候。团队和客户可以在功能和成本之间进行权衡，从而找到一个合适的方案。在敏捷项目中，谈判并非一定要做，而不是一个零和游戏，正如敏捷宣言"客户合作胜过合同谈判"。"健康的"判断可以给双方一个机会去充分描述每个观点，权衡利弊。

冲突是项目工作中不可避免的一部分。当大家集中去解决一些问题时，就会存在观念的差异性以及竞争利益。有些程度的冲突是"健康的"，可以确保一些观点在应用之间被充分地阐述和验证。但是，我们需要确保冲突不要升级。

创建一个让大家可以提出建设性的冲突的环境，对成功管理干系人参与项目来说非常重要。当冲突超越了正常界限时会变得具有破坏性。Seep B.Leas提出了一个描述冲突的框架，帮助我们判断冲突的级别并且更好地理解冲突从1级(解决问题)上升到5级(世界大战)，如下：

如果这个冲突在第1~3级，不要立刻采取行动去解决冲突，而是让团队自己去解决。因为自组织团队是需要尝试自行解决问题的。如果团队能够自己克服冲突，它将会提升一项重要技能，在将来可以自我管理类似的冲突。如果对于这个冲突，团队不能解决，而且这个冲突还有可能升级，那么敏捷项目经理就需要介入。

减少误解和错误信息传递的一项沟通技能是积极聆听。积极聆听是指听到说者想表达什么，站在说者的角度去考虑，而不是仅仅听到说话的内容。根据关注点的不同，可以把聆听分为以下三个层级。

参与式决策鼓励团队成员参与过程决策。决策的速度和团队对这些决策的认可程度都会直接影响项目绩效与团队凝聚力。沟通和参与决策对保持每个人参与非常重要。如果在做决策的时候不咨询团队成员的想法，团队成员就有可能感觉自己被孤立或者隔离，这对于自组织团队的打造是一个风险隐患。

敏捷鼓励领导进行更多的授权和更少的命令控制。团队授权不仅可以提升干系人的满意度和生产力，还可以提升决策过程的有效性。以下为常见的几个参与式决策的模型。

我们需要找出一些方法让干系人参与到重要的项目决策中，包括迭代计划和版本计划，估算讨论和回顾会。如果这些人不参与，他们就不会对这个决策做出承诺。最终，他们也不会对这个项目做出承诺。

领导需要确保"做了正确的事情"，关注方向。管理需要确保"正确的做事"，关注方法。相对于领导来说，管理聚焦更多的流程机制、任务控制上。领导更关注人与目标。但是，并非说领导比管理者要好，有些场合依然需要管理，把领导和管理结合起来去打造团队的高效生产力。

敏捷提倡服务型领导，聚焦在给团队成员提供需要，移除障碍，并且执行一些支持型性的工作进而最大化团队生产力上。一个领导在团队中的主要角色为以下四类：保护、保障、保持、保姆。

我们要不断的创新以寻找一些改进的方法，通过实践去学习和成长；鼓励干系人为改进提出一些新的想法，并给他们机会去尝试；鼓励团队去挑战现状，既可以践行过程改进，还可以激励团队成员。

分布式团队在面对面的沟通中会存在一些挑战，用信息发射源这样的协作工具会比较好。但是，这是一个大部分项目需要解决的挑战。数据显示，超过50%的敏捷项目团队至少在一个不同的物理办公区域。为了解决这个问题，分布式团队可以用一些沟通的技术，比如语音会议、实时聊天或者用它们自己的方式提供一个共享的团队环境让分布式的这些干系人进行实时交互和聊天

Agile敏捷管理

目录：

一、什么是Agile

二、什么样的团队适合Agile

三、敏捷开发的实施步骤（SCRUM）

四、Agile敏捷管理的具体实施

五、敏捷工作坊的体验

六、结语

七、附：SCRUM在教育和政府领域的应用

从本质上讲，敏捷（Agile）并不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代，让产品逐渐完善。

在数十年前，瀑布式项目管理是软件研发的主流方法，在研发过程中，团队成员将会花大把的时间和精力在项目前期去收集资源和信息，然后基于这些去做产品设想和研发规划。

到了70年代，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度还很慢，显然Out了。尤其到了90年代末期，开始出现黑客来捣乱，这就意味着前功尽弃、全部推倒重来，这简直是研发的噩梦。

相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。

另外，你也可以通过这个视频学习 什么是敏捷（Agile）

在2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观。

总结为：

尽管如此，这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注更核心的事物：人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行，他们又将写了 敏捷开发12项原则 作为指导：

如果我们把这些原则和遇到的问题对号入座，很快我们就会发现，这12项原则正是对应了客户期望。比如，客户不会关心开发文档写的怎么样，他们更感兴趣交付的成品能干什么；他们不在意你的开发计划，他们希望你能立马交付；昨天他们想要修个BUG，而不是等到下次版本更新。

我们总会遇到需求多样化的客户，而这时，敏捷能够确保你在研发过程中始终将用户需求作为核心。

敏捷虽然听起来光鲜亮丽，但不是所有项目都能用敏捷来做。

敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目，也就是说并不是所有事情都是按部就班。因此，我们得知道在这种快速变化的环境下，团队是否能够适应变化。

所以在部署使用敏捷前，需要团队先明确几个问题：

1.你是否会愿意接手目标不明确的项目？

敏捷项目管理中有句话叫做：快速失败。比如我们接手了一个连最终产出都不明确的项目，首先我们会先交付最小模型产品，这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品，所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后，我们才会逐步了解他们的真实需求，这时候我们离成功又近了一步。

2.你会如何规避项目风险？

就像我们前面提到的，敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路，用传统项目管理的方法来推进的话，我们会要承担更大的风险。当然就算我们开始敏捷之后，也要准备好随时响应未知问题。

3.你的团队能有多灵活？

作为项目经理，我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊，是否愿意放下老套路，根据用户需求来调整想法、重新规划方向。

4.公司阶层制度严格吗？

敏捷的其中一项原则不仅是和用户一起工作，研发成员的身份也会发生变化。你们公司的文化开放吗？是否能接受扁平和开放的管理方法？

5.你怎么衡量进度？怎么定义成功？

用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务，那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了？

在Scrum中，产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。

有了产品清单，产品经理就会开始确定需求优先级，研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。当一轮迭代完成后，全员再次分析需求清单、划分需求优先级，然后进入下一轮迭代。

1.三个角色

2.三种可视化文档

另外，用户故事要注意必须完整，遵循INVEST标准：

Independent——让一个用户故事独立于其他用户故事

Negotiable——可协商性，协商更多细节

Valuable——必须对客户具有价值

Estimable——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划

Small——规模小，至少要确保在一个冲刺周期中能完成、

Teatable——可测试，便于确定它是可以完成的

3.三种不同形式的会议

1、确定敏捷开发中的3个角色：Product Owner, Scrum Master, Scrum Team。

2、拟定待办事项清单，并确定优先级

3、改进和评估待办事项清单：

·要完成这些事项，现有信息足够吗？

·是否细分到了可以评估的程度？

·是否成员都能接受，用于评定一个事项已完成的标准？

·用相对难度去评估，利用斐波那契数列的数字

4、冲刺规划会：Product Owner, Scrum Master, Scrum Team一起规划冲刺的内容，记录每个冲刺完成事项的点数

5、将工作透明化：利用白板和燃尽图更新进度

6、每日站会

7、冲刺评估和冲刺展示：将成果展现给产品负责人看，哪些事项可以移到“完成事项”一栏，并接受评价。

8、冲刺回顾会

9、上一个冲刺阶段结束之后，立刻开始新的冲刺阶段

在冲刺阶段结束之际，把所有已完成的用户故事列出来，将各项难度评分加在一起，最终的数字就告诉我们团队的进度是多少。然后再看未完成用户故事的难度分值总和，就可以知道什么时候可以完成项目。

速度 X 时间 =交付工作量

敏捷非常注重节奏，当你有多个任务要交付，团队更需要注重节奏的把握。而身为项目经理，我们的职责是让整个团队通过协作最终交付产品。

敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下7步：

第1步：通过战略会议定义你的愿景

每当开始新项目时，第一件要做的事情是定义产品的业务需求，或者说想要达到的愿景。事实上，我们只需要回答一个问题：你为什么想要做这个产品。这是我们心中的蓝图，时时提醒我们不要跑偏。

作为一家产品公司，定义愿景的最佳方法之一是电梯演讲：

用于：（哪部分目标客户）

需求：（用户的需求）

类别：（我的产品是哪种类型）

功能：（产品的价值、客户为什么选我们）

竞品：（主要的竞争对手有哪些）

差异化：（和竞品的差异化描述）

即使我们做的不是软件产品，我们也可以根据项目的目标来调整上述内容。

战略会议的参与角色都有谁？

此时我们要让更多人认同这个项目，所以很多关键的利益相关者自然不能缺席，包括相关主管、经理、主任和产品经理。

战略会议该什么时候召开？

项目开始前我们就该来开战略会，或者至少每年一次的定期会议来保证愿景依然不过时

战略会议要召开多久？

这个就由你主观来决定了，一般来讲，花4-16小时来探讨战略已经足够了。

第2步：绘制产品路线图

当我们开完战略会后，就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路，让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划，而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。

项目管理专家Roman Pichler认为：目标导向的产品线路图能够聚焦于目标和产出结果（比如：获客、增加活跃度、满足客户需求）。而产品特性来自于这些目标，所以我们在制定目标时应谨慎，每个目标对应3-5个产品特征。

而每个目标，我们需要包含5个关键信息：时间、名称、目标、产品特征和衡量标准，有了这些，我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。

产品路线图由产品负责人画，同时听取利益相关者的想法，如客户、市场、研发代表等，并最好在战略会议结束后着手画产品路线图。

第3步：制定发布计划

当我们有了战略和计划，下一步我们就可以暂定几个时间节点。

这个阶段产品经理要严格按照计划发布新版本。我们也不用担心功能不齐全的问题，敏捷项目都会有多次发布的过程，所以我们只要优先发布核心功能的版本即可。

举例来说，你的项目要在11月交付，而你可能在2月初就已经做好了最小模型，打算在5月左右发布完整版。这些时间节点的安排都将由你的项目难度和每次迭代时长（或者说每次达成目标需要的工作时长）决定。通常每次发布新版本都需要经历3-5次迭代。

谁来制定发布计划？

产品经理、项目经理和所有团队成员都该来参与其中。当然，邀请少数利益相关者来加入其中也是对其他成员的鼓励，让团队能够尽早开始。

发布计划什么时候来做？

越早越好，你的发布计划应该在确认新产品后的第一天开始制定。在随后的每个季度中至少记录一次。

制定发布计划要多久？

一般来说会需要4-8小时，实际时长由具体情况决定，但不能因为它拖进度。

第4步：制定迭代（Sprint）计划

迭代（Sprints），我将其理解为通过短期研发完成具体任务来达到目标的一个过程，也是帮助产品经理和研发团队逐渐切入项目细节的方法。

通常情况下，每次迭代大约要花费1-4周。具体的时长我们需要根据团队过往的表现情况来制定，同时尽量保持每次迭代的时长相同。

哪些角色参与制定迭代计划？

迭代是整个团队的活，因此，产品经理、项目经理以及其他所有成员都该积极参与其中，表达自己的声音和想法。

迭代计划什么时候来制定？

在每次迭代周期开始前，我们就需要做好迭代计划。比如说，你的计划是每周迭代，那么就你就需要在每周一（或者你选好的某一天）告诉其他人迭代计划。

制定迭代计划要多久？

迭代计划是迭代周期的基石，虽然如此，我们也不要在这上面浪费过多的时间，通常2-4小时足够了。写好了迭代计划也就意味着我们已经踏上了正轨。

第5步：每日站会

在每次迭代过程中我们需要有时间来确认项目组没有遇到阻碍，同时保证能准时完成既定目标。这时候我们就需要使用每日站会。

每日站会，如同字面意思一样通俗易懂，每天花15分钟左右的时间来讨论下面3件事：

昨天我完成了哪些事情

今天我打算做哪些事情

我有遇到哪些问题，如何解决

或许讨论这3件事，可能让团队的一部分人的脸挂不住。但这对推动敏捷项目管理的沟通有积极意义。敏捷之所以能够跨团队协作，主要依靠的就是团队快速响应和有让成员发声表达的空间。

第6步：迭代（Sprint）结束了？那就进入评审阶段吧

如果迭代中一切顺利，那么迭代周期结束后，我们需要来检测下软件的功能。我们可以借评审的机会来向团队成员和利益相关者展示成果。

作为产品经理，你对产品功能有选择的权利。如果有哪步错误，尝试多问几个为什么？下次迭代时我该怎么调整才能让团队达成目标？敏捷是不断学习和迭代的过程，你的流程管控和最终产出也是同一道理。

哪些角色参与评审？

团队全员和利益相关者都应该参加迭代评审会来确认项目进度和表达他们的观点。

什么时候执行评审？

每次迭代结束后就可以开始。

评审阶段要多长久？

无需特意去准备PPT、功能说明，审查会最多1-2小时就够了。

第7步：迭代（Sprint）回顾总结

为了让敏捷项目管理能顺利运作，我们在每个阶段结束后需要知道下一步要做什么。这是我们在迭代回顾阶段要做的事。当迭代和审查结束后，接下来该去决定下次要做哪些工作。我们需要回顾下，在迭代中是否发生了些事情改变了你的既定时间，甚至是项目愿景。

谁来参加回顾总结会议？

回顾总结是审查的延伸，这时利益相关者离开也没有关系，而其他团队成员则加入其中，给出自己的意见。

什么时候来做？

当然最好是在审查阶段结束后，立刻开始迭代回顾总结。

这会花多长时间来做？

概括下来大概几个词：简短明了、甜蜜温馨，最多花1-2小时来总结和大致规划下次计划。

工作坊的体验主要是让学员大概体会一下运用敏捷的方式开发项目的流程，并通过一些敏捷工具深化在敏捷开发过程中的运用。

1、制作自行车项目

（1）分组并确定团队内敏捷3个角色

（2）定冲刺周期（每10min1个sprint，3个sprint）

（3）在冲刺开始前，给每个组15分钟开战略规划会，此期间验收人对自行车提出需求，要满足什么样的功能，团队开战略会列出任务清单。

（4）每个sprint结束后给每个组7分钟开站会

（5）每个组的SCRUM Master更新看板和燃尽图

（6）进行项目验收，对成果进行点评

（7）结束后小组内进行总结回顾会

2、乐高堆房子项目

（1）分组并确定团队内敏捷3个角色

（2）定冲刺周期（每15min1个sprint，4个sprint）

（3）在冲刺开始前，给每个组15分钟开战略规划会，此期间验收人对自行车提出需求，要满足什么样的功能，团队开战略会列出任务清单。

（4）每个sprint结束后给每个组10分钟开站会

（5）SCRUM Master更新看板和燃尽图

（6）在第三个Sprint开始时，要求团队内交换2名成员到其他组完成自己组的任务，期间不得交流，只能依据看板进行

（7）进行项目验收，对成果进行点评

（8）结束后小组内进行总结回顾会

七、SCRUM的应用

1、SCRUM与教育

教师首先让学生对自己的性格做评价，将自己划分为不同类别，分为”勇敢类“，“喜欢数学类”，”关心他人感受类“，”勇往直前实现目标类“，将不同类型的学生组合在一起，形成多功能小组。教师拟好所有待学事项，让各小组的学生每天将“所有事项”移到“待办事项”中，然后开始动手，打开教材，自己学习，组内互教互学。教师从“完成事项”一栏随机挑出一些事项问组内成员，以确定每个人都理解相关概念，只有当每个人都理解了之后，才符合所说的”完成的定义“，一切交给学生来做决定。

2、SCRUM与政府

制定政策：每周都去改变一件事情，采用增量方法，每周都会展示一种可交付的产品，每个机构都会切实感受到成果的存在。

书籍建议：

《敏捷革命：提升个人创造力与企业效率的全新协作模式》

SCRUM的一些工具：

Leangoo（领歌）——基于看板的可视化协作

Confluence——Jira

国外有Redmine，Axosoft，国内有禅道，一些自研工具（百度Icafe，阿里Aone，腾讯Tapd)

劳伦斯在《七根智慧之柱》中写道：所有人都做梦，但是却不尽相同，那些夜里在蒙灰的心灵角落做梦的人，早上醒来往往发现是空洞虚无的。而那些白日做梦的人，则是最危险的，因为他们会在睁着眼睛做梦的时候，把梦想变成现实。

看了这么多，不如试一试吧！此文由个人整理而来，主要来源于个人在敏捷团队时敏捷开发的逻辑和思考，以及明道云博客和敏捷相关书籍、英文文档翻译等。如有疑问或补充，欢迎评论下方交流~

ACP和PMP有哪些区别？

PMP 是项目管理（预测法）的方法论，核心强调计划驱动，教会我们如何在一种复杂多变的环境下一次性做成一件事的工作流程和思维方式；遵循计划和流程的提前规划，需求明确，尽量拒绝变更；——如果你想高效提升执行力和规划性，无论你在什么岗位，PMP 都是你的最佳选择

ACP 是敏捷项目管理（敏捷方法）的方法论，核心强调价值驱动，教会我们如何在需求多变或不确定或产品版本发布周期短的情况下，交付有价值且质量高的产品，注重价值及效果；—— 如果你在创新、探索、多变的环境下想实现项目或产品交付，无论你在什么岗位，ACP 都是你的最佳选择

ACP 和 PMP 并列成为当前为项目团队获得更好项目成果的两种高效可应用的方法，已经被越来越多组织和团队正确使用！ACP+PMP：项目成功实施“双模管理模式”，帮助我们提升项目能力，ACP 在全球及中国的快速发展，成为 PMP Plus 的另一实施项目保障的认证，越来越获得高关注点，未来 5 年前景可期

pmp和acp哪个含金量高知乎

PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会（Project Management Institute(简称PMI)）发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。

ACP(Agile Certified Practitioner)敏捷管理专业人士资格认证,它是由美国项目管理协会（Project Management Institute(PMI)发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证。

PMP认证和ACP认证，一个是项目管理的标准和框架体系最佳实践，一个是以“为用户提供价值”为核心价值观的方法论实践；一个是计划驱动，一个是价值导向。这两种相辅相成的项目管理方法，它们应用于不同环境下，相互补充。

PMP与ACP并不是相互独立或对立存在，而是做事方式的不同选择。在项目管理实践中将他们结合起来能更好地达成利益相关方的诉求。ACP特别验证了从业者在项目工作中理解及实施敏捷管理原则与实践的能力。PMP则认证了从业者所表现出的领导和引导项目团队的能力。

敏捷项目管理相关知识

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

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

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

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

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

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

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

任务管理团队管理：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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