什么是敏捷开发？
敏捷开发（Agile Software Development）是一种应对快速变化的需求进行迭代、循序渐进的开发方法。
在敏捷开发中，软件项目的构建被切分成多个子项目（子任务），各个子项目的成果都经过测试，具备集成和独立可运行的特征。
敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。
团队节奏紧凑、推进迅速、调配灵活是敏捷开发的重要特性。
为什么要敏捷开发？
按传统的瀑布式开发，要求每个开发阶段都需要做到最好，最终达到最好的整体交付。这种开发方式，在初期产品经理撰写需求的阶段，已经要求尽善尽美了。
比如某些可能在后几个开发阶段才完善的细节，也是需要在产品需求文档考虑到，以保障后期开发的顺利。这种做法非常耗时，并且每个阶段的持续时间很久，单从产品需求阶段，可能长达2周到一个月时间，用来修改完善需求文档。如果需求从一开始的设定就是方向错误，到完整交付的时候才发现的话，会出现巨大的损失。因而在小型团队做某个小的想法的时候，应该优先考虑敏捷开发模式，一边开发一边复盘，以快步小跑的形式时刻保障开发进程在正确的轨道上面，以降低错误的概率。
在这里我们先来讨论的是比较流行的 Scrum。
Scrum 的工作流程，我们先要了解几个官方术语，后面再通过我之前的实践稍作补充解释：
Sprint：冲刺周期，也就是实现一个“小目标”的周期。我与团队实践的时候，把周期定为一周（5个工作日），按具体项目，有的项目需要2周时间，具体问题具体分析。
User Story：用户的外在业务需求，可以理解为故事版，用户在特定场景下的特定需求如何被满足。拿微信产品来说的话，用户的分享行为就是一个 Story，这个 Story 还可以被拆分为分享到朋友圈、分享给好友两个任务 Task。
Task：由 User Story 拆分成的具体开发任务， Task 下面还有子 Task。
Backlog：需求列表，可以看成是小目标的清单。分为 Sprint Backlog 和Product Backlog。
Daily Meeting：每天的站会，用于监控项目进度。每日早上的10分钟例会，快速回顾昨天的开发进程，和简要描述今天的开发目标，这个很有必要，让团队保持高度紧密的沟通。
Sprint Review Meeting: 冲刺评审会议，通常这个过程在测试前，拿出可供测试版本给团队成员内测并纠正显而易见的 bug。
Sprint Burn Down：冲刺燃尽图，记录当前周期的需求完成情况。
Release：开发周期完成，项目发布新的可用版本。
上面的一些官方术语，在实践过程中还是有差别的。敏捷开发是从美国传过来的方式，在中国需要更本地化一点，但基础的框架是八九不离十的。
一般来说，在项目启动之前，会由团队的产品经理（Product owner）按照需求优先级来明确出一份Product Backlog，为项目做出整体排期。这个需求文档会简明扼要地叙述这个需求的使用场景，交互方式，并且做初步的大模块拆分。表达再接下来几周的迭代周期里面希望达到的交付效果。
随后在每一个小的迭代周期里，团队会根据计划（Sprint Plan Meeting）确定本周期的 Sprint Backlog，再细化成一个个 Task，分配给团队成员，进行具体开发工作。每一天，团队成员都会进行 Daily meeting，根据情况更新自己的Task状态，整个团队更新任务列表的任务状态。
当这一周期的 Sprint backlog 全部完成，团队会进行 Spring review meeting，也就是评审会议。一切顺利的话，会发布出这一版本的Release，并且进行Sprint回顾会议（Sprint Retrospective Meeting）。
通常情况下，整个敏捷开发过程并不会很顺利。
为什么这么说？因为从敏捷开发的特性决定，Sprint Backlog 并不会详尽得面面俱到，在我们开发某小程序商城的时候，就深有体会：
第一，需求评审
当产品经理的 Sprint Backlog 下发给工程师后，工程师会对需求进行初步评审，这时候需求列表加上类似的产品例子或者市面上已有的类似开发源码，将会对开发进度有良好的促进作用。这是加强表达，降低工程师理解成本的方式。
然后产品经理与工程师们一条条需求过，并且确保工程师能对需求有80%以上的理解，以最大程度在开发过程中目标一致。
过完需求后，工程师将对已有优先级需求进行时间估算。
第二，迭代节奏
我习惯将迭代周期设为一周一迭代，而开发任务则是团队讨论后决定如何在一周内尽可能多地完成需求并且发布一个版本。
将每周二设为小版本上线（bug 修复，改个文案、图片之类可以集中发布一次），周四设为本周期的一个正式版本上线（如约而至的新功能，之前团队商讨好可交付的版本）。
第三，紧密沟通
每日例会，早上花上10分钟来回顾和简要说明今天的任务，有很好促进作用。但很多时候产品经理非常勤快每天穿梭在工程师中的话，也无需坚守每日例会这件事，毕竟这是以加强沟通为导向的方式而已。
第四，版本发布
对于冲刺评审会并没有很严格的要求，只要约定开发的功能具备可用性，在测试环境即可给内部同事进行预览体验，及时发现问题，然后埋头修复，再进行内测，如此重复，直到正式发布。
本次分享就到这里，希望对大家有用，也欢迎大家的探讨，共同进步。