引言：敏捷绝非某一种特定的开发方法，它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。
敏捷的起源：
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
目前很多互联网公司都在搞或者想搞敏捷开发流程，但能正常的运行起来的比较少，很多公司还是产品、开发、测试相对于独立，产品提需求，开发做功能，测试功能，这样看来不是一个Tim，而是不同的人在在做不同的工作，客户的需求在不断的变化，那么产品的需求也在不同的变化，如果做一个项目做到最后了客户需求又发生了变化，那么又要重新开始。这样的项目管理很混乱。
敏捷开发流程是一个标准的项目管理流程，是不能适用于所有的公司，但是适用大部分的公司，公司根据标准化流程去进行优化，不管是新增还是减少，只要适用于自己的公司那就是贵公司的敏捷流程。
核心原则：
1.主张简单：当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。
2.拥抱变化：需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。
3.有目的的建模：对于自己的产出，例如模型、源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。你不应该毫无意义的建模，应该先问问，为什么要建立这个产出，为谁建立它。
4.多种模型：开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于产出的清单，可以参阅AM的建模工件）。
5.快速反馈：从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。
6.软件是你的主要目标：软件开发的主要目标是以有效的方式，制造出满足投资者需要的软件，而不是制造无关的文档，无关的用于管理的工件，甚至无关的模型。
7.你的第二个目标是可持续性：即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现项目投资者的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。
以下是我司的敏捷开发流程（我司的流程也是经过几次改版，这个过程可能需要几个月，因为敏捷开发的实行是在不同的流转，这就需要根据公司实际情况进行调整）：
产品设计（以下就是敏捷中重要的节点）：
1.产品指南评审：软件中的一切功能需求与功能来源都是客户与市场，产品设计功能不可能天花乱坠的想象，要贴合实际业务。产品指南评审就是产品跟客户、市场深入调研后产品的产物，就是产品的背景、目前产品的缺陷、输入、输出。需要产品、开发、项目经理、测试评审。
2.产品方案评审：就是产品根据客户需求设计功能，产品方案是否符合客户需求。需要产品、开发、项目经理、测试评审。
3.UI评审：产品只是把功能设计出来，交互与页面的展示就是要靠UI来设计。
4.技术方案（包含测试计划/方案）：产品如果只是想的话，那么开发就是要实际去做了，这个技术方案设计要慎重，要关联到目前的业务是否有关联，还要有拓展性与可移植性等。需要另一个平级或者更高级别的开发评审。
项目启动：
1.项目启动：经过了产品设计阶段，一切都是计划，项目启动主要就是把项目组的成员确定，确定好目标、时间（开发时间、测试时间、产品验收时间、发布时间）。
敏捷迭代：
1.迭代：包含了晨会、单元测试、codereview、测试用例评审、迭代演示（项目过大的时候会分为好几个迭代）
2.交付：首先测试完成后，产品进行验收，是否符合产品的需求。
3.发布：产品验收后就可以进行发布了
4.回顾：回顾本次迭代或者本次项目中做的不好的、好的点进行总结，好的点要继续保持，不好的点可以要进行总结，下次迭代改进
以上就是我司的敏捷开发流程，执行下来肯定有很多困难与不适应，但是这样利于项目管理，一个团队共同为一个目标去奋斗。
