从2015年以来，一直在使用敏捷开发模式。
今天主要来总结一下敏捷开发模式的步骤。敏捷开发以一个迭代(一般是两周)为开发一个开发周期。他的目的是为了小步快跑快速迭代，适应不断变化的市场需求。敏捷开发能用很短的时间开发出一个可用的产品跟客户试用，然后不断迭代改进。瀑布模式就是严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单元测试和系统测试等。使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。重视和强调过程文档，在开发的中后期才会看到软件原型，早起只能通过文档来了解系统的模样。而且一旦开始，返工的成本很大。不能很好的响应市场的变化。
敏捷开发的主要流程包括哪些呢？
1，用户故事拆分。在此阶段我们的需求分析师(BA)会讲接到的需求进行分析，包括可行性分析和波及分析。拆成一个个的用户故事之前的需求特性特性来划分的，需求分析以后就变成史诗故事，BA分析后变成用户故事。故事需要考虑故事的粒度，功能点和验收点。故事能过于复杂，并且工作量不能过多，因为这样的话团队不好进行任务拆分，就不能很好的进行任务协同工作了。
拆分用户故事要遵循比尔·维克(Bill Wake)的INVEST原则，即一个合适的用户故事应该是独立的(Independent)、有价值的(Valuable)、可讨论的(Negotiable)、小的(Small)、可估算的(Estimable)和可测试验证的(Testable)。
2，敏捷的需求澄清会和计划会。澄清会主要是用来将故事介绍给开发人员听，也就是澄清故事，在这个过程中开发人员也会提出自己的建议和想法，并充分讨论。讨论后大家用敏捷牌估算工作量也就是故事点数。如果大家牌的点数差不多，那么就按照那个点数来写到这个用户故事卡上面去。如果相差比较大，那就让差距最大的两个人说一下原因，然后继续出牌直到一致即可。这样做的目的是为了团队无差别的领取需求和任务，要按照团队实力来考虑这个因素，而不是自己的能力，因为这个任务到时并不是自己做的。
3，每日站会。在需求计划会之后，将所有的故事和任务放到看板上。团队开始领取任务进行开发。在开发过程中每天早上会有一个大约15分钟的每日站会，在这个会议室大家主要是讲三点事情，一是自己昨天做了什么以及碰到的问题，二是今天要做什么。三是移动任务卡，从to do 移到doing，或者从doing移到done，并减任务卡的小时数，这样方便SM记录燃尽图，可视化团队的开发进度。
4，验收showcase会。在一个迭代快完成的时候我们就要进行需求的验收会，这个会议形式比较自由，如果需求比较大的话可能整个团队都参加验收会，如果小需求则可能就是一两个人共同验收一下即可。
5，回顾会，时间就是迭代末。会议内容包括:评优和总结。评优是大家匿名投票，选出自己觉得本迭代做的好的同事，并写上理由。总结是总结本迭代做的好的和不好的地方。并对不好的地方投票选出最需要解决的问题。然后针对这个问题分析根本原因和解决办法。
敏捷就是由这些会议组成，重代码轻文档。重视可交付软件。
