敏捷项目管理：最佳实践和方法论

摘要：敏捷是一种迭代式和增量式解决方案开发方法，它致力于通过寻求客户反馈、拥抱和适应变化以及不断改进为客户交付价值。因此在敏捷项目管理中，最佳实践是什么呢？

敏捷是一种迭代式和增量式解决方案开发方法，它致力于通过寻求客户反馈、拥抱和适应变化以及不断改进为客户交付价值。

敏捷宣言和敏捷原则是各种敏捷框架的核心和精神所在，这些框架正被越来越多的企业用作项目管理框架。

敏捷项目管理

敏捷项目框架

Scrum、看板、XP、SAFe等敏捷框架已经取代了传统的瀑布式和软件项目管理的预测方法。这些框架利用了精益等长期存在的理念，以及TDD、BDD、结对编程等实践。

Scrum和看板是目前最流行的敏捷框架，据《2020年敏捷状态报告》发现，近58%的敏捷项目使用了Scrum。

Scrum使用时间限定的迭代方法开发增量产品和解决方案，每个迭代周期为2 /3/ 4周。看板的迭代没有时间限定，它通过控制在制品(WIP)来建立工作流程，非常适合于维护、支持或帮助部门项目。

在本文中，我们将讨论使用Scrum的敏捷项目管理。在简要了解Scrum框架之前，我们需要了解敏捷项目管理与传统瀑布式项目管理两个不同却又非常重要的方面——范围和估算。

铁三角

与传统项目不同，在敏捷中，项目所涉及的进度和成本在很大程度上是固定的。范围为可变实体，需要根据客户的最新信息和反馈进行调整。重点是交付价值，而不是刻板遵循项目开始时制定的严格而详细的计划。例如，在Scrum中，每个Sprint都有一个固定的运行时间，因此我们并不建议改变敏捷团队的结构。

（铁三角）

估算——相对规模

敏捷建议对工作项进行“相对规模的调整”，以实现可预测性，而不是一味追求准确性的复杂评估技术。

（敏捷估算)

在上面的图2中，路上的人们很可能会看到这样一个事实，那就是A楼是三楼中最小的，B楼是A楼的两倍，C楼是最高的，几乎是B楼的3倍。一眼扫过去，估量出三栋楼孰高孰低这件事很容易。相反，如果他们必须估算这座建筑物的实际高度，以米为单位进行估量就会很容易出现错误。“相对规模的调整”遵循以下标准：我们不追求准确性（例如：以米为单位的建筑物的高度），而是着眼于确定工作的规模并随着时间的推移实现可预测性。

高级史诗/功能通常根据T恤的尺寸(小型、中型、大型、超大型)进行估算，取代以工时/小时为单位的复杂工作量估算。故事按照修改的斐波那契数列(1、2、3、5、8、13、20、40、100)进行估算并给出“故事点”。

Scrum框架概述

Scrum框架由角色、事件和工件组成，描述了这些实体如何相互连接并实现框架。

Scrum采用迭代方法，其中开发周期为一般为2—4周。在每个迭代结束时，产品/解决方案的增量版本就准备好交付了。Scrum框架中的每个事件/工件/角色都服务于一个目的，并进一步推进了敏捷项目开发的目标。接下来我们将逐一介绍。

（Scrum框架）

发布计划

尽管敏捷不建议提前制定详细的刚性计划，但它并非完全放弃计划。在发布的开始有一个高级的发布计划，在每个Sprint的开始处有较短的、详细的Sprint计划事件。在整个项目实施过程中，缩短计划阶段有助于适应变化并正确地进行培训。

对于由多个Scrum团队共同努力开发解决方案的大型组织来说，计划发布和确定发布的时间非常重要。组织可以选择根据客户的需求或既定的节奏来确定发布的时间(例如：每季度)或与某些事件排列一致(例如：贸易展或合规截止日期等)。发布计划是一个前瞻性的计划，其目标是将进度和预算作为铁三角的固定组成部分来考虑，以达到发布范围。

这次活动需要两个重要的投入，一个是按优先级排序的产品待办事项列表，另一个是参与发布的团队的速度(运行敏捷的团队的历史数据，以及对新团队的合理估计)。团队将大致规划出他们即将到来的Sprint(如果一个版本发布周期长达12周，那么可以有5个Sprint，每个Sprint为期两周，并紧接着一个2周的“强化Sprint”)。在计划事件的最后，会有一个列表，列表会列出可以在版本中包含的优先级特性，以及每个Sprint的高级计划。

Scrum 角色

