《启示录》流程篇：敏捷方法VS瀑布式开发.jpg
一、合理运用敏捷方法
定义：敏捷方法是一种应对快速变化的需求的一种软件开发能力（只适用于产品软件，不适用于定制软件）。相对于"非敏捷"，它更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。敏捷方法包括Scrum和极限编程。
敏捷方法优于瀑布式开发。
十大诀窍
- PM即是产品负责人，它代表了客户需求，与开发沟通，协助督促开发进度，及时解决出现的问题。
- 敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法（即产品原型图），替代冗长的市场需求文档。
- PM和设计师的工作进度，应该比开发团队领先一两个迭代周期。
- 尽量把产品设计工作拆分成独立的部分，分而治之（但也不能拆得太细）。设计师必须加快工作速度，采用迅速制作原型的方法更适应敏捷环境。
- 用产品原型和用户故事替代厚厚的产品需求文档和功能说明文档。好的原型可以提高估算工作量和开发时间的精度。
- 让开发人员自主划分迭代周期——因为有的产品功能可以在一个迭代周期完成，有的要好几次迭代；开发团队必须考虑产品的质量、性能、扩展性。
- 每日晨会，开始一天关于产品的沟通讨论（PM和交互设计师必须出席）。
- 除非达到了PM的要求，否则不要轻易发布新版本；
- 每次迭代完成后，PM应该向团队展示产品现状（成果），及下次迭代的产品原型（加深大家对产品的理解，团队的信心）。
- 团队内开展敏捷培训（需敏捷教练）。只有团队成员都正确理解敏捷方法，PM才能把工作重心放在执行上。
敏捷方法唯一不适合产品软件团队的地方，是在架构设计方面——敏捷方法相信简单重构和快速重新设计架构的优势，这不适用于产品软件。
注意：迭代初期的产品不能用作产品原型。
二、瀑布式开发方法
这是大多数团队仍在使用的、最常见的开发方法，但并不好用。（很传统）
- 定义：瀑布式开发方法也叫持续改进方法/里程碑式开发方法。它采用阶段式开发，阶段式评审。流程具有可预测性（但过于理想化，以为人们能预见所有问题、全面把握需求，除非是规模很小的项目，否则很难顺利执行），每个阶段结束都会提交书面材料。
- 存在问题：产品验证严重滞后，变更计划代价不菲，无法适应快速的市场变化，交付时间通常比预期的晚，产品常常存在缺陷需要花大量时间和资金修补完善。
- 如果不得不使用瀑布式开发方法，需要在定义产品阶段制作产品原型，请目标用户试用，确保产品有价值可用可行。
