agile项目管理

本文目录一览：

• 1、第3章 敏捷项目管理概述 转
• 2、敏捷项目管理
• 3、Agile敏捷管理

第3章 敏捷项目管理概述 转

第3章 敏捷项目管理概述 

3.1  敏捷项目管理架构 1.敏捷项目管理架构概述 敏捷项目管理架构(Agile Project Management Framework,APMF)，旨在协助团队聚焦于将项目的商业价值最大化，是基于价值分析和分解的项目管理，也就是价值驱动的项目管理。

第3章 敏捷项目管理概述

3.1  敏捷项目管理架构

1.敏捷项目管理架构概述

敏捷项目管理架构(Agile Project Management Framework,APMF)，旨在协助团队聚焦于将项目的商业价值最大化，是基于价值分析和分解的项目管理，也就是价值驱动的项目管理。

2.参与人员

APMF敏捷项目管理过程中，参与人员包括干系人、发起人、产品负责人/客户代表、敏捷教练、团队成员和测试员。

3.敏捷项目管理阶段

敏捷项目管理可分为5个阶段：立项阶段、启动阶段、发布循环阶段、迭代循环阶段、收尾阶段。

4.产出

(1).立项阶段

1).建立项目愿景，产出“产品盒”。

2).准备商业论证，产出“商业论证”。

(2).启动阶段

1).制定项目章程，产出“敏捷项目章程”。

2).辨识角色，产出“角色卡”。

3).建立产品待办列表，产出“用户故事卡”和“产品待办列表”。

4).进行粗略估算，产出“有粗略估算结果的用户故事卡”。

5).建立产品地图/用户故事地图，产出“产品地图”。

(3).发布阶段

1).分解用户故事，产出“已分解的用户故事”。

2).定义验收标准，产出“已撰写验收标准的用户故事”。

3).估算用户故事点数，产出“已估算点数的用户故事”。

4).发布待办列表，产出“已排序的产品待办列表”。

5).刺探，产出刺探的结果。

6).进行迭代循环，产出“增量成果”。

7).发布与回顾，产出“发布增量成果”和“改进行动方案”。

(4).迭代阶段：

1).迭代规划，产出“工作卡”和“已排序的产品待办列表)”。

2).准备测试用例，产出“验收测试用例”。

3).开发和测试增量成果，产出“通过验收测试的增量成果”。

4).每日站立会，产出“用户故事看板”和“燃尽图”。

5).迭代审查与回顾，产出“改进行动方案”。

(5).收尾阶段

1).交付项目成果，产出“项目成果”。

2).进行项目回顾会议，产出“改进行动方案”。

3).收尾项目活动。

3.2  敏捷团队

敏捷团队是被充分授权且自我组织的跨职能团队，他们拥有令人赞赏的技能，他们将时间、精力、金钱集中在最有商业价值的部分。

敏捷自组织团队要做到：

(1).自律。

(2).共同分担责任。

(3).达成共识的核心价值观并遵守团队工作协议。

(4).遵守承诺。

(5).开发过程透明化。

(6).遵从公司标准。

3.3  敏捷团队成员

3.3.1  开发团队

1.开发团队的组成

2.开发团队的工作

(1).确认用户故事。

(2).罗列待办列表。

(3).完成增量产品或成果。

3.3.2  敏捷教练/团队促进者

1.敏捷教练的责任

(1).改善团队动态行为。

(2).改善的代言人和影响者。

(3).进行过程裁剪与敏捷实践裁剪。

(4).促进团队讨论阶段目标及相关限制。

(5).促进过程改进顺利进行。

(6).协助识别可以使团队更有生命力的新事物。

(7).使团队成长并培养出更多的敏捷教练。

(8).对现状提出挑战。

2.敏捷教练的目标

(1).协助团队达成令人惊艳的成果。

(2).协助团队发展和更健康的在一起。

(3).协助每个人在通往敏捷成功的旅程中，踏出下一步。

3.敏捷教练的工作

(1).以设定共同的愿景和充分授权来领导团队。

(2).确认大家遵循敏捷价值观、原则及过程。

