敏捷项目管理是什么

敏捷项目管理是规划和指导项目流程的迭代方法。与敏捷软件开发一样，敏捷项目是在叫做迭代的小型部门中完成的。每个迭代都由项目团队审查和评判;从迭代的评判中获得的信息用于决定项目的下一个步骤。每个项目迭代通常是安排在两周内完成。

一、基本介绍

敏捷项目管理简化了繁琐的流程和文档管理，主张团队内部的面对面沟通和交流。以 Scrum 为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得十分友好。敏捷项目中，项目管理计划分不同的等级，可以用一个洋葱图来表示，也就是洋葱计划图。

战略和投资规划在敏捷项目管理的最外层，由更广泛的组织管理系统来处理。由外往内，不断切分项目计划，最后实现最小周期的可行性版本迭代。对复杂或不明确的客户需求进行合理的分割，最终实现总体上的统一。

二、基本框架

依据2017 年发布的最新版Scrum Guides，以Scrum为主介绍敏捷的结构框架和流程仪式。自20 世纪90年代初以来，它就已经被应用于管理复杂产品的开发。Scrum并不是构建产品的一种过程或一项技术，而是一个过程框架，在此框架中可以使用各种不同的过程和技术，让产品管理和开发实践的成效可以更加清楚地显现出来。

产品的研发过程有许多冲刺，也可视为一次迭代(Sprint)。每个Sprint都可以被视为一个项目，为期不超过一个月。如同项目一样，Sprint被用于完成某些事情。每个Sprint都会定义要开发什么，还有一份灵活的计划，用来指导如何做这些事、工作内容和最终产品。Sprint的长度限制在一个月内。因为，如果周期太长，复杂性和风险也有可能会增加。Sprint通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint同时也把风险限制在一个月的成本上。

标准动作和仪式

敏捷不意味着不再重视计划，而是计划变得更加频繁，仪式感也必不可少。没有这些都会让敏捷不复存在。敏捷的基本流程是: 首先，负责人(通常称之为产品负责人) 从客户/ 组织那里了解到他们的想法；其次，创建一个排好优先级的产品待办事项列表，跨部门团队从这份列表中领取任务，频繁定期地交付小的可运行的产品；最后，在某个时间点，团队演示他们的工作并进行总结回顾。

如果使用迭代，就要制订时间计划，因为迭代是个时间箱。按照定义，团队在时间结束时完成相应的工作。产品负责人决定未完成的工作移至下个迭代还是移到更往后的产品路线图。如果团队使用像Scrum中的迭代，就是以有优先级的待办事项为始，以演示和总结回顾为终。如果团队使用工作流，就可以随时演示和回顾。以下是Scrum的几个主要会议。

(１) 计划会议

在计划会议中针对要做的工作制订计划。这份工作计划是由整个团队共同协作完成的。计划会议是限时的，以一个月的Sprint来说，最长为8个小时。对于较短的Sprint，会议时间通常会缩短。每个参会者都应理解会议的目的，团队需遵守时间盒的规则。计划会议回答以下问题: 接下来的交付的增量中要包含什么内容? 要如何完成交付增量所需的工作?

(２) 每日站会

每日站会是开发团队的一个以15分钟为限的事件。每日站会在每一天都可以举行。在站会上，开发团队为接下来的24个小时的工作制订计划。通过检视上次站会以来的工作和预测即将到来的工作以优化团队协作。站会可以在同一时间同一地点举行，以便降低复杂性。所有团队成员站在看板前，团队成员按照下面的结构做简单的陈述:

１) 昨天，我做了什么?

２) 今天，我准备做什么?

３) 是否有任何障碍阻碍我目标的达成?

(３) 评审会议

评审会议在Sprint即将结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。在Sprint评审会议中，Scrum团队和利益相关者协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是获取反馈并促进合作。对于长度为一个月的Sprint来说，评审会议时间最长不超过４ 个小时。对于较短的Sprint来说，会议时间通常会缩短。会议主持者要确保会议举行，要求每个参会者都明白会议的目的，并且教导每位参会者遵守时间盒的规则。

(４) 回顾会议

回顾会议发生在评审会议结束之后，下个Sprint计划会议开始之前。对于长度为一个月的Sprint来说，回顾会议时间最长不超过３ 个小时，主要用来总结经验教训，提炼最佳实践。在Sprint回顾会议结束时，Scrum团队应该明确在接下来的Sprint中需要实施的改进。