编辑贡献：Laureli Mallek（项目经理）
敏捷开发的早期采用者往往是小型独立团队，从事的是小型独立项目。他们证明敏捷模式行之有效，让世界各地的软件制造商感到喜悦和进步。事实证明，瀑布式开发模式在软件开发方面的效用不如敏捷项目管理那样适用于大多数的团队。
敏捷开发项目管理的普及促使更多组织将敏捷开发扩展到单个团队或项目之外，并将其应用于整个项目群。敏捷开发甚至超越了开发团队，扩展到了 IT、营销和业务开发等领域。
什么是敏捷项目管理？
敏捷项目管理是一种迭代式项目交付方法，侧重于持续发布并融合客户反馈。能够在每次迭代中进行调整，提高了速度和适应性。这种方法不同于线性的瀑布式项目管理方法，后者遵循有限偏差的固定路径。
当今的客户和企业需要快速响应和变革，敏捷提供了在开发过程中进行调整和迭代的灵活性。敏捷项目管理也为需要开发和运营团队互相协作的 DevOps 实践奠定基石。
什么是瀑布式项目管理？
瀑布式项目管理方法需要一个明确界定的执行顺序，只有在一个阶段获得最终批准后才会推进项目阶段。一旦阶段完成，重新审视前一阶段可能既困难又昂贵。敏捷团队可以遵循类似的顺序，但会以较小的增量进行操作，并定期进行反馈循环。
瀑布式项目管理方法遵循线性的顺序公式。这对于具有可预测重复流程的工作来说效果甚好，但可能会使开发团队步履蹒跚，无法以快于竞争对手的速度进行调整。
A single missed deadline or scope change during a waterfall project can cause outsized impacts on subsequent releases. Additionally, when a team is fully focused on the next phase of work, resolving technical debt or fixing bugs can be painful if the team is fully allocated to new feature work and always pressing forward to the next stage.
下图展示了一个标准的瀑布式项目，具有严格分割的时间块。这会产生一种“用进废退”的心态，鼓励开发人员、产品负责人和利益相关者在每个时间窗口中请求尽可能多的时间，因为将来或许没有机会进行迭代。通常，使用瀑布式的团队会尝试通过“变更控制”来控制范围蔓延，其中每个人都同意原始合同不会改变。
瀑布式模型可能会加剧产品开发面临的一些已知挑战：
- 障碍和依赖关系管理：传统风格的项目管理通常会形成“关键路径”，只有解决了阻塞问题，项目才能向前推进。
- 难以获得用户反馈和产品验证：雪上加霜的是，最终客户在产品彻底完成前无法与之交互。因此，产品设计和代码中的重要问题只有等到发布之后才会被人发现。
瀑布式的优点
- 需要较少的协调，因为已明确定义分阶段顺序流程
- 清晰的项目阶段有助于明确定义工作依赖关系
- 可在确定需求后估算项目成本
- 更好地关注设计和要求文档
- 在编写任何软件之前，设计阶段更有条理且结构更好
瀑布式的缺点
- 分解和分担工作难度更高，因为阶段顺序更严格并且团队更专业
- 存在阶段过渡期间延误和挫折导致时间浪费的风险
- 需要额外招聘要求来满足专业阶段团队，而敏捷方法则鼓励更多跨职能团队组成
- 阶段过渡之间移交时需要额外通信开销
- 产品所有权和参与度可能不如敏捷方法强大，因为重点放在了当前阶段。
Agile vs. Waterfall Methodologies
率先采用敏捷方法的是软件团队，他们从传统的顺序瀑布式方法转向一种在整个开发生命周期获得一致反馈和调整的方法。
敏捷项目管理采用迭代方法进行开发，创建几个具有固定反馈间隔的渐进步骤。这提高了适应性，因为团队可以在整个产品开发过程中进行调整，而不是局限于一个线性路径。它还允许定期的高影响力的发布，使团队能够随时间推移取得一系列胜利。
迭代式发布为团队开启了多种机会：
- 从新发现的需求到被阻塞的工作，适应不断变化的环境。
- 沿途收集利益相关者反馈，并进行快速迭代，没有最终交付截止时间的压力。
- 建立跨职能关系和联系，使人们更容易进行有效的联系和沟通。
敏捷开发使团队能够更灵活地应对项目期间不可避免的变更。
更大的好处是在软件团队之间共享技能。团队技能组合彼此重合，为团队代码库各个方面的工作增添灵活性。这样一来，即使项目方向有所改变，也不会浪费工作和时间。（如需更多信息，请参阅我们关于打造优秀的敏捷团队的文章。）
敏捷原则
- 敏捷项目分为几个渐进步骤，其包括定期的反馈间隔。
- 项目需求细分为较小的部分，按重要性排定优先级。
- 促进协作，尤其是与客户协作。
- 定期进行调整，确保满足客户的需求。
- 将规划与执行相结合，使团队能够有效响应不断变化的需求。
敏捷项目管理的优点
- 更快的反馈周期
- 尽早发现问题
- 更有可能让客户满意
- 上市时间显著缩短
- 可见性/问责制更佳
- 专属团队随着时间推移提高工作效率
- 灵活确定优先级，注重价值交付
敏捷项目管理的缺点
- 关键路径和项目间依赖关系可能无法像瀑布式那样明确定义
- 存在组织学习曲线成本
- 通过持续部署管道实现真正的敏捷执行需要确立许多技术依赖关系和工程成本
向敏捷转变时要考虑的因素
向敏捷转变可能具有挑战性，尤其是当团队或组织植根于更传统的项目管理方法时。转变为采用敏捷实践可能需要进行一些流程变革，尤其是在采用 DevOps 方法时，即开发和运营团队紧密合作以开发和维护软件。在采用敏捷原则时，团队和利益相关者必须接纳两个重要概念：
- 产品负责人的重点是优化团队的产出价值。团队依靠产品负责人先确定最重要工作的优先级。
- 开发团队仅在有能力前提下接受工作。产品负责人不会将工作推给团队，也不会为工作设定随意的截止时间。有能力接受新工作时，开发团队从项目群的待办事项中拉取工作。
我们来探讨敏捷项目群用来以迭代方式组织、运行和构建工作的机制。
路线图
产品路线图概述了产品或解决方案如何随着时间推移而发展。敏捷开发中的路线图提供重要的背景信息，使团队能够实现渐进和项目范围的目标。路线图由计划组成，它们是较大的功能领域，还包括传达某项功能在何时可用的时间表。随着工作推进并且团队掌握更多信息，路线图以或微妙或广泛的方式发生变化，从而反映这些新的信息。目标是使路线图聚焦于影响项目和长期目标的当前条件上，以便与利益相关者高效合作并应对竞争格局。
下图展示了产品团队的一个简单路线图，在方框中列出计划，并在时间线上用红色标示里程碑。
要求
路线图中的每一计划细分为一组要求。敏捷开发要求是对所需功能的简要描述，而不是与传统项目相关的 100 页文档。它们会随着时间推移而发展，并利用团队对客户和所需产品的共同理解。敏捷开发要求应保持精简，团队中的每个人都通过持续对话和协作形成了共同的理解。只有在即将开始实施时，才会充实全部的细节。
待办事项列表
待办事项列表为敏捷项目群排定优先顺序。团队将所有工作项容纳在待办事项列表中，如新功能、缺陷、增强功能、技术或架构任务等。产品负责人为工程团队确定待办工作的优先顺序。然后，开发团队使用按优先顺序排列的待办事项作为待完成工作的唯一事实来源。
敏捷开发指标
敏捷团队的蓬勃发展离不开衡量指标。进行中工作 (WIP) 限制可使团队和业务专注于交付最高优先级的工作。燃尽图和控制图等图表帮助团队预测交付节奏，而连续的流程图则有助于识别瓶颈。这些指标和工件使每个人都着眼于宏伟目标，加强大家对团队未来工作交付能力的信心。
敏捷开发离不开信任
如果团队成员之间缺乏高度信任，敏捷流程就无法运作。需要开诚布公，才能就什么适合该项目群和产品进行艰难对话。由于对话是定期进行的，因此会时常表达想法和担忧。这意味着，团队成员之间必须彼此相信对方的能力（和意愿），才能执行对话中做出的决策。
总之...
敏捷项目管理是一种创新的方法，不仅适用于软件项目，也适用于所有领域的项目。采用敏捷方法后，团队可以灵活响应开发生命周期中的变化，交付出更高质量的产品来满足客户的需求。敏捷为团队赋能，建立问责并鼓励创新，同时促进持续改进。敏捷让您能够在不脱轨的情况下响应更改。而这对于任何项目群来说都是好消息。
Learn more about agile project management and check out our free jira project management template. Plus, dive into agile adoption with agile tools for software teams, and learn how to communicate the progress of work across teams.