(3).以帮团队挡掉干扰和排除团队前进的障碍来服务团队。

(4).促进站立会议、规划会议及审查与回顾会议的开展。

(5).提供支持，确认项目有明显的进展，且确保计划是灵活的。

(6).精髓是帮助团队成长。

3.3.3  产品负责人/客户及发起人

1.产品负责人/客户的工作

(1).拥有产品待办列表，也就是项目完成哪些功能。

(2).决定每个发布的日期和内容。

(3).排定优先级，包括项目、发布、迭代及每天的工作计划。

(4).促进干系人的参与和管理他们的期望。

2.发起人的工作

(1).提供项目目标及财务资源。

(2).对产品负责人提供指导。

(3).要参加发布与迭代审查，以查看团队是否已交付增量成果。

(4).时刻关注价值和成本。

3.4  仆人式领导

3.4.1 什么是仆人式领导

敏捷仆人式领导，运用快速迭代等积极的作法，拥抱变化，进行团队激励与团队合作，做出最深度契合用户需求的产品。仆人式领导者必须从解决问题转换为提倡授权，帮助团队成员成长和帮助他们解决实际的问题，不断进化，逐渐具备自我组织、自主成长、自我修复的敏捷能力，达成迭代目标。

3.4.2  积极倾听：仆人式领导的询问和倾听

仆人式领导，最需要练习的是积极倾听，也就是要学习如何问问题和停止解决问题。积极倾听的有效步骤为：听、了解、响应。

仆人式领导者要倾听、要询问让团队思索的问题，只问而不讲答案，借由询问问题，让团队学习思考解决问题的方法。这样能加强团队建设、找到双赢解决方案、减少冲突及促进了解。仆人式领导者要引导并授权团队去反应、思考、发现及让他们自己做决定。

3.4.3  开发高情商

EQ是了解与管理我们的情绪、社会互动及人际关系的竞争力，包括自我察觉、自我管理、社会察觉、人际关系管理。

3.5  组建高效能团队

1.团队组建阶段

(1).建立期。

(2).风暴期。

(3).规范期。

(4).高效期。

2.管理冲突

(1).很技巧的决定冲突的严重性。

(2).小心的决定是否需要介入。

(3).拒绝用逃避的方式来解决问题。

3.促进团队会议技巧

(1).协作游戏

3.6  沟通与团队空间

1.面对面沟通

2.集中办公

3.团队空间

(1).信息发射源。

(2).讨论环境。

(3).支持工具。

(4).视频会议。

(5).空间安排。

4.虚拟团队

3.7  指导团队

1.指导技巧

(1).培训。

(2).教练。

(3).师徒辅导。

2.指导方式

(1).初期进行全队指导。

(2).中期进行个别指导。

(3).后期进行全队指导。

3.注意事项

(1).时区的不同。

(2).阶层的不同。

(3).更多的文档。

(4).文化的差异。

敏捷项目管理

在敏捷项目管理角色方面，大多数敏捷流程 - 特别是Scrum - 不包括项目经理。敏捷的“项目经理”角色和职责在项目中共享，即团队，Scrum Master和产品所有者。

在敏捷开发，Scrum的拥有最谈谈 什么   是 敏捷项目管理。因此，让我们使用Scrum作为回答这个问题的模型。在Scrum项目中，有三个角色：产品所有者，Scrum Master和团队。

产品所有者负责项目的业务方面，包括确保正确的产品构建和正确的顺序。优秀的产品所有者可以平衡竞争优先级，可供团队使用，并有权对产品做出决策。

Scrum Master担任团队的教练，帮助团队成员以最有效的方式一起工作。一个优秀的Scrum Master将该角色视为向团队提供服务，消除进度障碍，促进会议和讨论以及执行典型项目管理职责（如跟踪进度和问题）的角色。

在确定如何最好地实现产品目标时（由产品所有者建立），团队自身承担敏捷的项目管理角色。团队成员将协作决定哪个人应该处理哪些任务，哪些技术实践是实现既定质量目标所必需的，等等。

那么，关于这个过程的“敏捷”是什么？敏捷项目管理将责任分配给多个团队成员。就Scrum而言，它是项目的产品所有者ScrumMaster和团队的其他成员。