Scrum Master、产品所有者和开发团队组成了“3位朋友”。这三个角色之间有着良好的信任和健康的关系。同样，三个角色下的人们必然会发生预期中的冲突和分歧。在这种时候，团队遵循Scrum价值观的指导：尊重、勇气和开放。Scrum团队在任何时候都在实践承诺，并专注于实现Sprint目标，从而进一步贯彻敏捷价值观及原则。

（三个朋友）

每个角色的职责

（每个角色的职责）

Scrum 工件

产品待办事项列表：产品待办事项列表包括所有的新功能、对现有功能的更改、技术要求(例如基础架构升级或体系结构要求)。产品经理、产品所有者和Scrum团队会不断完善这一点。改进的目的是对待办事项的内容进行优先级排序、分割和细化，这样团队就可以在Sprint计划期间选择待办事项中的第一组项目。
Sprint 待办事项列表：从产品待办事项列表中挑选出团队为Sprint提交的任务从而构成Sprint待办事项列表。在Sprint/迭代期间，不会再更改。产品所有者卡哇伊在与团队达成共识的基础上进行更改。但不鼓励在Sprint内对Sprint 待办事项列表进行多次更改，如果这种情况经常发生，就必须在回顾会议期间进行溯源分析。
产品增量：在Sprint结束时准备交付的工作项是产品增量。它必须处于潜在可交付的条件下，满足团队定义的“完成”标准，必须被产品所有者接受并且已经准备好进行发布。

Scrum 事件

事件	发生频率	描述
积压细化	连续	史诗和功能被分解为故事，并添加验收标准。待办事项被划分优先级并排序。
Sprint计划	一次Sprint持续4个小时，周期为2周	挑选出经过优化并为团队准备好的优先级最高的故事。团队对故事进行评估，并根据自身的能力进行Sprint。
Sprint	可以为2—4周	不建议经常更改Sprint时间。设置的节奏必须运行至少3到4个Sprint，以便收集可预测的数据。
每日站会	每天10-15分钟	Scrum Master为故事的交互提供了便利，团队共享前一天彼此的工作，提出遇到的问题和障碍，并制定当天的战略和计划。
Sprint评审会议	在冲刺结束时进行一次	该事件主要面向利益相关者，根据Sprint审核和结果，对产品待办事项列表进行输入和更改。
Sprint回顾会议	在冲刺结束时进行一次	这是整个团队“神圣的学习时间”。会议中讨论Sprint期间遇到的问题和困难，对问题进行了溯源分析，并最终达成解决方案，以便日后解决和预防。

Scrum价值观

勇气——每个团队成员都有勇气接受错误、寻求帮助、学会拒绝以及大胆质疑；
承诺——作为团队对Sprint目标作出承诺，但不做过度承诺；
专注——专注于完成已经开始的工作，远离令人分心的和没有优先级的工作，限制正在进行的工作数量。
开放——寻求并重视反馈和学习机会。让障碍、失败和学习成果变得清晰可见。
尊重——团队合作，认可每个成员的工作和成就，建立与人的信任关系。

量化指标

组织可以收集和测量各种度量标准。下面的度量标准最有可能被大多数项目捕获并增加项目的整体价值。

燃尽图：燃尽图是Scrum团队根据每日完成的故事点数量来计算团队在一个Sprint中完成工作的速率的运行图。
速度：速度是指产品所有者在Sprint中完成并接受的故事点数。收集速度相关数据能够使团队、发布和项目变得更加强大、可预测。除了绝对速度之外，速度数据的另一个重要角度是故事点数占总故事点数的百分比。速度不能用来衡量团队之间的效率高低，因为一个团队的故事点与其他团队是不同的。
质量相关度量标准：捕获与质量相关的度量标准，例如发布后生产中报告的缺陷数量，集成测试中的缺陷数量，以了解质量级别。借助定量数据，团队可以提出提高质量的方法。

（质量相关指标）

规模化敏捷项目

尽管Scrum框架规定了运行敏捷团队的指导方针，但可以推断出同规律的指导原则，并可以采用适当的机制，将其扩展至多个团队。SAFe和Nexus提供了在大型企业中扩展敏捷的框架。

企业中的大型项目涉及多个团队，并依赖于其他职能部门和第三方合作伙伴、供应商和供应商。大型解决方案和项目的复杂性需要治理、法规遵循、涉众管理、简化沟通、冲突和风险管理。敏捷项目管理办公室在高级领导、敏捷教练和变革代理人(可能是敏捷项目经理和Scrum Master)的帮助下，负责规模化敏捷的建立。

