浅谈敏捷开发-实践思考

敏捷开发是相对于瀑布开发来说。我没有在软件公司工作过，对于瀑布开发的认知主要来自于大学软件工程的课程。我一毕业就在网易公司工作，采用的开发的方式可以认为一直是敏捷的方式（从low敏捷到高逼格的敏捷）。

引用下孙恩童鞋PPT里的一张图，我们可以看到瀑布开发是一次把事情做完，统一交付，而敏捷开发是多次把事情做完，增量交付。那是不是可以认为左图的“软件计划”等同于右图的“Product planning”。敏捷开发只是把软件计划拆分成多个sprint，每个sprint，可以看做是一个小的瀑布，也是需求分析和定义->软件设计->软件实现->软件测试->软件运行与维护。

显然不是这么简单，那到底什么是敏捷开发？我们为什么要用敏捷开发？如何来进行敏捷开发呢？

敏捷开发的核心不是把大的计划拆分成小的计划，然后阶段性的交付，而是可以 通过快速交付后的用户反馈，不断的调整需求计划 。举个简单的例子，原来拍电视剧都是把整部电视剧都拍好，然后才推出来。现在很多网络节目，比如我喜欢听的晓说，会根据用户的反馈或当前的热点事件来不断调整节目的内容。比如晓说前面讲战争题材，男女性观众比达到89%:11%，就开始讲林徽因，讲了林徽因发现大家对民国题材很感兴趣，就又做了一系列民国题材。如果高晓松是把整个晓说全部制作完（瀑布开发），然后对外发布，就不能根据用户的反馈，敏捷的调整节目内容，从而满足观众的需求。

了解了敏捷开发的的核心后，为什么需要敏捷开发这个问题就比较简单了？

1. 用户真实需求的把握是非常困难。 用户讲出来的需求并不一定是真实的需求，绝大部分时候用户是不知道自己到底想要什么的。亨利·福特的名言“如果你问消费者需要什么，他们只会告诉你他们需要一匹更快的马车”，而福特造出了汽车。我们需要把产品快速的交付到用户手中使用，看是否符合用户的需求。

2. 用户的需求是快速变化的。 现在用户的需求变化很快，普遍喜新厌旧啊，O(∩_∩)O~）。即使我们正确把握了用户的真实需求，我们为用户的需求做了整个产品的计划，我们追求尽善尽美，花了很长时间完美做出了产品，满足了用户的需求。但是等产品交付的时候，用户的需求可能已经变了，一切前功尽弃啊。

关于如何做敏捷开发？想系统理解项目管理的，可以学习网易杭研项目管理部出品的 互联网项目管理微专业 ，或关注网易杭研项目管理公众号。我不是专门做项目管理的，不会系统性的去阐述，主要是从我做管理时的一些感受和思考来讲。

1. 一个产品的版本尽量保持稳定的周期 。我们以前做有数，经过一段时间的摸索，我们每个版本的迭代周期稳定在3周。现在我在网易严选，我们稳定的数据产品迭代周期一般保持在2周。稳定的迭代周期，让用户对产品有稳定的预期。不只是用户需要快速的反馈，我们的团队成员也需要阶段性的反馈，来保持成就感。

2. 产品经理要让团队成员充分的了解需求和规划。 团队成员如果沦为产品经理需求的执行者，就没有参与感和主人翁精神，产品经理就会非常的累，且最终产品也做不好。在做有数的时候，对于每个版本的核心需求（每个版本一般也只排一两个核心需求），在需求阶段，产品经理就跟核心技术负责人（后端、前端）说明需求的来源，讨论技术的可行性。一方面产品经理可以了解实现成本，另一方面让核心人员深度参与。核心的技术人员已经在需求阶段达成一致。在交互确认会的时候，主要是跟其他人员做充分的说明，既不会因为发现很多实现问题，让交互确认会无限扩散，且没有结果，导致需求交互返工，又让整个团队对需求交互充分理解。

3. 合理的变更控制。 大家都知道，变更是让项目范围不可控，时间延期的最大风险。关于变更管理，有各种各样的方法。我们的项目中采用的方法是，产品经理通过说明变更的合理性来说服研发。如果没有说服，产品经理还是觉得非常必要，需要上线功能，产品经理需要写邮件（书面很重要，不能口头）给我申请，并抄送团队。

敏捷开发不只是个管理问题。现在的需求变化非常快，外界的新的产品形态也越来越多（小程序、快应用、答题等等），如何快速的进行产品的尝试，不仅需要管理上的敏捷，还需要强大的中台的支持。关于这点，我会在以后的文章中再讲。