目录：
一、什么是Agile
二、什么样的团队适合Agile
三、敏捷开发的实施步骤（SCRUM）
四、Agile敏捷管理的具体实施
五、敏捷工作坊的体验
六、结语
七、附：SCRUM在教育和政府领域的应用

什么是敏捷？

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

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

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

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

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

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

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

总结为：

1. 以人为本：重视个体间的合作互动
2. 目标导向：我们最终交付的是“可使用的软件”，而不是一堆繁重的文档
3. 客户为先：理解客户需求，与客户合作
4. 拥抱改变：客户会在不断变化需求的过程中明晰真正需要的，因此敏捷需要拥抱变化

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

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

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

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

二、什么样的团队适合Agile

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scrum的工作原理：

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

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

SCRUM包含的三个内容：

1.三个角色

• 产品负责人（Product Owner）：他/她清楚的知道要做什么，知道产品的特性以及会取得什么成果。从客户的角度去认识产品，思考实际使用产品的人需要什么。

• SCRUM Master：他/她为敏捷开发的过程负责，帮助团队尽其可能完成工作，组织日常会议和帮助团队消除一切障碍。

• SCRUM Team:由开发人员，测试人员，文案以及其他帮助研发的人员组成。团队成员经常扮演多种角色，有些时候开发人员可能把测试做完，测试人员把文案做完，无论如何，他们都在努力完成产品。

2.三种可视化文档

• Product Backlog（产品需求清单）：列出了为落实产品负责人的愿景（根据用户故事）而需要完成的所有事项，并确定各事项的优先级。通常优先级会用斐波那契数列（0，1，1，2，3，5，8，13，21，34，55···）来衡量，目的是更加直观的看出各事项的紧急程度和难度。将这些事项的内容、优先级、负责人分别用便签贴在写有待办事项、在办事项、完成事项的白板上，可视化在团队成员都可以看见的地方，任何时刻成员都清楚知道其他成员在忙什么，同时一定程度上消除沟通障碍。
  

  Backlog

• User Story（用户故事）：是一种表达产品需求的语言格式，通过这样的表述来了解产品需求的细节，为团队合理制定任务优先级。一般的格式为：
  作为一名____用户，我需要__________,所以_____________能够。
  

  用户故事

另外，用户故事要注意必须完整，遵循INVEST标准：
Independent——让一个用户故事独立于其他用户故事
Negotiable——可协商性，协商更多细节
Valuable——必须对客户具有价值
Estimable——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划
Small——规模小，至少要确保在一个冲刺周期中能完成、
Teatable——可测试，便于确定它是可以完成的

• 燃尽图：用来表示整个sprint代办事项清单的进度，当燃尽图曲线接近于0时，也就意味着这次Sprint即将完工。
  燃尽图

3.三种不同形式的会议

• 冲刺规划会：是产品负责人，SCRUM主管和团队碰头的会议，用于讨论用户故事以及估算任务量

• 每日站会：会议时间为15分钟，由团队每位成员站在白板前或者对着Backlog围绕3个问题简述工作进度：
  你昨天做了什么去帮助团队完成冲刺？
  你今天打算做什么去帮助团队完成冲刺？
  在任务完成的过程中，你遇到了哪些问题或障碍？

• Sprint回顾会：讨论在整个任务完成过程中的优点和缺点，每位成员都发言总结，并计划在下一阶段针对优点可以如何更好的发扬，缺点可以做什么改善。
  如何发现需要改善的环节？第一是要相互信任，第二是做到不指责。把注意力放到流程上，寻求解决问题之道。接着团队确定最值得改善的地方，作为下一阶段首要任务。
  如何证明成功做出了改善？这就需要具体的，可操作的方式进行界定：什么是“成功”。

SCRUM实践步骤

1、确定敏捷开发中的3个角色：Product Owner, Scrum Master, Scrum Team。
2、拟定待办事项清单，并确定优先级
3、改进和评估待办事项清单：
·要完成这些事项，现有信息足够吗？
·是否细分到了可以评估的程度？
·是否成员都能接受，用于评定一个事项已完成的标准？
·用相对难度去评估，利用斐波那契数列的数字
4、冲刺规划会：Product Owner, Scrum Master, Scrum Team一起规划冲刺的内容，记录每个冲刺完成事项的点数
5、将工作透明化：利用白板和燃尽图更新进度
6、每日站会
7、冲刺评估和冲刺展示：将成果展现给产品负责人看，哪些事项可以移到“完成事项”一栏，并接受评价。
8、冲刺回顾会
9、上一个冲刺阶段结束之后，立刻开始新的冲刺阶段

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

四、Agile敏捷项目的实施

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

敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下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）结束后小组内进行总结回顾会

六、结语

• Be Agile, not do Agile.很多人会为了敏捷而强行用敏捷方法论做敏捷开发，这样的效果反而会适得其反。一些敏捷工具如看板、燃尽图等都是为了帮助团队更好的遵循敏捷的原则和理念，比如站着开会并不代表你就敏捷了，使用卡片管理也不代表你敏捷了，这些形式只是因为遵循了敏捷原则的结果，而不是让你敏捷的原因。要想成为优秀的敏捷团队，每个团队成员应该理解敏捷的原则和理念并主动的去遵循这样的原则，与此同时感受到敏捷为工作带来的便利并持续遵守敏捷的原则和价值观。

• 深挖敏捷的逻辑本质，我认为其提高的工作效率、带来的便捷主要是解决了沟通的问题，在团队的作战中，内部成员的沟通是核心，而基于看板和站会这样的形式，可以让工作更加透明化、可视化，成员间知道哪些人负责哪些任务，队友在做什么，遇到问题或者需要接触的时候直接找到任务负责人即可。这种减少沟通成本，提高沟通效率的方式，可以更好地交付产品。

• 在敏捷开发团队中，除了3种角色的定义，对岗位、级别没有明确的划分，因此在一个敏捷团队中，是不存在项目经理的。一个团队都在为了更好地交付产品而努力。

• 项目下的任务应该支持分配到具体的负责人，这样能够在任务出现问题的时候更快地追根溯源，责任到人，同样是一种提高沟通效率的方式。

• 将任务尽可能地量化，才能让团队成员更好地感受到每天的进步以及自己在整个团队的贡献度，激发团队作战力量。

• 战略上着眼于全局，策略上迅速行动。重点并不是一开始就设计得尽善尽美，而是先做出基本功能的汽车原型，然后看看哪里需要改善。你越能更快地获得一些反馈意见，就能越快做出更好的汽车。

• 其实敏捷的一些原则和价值观也可以很好的迁移到个人的为人处世以及工作做事中，参透其中的目的和本质，我们自然而然就敏捷了。

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

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

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

敏捷管理

SCRUM的一些工具：
Leangoo（领歌）——基于看板的可视化协作
Confluence——Jira
国外有Redmine，Axosoft，国内有禅道，一些自研工具（百度Icafe，阿里Aone，腾讯Tapd)

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

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