背景
随着组织架构的调整，产品越来越期望能够快速验证自己的猜想假设。作为技术负责人必然不想压榨组员，然后准备从工作流程下手。
过程
关于优化工作流程，业内很早就开始推崇敏捷开发。但是，敏捷开发适用于所有公司吗？不见得。
其核心原则却深深令我着迷。
主张简单、拥抱变化、你的第二个目标是可持续性、递增的变化、令投资最大化、有目的的建模、多种模型、高质量的工作、快速反馈、软件是你的主要目标、轻装前进
基于此，我决定基于敏捷开发创造一套属于我们自己的敏捷开发流程。
关于瀑布式开发
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
关于敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
两种模式对比
瀑布开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
- 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
- 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
- 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
- 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
- 于是，后厨只给客户加了盐，加了辣
- 客人吃完，不是很满意，下次不来了（没有满足需求）
敏捷开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
- 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
- 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
- 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
- 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）
- 客人吃完，很满意（基本满足了全部的要求）
迭代流程管理
我们是用teambition来管理的。下面是一个简化的tb流程，根据自己的业务可以灵活调整
欢迎大家讨论，如有疑问可留言私信
| 列表 | 产品立项 | 技术立项 | 交互评审 | 需求评审 | sprint池 | 开发进行中 | 测试 | 等待上线 | 上线完成 |
|---|---|---|---|---|---|---|---|---|---|
| 解释 | 产品需求 | 技术需求（重构、优化、fix） | 产品备好初版PRD | 产品备好终版PRD | 需求评审通过后，将需求放入此 | 开发按估算时间，进行开发 | 开发完成，自测后交由测试 | 测试通过告知开发可以上线，开发提交审核 | 审核完成且发布后更新状态 |
敏捷开发流程图
scrum2.0.png