概括来讲，敏捷开发就是一种以用户的需求进化为核心，迅速迭代、循序渐进地进行软件开发的方法，核心是快速响应和持续迭代。要保证在迭代周期内，团队成员思想保持高度一致、以共同的节奏和共同的周期完成周期性运转，保证在每一个周期的同一时间点，团队中的每一个人做的事情是相对一致的。迭代也让团队内外有着共同的预期，知道什么时间点该做什么，该交付什么出来。
或许这样理解起来仍有些抽象，那么让我们来看传统的开发是怎样进行的。传统的开发有个专有名词叫“瀑布式开发”，分为5个阶段：需求分析、设计、编码、测试和维护。这套方法定义了很完备的过程规范、严格遵从这种方式会使得研发运作过程十分严谨。但是，在瞬息万变的互联网和移动互联网时代，市场环境、用户需求、竞争对手等因素都在时时发生着改变。传统的瀑布式开发要求针对客户需求写出详细的分析说明书，仅仅这一点就耗费了大量时间，严格遵循规范但不够灵活的流程管理的结果可能是研发人员在开发过程中按部就班，产品技术上没有太多瑕疵，但是正式推出市场时可能部分功能已经落伍。
和瀑布式开发相比，敏捷开发的特点就是“小步快跑、尽早交付”。在市场环境和客户需求变更非常迅速的情况下，为了让需求方尽早地看到结果，并给出反馈，以小步快跑进行开发并尽早地交付新的版本不失为一种好的解决方式。毕竟在互联网时代，可用的产品一定胜过完备的文档，并且及时的迭代可以不断修正问题。
而要做到“小步快跑、尽早交付”，对团队也提出了一定要求：
（1）准确分析市场需求
这一点也是很多人对敏捷开发的误区。敏捷并不意味着不做项目计划，只是不一定拘泥于形式，一定要拿出完备规范的开发计划书，有时候敏捷开发的计划就是团队人员在白板上画出的原型和点、甚至是口头计划。这种计划不代表分析不严谨，事实上，敏捷开发比瀑布式开发更加注重需求的分析和计划的制定。因为敏捷开发的核心就是为了及时响应用户和市场的需求，所以并不会死守着计划不进行调整。一旦市场发生变化，即使到了开发后期，敏捷团队也应该对需求的改变持欢迎态度，对原先的计划进行调整，利用变化来为产品创造竞争优势。
（2）迭代周期尽可能短，且周期固定
“小步快跑”意味着产品的交付时间间隔越短越好，通常是2-4周，频繁地迭代能保证不断修正BUG，而迭代周期固定则能和用户形成良好的合作关系，便于客户及时反馈，不断地完善和提高产品的用户体验。小米就是一个很好的例子，MIUI开发版一周更新一次，至今已连续363周进行更新。
（3）团队规模最好也能敏捷
敏捷开发对团队的沟通要求很高，过多的人数会造成沟通成本的增高，信息在传达过程中很可能会有偏差，使团队难以保持步调一致。通常情况下，敏捷团队的人数少于20人，超过的话可以再进行团队分割。比如腾讯在管理200人或者更大规模团队时，就会按照产、研、运的组织结构进行复制，把大规模团队拆分为10个20人的团队，或20个10人的团队，分别负责产品的子模块。拆分时会保证子团队人员仍以产、研、运三驾马车组成，具备交付功能，可独立工作，再通过子团队之间的协作，完成整个大产品的研发和交付。
谦启将企业案例解析与专题研究结合，前期以读书会形式带领大家拆解相关企业书籍，并附以独有专题研究进行解析，关注我们，私信留言，或搜索关注“谦启学堂”，并在后台回复“研企社”，小谦将与各位一起解读企业案例。