敏捷项目经理的角色

在大型企业中实施规模化敏捷时，敏捷PM扮演着重要的角色。在通过与多个Scrum团队和各个利益相关者进行交互来实现无缝项目发布的同时，敏捷PM在企业的敏捷转型过程中也发挥着关键作用。

（规模化敏捷）

（敏捷项目经理）

Scrum Master和敏捷PM角色

大规模的敏捷项目要求Scrum Master负责团队的内部运作，而敏捷PM则负责协调多个团队并协调发布活动。

敏捷PM

Scrum大师

负责风险管理，冲突管理，跨团队和外部利益相关者的障碍处理；

与高级领导层、产品经理、产品所有者、Scrum Master密切合作，确保当前版本的顺利实施，为后续版本制定计划，并协调前一个版本的后期生产活动；
定期（每周）促进Scrum of Scrum同步会议)；
当升级时，敏捷PM会指导Scrum Master解决团队内部的风险和障碍。

在Scrum团队中负责以下活动：
Scrum Master关注当前的Sprint和当前的发布版本；
聚焦于Scrum仪式。如果团队及能够达到Sprint的目标，并且有任何变更或风险可以预见，可以通过参加Scrum of Scrum；
在这次会议期间，Scrum Master会提出他们无法解决的、需要帮助的障碍或风险。

发布管理

持续集成和部署：团队在每次迭代后都会发布产品的增量版本，因此早期的持续集成是需要时间的。应鼓励团队在准备阶段或生产环境中进行自动连续部署，以便发布产品的最新版本。企业逐渐使用切换配置来开启或关闭一组功能，以便针对特定细分市场进行发布，或者可以与重要的里程碑（如贸易展览会）同步发布。通过将部署和实际发布分开，可以避免很多风险。可以根据市场需求或在完成强大的Beta测试后，在适当的时间宣布实际的产品发布，并在合规期限或重要里程碑（如贸易展览会）中纳入反馈、安排时间。
后期制作支持：定期发布可工作的软件并不是最终目标，必要时需要客户的支持、培训和客户文档，这些活动也应在敏捷工作环境的范围内进行。

敏捷PM与传统PM的异同

传统项目经理的角色和职责现分布在Scrum团队、Scrum管理员、产品所有者和敏捷项目经理中。
但是传统PM敏捷PM之间最重要但最微妙的区别在于思维定势。

敏捷项目经理是仆人式的领导，他希望创建一个自授权、自组织的团队；
他营造了一个敏捷的环境，在那里每个人都有责任心，不怕失败，愿意学习并不断提高；
敏捷项目管理避免了传统的命令和控制方法，该方法由团队决定；
还有一种有意识的做法是将决策权力下放，以便决策更接近实际情况；
强调工作的可视化和透明度。

成功的敏捷项目需要具备的特征

自组织的团队：自组织的团队被授权并能在很大程度上实现自给自足，这是敏捷的一个重要方面。以前的团队习惯了传统的工作方式，在这种方式下，他们尊重上级做的决策。因此，分散式决策将在很大程度上帮助团队实现自组织、自授权。
响应变化：创建自授权的团队，使他们能够以最小的代价、最快的时间响应变化。
快速反馈循环：当建立了快速反馈循环，且团队能够根据明智的决策适应变化时，敏捷就会蓬勃发展。
持续改进：从过去吸取教训、避免重复错误，这是敏捷团队需要注意的一个重要方面，因此敏捷项团队需要在每次迭代和发布结束时进行回顾。
业务敏捷性：即使工程团队敏捷并能无缝生产软件，也远远不够。“正确构建产品”是不够的，团队应该“构建正确的产品”，也就是说解决方案和产品必须满足客户需要并能够解决客户的问题。此外，其他职能部门，如产品管理、市场营销、销售、人力资源都必须归入敏捷原则和价值观的范畴，以实现以客户为中心并交付价值的业务敏捷。

总而言之，敏捷是一种范式的转变，它不同于分阶段的传统瀑布式方法。后者在预先制定的详细计划上运行，敏捷项目管理是考虑到快速变化的市场场景、颠覆性的技术和不断增长的竞争时的需要。

在开始敏捷项目之前，组织必须投入时间和精力来创建一个有益的敏捷工作环境。首先，要确保最基本的敏捷培训和创建小型敏捷团队(建议5到9名成员)，以及实现团队自组织。其次，必须确定敏捷教练和变革代理人，以确保敏捷转型的开始并保持小步子前进，并且不会随着团队、业务和领导以敏捷的名义回归传统的瀑布式方法而自然消亡。