敏捷项目管理的重要知识点

备考PMP的小伙伴都知道，敏捷已经成为考试中的一大重要部分，要想顺利通过PMP考试，敏捷相关知识必须要掌握。

今天，小编就带大家回顾一些涉及敏捷项目管理的重要知识点。

敏捷宣言

我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。通过这项工作，我们开始更重视：

个体和交互  胜于  流程和工具

工作的软件  胜于  详尽的文档

客户合作    胜于  合同谈判

响应变化    胜于  遵循计划

也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。

敏捷阶段框架

相较于结构化项目管理的启动、规划、执行、监控、收尾五大过程组，部分流派将敏捷也做了一个五阶段框架：构想、推演、探索、适应、结束。他们不能直接跟结构化项目管理中五大过程组完全匹配对应，但是可以粗略这样对应。

构想阶段，得到产品愿景；推演阶段，得到用户故事清单、产品待办事项列表、产品发布计划等；探索阶段，执行得到完成的用户故事；适应阶段对完成的进行把关；结束阶段，完结整个项目。

敏捷项目章程

敏捷项目也是有项目章程的。

项目章程是重要的管理文件，需要所有干系人的参与。

虽然专家建议章程应不超过一页，但是因为所有的干系人必须参与进来并且达成一致意见，所以创建项目章程是非常具有挑战性的。 

敏捷项目章程中应包含3个关键信息：愿景，任务和成功标准。

敏捷教练

它是指掌握了敏捷知识和经验的人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。

敏捷教练可以是内部教练或外部教练，教练需要：

1）跟不同团队共事时具备平衡视角；每个团队具备不同的进展节奏，可能会面临制约，需要帮助去克服；

2）忠于团队成员价值；

3）认识社会心理及团队复杂性；

4）运用有效方法解决团队面临的问题；、

5）开发方法进行非侵入型干预从而改变团队动力；

6）学习真正需要什么才能让人们作为一个团队去工作。

仆人式领导

仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。仆人式领导的作用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。

仆人式领导按照以下顺序从事项目工作：

1）目的

与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合作互动。整个团队在项目层面而不是在人员层面优化。

2）人员

目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献。

3）过程

不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完成的价值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要。

4）特征

以下仆人式领导的特征让项目领导变得更加敏捷，促进团队的成功：

A. 提升自我意识

B. 倾听

C. 为团队服务

D. 帮助他人成长

E. 引导与控制

F. 促进安全、尊重与信任

G. 促进他人精力和才智提升

优先级技术-MoSCoW

MoSCoW 技术是进行需求优先级排序的敏捷方法。在这种技术下，需求基于以下方面排序：

1）Must 必须有——这些需求是强制性的

2）Should 应该有——这些需求不是强制性的，但是高度渴望的

3）Could 可以有——这些需求如果满足会很好

4）Won’t 不会有——当下可以不去满足，但是将来可以加入在开始新一轮时间箱前，会有一个新的 MUSTs 加入。这些可能是新的需求，或者现有需求被调整优先级进而转移成为 MUSTs

Kanban 看板

看板在项目实施期间作为信息发射源运用，它有助于相关干系人去了解冲刺或迭代的当下状态。

1）看板是一个跟精益和及时制生产相关的概念。

●任务板被细分成段来反映关键活动。

●故事是由索引卡或代表的便利贴来表示。

●卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化。

●看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指挥。

2）Kanban卡片

●Kanban任务板上的每一张卡片就是Kanban卡片。

●Kanban卡片用来显示迭代过程。

●Kanban任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。

●Kanban卡片反映所有需要被跟踪的事物。例如：用户故事，缺陷，任务。

●在用户故事定义完整前，相关干系人需要对用户故事必须经历的部分进行评估。

3）简化的看板面板简化的看板面板有3列：

●待完成

●进展中

●已完成

用户故事

用户故事：User Strory，它是这样来描述需求的：身为某一个角色，为了什么价值，需要什么功能。

用户故事三要素：角色，动机，价值。

举例：作为一个60后的微信用户，为了高效地完成信息交流，需要一个语音聊天的功能。这就是用户故事来描述用户需求的方法。

用户故事开发时长：开发一个用户故事的理想持续时长是2-5天。

用户故事3C：卡片card，对话communication，确认confirm。(罗恩•杰弗里斯提出的)

亲和估算

亲和估算是预测工作量的一个方法，基本的亲和估算模式涉及从小到大范围测量用户故事。这个范围可以是斐波那契数列或者T-shirt尺码，常常贴在大型会议室墙上。然后参与者在估算时可将他们的用户故事贴到这面墙上。

冲刺 Sprint

冲刺包括冲刺规划、冲刺执行、冲刺评审、冲刺回顾四大过程。

冲刺是从规划开始，团队成员必须就本次冲刺的目标和计划达成共识，全体成员在整个冲刺过程按照既定的计划奔着这个目标前进，每天对取得的成果和面临的问题进行沟通讨论。冲刺结束阶段，在冲刺评审活动中召集相关利益相关方一起演示产品功能并获得反馈，获得的反馈是产品列表和下一阶段冲刺规划内容的重要来源。在冲刺回顾活动中，全部团队成员对冲刺执行过程进行检视和讨论，抓住其中存在的问题并讨论优化方案，在下一个冲刺进行改善和优化，实现冲刺过程的优化和冲刺执行效率的提升。

计划扑克

计划扑克是基于宽带德尔菲估算技能、是以共识为基础的工作量估算技能。有时候也称为敏捷扑克，往往在故事点和开发用户故事中用来估算相对工作量。

在计划扑克会议中，每一位成员各持有一副相同价值的计划扑克卡片。 

计划扑克会议按如下的步骤运行：

1）一名调停人，主持会议，不参与估算。

2）产品负责人对用户故事做概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票。 

3）每一位成员抽取一张卡片来估算工作量。 

4）每人抽取一张卡片后，同时将他们的卡片翻转

5）持高和低估算的成员各有一次辩护机会。 

6）达成共识前，不断重复以上流程。

XP极限编程

极限编程(XP)是一项以编程人员为中心的敏捷架构，注重小而迅速的发布。XP极限编程强调以下原则：结对编程、可持续速度、不断自动测试、有效沟通、简单性、反馈、勇气、集体所有、持续集成、激励工作、共享工作空间、现场客户代表、使用隐喻说明概念。

XP极限编程用语中“caves和common”指的是，为团队成员创造的两个分区。common是一个公共的空间，在此常有渗透沟通和协作。caves是一个私人的交易预留空间，需要一个孤立且安静的环境。

五问法（五个为什么 5whys)

五问法是一种通过不断重复询问为什么来识别问题根本原因的技术。每个为什么的答案成为了识别下一个为什么的驱动力。

确切地说，不是强制的使用五个“为什么”来深入到问题的根源，“五”只是一个指示性的数字。

这种技术同鱼骨图结合起来使用提供了一个问题解决可视化过程。