敏捷项目管理冲刺

冲刺是最受欢迎的敏捷项目管理和产品交付方法的一个特性。它们主要用于将大型工作分解为更小、更易管理的块，由敏捷团队交付。

冲刺最初是作为Scrum的一部分被描述的——Scrum是最早的敏捷方法之一，也绝对是当今使用最广泛的敏捷方法。它们也被Nexus和LeSS（用于扩展Scrum的方法）以及最新版本的AgilePM所使用。其他敏捷方法如SAFe、DAD和XP使用几乎相同的概念，但使用术语迭代而不是冲刺。

在接下来的段落中，我将首先描述什么是冲刺以及它们是如何构建的，然后提供一些实用的建议和指导，以确保它们按预期交付。

Sprint是一个短期、固定长度的时间盒，团队在此期间致力于完成一组优先级工作。Sprint旨在让交付团队能够以可预测、循序渐进的方式，朝着长期目标取得有意义的增量进展。

将Sprint限制在2-4周的时间框架内，并确保每个Sprint都有明确的目标，这鼓励频繁交付有价值的、战略一致的成果。

Sprint的节奏和纪律性，帮助团队建立动力，逐步管理复杂性，并快速适应变化。重要的是，它通过提供频繁的反馈、学习和调整机会，实现持续改进。

Scrum定义的Sprint具有特定的结构。鉴于Scrum不承认项目经理的角色，这种形式最适合在非项目环境中使用。AgilePM建议对这种默认结构进行一些实用且务实的改进，在项目环境中提供价值，同时不与Scrum的原始意图相矛盾或有所减损。

下图显示了《Scrum指南2020》中描述的Sprint结构——这是由Scrum共同创始人Jeff Sutherland和Ken Schwaber撰写的Scrum权威指南。

它描述了四个关键事件，大多数人会将其识别为Sprint期间发生的团队会议。该图表展示了一个为期2周的Sprint，但对于不同持续时间的Sprint，大多数事件应相应调整规模。

1. 每个Sprint都以Sprint计划事件开始，在此期间：

• 达成Sprint目标
  • 这是一个涉及产品负责人和Scrum团队中开发人员的协作过程。
  • 产品负责人负责确保计划的工作为利益相关者提供最佳价值。
  • Scrum团队需要协商一个他们可以承诺的目标。
• 协商Sprint中要完成的工作
  • 这也是一个涉及产品负责人和开发人员的协作过程。
  • 从产品待办列表中选取满足Sprint目标和实现产品目标所需的项目。请注意，产品目标可能需要几个Sprint才能实现。
  • 在达成精确的Sprint目标和实现该目标所需的工作之间可能存在一定程度的迭代。
• 商定工作的完成方式
  • 这是一个协作过程，开发人员将选定的产品待办列表项目分解为可执行的工作项目，并商定它们在Sprint待办列表中的排序方式。

Sprint待办列表包括上述所有三个要素以及要完成的工作。到Sprint计划结束时，由开发人员拥有的Sprint待办列表，即Sprint的"计划"，将得到确认。

2. 每日Scrum

• 这是开发人员的15分钟（最多）日常会议
  • 通常在每个工作日的同一时间举行。
  • 它不会根据Sprint的长度进行调整。
  • 其目的是让开发人员调整他们的计划，以保持对Sprint目标的关注和承诺。

随着Sprint的进展，可能会交付产品增量，每个这样的增量都包含前面的增量。产品增量的交付是前面提到的有意义增量进展的衡量标准。

3. Sprint评审

• 这是Scrum团队用来向利益相关者展示其在Sprint结束时所交付价值的论坛。
• 最终产品增量将在其对产品目标贡献的背景下进行正式审查，并讨论任何潜在的增强功能
• 假设这些增强功能尚未记录，它们将被添加到产品待办列表中。

4. Sprint回顾

• 此事件的目的是让Scrum团队反思其工作方式的有效性
• 讨论并优先考虑任何改进想法。其中一两个想法将作为下一个Sprint的实验被采用，其影响将在随后的回顾中进行评估

以下是 AgilePM 对 Scrum Sprint 提出的增强功能，这些功能在项目管理环境中能够增加价值。它们最有可能在多团队项目中增加价值，因为在这种项目中，各团队的计划需要同步到一个连贯的整体项目计划中。

5. 第一个增强功能是用特殊的整合Scrum来替代在冲刺结束前2天进行的每日Scrum。

• 此活动持续30分钟，比每日Scrum稍长一些。
• 除了替代原有活动的目的外，还要求Scrum团队预测冲刺中未完成工作的哪些部分将会完成，哪些部分很可能仍未完成。

6. 第二个增强功能是引入项目规划活动。

• 此活动由项目领导角色参与，包括业务愿景师、解决方案架构师和项目经理，他们每个人在AgilePM项目领导中都有特定职责。

