9种项目管理方法让工作变得简单：PM的完整指南
敏捷，scrum，看板，精益，xp，瀑布、PRINCE2和PMBOK，这么多不断演变的项目管理方法可能会让人困惑。在你看了这个完整的项目管理方法指南中，这一切都变得非常简单易懂。
有许多不同的项目管理方法可以应用于不同的项目，但了解它们之间的差异，以及选择适合使用哪种方法却是非常棘手的。
阅读本指南，让您自己了解最常用的项目管理方法，并考虑它们如何才能在信息团队交付项目的过程中发挥最佳作用。
常见9种项目管理方法概述：
敏捷 -- 协作迭代交付任何作品
Scrum -- 使一个小型，跨职能，自我管理的团队能够快速交付
看板 -- 通过提高工作进展的可视性，提高交付速度和质量，并限制多任务处理
Scrumban -- 像看板一样每天都像Scrum一样限制工作进展
精益 -- 简化和消除浪费，以更少的投入获得更多
XP -- 极限编程方法 - 坚定地进行开发以确保质量
瀑布 -- 完全规划项目，然后通过阶段执行
PRINCE2 -- 受控的项目管理，没有任何机会
PMI的PMBOK -- 将通用标准应用于瀑布项目管理
看完下面关于每种方法的介绍之后，请关注本头条，还将继续介绍《如何选择项目管理方法》《对于外包团队最佳的项目管理方法》
介绍项目管理方法
让我们试着了解项目管理方法是什么。PMI对项目管理方法论的广泛定义是有帮助的 - “方法论是一个在一门学科中工作的人使用的实践，技术，程序和规则的系统” - 但方法学必须植根于更基本的东西，这就决定了我们为什么要选择以某种方式做事，所以我建议它也应该包括主题。
作为项目经理，交付项目有很多不同的方式。一般来说，这些方式是我们的方法论 - 应用不同的原则，主题，框架，流程和标准来帮助为我们交付项目提供结构。
项目管理方法
某些项目管理方法只是简单地定义了基本原则，比如Agile敏捷。而有的则定义了包括主题，原则和流程的“全套”方法框架，如Prince2。有些是与一些过程有关的标准的广泛列表，如PMI的PMBOK或XP，其中一些非常轻便，并且简单地定义过程，如Scrum。
也许会有争议，但是与其无休止地争论争论哪些属于方法论哪些不是，我宁可认为使用对项目管理方法的较为宽泛（也许不准确）的理解，简单地指我们综合运用各种方法一起把项目完成的最佳实践框架。我不认为一种方法必须是一个完整的全栈实现“系统”才能被视为一种方法。
这是一个很好且有用的定义，因为事实上，作为项目经理，我们会使用为客户和项目量身定制的各种原则，主题和流程的大杂烩。
在我们开始之前，让我们先弄清楚一件事情，方法论有很多，单没有绝对“正确的”方法。没有一种万能的方法是每个项目都应该始终使用的方法。
最终，最好的方法是合理的且最适合项目、团队和客户的。我们先来看看一些比较流行的项目管理方法，并了解一些在信息世界中交付项目的宝贵经验。
通用项目管理方法
敏捷方法论 - 协作迭代交付任何作品
让我们从每个人最喜欢的流行词开始，敏捷。事实上，敏捷并不是一种方法论，而是一套开发软件的原则。敏捷宣言概述了四条基本原则 - 个人与过程与工具之间的相互作用 ; 通过全面的文档工作软件 ; 客户协作合同谈判; 回应计划的变化 - 敏捷更多的是理念和一套遵循的价值观和原则，而不是适用于项目的过程。
当人们谈论敏捷项目管理方法论时，他们通常所描述的是一个灵活的迭代设计和构建过程。敏捷项目的特点是根据具体情况需要构思，执行和调整的一系列任务，而不是预先规划的过程。敏捷可以帮助团队通过增量迭代工作流程来应对不可预测性。
就像一个好厨师在烹饪过程中品尝食物时一样，在添加缺少的成分时，一个敏捷的项目管理过程要求项目团队循环执行规划，执行和评估过程。
敏捷与其他项目管理方法不同，后者通常认为影响项目的因素是可预测的，因此它强调对变化情况的适应性，项目团队之间以及他们与客户之间充分和持续的沟通。敏捷方法非常适用于动态环境，这些动态环境可能会发生变化或不断变化的需求，例如软件和游戏开发。
作为一套原则，敏捷是一个大的概念，并且倾向于被用作包括Scrum，极限编程（XP），看板和Scrumban在内的敏捷风格的总称。简而言之，敏捷并不是一种可以直接使用的方法或流程，这让事情变得混乱 - 如果您掌握了这些原则，您仍然需要定义交付项目的流程。
Scrum方法论 - 使一个小型，跨职能，自我管理的团队能够快速交付
Scrum是一种项目管理方法，提出了改进交付的原则和流程。在软件开发中，Scrum是将敏捷原理应用于实践的最流行和最简单的框架之一。
Scrum的目标是改善沟通，团队合作和发展速度。如果你听到人们在谈论冲刺，混乱，积压和burndowns，他们可能在谈论Scrum或其衍生物。
Scrum并不是一个真正的项目管理方法论，而是一个持续开发和维护复杂产品的框架。Scrum是一种轻量级的方法，它定义了一组简单的角色，会议和工具，以高效，迭代和递增方式提供有价值的可交付功能。
从根本上讲，Scrum的重点是让自我管理团队提供和定义角色和责任，以便在尽可能快地提供正确的方式和正确的方式之间创造健康的紧张关系。
Scrum倡导使用一个由多达9人组成的小型跨职能团队来处理待处理项目 - 一组用户故事（需求） - 由产品负责人定义并确定优先级。
工作被分为一个个“sprints”，一个通常为2-4周的开发周期，在此期间，每天的“scrum”发生在团队报告进展和障碍的地方。在每个sprint结束时，工作将在Sprint评审会议上进行审核，以便与产品负责人一起确定是否通过完成定义（DoD）。
Scrum由Scrum Master提供支持和服务，Scrum Master支持并领导Scrum，Sprint演示和评论，领导开发团队完成他们的最佳工作，并在每个sprint之后领先进行“sprint回顾”，以确保团队持续优化和改进。
Scrum最初是为软件开发而设计的，尽管Scrum可以提供灵活的构件，但Scrum并不适合整合到通常更具战略性和创造性的外包开发领域。即使在一个网站的开发项目上，固定的预算，时间表和范围也会让一个Scrum自我管理团队缺乏灵活性，而这个项目的开始和结束都是定义好的。
这并不是说它不适用于开发项目 - 外包开发项目经理可以扮演scrum的主人，而客户则可以作为一个大型快乐混合团队的产品所有者。但它通常比这更复杂，固定的预算和范围提供了严重的限制。这就是为什么许多机构采用scrum的一些概念 - 小型，自组织，跨职能团队，日常站立，进度演示和回顾，并以某种混合方式使用它们。
看板方法论 - 通过提高工作进展的可视性并限制多任务，提高交付速度和质量
看板是一种专注于精益原则和提高效率的严格流程的项目管理方法论。它在很多方面与Scrum类似 - 它们都是尽早发布，并经常与合作和自我管理团队合作。但与Scrum相比，看板是一种更具进化性的变化，因为它不太具有说服力，所以它更轻松地登陆敏捷世界。
看板流程简单，灵活，没有规定的角色，只是试图通过增加团队对真正重要的事情的关注来提高吞吐量。核心实践是对工作流进行可视化，限制正在进行的工作，衡量交付周期，明确制定工艺策略并不断评估改进机会。
看板的重点是不断发布的工作，速度更快，质量更好。对于优先级经常变化的运行或维护环境而言，这非常棒。看板的重点是测量提前期 - 在收到简报后需要多长时间才能交付。
通过看板，项目经理通常在Kanban白板或Trello等在线工具上使用便笺来表示团队的工作流程，其分类很简单，如“待办事项”，“正在做”和“已完成”。
这可以显示您想要执行的操作并限制正在进行的工作（WIP），以便在您测量和优化完成项目的平均时间时改进工作流程。
它还使团队可以直观地看到接下来会发生什么，这可以轻松重新排列优先顺序，发现过程问题并防止任务停滞。这也有助于他们了解新任务如何影响正在进行的工作。
看板非常适合需要稳定生产的工作，如生产或支持和维护。在机构的世界里，它也可以成为一个有用的工具，因为它更适应变化，客户也喜欢不断地改变主意。如果Scrum看起来太僵化了，但你想做'敏捷'，看板是一个更简单的选择。
Scrumban方法论 - 像看板一样每天都像Scrum一样限制工作进展
Scrumban是一种相对较新的混合项目管理方法，将混合Scrum和看板方法结合到项目管理中。它需要看板的灵活性，并增加了一些Scrum结构来创建管理项目的新方法。
Scrumban并没有在潜在的限制性时间框冲刺中工作，而是使用按需计划原则来填补积压工作，而任务由团队负责分配任务，因为他们可以适应这些任务，就像看板一样。这意味着进行中的工作是有限的，开发团队仍然专注于手头的任务，而不是担心冲刺审查会议和团队承诺在冲刺中提供什么。
然而，并非所有的看板 - Scrumban保留每日Scrum与审查和回顾，以改善只在需要时使用的过程。此外，没有冲刺的限制，计划是在需要的基础上进行，而不是在冲刺周围进行 - 这可能会节省时间。
Scrumban真的只是通过消除冲刺和允许自适应方法来为Scrum添加一些灵活性。或者，您可以将其看作是为Kanban添加一些急需的结构，通过会议来协助和优化流程。
对于产品开发而言，Scrumban可能非常有用，因为前景不清晰，需求不断发展或没有明确的路线图，以及流程是否需要在流程中包含支持和维护工作。
精益方法 - 精简和消除浪费，以更少的资源交付更多
精益是一种专注于效率主题的项目管理方法论。可以说敏捷教父 - 精益就是用更少的钱做更多的事情。它通过识别价值开始，然后通过持续改善，通过优化价值流动和消除浪费来最大化价值。
这是一个有原则的主题，而不是一个方法论的决定过程和事情。它表明，通过解决导致浪费的三种功能障碍，您可以少花钱多办事; Muda，Mura和Muri，也被称为3Ms。
Muda正在消除废物处理过程或任何最终不会增加客户价值的事情。在数字世界中，这可能会消除几轮修订。
Mura正在消除变化 - 消除标准流程造成的差异。对我们来说，这可能意味着标准化简报和审批流程。
穆里关于消除超载 - 最佳容量在60-70％; 除此之外，任何事情都会变慢。我们可以将此应用于最小化我们试图通过代理机构运行的项目数量。
精益专注于改变我们的经营方式，以激光为中心实现价值。它将关注点从优化独立技术，资产和垂直部门转向优化通过整个价值流的流量项目，这些价值流横跨技术，资产和部门横向流向客户。
在审查项目交付过程时，精益可以成为一种有益的思维方式 - 思考如何将项目过程剥离回仅仅提供价值的切合实际的要素，并且删除那些只是松散的事情，或者你总是完成的方式它 - 你会想到精益。
XP - 极限编程方法 - 坚定地进行开发以确保质量
极限编程（XP）是一种软件开发项目管理方法，它定义值和流程以提高软件质量并确保对不断变化的客户需求的响应。的值，或原理非常类似于Scrum的，围绕简单起见，通信，反馈，尊重和勇气。
它真正背离Scrum的地方在于定义规则或规范流程。其中一些类似于Scrum，但是围绕设计编码和测试的技术实践有规则，这些规则使得它成为开发项目的特定对象。这些规则包括强制性的; 包括用户故事，测试驱动开发（TDD），结对编程以及其他许多方面的持续集成。
瀑布方法 - 充分规划项目，然后分阶段执行
通常被称为SDLC（软件开发生命周期）的瀑布是一个项目管理方法学主题，它具有非常简单的方法，它重视可靠的规划，一次做好并且做得对，而不是增量和迭代交付的敏捷方法。这很容易理解，因为你只需制定一个好的计划，然后执行就可以了。
项目经理往往比较庞大而且负责，而且工作是事先进行广泛的规划，然后按照严格的顺序执行，遵守要求，以一个单一且通常很长的周期交付项目。
任何工作开始前，需求都会在瀑布顶部的开始处全部定义。然后工作级联，如通过项目阶段的瀑布瀑布。在瀑布模型中，每个阶段必须在下一个阶段开始之前完成，并且阶段中没有重叠。通常，在瀑布方法中，一个阶段的结果将作为下一个阶段的输入顺序。
在计划获得批准后，除非绝对必要，否则几乎没有必要调整计划，而且所需的更改通常需要更改请求。然后该项目从需求流程开始，直到设计，实施，测试和维护。
由于采用单循环方法，因此在瀑布项目中，一旦完成某项工作，就没有多少空间可以反思，修改和适应。一旦你进入测试阶段，很难回头去改变在概念阶段没有很好设计的东西。当你走的时候，也没有什么可以显示并告诉客户的。你大肆宣传完成该项目，并祈祷客户喜欢它。这可能是非常危险的。
一般认为，瀑布在一些机构中被视为一种效率低下且过时的传统项目管理方法。但是，如果需求是固定的，有据可查的和清晰的，技术被理解和成熟，项目很短，并且没有从“敏捷”中获得额外价值，瀑布可以成为一种有用且可预测的方法。瀑布方法实际上可以为预算，时间表和范围提供更可预测的最终结果。
PRINCE2方法论控制的项目管理，没有任何机会
PRINCE2是一个'完整的'瀑布式项目管理方法论，包含原则，主题和流程。它是由英国政府于1996年为IT项目创建的。'PRINCE'表示PR ojects IN Ç ontrolled ê nvironments。它是一种非常面向过程的方法，将项目分为多个阶段，每个阶段都有自己的计划和流程。该方法为项目的每个阶段定义投入和产出，以便不会有任何机会。
该系统强调企业采取的课程理由，因此第一步就是确定项目的明确需求，目标客户是谁，是否有现实利益以及彻底的成本评估。项目委员会拥有该项目并对其成功负责。该董事会为团队定义了结构，而项目经理负责监督较低级别的日常活动。该方法基于八个高层流程，为团队提供更多的资源控制和有效降低风险的能力。
作为一种方法论，它非常全面 - 它是如何运行大型可预测的企业项目的一个很好的框架。它阐明了将会交付什么，确保关注项目的可行性，明确界定角色和责任，通过例外（可以说是敏捷原则）支持管理，与PMBOK类似，提供了一个我们可以应用于其他方法的通用词汇。另一方面，虽然原则和主题很好，但这个过程可能会使小项目变得繁重和繁琐。
PRINCE2专为大型IT项目而设计，因此绝不会在某个机构中用作项目管理方法。但是，当我们考虑为客户管理项目时，强调利用KPI和价值创造良好的商业案例，明确角色和职责，管理变更和风险很有帮助。
PMI的PMBOK方法 - 将通用标准应用于瀑布项目管理
PMI（项目管理协会）项目管理方法论并不是一种真正的方法学，而是一套参照项目管理的五个流程步骤的标准，它们概述了项目管理知识体系（PMBOK）。这些是启动，计划，执行，控制和关闭。
这不仅仅是一种方法论，而是一种在项目管理行业内被接受为标准的标准，惯例，流程，最佳实践，术语和指导方针的框架。它包含许多项目管理过程和技术，通过它们来评估或完成项目运行方式或使用的方法。
因此，这是一个更理论化的参考指南，您可以通过认证，虽然它在IT方面很受欢迎，但并不真正在机构世界中飞翔。您实际上无法运行PMI或PMBOK项目，但您可以利用这些标准在项目周围创建通用语言和最佳做法。与PRINCE2相比，你可以想象PMI的PMBOK和PRINCE2是互补的，而不是两种不同或独立的瀑布方法。
如何选择正确的项目管理方法
选择正确的项目管理方法很重要，因为它定义了我们的工作方式。项目管理方法论提供了可以指导我们实现项目成败的结构。
因此，在决定在项目中使用哪种项目管理方法时，我们需要考虑项目的简单性或复杂性，客户，可用资源和项目限制（包括对变更和风险的偏好），时间表，工具和人。
在涉及项目管理方法时，没有适用于所有业务类型，规模或行业的万能解决方案。无论您是在一个充满变化和变化的动态环境中工作，而是采用灵活的方法。或者，如果您在非常固定，严格的要求，时间表和预算内工作，并采用瀑布式方法，那么每种项目管理方法都有其自身的优势和弱点。
最终，所选择的方法应该基于其为客户提供最大价值的能力进行分析，对交付方案的影响最小，满足组织目标和价值的程度如何，项目团队必须处理的限制，利益相关者的需求，涉及的风险，项目规模，成本以及项目的复杂性。
外包开发团队最好的方法是什么？
简而言之，没有对错 - 这取决于你的客户，你的团队和项目。
也就是说，在一个团队中，几乎普遍地建议瀑布对于一个项目来说可能是一个好方法，这无异于为自己画一个大目标。瀑布是没有客户或团队想要听到的东西 - 我们都希望被视为最前沿，而瀑布绝对不是很酷。
这不仅不是很酷，但瀑布是具有挑战性的，因为它在任何创造价值的工作完成之前需要大量的前期规划。有时需要规划，因为客户需要批准成本，时间表和范围。但是客户通常不愿意为计划付费，即使他们这样做，如果您的计划不符合要求，会发生什么？
事实上，在IT世界中，我们经常会遇到要做出准确的预估。我们通常在不是太明确的项目中使用新技术。因此，除非您一次又一次地做同样类型的项目，否则一旦开始项目，您的计划可能就会过时。因此，虽然客户喜欢可交付成果，预算和时间表的可预测性，但瀑布式方法本质上不灵活。
那么敏捷的味道呢？
在代理和客户之间，对敏捷的理解往往非常流畅。敏捷在很大程度上被称为'不是瀑布'，而且被广泛误解为意味着以更少，更快，更便宜的方式做更多的事情。你为什么不想要那个？
客户倾向于喜欢敏捷的想法，因为它明显具有灵活性来支持项目，并为他们提供更多的机会来提供反馈或在整个项目中持续改变他们的想法。
他们经常认为这意味着他们会以更少的工作量完成更多的工作，或者他们实际上不需要对任何事情做出最终决定，因为他们可以改变自己的想法，甚至到最后一刻。
这是真的，但不是真的整个故事。
故事的其他部分是这种灵活性是昂贵的 - 是的，你可以枢轴转动，改变主意，但它耗费时间，而且时间花钱。
另一个挑战是，为了成功并且真正敏捷，客户必须使自己能够获得并被授权作出决策（这在分级和董事会导向的组织中是罕见的），并且提供持续的反馈和优先级以便保留项目移动。这通常非常棘手。
在很多方面，这归结为信任。客户是否真的相信该机构能够提供价值，他们是否愿意为成功之路付出失败的代价？从根本上说，机构想要为他们所从事的工作获得报酬，并且客户希望机构能够第一时间完成他们的最佳工作。需要有一些快乐的媒介。
少花钱多办事，消除浪费是一种很好的精益原则，但这种方法面临的挑战往往是客户 - 外包方关系; 大量的浪费是由客户引起的，没有真正的嵌入式客户端，具有真正的决策权力和大量的相互信任，没有任何一种敏捷项目方法能够解决这个问题。
但是，如果有相互信任，并且愿意尝试，它可以创造出魔术发生的正确条件。事实是，敏捷可能会更好，但敏捷并不便宜或容易。
所以敏捷可能意味着应用从Scrum到XP的各种不同方法 - 最好的方法是挑选最适合您和您的团队的产品，以实现最大的价值。
它要求我们的客户成熟起来，明白我们不能确切地定义他们会得到什么，或者什么时候，但有了一些健康的信任，我们将一起努力，尽我们所能。
结论是
选择最合适的项目管理方法可能会很棘手。这取决于很多变数，其中许多变数是我们无法控制的。
但这是真正重要的 - 超越了这个领域方法论的“抢地盘游戏”。项目管理方法只是帮助我们交付项目的工具。对于方法论的最终细节来说，真的不值得争论 - 相反，我们应该把重点放在更大的局面上。无论是看板，瀑布还是其他方法，它都无关紧要。
重要的是要做好质量工作，满足用户需求，为我们的客户创造价值。
最好的方法是持续有机地改进，适应并通过强大的协作增加产出的价值，因此总和远大于部分。
这是一种让客户感到惊喜和愉悦的方法，通过持续不断交付有价值和正确的产品。要做到这一点，你需要务实，而不是机械教条地使用你的方法。