PM学项目管理之：什么是敏捷开发？（上）

前段时间，微信的创始人张小龙在WXG（微信事业群）领导力大会上的讲话又一次刷爆了互联网人的朋友圈，圈内人士纷纷拜读一篇名为《张小龙最新内部演讲:警惕 KPI 和流程》的文章，其中就讲到了敏捷开发。产品大神张小龙是这么描述“敏捷开发”的：

实际上，就这么小的一个团队在后面几年里面做的事情远远超过之前几十人的努力，这个小团队是怎么样工作的？这个小团队是当时用了一个方法，叫敏捷项目管理，这里可能在座的一些同事都已经不太了解这个词了，但是当时在腾讯挺鼓励用这样一种方法，我建议在座的如果没有去好好研究过的可以好好研究一下。我们真的做到一种非常敏捷的一种项目的推进方式。我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果，因为我们可以很快把它上线了，然后可以去验证，如果不对就下线，如果还有改进余地，下个星期再去改它。这是一个能够持续实现你的想法的过程。

其实，敏捷开发这个词对产品经理来说并不陌生。近年来，国内越来越多的互联网公司也开始采用敏捷开发的方法来做项目管理，你可以在很多公司的办公桌椅旁边到处可见白板和贴满各种颜色便签的任务墙，然后，每天早上上班的时候，几个人围着白板开个站会，这其实就是敏捷开发的典型特征。在国外硅谷等地，敏捷式开发也早已经被Google、Facebook、LinkedIn等企业应用。

另一方面，理论上来说，如果一家公司有专职的项目经理，那么产品经理是不需要做项目管理的，而且，一个优秀的项目经理在产品迭代的过程中，有着不可小觑的作用。但国内大部分创业型公司，由于团队规模的限制，产品经理又往往会承担一定的项目管理职能，那么对于产品经理来说，了解一些关于项目管理的知识和技能就显得很有必要。

那究竟什么是敏捷开发，我们来进行一一拆解下。

敏捷  vs  不敏捷

敏捷的反义当然是不敏捷，但是这个“不敏捷”在软件工程里面却有个专业的术语叫做“瀑布式开发”。

所谓的瀑布式开发，其实是经典的软件工程方法为了定义出一套完备的过程规范，使得软件开发的运作就像是机器设备一样正常的运转而总结出来的项目管理方法论。这套方法论分为5个阶段：需求分析、设计、编码、测试和维护。需求分析阶段通常定义系统的需求，明确系统的目标；设计阶段通常确定系统使用什么数据库，系统模块的划分，各个模块的功能；编码阶段用编程语言实现设计阶段的任务；测试阶段主要测试功能是否实现，以及是否正确没用Bug；维护阶段是根据用户新的需求重新修改系统，使系统运行正常，更加稳定。

瀑布式开发的局限性也非常明显，比如对市场变化和用户需求的响应慢，更改成本高等，有可能出现的情况是产品一推出市场就宣告失败。

而敏捷开发则是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的一种方法。所以，在瞬息万变的互联网、移动互联网时代，大家已经渐渐体会到敏捷的优势，我们也看到越来越多的互联网产品出现了一周发布一次的快节奏，这么快的速度，就是为了迅速响应市场与用户的需求。

敏捷开发的一些特点

1、小步快跑，尽早交付

在互联网时代，尤其是移动互联网时代，随着时间的变化，市场环境、用户需求、竞争对手等因素都在时时发生着改变，需求方（比如用户、市场、运营、老板或者是产品自己）会不断地赋予产品新的需求来应对这种变化。为了让需求方尽早地看到结果，并给予反馈，我们就应该以小步快跑的姿势来做产品，尽早地交付新的版本。对于敏捷来说，可用的软件胜过完备的文档。比如之前传统的瀑布式开发要求的使用产品需求说明书来写详细的需求，这个时候我们采用敏捷开发的方法，或许有时候只画一个原型加点备注来告知需求，又或者直接通过口头沟通来告知需求，这就大大简化了项目交付的时间，从而达到了尽早交付的目的。

小步快跑，意味着产品交付的时间间隔越短越好，也就是产品有较短的迭代周期，通常是2-4周。传统的瀑布式开发最大的缺点之一，就是产品投放市场的速度太慢。当然，通过这种频繁地迭代是为了与用户形成良好的合作关系，及时反馈，不断地完善和提高产品的用户体验，对于不能给用户或者产品带来价值的功能需求，则坚决不做。

2、有项目计划，但也“拥抱变化”

敏捷不代表不做项目计划，恰恰相反的是，敏捷更加注重计划的制定。因为敏捷开发就是为了能够及时地响应用户和市场的需求，所以并不会死守着计划不进行调整，一旦市场发生变化，即使到了开发后期，敏捷也欢迎改变需求，不断地修正自己原先的计划，利用变化来为产品创造竞争优势。同时，参与敏捷项目的团队成员也不害怕变化，因为这些改变意味着自己更了解了市场需求，让团队本身能够与市场、用户需求同步。

3、版本周期内尽量不加任务

尽管敏捷的目的是为了尽量让产品能够适应市场需求的变化，但也并不意味着可以毫无节制地添加和修改项目任务。事实上，从这个角度来看，我们可以把每个版本迭代看作一次小的瀑布式开发，敏捷并不是全盘否定了瀑布式开发，而是借鉴了它优秀的部分。比如说，瀑布式开发对于那种需求比较确定的项目来说还是不错的，比如工厂里面的生产环节就可以采用瀑布式开发的项目管理方法。

每个版本都有自己的开始时间和结束时间，也在项目刚开始的时候就配置了相关的资源来实现产品的需求，如果临时突然插入新的需求或是修改需求的话，多少会对项目的进度产生影响。所以，我们还是尽量在版本开始前就思考地清楚一些，除非碰到特殊情况，尽量做到版本内不加任务。

4、团队配置也要敏捷

为了实现项目的敏捷，在团队组成上也是需要进行敏捷处理。一般来说，一个项目团队要小于20个人以下，太多了的话可以进行团队分割（事实上，很多大公司已经在这么做了）。有过异地沟通经验的人都知道，异地沟通的成本有多高，如果可以，项目成员在一个办公室进行办公将会大大提高沟通效率，有什么问题可用直接面对面地解决。这样的话，也可以充分利用办公室里的白板和墙壁。

在互联网公司里，应该都听说过“站立晨会”这么一说，这种形式也是要基于敏捷的团队的配置才能更好的完成。想象一下，如果一个场地，站满了几十上百号人，每个人说一下自己的日常工作，那么基本上一个上午的时间就过去了，这是效率非常低下的一种表现形式，如何谈的上敏捷二字呢？

5、敏捷也需要反思

项目团队成员需要定期对前一个或者前一段时间的迭代进行反省总结，以便调整自己的行为，提高项目的开发效率。因为很多不确定的因素都会导致项目的原计划失败，比如项目需求的变更、人员的流动、市场的变化等等都会让我们做出不同的反应。在每次失败中进行反思，吸取经验教训，其实是对敏捷的进一步认识，团队成员只有通过不断地总结、反思和调整，才能更好地保持团队的敏捷性。

作者：壹百度（微信公众号：倒退集），在线教育企业服务领域产品经理，创业公司Team Leader。常常自诩是文艺青年和极客青年的结合体，在宅与不宅之间可以自由切换，曾主导多款重量级产品的产品策划和设计工作。