在敏捷项目管理中，世界可能会将Scrum Master视为项目经理的21世纪版本。但与传统的项目经理不同，Scrum Master并不被视为对项目成功（或失败）的信任（或责备）。

Scrum Master的权限仅限于该过程。Scrum Master是该流程的专家，并使用它来让团队达到最高水平。但是，Scrum Master并不具备项目经理所承担的许多传统职责 - 范围，成本，人员，风险管理。

谁负责敏捷开发中的传统项目经理职责？

传统的项目经理通常承担很大的责任。他们负责管理范围，成本，质量，人员，沟通，风险，采购等。

敏捷项目管理经常使传统的项目经理陷入困境。例如，他或她被告知做出范围/进度权衡决策，知道如果项目进展不顺，产品经理或客户可能会猜测这些决策。

敏捷承认这一困难，并分配传统项目经理的职责。这种新模式的敏捷之处在于，许多这些职责，例如任务分配和日常项目决策，都会回归到他们理所当然的团队。

范围和进度权衡的责任归产品所有者所有。质量管理成为团队，产品所有者和Scrum Master共同承担的责任。其他传统任务也在团队的敏捷项目管理角色中分发。

像Scrum这样的敏捷流程绝对可以扩展。虽然典型的敏捷项目在一到三个团队中有五到二十人，但敏捷实施在200到500甚至1,000人的项目上取得了成功。

正如您所料，这种规模的项目必须引入更多的协调点和敏捷的项目管理，而不是小规模的实施。

为了协调许多团队的工作，较大的项目有时会包含一个名为“项目经理”的角色。虽然在项目中涉及此项目或背景的人员非常有帮助，但我们需要注意与项目经理职称相关的行李。 。

即使是在一个非常大的敏捷项目中，团队仍然会做很多项目管理。例如，团队决定如何分配任务，而不是项目经理; 所以项目经理角色变得更像项目协调员。

职责包括分配和跟踪预算; 与外部利益相关者，承包商和其他人沟通 在团队，Scrum Masters和产品所有者的指导下维持风险普查; 等等。这是一个真正的敏捷项目管理角色。

项目经理 vs Scrum Master vs 项目负责人

For new contacts with Agile, project managers and scrum protagonists may look similar or even the same. But it is important to recognize the differences between the two, the possible overlap of certain tasks, and how they complement each other in large projects. ( 对于刚接触Agile的人来说，项目经理和scrum主角可能看起来相似甚至相同。但重要的是要认识到两者之间的差异，认识到某些任务可能重叠的地方，并认识到它们在大型项目中如何相互补充。)

Scrum: 什么是猪和鸡的角色？

Roles are key in Agile: The business fable of The Chicken and the Pig explains breakfast: pigs and chickens in the Scrum process. It’s a way to differentiate between roles in the Scrum/Agile world. (角色是敏捷的关键：鸡和猪的商业寓言解释了早餐：在Scrum过程中的猪和鸡。这是一种区分Scrum/Agile世界中角色的方法。)

敏捷开发：如何成为合格的Scrum Master？

Scrum Master is considered to be a project manager in many projects, which is actually a misunderstanding. At the same time, I often see people who argue that Scrum Master is completely different from project managers. So what is Scrum Master’s responsibility? What can we do to become a qualified Scrum Master? ( Scrum Master被认为是许多项目开发中的项目经理，这实际上是一种误解。与此同时，我经常看到那些主张Scrum Master和项目经理完全区别的人。那么Scrum Master的责任是什么？我们可以做些什么来成为一名合格的Scrum Master？)

如何成为Scrum项目的优秀产品负责人？

Without a good product owner, the Scrum project will not succeed. It must be decisive, not only by referring to the required responsibilities, but also by embedding the following thinking patterns: 1) To continuously protect the best interests of customers in terms of functions provided. 2) Protect the organization as a whole in terms of strategic direction and return on investment. (如果没有一个好的产品所有者，Scrum项目就不会成功，他必须具有决定性，不仅要求提到所要求的责任，而且还要嵌入以下思维模式：1) 在提供的功能方面不断保护客户的最佳利益，2) 在战略方向和投资回报率方面保护整个组织。)