注意：从一般项目管理角度来看，角色标签并不重要。此活动应由项目经理和任何其他负责逐个冲刺塑造项目进程的人员参加。

• 来自整合Scrum的短期预测作为此活动的输入，为下一个冲刺中所有团队提供合理的规划输入
• 此活动还为规划超越即将到来的冲刺的更远期目标提供机会，以及为可能不是Scrum团队成员的项目团队成员执行任何项目活动提供机会。

自1997年以来，我一直在项目管理和交付方面采用敏捷方法。我深知这些方法的效果可以有多好，同样也清楚如果运作不当，绩效会有多差。

如果你想在项目管理中拥抱敏捷性，我能提供的最佳建议是按照Scrum指导原则来运行你的Sprint。这意味着如果你是项目经理，需要与Sprint的规划和执行保持一定距离。你需要足够接近以确保它们按预期运作，同时允许敏捷性最强大的方面为其交付注入强劲动力。

以下是成功使用Sprint的6个"顶级建议"

1. 尽量让Scrum保持原样。

• 如果按照Scrum指南正确执行，它是经过验证、测试且有效的。话虽如此，理解其运作原理而不只是程序化地遵循，对于充分发挥其价值至关重要。

2. 以固定节奏使用固定长度的Sprint

• 理论上你可以改变序列中每个Sprint的长度，偶尔进行不规则长度的Sprint确实有意义。例如，偶尔的Sprint可能比平常更长或更短，以适应季节性假期或满足否则会落在Sprint中期的交付日期。
• 然而，默认使用固定长度的Sprint确实能让利益相关者参与规划和进度跟踪变得更容易。

3. 永远不要推迟Sprint结束日期

• 使用Sprint的关键优势之一是它提供的交付可预测性。通过以下方式几乎可以保证有价值产品的按时交付：
  • 尊重Sprint的结束日期，以及
  • 优先处理最高价值和/或风险最大的方面，然后再处理较低价值和/或更直接的方面。

4. 不要跳过任何活动。

• Sprint中的每个活动都有其目的，与敏捷性的经验基础相关。具体包括：
  • 正在做什么以及如何做的透明性
  • 对不断演进的产品和工作方式的检查
  • 对这些进行调整以使产品价值不断提升并改善工作实践的效率和效果

5. 尝试"践行"团队赋权的概念。

• 理解并拥抱支撑敏捷工作方式的价值观，并鼓励与项目相关的每个人都这样做。Scrum将这些价值观定义为承诺、专注、开放、尊重和勇气。引用2020年Scrum指南：

"当Scrum团队和与他们合作的人员体现这些价值观时，透明性、检查和调整这些经验性Scrum支柱就会焕发生机，建立起信任。"

请记住，你不需要遵循Scrum方法才能采纳其价值观。在任何基于团队的工作中，拥抱这些价值观都会增加价值。

• 不要独断专行，要协作式领导。
  • 在项目经理等单一个人独断决定应该做什么和何时做的环境中，团队所有权和承诺会显著减弱
  • 拥抱上述Scrum价值观的协作领导方法将提升质量和生产力。
• 通过产品负责人影响计划（包括解决方案和交付计划）。这需要产品负责人认识到项目领导角色是关键利益相关者。

如果你的团队还不能很好地以敏捷方式工作...

6. 指导他们朝这个方向发展

• 敏捷工作方式很大程度上依赖于这样的理念：做工作的人最能做出关于需要做什么和如何做的详细决策。结合产品负责人作为团队一员协作提供的清晰详细的需求定义和原因说明，这种方式效果很好。我亲自见证了显著的生产力提升，这只能归因于从集中式"命令和控制"方法转向赋权团队。
• 然而，赋权必须被认识为双向的，领导者愿意赋权给团队，团队能够拥抱这种赋权。在团队成员缺乏能力和承诺的情况下，我见过生产力急剧下降。
• Paul Hersey和Ken Blanchard在1970年代发展的情境领导理论描述了领导者（在我们的语境中可能是项目经理）如何向敏捷的最佳领导/团队动态转变。

冲刺是许多敏捷方法的基石，为价值交付提供结构、专注和节奏。虽然其根源在于Scrum，但这一概念已被一系列框架和规模化模型成功采用，通常以更广泛的术语"迭代"来称呼。无论术语如何，原则保持一致：对工作进行时间盒约束，实现频繁检视和适应，并赋能团队围绕明确目标进行自组织。

如果使用得当，冲刺可以显著改善项目交付——但前提是它们得到尊重。将冲刺视为不仅仅是一个时间表，并拥抱支撑它们的纪律、价值观和协作精神，这才是释放其潜力的关键。

对于在敏捷环境中工作的项目经理来说，挑战在于支持而非控制——为被赋能的团队创造空间，同时确保一致性和专注。如果做得好，这种平衡不仅能带来成功的冲刺，还能造就持续高绩效的团队和持久的项目成功。