敏捷项目管理五个阶段
构想：确定产品构想、项目目标和控制要素、项目组织以及团队如何工作
推测：制定基于性能和功能的发布计划，确保交付构想的产品
探索：在短期内计划和提供可交付的功能，不断致力于减少项目风险和不确定性
适应：审核提交的结果、当前情况以及团队绩效、必要时做出调整
- 结束：终止项目、交流主要的学习成果并庆祝
其中推测-探索-适应应该是一个不断循环的过程，对应到每次迭代的不断优化。大概场景应该是迭代开始前和客户沟通后确认迭代1的版本，迭代结束时与客户确认，将客户的反馈体现在下一个迭代中。
敏捷主要解决什么问题
相比传统项目管理方法，敏捷更适合解决复杂问题、适应多变的、未知的环境、持续交付有价值的产品、满足客户需求并帮助客户建立竞争优势，从而提升企业项目、产品的投资回报。
由此总结可以看出，实施敏捷的最终目的还是要考虑ROI，所以敏捷实施的推进有一个很重要的方法就是及时让管理层能够了解到敏捷带来的变化。其实不止是敏捷，任何工作的推进，及时通过数据报告让领导知晓成效，是这项工作能够顺利继续进行的关键。
什么时候使用敏捷
项目开始时，项目范围不能确定
项目中存在极端变化时
其实除了以上，还有一个很重要的前置条件是团队必须对敏捷的实施达成一致，有点类似让团队成员自己做出承诺的意思，这样敏捷实施才不会无疾而终。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动高于流程和工具
可用的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
通常说到敏捷宣言会漏掉开头一句，实际敏捷并没有否定其他软件开发方法，敏捷也有其特殊的使用场景。对于一些精密度要求特别高，结果要求特别严格的项目（记得当时老师举的是军工行业），敏捷就不一定适用。敏捷宣言除了第一句是谈论工作方式，其他后三句其实都是在强调价值，就是敏捷的最终目的其实就是让客户心甘情愿地掏钱。
敏捷原则12条
我们最重要的目标，是通过持续不断地尽早交付有价值的软件使客户满意。
欣然面对需求变更，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，一起工作，项目中的每一天都不例外。
激发个人的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计。敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期的反思如何能够提高成效，并以此调整自身的举止表现。
关于需求变更应该有流程控制，保障PO的权限。实际这一点很难做到，毕竟实际大部分开发工作就是采用的BDD（Boss Driver Development）