什么是产品负责人在Scrum中的角色？

Role and Responsibilities - The product owner who represents the company’s ownership of the product is a member of the Scrum team. However, the product owner has no authority over other members of the team, as is the case with Scrum Master. The product owner is responsible for the long-term care of the product and the success of the product. (代表公司拥有产品的产品负责人是Scrum团队的一员。但是，产品所有者对团队中的其他成员没有权限，与Scrum Master相同。产品负责人负责长期照顾产品，并负责实现产品成功。)

Scrum团队如何运作？ – 简要指南

Scrum in a Nutshell: Scrum relies on which are periods of time when software development is actually done. A Sprint usually lasts from one week to one month to complete an item from the backlog. The goal of each Sprint is to create a potential shippable product. (Scrum依赖于软件开发实际完成的时间段。冲刺通常持续一周到一个月，以完成积压的项目。每个冲刺的目标都是创建一个潜在的可交付产品。)

如何成为Scrum项目的优秀产品负责人？

A product owner is the guardian of the product vision and goals, because it focuses on delivering business results and values for Scrum projects. So the question is how to be the best product owner? Based on our experience, we believe that the product owner should possess some key qualities. (产品所有者是产品远景和目标的守护者，因为它专注于为Scrum项目提供业务结果和价值。所以问题是如何成为最好的产品拥有者？根据我们的经验，我们认为产品所有者应该具备一些关键的品质。)

什麼是Scrum的自组织团队？

A self-organizing team is a team that has the autonomy to choose how best to do its work, rather than being guided by others outside the team. ( 自组织团队是一个团队，拥有自主选择如何最好地完成工作，而不是由团队外的其他人指导。)

Scrum团队是什麼？

The Scrum team shares different tasks and responsibilities related to product delivery. Every role is closely related. It is recommended that Scrum team members work together in the same place as possible. Let’s look at these roles from the perspective of responsibility, authority and characteristics. (Scrum团队分享与产品交付相关的不同任务和职责。每个角色都密切相关。建议Scrum团队成员尽可能在同一位置一起工作。让我们从责任，权限和特徵的角度来看看这些角色。)

Scrum中最经常提到的10个基本规则

The main goal of Scrum rules is to optimize the development process and minimize waste of time. Scrum Master is responsible for ensuring that everyone follows Scrum project-related rules. These rules combine Scrum processes so that everyone knows how to play. (Scrum规则的主要目标是优化开发过程并最大限度地减少浪费的时间。在Scrum Master的是负责确保每个人都遵循的Scrum与项目相关的规则。这些规则将Scrum流程结合在一起，以便每个人都知道如何玩。)

Agile敏捷管理

目录：

一、什么是Agile

二、什么样的团队适合Agile

三、敏捷开发的实施步骤（SCRUM）

四、Agile敏捷管理的具体实施

五、敏捷工作坊的体验

六、结语

七、附：SCRUM在教育和政府领域的应用

从本质上讲，敏捷（Agile）并不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代，让产品逐渐完善。

在数十年前，瀑布式项目管理是软件研发的主流方法，在研发过程中，团队成员将会花大把的时间和精力在项目前期去收集资源和信息，然后基于这些去做产品设想和研发规划。

到了70年代，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度还很慢，显然Out了。尤其到了90年代末期，开始出现黑客来捣乱，这就意味着前功尽弃、全部推倒重来，这简直是研发的噩梦。

相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。

另外，你也可以通过这个视频学习 什么是敏捷（Agile）

在2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观。

总结为：

尽管如此，这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注更核心的事物：人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行，他们又将写了 敏捷开发12项原则 作为指导：

如果我们把这些原则和遇到的问题对号入座，很快我们就会发现，这12项原则正是对应了客户期望。比如，客户不会关心开发文档写的怎么样，他们更感兴趣交付的成品能干什么；他们不在意你的开发计划，他们希望你能立马交付；昨天他们想要修个BUG，而不是等到下次版本更新。

