敏捷项目管理的框架与内容

敏捷项目管理的框架与内容
１.基本框架
下文依据2017 年发布的最新版Scrum Guides，以Scrum为主介绍敏捷的结构框架和流程仪式。

自20 世纪90年代初以来，它就已经被应用于管理复杂产品的开发。

Scrum并不是构建产品的一种过程或一项技术，而是一个过程框架，在此框架中可以使用各种不同的过程和技术，让产品管理和开发实践的成效可以更加清楚地显现出来。

产品的研发过程有许多冲刺，也可视为一次迭代(Sprint)。

每个Sprint 都可以被视为一个项目，为期不超过一个月。

如同项目一样，Sprint被用于完成某些事情。

每个Sprint都会定义要开发什么，还有一份灵活的计划，用来指导如何做这些事、工作内容和最终产品。

Sprint的长度限制在一个月内。

因为，如果周期太长，复杂性和风险也有可能会增加。

Sprint通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。

Sprint同时也把风险限制在一个月的成本上。

敏捷项目管理的基本框架如图2-10所示。

图-敏捷项目管理的基本框架
２.标准动作和仪式
敏捷不意味着不再重视计划，而是计划变得更加频繁，仪式感也必不可少。

没有这些都会让敏捷不复存在。

敏捷的基本流程是: 首先，负责人(通常称之为产品负责人) 从客户/ 组织那里了解到他们的想法；其次，创建一个排好优先级的产品待办事项列表，跨部门团队从这份列表中领取任务，频繁定期地交付小的可运行的产品；最后，在某个时间点，团队演示他们的工作并进行总结回顾。

如果使用迭代，就要制订时间计划，因为迭代是个时间箱。

按照定义，团队在时间结束时完成相应的工作。

产品负责人决定未完成的工作移至下个迭代还是移到更往后的产品路线图。

如果团队使用像Scrum中的迭代，就是以有优先级的待办事项为始，以演示和总结回
顾为终。

如果团队使用工作流，就可以随时演示和回顾。

以下是Scrum 的几个主要会议。

(１) 计划会议
在计划会议中针对要做的工作制订计划。

这份工作计划是由整个团队共同协作完成的。

计划会议是限时的，以一个月的Sprint来说，最长为8个小时。

对于较短的Sprint，会议时间通常会缩短。

每个参会者都应理解会议的目的，团队需遵守时间盒的规则。

计划会议回答以下问题: 接下来的交付的增量中要包含什么内容? 要如何完成交付增量所需的工作? (２) 每日站会
每日站会是开发团队的一个以15分钟为限的事件。

每日站会在每一天都可以举行。

在站会上，开发团队为接下来的24个小时的工作制订计划。

通过检视上次站会以来的工作和预测即将到来的工作以优化团队协作。

站会可以在同一时间同一地点举行，以便降低复杂性。

所有团队成员站在看板前，团队成员按照下面的结构做简单的陈述:
１) 昨天，我做了什么?
２) 今天，我准备做什么?
３) 是否有任何障碍阻碍我目标的达成?
(３) 评审会议
评审会议在Sprint即将结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。

在Sprint评审会议中，Scrum团队和利益相关者协同讨论在这次Sprint中所完成的工作。

根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情。

这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是获取反馈并促进合作。

对于长度为一个月的Sprint来说，评审会议时间最长不超过４个小时。

对于较短的Sprint来说，会议时间通常会缩短。

会议主持者要确保会议举行，要求每个参会者都明白会议的目的，并且教导每位参会者遵守时间盒的规则。

(４) 回顾会议
回顾会议发生在评审会议结束之后，下个Sprint计划会议开始之前。

对于长度为一个月的Sprint来说，回顾会议时间最长不超过３个小时，主要用来总结经验教训，提炼最佳实践。

在Sprint回顾会议结束时，Scrum 团队应该明确在接下来的Sprint中需要实施的改进。

３.敏捷的角色
(１) 产品负责人
产品负责人负责把产品和开发团队工作的价值最大化。

客户往往不知道自己需要什么，如一个ICT 软件产品，有近60％的功能客户从来没有使用过，属于过度开发。

产品负责人是负责管理产品待办列表的唯一责任人。

通过产品待办列表可解决上述问题，主要包括: 清晰地表述产品待办列表项；对产品待办列表项进行排序，使其最好地实现目标和使命；优化开发团队所执行工作的价值；产品功能优先级排序，确保产品待办列表对所有
人是可见、透明和清晰的，显示团队下一步要做的工作；确保开发团队对产品待办列表项有足够的了解。

产品负责人可以亲自完成上述工作，或者让开发团队来完成。

然而无论何种情况，产品负责人都是负最终责任的人。

(２) 开发团队
开发团队包含各种专业人员，负责在Sprint完成时交付潜在可发布并且“完成”的产品增量。

只有开发团队成员才能创建增量。

开发团队由组织组建并得到授权，自己组织和管理工作，可以最大化开发团队的整体效率和效用。

团队作为一个整体，拥有创建产品增量所需的全部技能，开发团队的最佳规模通常维持在5-9人。

过小的开发团队，成员之间没有足够的互动；过大的开发团队，会产生太多的复杂性，产生沟通衰减，不便于过程管理。

(３) 敏捷教练
敏捷教练对团队而言是一位服务型领导，帮助团队之外的人了解如何与团队交互。

通过改变与团队的互动方式来最大化团队所创造的价值。

敏捷教练要尽可能确保团队中的每个人都能理解目标、范围和产品域，负责移除开发团队工作进展中的障碍，在组织范围内规划敏捷标准动作的实施，维持自组织团队管理高效运作。