项目管理简介：敏捷方法与瀑布式方法对比
哪种项目管理方法最适合您？这取决于项目。
开始使用免费的 Jira 项目管理模板
使用强大的任务管理和简单的优先排序工具，管理任何项目的活动。
Key Takeaways
Agile vs waterfall contrasts iterative, flexible project management with linear, sequential approaches.
Agile enables rapid feedback, adaptability, and continuous delivery, while waterfall emphasizes upfront planning and fixed phases.
Choosing the right approach depends on project complexity, stakeholder involvement, and team expertise.
Assess your project’s needs and consider adopting Agile practices for greater flexibility and customer satisfaction.
编辑贡献：Laureli Mallek（项目经理）
敏捷开发的早期采用者通常是小型独立团队，从事的是小型独立项目。他们证明敏捷模式行之有效，这让全世界的软件开发者感到欣喜，并从中受益匪浅。事实证明，对于大多数团队而言，瀑布式开发模式在软件开发方面并不像敏捷项目管理那样有效。
随着敏捷项目管理的普及，越来越多的组织将敏捷开发扩展到单个团队或项目之外，并应用到整个项目群中。敏捷开发甚至已经超越了开发团队的范围，扩展到 IT、营销、业务开发等领域。
什么是敏捷项目管理？
什么是瀑布式项目管理？
瀑布式项目管理方法需要一个明确界定的执行顺序，只有在一个阶段获得最终批准后才会推进项目阶段。一旦阶段完成，重新审视前一阶段可能既困难又昂贵。敏捷团队可以遵循类似的顺序，但会以较小的增量进行操作，并定期进行反馈循环。
瀑布式项目管理方法遵循线性的顺序公式。这对于具有可预测重复流程的工作来说效果甚好，但可能会使开发团队步履蹒跚，无法以快于竞争对手的速度进行调整。
在瀑布式项目期间错过一个截止日期或范围变更可能会给后续发布造成巨大影响。此外，当团队全神贯注于下一阶段工作时，如果全员分配到处理新的功能并且一直有向下一阶段推进的压力，那么解决技术债务或修复缺陷可能会令人痛苦。
下图展示了一个标准的瀑布式项目，具有严格分割的时间块。这会产生一种“用进废退”的心态，鼓励开发人员、产品负责人和利益相关者在每个时间窗口中请求尽可能多的时间，因为将来或许没有机会进行迭代。通常，使用瀑布式的团队会尝试通过“变更控制”来控制范围蔓延，其中每个人都同意原始合同不会改变。
瀑布式模型可能会加剧产品开发面临的一些已知挑战：
障碍和依赖关系管理：传统风格的项目管理通常会形成“关键路径”，只有解决了阻塞问题，项目才能向前推进。
难以获得用户反馈和产品验证：雪上加霜的是，最终客户在产品彻底完成前无法与之交互。因此，产品设计和代码中的重要问题只有等到发布之后才会被人发现。
瀑布式的优点
需要较少的协调，因为已明确定义分阶段顺序流程
清晰的项目阶段有助于明确定义工作依赖关系
可在确定需求后估算项目成本
更好地关注设计和要求文档
在编写任何软件之前，设计阶段更有条理且结构更好
瀑布式的缺点
分解和分担工作难度更高，因为阶段顺序更严格并且团队更专业
存在阶段过渡期间延误和挫折导致时间浪费的风险
需要额外招聘要求来满足专业阶段团队，而敏捷方法则鼓励更多跨职能团队组成
阶段过渡之间移交时需要额外通信开销
产品所有权和参与度可能不如敏捷方法强大，因为重点放在了当前阶段。
敏捷方法与瀑布方法
率先采用敏捷方法的是软件团队，他们从传统的顺序瀑布式方法转向一种在整个开发生命周期获得一致反馈和调整的方法。
敏捷项目管理采用迭代方法进行开发，创建几个具有固定反馈间隔的渐进步骤。这提高了适应性，因为团队可以在整个产品开发过程中进行调整，而不是局限于一个线性路径。它还允许定期的高影响力的发布，使团队能够随时间推移取得一系列胜利。
迭代式发布为团队开启了多种机会：
从新发现的需求到被阻塞的工作，适应不断变化的环境。
沿途收集利益相关者反馈，并进行快速迭代，没有最终交付截止时间的压力。
建立跨职能关系和联系，使人们更容易进行有效的联系和沟通。
敏捷开发使团队能够更灵活地应对项目期间不可避免的变更。
更大的好处是在软件团队之间共享技能。团队技能组合彼此重合，为团队代码库各个方面的工作增添灵活性。这样一来，即使项目方向有所改变，也不会浪费工作和时间。（如需更多信息，请参阅我们关于打造优秀的敏捷团队的文章。）
敏捷原则
敏捷项目分为几个渐进步骤，其包括定期的反馈间隔。
项目需求细分为较小的部分，按重要性排定优先级。
促进协作，尤其是与客户协作。
定期进行调整，确保满足客户的需求。
将规划与执行相结合，使团队能够有效响应不断变化的需求。
敏捷项目管理的优点
更快的反馈周期
尽早发现问题
更有可能让客户满意
上市时间显著缩短
可见性/问责制更佳
专属团队随着时间推移提高工作效率
灵活确定优先级，注重价值交付
敏捷项目管理的缺点
关键路径和项目间依赖关系可能无法像瀑布式那样明确定义
存在组织学习曲线成本
通过持续部署管道实现真正的敏捷执行需要确立许多技术依赖关系和工程成本
向敏捷转变时要考虑的因素
向敏捷转变可能具有挑战性，尤其是当团队或组织植根于更传统的项目管理方法时。转变为采用敏捷实践可能需要进行一些流程变革，尤其是在采用 DevOps 方法时，即开发和运营团队紧密合作以开发和维护软件。在采用敏捷原则时，团队和利益相关者必须接纳两个重要概念：
产品负责人的重点是优化团队的产出价值。团队依靠产品负责人先确定最重要工作的优先级。
开发团队仅在有能力前提下接受工作。产品负责人不会将工作推给团队，也不会为工作设定随意的截止时间。有能力接受新工作时，开发团队从项目群的待办事项中拉取工作。
我们来探讨敏捷项目群用来以迭代方式组织、运行和构建工作的机制。
路线图
产品路线图概述了产品或解决方案如何随着时间推移而发展。敏捷开发中的路线图提供重要的背景信息，使团队能够实现渐进和项目范围的目标。路线图由计划组成，它们是较大的功能领域，还包括传达某项功能在何时可用的时间表。随着工作推进并且团队掌握更多信息，路线图以或微妙或广泛的方式发生变化，从而反映这些新的信息。目标是使路线图聚焦于影响项目和长期目标的当前条件上，以便与利益相关者高效合作并应对竞争格局。
下图展示了产品团队的一个简单路线图，在方框中列出计划，并在时间线上用红色标示里程碑。
要求
路线图中的每一计划细分为一组要求。敏捷开发要求是对所需功能的简要描述，而不是与传统项目相关的 100 页文档。它们会随着时间推移而发展，并利用团队对客户和所需产品的共同理解。敏捷开发要求应保持精简，团队中的每个人都通过持续对话和协作形成了共同的理解。只有在即将开始实施时，才会充实全部的细节。
待办事项列表
待办事项列表为敏捷项目群排定优先顺序。团队将所有工作项容纳在待办事项列表中，如新功能、缺陷、增强功能、技术或架构任务等。产品负责人为工程团队确定待办工作的优先顺序。然后，开发团队使用按优先顺序排列的待办事项作为待完成工作的唯一事实来源。
敏捷开发指标
敏捷开发离不开信任
如果团队成员之间缺乏高度信任，敏捷流程就无法运作。需要开诚布公，才能就什么适合该项目群和产品进行艰难对话。由于对话是定期进行的，因此会时常表达想法和担忧。这意味着，团队成员之间必须彼此相信对方的能力（和意愿），才能执行对话中做出的决策。
总之...
敏捷项目管理是一种创新的方法，不仅适用于软件项目，也适用于所有领域的项目。采用敏捷方法后，团队可以灵活响应开发生命周期中的变化，交付出更高质量的产品来满足客户的需求。敏捷为团队赋能，建立问责并鼓励创新，同时促进持续改进。敏捷让您能够在不脱轨的情况下响应更改。而这对于任何项目群来说都是好消息。
请详细了解敏捷开发项目管理，并查阅我们的免费项目管理模板。此外，借助适用于软件团队的 Agile 工具，深入探索敏捷开发的采用情况，并了解如何跨团队沟通工作进度。