我们总会遇到需求多样化的客户，而这时，敏捷能够确保你在研发过程中始终将用户需求作为核心。

敏捷虽然听起来光鲜亮丽，但不是所有项目都能用敏捷来做。

敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目，也就是说并不是所有事情都是按部就班。因此，我们得知道在这种快速变化的环境下，团队是否能够适应变化。

所以在部署使用敏捷前，需要团队先明确几个问题：

1.你是否会愿意接手目标不明确的项目？

敏捷项目管理中有句话叫做：快速失败。比如我们接手了一个连最终产出都不明确的项目，首先我们会先交付最小模型产品，这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品，所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后，我们才会逐步了解他们的真实需求，这时候我们离成功又近了一步。

2.你会如何规避项目风险？

就像我们前面提到的，敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路，用传统项目管理的方法来推进的话，我们会要承担更大的风险。当然就算我们开始敏捷之后，也要准备好随时响应未知问题。

3.你的团队能有多灵活？

作为项目经理，我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊，是否愿意放下老套路，根据用户需求来调整想法、重新规划方向。

4.公司阶层制度严格吗？

敏捷的其中一项原则不仅是和用户一起工作，研发成员的身份也会发生变化。你们公司的文化开放吗？是否能接受扁平和开放的管理方法？

5.你怎么衡量进度？怎么定义成功？

用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务，那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了？

在Scrum中，产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。

有了产品清单，产品经理就会开始确定需求优先级，研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。当一轮迭代完成后，全员再次分析需求清单、划分需求优先级，然后进入下一轮迭代。

1.三个角色

2.三种可视化文档

另外，用户故事要注意必须完整，遵循INVEST标准：

Independent——让一个用户故事独立于其他用户故事

Negotiable——可协商性，协商更多细节

Valuable——必须对客户具有价值

Estimable——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划

Small——规模小，至少要确保在一个冲刺周期中能完成、

Teatable——可测试，便于确定它是可以完成的

3.三种不同形式的会议

1、确定敏捷开发中的3个角色：Product Owner, Scrum Master, Scrum Team。

2、拟定待办事项清单，并确定优先级

3、改进和评估待办事项清单：

·要完成这些事项，现有信息足够吗？

·是否细分到了可以评估的程度？

·是否成员都能接受，用于评定一个事项已完成的标准？

·用相对难度去评估，利用斐波那契数列的数字

4、冲刺规划会：Product Owner, Scrum Master, Scrum Team一起规划冲刺的内容，记录每个冲刺完成事项的点数

5、将工作透明化：利用白板和燃尽图更新进度

6、每日站会

7、冲刺评估和冲刺展示：将成果展现给产品负责人看，哪些事项可以移到“完成事项”一栏，并接受评价。

8、冲刺回顾会

9、上一个冲刺阶段结束之后，立刻开始新的冲刺阶段

在冲刺阶段结束之际，把所有已完成的用户故事列出来，将各项难度评分加在一起，最终的数字就告诉我们团队的进度是多少。然后再看未完成用户故事的难度分值总和，就可以知道什么时候可以完成项目。

速度 X 时间 =交付工作量

敏捷非常注重节奏，当你有多个任务要交付，团队更需要注重节奏的把握。而身为项目经理，我们的职责是让整个团队通过协作最终交付产品。

敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下7步：

第1步：通过战略会议定义你的愿景

每当开始新项目时，第一件要做的事情是定义产品的业务需求，或者说想要达到的愿景。事实上，我们只需要回答一个问题：你为什么想要做这个产品。这是我们心中的蓝图，时时提醒我们不要跑偏。

作为一家产品公司，定义愿景的最佳方法之一是电梯演讲：

用于：（哪部分目标客户）

需求：（用户的需求）

类别：（我的产品是哪种类型）

功能：（产品的价值、客户为什么选我们）

竞品：（主要的竞争对手有哪些）

差异化：（和竞品的差异化描述）

即使我们做的不是软件产品，我们也可以根据项目的目标来调整上述内容。

战略会议的参与角色都有谁？

此时我们要让更多人认同这个项目，所以很多关键的利益相关者自然不能缺席，包括相关主管、经理、主任和产品经理。

