什么是敏捷gile）
从本质上讲，敏捷（Agile）并不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代，让产品逐渐完善。
在数十年前，瀑布式项目管理是软件研发的主流方法，在研发过程中，团队成员将会花大把的时间和精力在项目前期去收集资源和信息，然后基于这些去做产品设想和研发规划。
到了70年代，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度还很慢，显然Out了。尤其到了90年代末期，开始出现黑客来捣乱，这就意味着前功尽弃、全部推倒重来，这简直是研发的噩梦。
相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。
另外，你也可以通过这个视频学习什么是敏捷（Agile）
在2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观
我将之总结为：
尽管如此，这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注更核心的事物：人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行，他们又将写了敏捷开发12项原则作为指导：
如果我们把这些原则和遇到的问题对 入座，很快我们就会发现，这12项原则正是对应了客户期望。比如，客户不会关心开发文档写的怎么样，他们更感兴趣交付的成品能干什么；他们不在意你的开发计划，他们希望你能立马交付；昨天他们想要修个BUG，而不是等到下次版本更新。
我们总会遇到需求多样化的客户，而这时，敏捷能够确保你在研发过程中始终将用户需求作为核心。
怎么知道敏捷（Agile）和团队成员是否三观相合
敏捷虽然听起来光鲜亮丽，但不是所有项目都能用敏捷来做。
敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目，也就是说并不是所有事情都是按部就班。因此，我们得知道在这种快速变化的环境下，团队是否能够适应变化。
所以在我们部署使用敏捷前，先来点前戏试试看。在使用前，我们可以先问自己5个问题：
1.你是否会愿意接手目标不明确的项目p>
敏捷项目管理中有句话叫做：快速失败。比如我们接手了一个连最终产出都不明确的项目，首先我们会先交付最小模型产品，这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品，所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后，我们会才会逐步了解他们的真实需求，这时候我们离成功又近了一步。
2.你会如何规避项目风险p>
就像我们前面提到的，敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路，用传统项目管理的方法来推进的话，我们会要承担更大的风险。当然就算我们开始敏捷之后，也要准备好随时响应未知问题。
3.你的团队能有多灵活p>
作为项目经理，我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊，是否愿意放下老套路，根据用户需求来调整想法、重新规划方向。
4.公司阶层制度严格吗p>
敏捷的其中一项原则不仅是和用户一起工作，研发成员的身份也会发生变化。你们公司的文化开放吗能接受扁平和开放的管理方法p>
5.你怎么衡量进度定义成功p>
用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务，那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了p>
研发团队如何使用敏捷
读到这儿，我想你已经跃跃欲试，准备踏上敏捷之路了。
敏捷非常注重节奏，当你有多个任务要交付，团队更需要注重节奏的把握。而身为项目经理，我们的职责是让整个团队通过协作最终交付产品。
敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下7步：
第1步：通过战略会议定义你的愿景
每当开始新项目时，第一件要做的事情是定义产品的业务需求，或者说想要达到的愿景。事实上，我们只需要回答一个问题：你为什么想要做这个产品。这是我们心中的蓝图，时时提醒我们不要跑偏。
作为一家产品公司，定义愿景的最佳方法之一是电梯演讲：
即使我们做的不是软件产品，我们也可以根据项目的目标来调整上述内容。
战略会议的参与角色都有谁p>
此时我们要让更多人认同这个项目，所以很多关键的利益相关者自然不能缺席，包括相关主管、经理、主任和产品经理。
战略会议该什么时候召开p>
项目开始前我们就该来开战略会，或者至少每年一次的定期会议来保证愿景依然不过时
战略会议要召开多久p>
这个就由你主观来决定了，一般来讲，花4-16小时来探讨战略已经足够了。
第2步：绘制产品路线图
当我们开完战略会后，就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路，让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划，而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。
项目管理专家Roman Pichler认为：目标导向的产品线路图能够聚焦于目标和产出结果（比如：获客、增加活跃度、满足客户需求）。而产品特性来自于这些目标，所以我们在制定目标时应谨慎，每个目标对应3-5个产品特征。
而每个目标，我们需要包含5个关键信息：时间、名称、目标、产品特征和衡量标准，有了这些，我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。
我想此时你已经跃跃欲试想把敏捷带给团队。但还有重要的一步，正如我们前面所说的，敏捷是项目管理的全新理念。为了能更好的执行，有些人研究出了一些敏捷方法。这些方法相似度很高，但从实施的角度来看，两者各有不同：
Scrum
Scrum应该是最广为人知的敏捷方法，与看板并驾齐驱。其受欢迎的原因归功于操作简单、高效以及极高的可复制性。你可以观看这个7分钟视频，学习如何使用Scrum。
我们来看下Scrum的工作原理：
在Scrum中，产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。
有了产品清单，产品经理就会开始确定需求优先级，研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。当一轮迭代完成后，全员再次分析需求清单、划分需求优先级，然后进入下一轮迭代。
看板（Kanban）
看板作为敏捷方法的一种，提倡化繁为简，不让研发团队超负荷工作。因此它和Scrum有一定相似，都强调持续性交付，这个视频解释了看板管理项目的原理。
当然看板也会有自己的三原则：
1.工作流可视化
当项目逐渐复杂的时候，看板工具用“白板”帮我们理清所有项目的进度和归属：代办、进行中、已完成，洞悉项目的关联信息，让事情逐步变得简单清晰。
2.WIP原则
WIP类似于Scrum的迭代清单，一旦制定后就不再加入新的需求（研发团队除外），团队需要依靠看板来了解他们在每次迭代具体的任务量。
3.明确规划下一步
为了更好的实施看板，我们需要知道下一个任务是什么。这也就意味着我们需要实时更新产品需求，重新确定需求优先级。
实施敏捷管理最后的建议
恭喜！你现在应该已经学会了敏捷的概念，和如何实施敏捷开发的方法，现在可以再自己的团队内推广了。
但是值得提醒的是，由于敏捷开发中涉及到大量的计划、开发任务管理、时间进度和负责人，你需要使用一个项目管理工具，让整个管理过程更可控。一个项目管理工具可以这样帮助你做好敏捷开发：
1.进度 告：你可以看到还有多人任务等待完成、有多少延期任务
2.沟通：让每个人反馈任务中遇到的问题和进展
3.分配：项目下的任务应该支持分配到具体的负责人
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！