文/明道团队
什么是敏捷？（Agile）
从本质上讲，敏捷（Agile）并不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代，让产品逐渐完善。
在数十年前，瀑布式项目管理是软件研发的主流方法，在研发过程中，团队成员将会花大把的时间和精力在项目前期去收集资源和信息，然后基于这些去做产品设想和研发规划。
到了70年代，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度还很慢，显然Out了。尤其到了90年代末期，开始出现黑客来捣乱，这就意味着前功尽弃、全部推倒重来，这简直是研发的噩梦。
相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。
另外，你也可以通过这个视频学习什么是敏捷（Agile）
在2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观
我将之总结为：
- 以人为本：重视个体间的合作互动
- 目标导向：我们最终交付的是“可使用的软件”，而不是一堆繁重的文档
- 客户为先：理解客户需求，与客户合作
- 拥抱改变：客户会在不断变化需求的过程中明晰真正需要的，因此敏捷需要拥抱变化
尽管如此，这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注更核心的事物：人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行，他们又将写了敏捷开发12项原则作为指导：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
如果我们把这些原则和遇到的问题对号入座，很快我们就会发现，这12项原则正是对应了客户期望。比如，客户不会关心开发文档写的怎么样，他们更感兴趣交付的成品能干什么；他们不在意你的开发计划，他们希望你能立马交付；昨天他们想要修个BUG，而不是等到下次版本更新。
我们总会遇到需求多样化的客户，而这时，敏捷能够确保你在研发过程中始终将用户需求作为核心。
怎么知道敏捷（Agile）和团队成员是否三观相合
敏捷虽然听起来光鲜亮丽，但不是所有项目都能用敏捷来做。
敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目，也就是说并不是所有事情都是按部就班。因此，我们得知道在这种快速变化的环境下，团队是否能够适应变化。
所以在我们部署使用敏捷前，先来点前戏试试看。在使用前，我们可以先问自己5个问题：
1.你是否会愿意接手目标不明确的项目？
敏捷项目管理中有句话叫做：快速失败。比如我们接手了一个连最终产出都不明确的项目，首先我们会先交付最小模型产品，这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品，所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后，我们会才会逐步了解他们的真实需求，这时候我们离成功又近了一步。
2.你会如何规避项目风险？
就像我们前面提到的，敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路，用传统项目管理的方法来推进的话，我们会要承担更大的风险。当然就算我们开始敏捷之后，也要准备好随时响应未知问题。
3.你的团队能有多灵活？
作为项目经理，我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊，是否愿意放下老套路，根据用户需求来调整想法、重新规划方向。
4.公司阶层制度严格吗？
敏捷的其中一项原则不仅是和用户一起工作，研发成员的身份也会发生变化。你们公司的文化开放吗？是否能接受扁平和开放的管理方法？
5.你怎么衡量进度？怎么定义成功？
用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务，那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了？
研发团队如何使用敏捷
读到这儿，我想你已经跃跃欲试，准备踏上敏捷之路了。
敏捷非常注重节奏，当你有多个任务要交付，团队更需要注重节奏的把握。而身为项目经理，我们的职责是让整个团队通过协作最终交付产品。
敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下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小时来总结和大致规划下次计划。
整个过程都结束了，接下来干啥？
这时候我们可以选择发布新版本、获取用户反馈、规划新功能或者修复bug。持续性的发布、学习、再建，这一系列过程让敏捷在管理方法中异军突起。
比起单纯的靠产品需求清单来执行项目，在敏捷指导下，我们可以通过不断发布新版本来看看客户的反馈。相比花一年时间来开发和发布，然后发现缺失核心功能的传统方法，敏捷能在每次迭代后迅速发现问题，并在下次迭代中及时调整。
如何实施敏捷方法：Scrum和看板
我想此时你已经跃跃欲试想把敏捷带给团队。但还有重要的一步，正如我们前面所说的，敏捷是项目管理的全新理念。为了能更好的执行，有些人研究出了一些敏捷方法。这些方法相似度很高，但从实施的角度来看，两者各有不同：
Scrum
Scrum应该是最广为人知的敏捷方法，与看板并驾齐驱。其受欢迎的原因归功于操作简单、高效以及极高的可复制性。你可以观看这个7分钟视频，学习如何使用Scrum。
我们来看下Scrum的工作原理：
在Scrum中，产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。
有了产品清单，产品经理就会开始确定需求优先级，研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。当一轮迭代完成后，全员再次分析需求清单、划分需求优先级，然后进入下一轮迭代。
看板（Kanban）
看板作为敏捷方法的一种，提倡化繁为简，不让研发团队超负荷工作。因此它和Scrum有一定相似，都强调持续性交付，这个视频解释了看板管理项目的原理。
当然看板也会有自己的三原则：
1.工作流可视化
当项目逐渐复杂的时候，看板工具用“白板”帮我们理清所有项目的进度和归属：代办、进行中、已完成，洞悉项目的关联信息，让事情逐步变得简单清晰。
2.WIP原则
WIP类似于Scrum的迭代清单，一旦制定后就不再加入新的需求（研发团队除外），团队需要依靠看板来了解他们在每次迭代具体的任务量。
3.明确规划下一步
为了更好的实施看板，我们需要知道下一个任务是什么。这也就意味着我们需要实时更新产品需求，重新确定需求优先级。
实施敏捷管理最后的建议
恭喜！你现在应该已经学会了敏捷的概念，和如何实施敏捷开发的方法，现在可以再自己的团队内推广了。
但是值得提醒的是，由于敏捷开发中涉及到大量的计划、开发任务管理、时间进度和负责人，你需要使用一个项目管理工具，让整个管理过程更可控。一个项目管理工具可以这样帮助你做好敏捷开发：
1.进度报告：你可以看到还有多人任务等待完成、有多少延期任务
2.沟通：让每个人反馈任务中遇到的问题和进展
3.分配：项目下的任务应该支持分配到具体的负责人
虽然有不少工具可以做到这些，我们已经研究出了如何使用明道来管理Scrum，如下面的视频演示的那样：
如果你现在就想实施敏捷开发，我会建议你搭配明道一起使用。
本文由明道团队编译，原文来自：https://plan.io/blog