战略会议该什么时候召开？

项目开始前我们就该来开战略会，或者至少每年一次的定期会议来保证愿景依然不过时

战略会议要召开多久？

这个就由你主观来决定了，一般来讲，花4-16小时来探讨战略已经足够了。

第2步：绘制产品路线图

当我们开完战略会后，就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路，让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划，而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。

项目管理专家Roman Pichler认为：目标导向的产品线路图能够聚焦于目标和产出结果（比如：获客、增加活跃度、满足客户需求）。而产品特性来自于这些目标，所以我们在制定目标时应谨慎，每个目标对应3-5个产品特征。

而每个目标，我们需要包含5个关键信息：时间、名称、目标、产品特征和衡量标准，有了这些，我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。

产品路线图由产品负责人画，同时听取利益相关者的想法，如客户、市场、研发代表等，并最好在战略会议结束后着手画产品路线图。

第3步：制定发布计划

当我们有了战略和计划，下一步我们就可以暂定几个时间节点。

这个阶段产品经理要严格按照计划发布新版本。我们也不用担心功能不齐全的问题，敏捷项目都会有多次发布的过程，所以我们只要优先发布核心功能的版本即可。

举例来说，你的项目要在11月交付，而你可能在2月初就已经做好了最小模型，打算在5月左右发布完整版。这些时间节点的安排都将由你的项目难度和每次迭代时长（或者说每次达成目标需要的工作时长）决定。通常每次发布新版本都需要经历3-5次迭代。

谁来制定发布计划？

产品经理、项目经理和所有团队成员都该来参与其中。当然，邀请少数利益相关者来加入其中也是对其他成员的鼓励，让团队能够尽早开始。

发布计划什么时候来做？

越早越好，你的发布计划应该在确认新产品后的第一天开始制定。在随后的每个季度中至少记录一次。

制定发布计划要多久？

一般来说会需要4-8小时，实际时长由具体情况决定，但不能因为它拖进度。

第4步：制定迭代（Sprint）计划

迭代（Sprints），我将其理解为通过短期研发完成具体任务来达到目标的一个过程，也是帮助产品经理和研发团队逐渐切入项目细节的方法。

通常情况下，每次迭代大约要花费1-4周。具体的时长我们需要根据团队过往的表现情况来制定，同时尽量保持每次迭代的时长相同。

哪些角色参与制定迭代计划？

迭代是整个团队的活，因此，产品经理、项目经理以及其他所有成员都该积极参与其中，表达自己的声音和想法。

迭代计划什么时候来制定？

在每次迭代周期开始前，我们就需要做好迭代计划。比如说，你的计划是每周迭代，那么就你就需要在每周一（或者你选好的某一天）告诉其他人迭代计划。

制定迭代计划要多久？

迭代计划是迭代周期的基石，虽然如此，我们也不要在这上面浪费过多的时间，通常2-4小时足够了。写好了迭代计划也就意味着我们已经踏上了正轨。

第5步：每日站会

在每次迭代过程中我们需要有时间来确认项目组没有遇到阻碍，同时保证能准时完成既定目标。这时候我们就需要使用每日站会。

每日站会，如同字面意思一样通俗易懂，每天花15分钟左右的时间来讨论下面3件事：

昨天我完成了哪些事情

今天我打算做哪些事情

我有遇到哪些问题，如何解决

或许讨论这3件事，可能让团队的一部分人的脸挂不住。但这对推动敏捷项目管理的沟通有积极意义。敏捷之所以能够跨团队协作，主要依靠的就是团队快速响应和有让成员发声表达的空间。

第6步：迭代（Sprint）结束了？那就进入评审阶段吧

如果迭代中一切顺利，那么迭代周期结束后，我们需要来检测下软件的功能。我们可以借评审的机会来向团队成员和利益相关者展示成果。

作为产品经理，你对产品功能有选择的权利。如果有哪步错误，尝试多问几个为什么？下次迭代时我该怎么调整才能让团队达成目标？敏捷是不断学习和迭代的过程，你的流程管控和最终产出也是同一道理。

哪些角色参与评审？

团队全员和利益相关者都应该参加迭代评审会来确认项目进度和表达他们的观点。

什么时候执行评审？

每次迭代结束后就可以开始。

评审阶段要多长久？

无需特意去准备PPT、功能说明，审查会最多1-2小时就够了。

第7步：迭代（Sprint）回顾总结

为了让敏捷项目管理能顺利运作，我们在每个阶段结束后需要知道下一步要做什么。这是我们在迭代回顾阶段要做的事。当迭代和审查结束后，接下来该去决定下次要做哪些工作。我们需要回顾下，在迭代中是否发生了些事情改变了你的既定时间，甚至是项目愿景。

谁来参加回顾总结会议？

回顾总结是审查的延伸，这时利益相关者离开也没有关系，而其他团队成员则加入其中，给出自己的意见。

什么时候来做？

当然最好是在审查阶段结束后，立刻开始迭代回顾总结。

这会花多长时间来做？

概括下来大概几个词：简短明了、甜蜜温馨，最多花1-2小时来总结和大致规划下次计划。

工作坊的体验主要是让学员大概体会一下运用敏捷的方式开发项目的流程，并通过一些敏捷工具深化在敏捷开发过程中的运用。

1、制作自行车项目

（1）分组并确定团队内敏捷3个角色

（2）定冲刺周期（每10min1个sprint，3个sprint）

（3）在冲刺开始前，给每个组15分钟开战略规划会，此期间验收人对自行车提出需求，要满足什么样的功能，团队开战略会列出任务清单。

（4）每个sprint结束后给每个组7分钟开站会

（5）每个组的SCRUM Master更新看板和燃尽图

（6）进行项目验收，对成果进行点评

（7）结束后小组内进行总结回顾会

2、乐高堆房子项目

（1）分组并确定团队内敏捷3个角色

（2）定冲刺周期（每15min1个sprint，4个sprint）

（3）在冲刺开始前，给每个组15分钟开战略规划会，此期间验收人对自行车提出需求，要满足什么样的功能，团队开战略会列出任务清单。

（4）每个sprint结束后给每个组10分钟开站会

（5）SCRUM Master更新看板和燃尽图

（6）在第三个Sprint开始时，要求团队内交换2名成员到其他组完成自己组的任务，期间不得交流，只能依据看板进行

（7）进行项目验收，对成果进行点评

（8）结束后小组内进行总结回顾会

七、SCRUM的应用

1、SCRUM与教育

教师首先让学生对自己的性格做评价，将自己划分为不同类别，分为”勇敢类“，“喜欢数学类”，”关心他人感受类“，”勇往直前实现目标类“，将不同类型的学生组合在一起，形成多功能小组。教师拟好所有待学事项，让各小组的学生每天将“所有事项”移到“待办事项”中，然后开始动手，打开教材，自己学习，组内互教互学。教师从“完成事项”一栏随机挑出一些事项问组内成员，以确定每个人都理解相关概念，只有当每个人都理解了之后，才符合所说的”完成的定义“，一切交给学生来做决定。

2、SCRUM与政府

制定政策：每周都去改变一件事情，采用增量方法，每周都会展示一种可交付的产品，每个机构都会切实感受到成果的存在。

书籍建议：

《敏捷革命：提升个人创造力与企业效率的全新协作模式》

SCRUM的一些工具：

Leangoo（领歌）——基于看板的可视化协作

Confluence——Jira

国外有Redmine，Axosoft，国内有禅道，一些自研工具（百度Icafe，阿里Aone，腾讯Tapd)

劳伦斯在《七根智慧之柱》中写道：所有人都做梦，但是却不尽相同，那些夜里在蒙灰的心灵角落做梦的人，早上醒来往往发现是空洞虚无的。而那些白日做梦的人，则是最危险的，因为他们会在睁着眼睛做梦的时候，把梦想变成现实。

看了这么多，不如试一试吧！此文由个人整理而来，主要来源于个人在敏捷团队时敏捷开发的逻辑和思考，以及明道云博客和敏捷相关书籍、英文文档翻译等。如有疑问或补充，欢迎评论下方交流~