写这篇文章主要是对目前敏捷转型实施过程做一些总结与反思，到底什么开发模式才更适合我们项目实施？

一千个读者，就有一千个哈姆雷特。每个人对于项目开发模式都有自己的想法，而且每种开发模式都有自己的优劣势，在经历了传统的瀑布式开发后，出现了很多问题，我们怎么去做到敏捷转型？

一、开发模式对比优劣势

传统的瀑布式在于项目实施过程中，每个环节的边界和产物很明确，如果上一个环节达不到要求的输出，下一个环节则不开展；

这种方式最大的好处就是每个环节的产物很全，每个阶段的人员只需要关注本环节的事情，提高阶段效率；

最大的弊端在于如果出现调整，由于前期阶段性工作迈的步子过大，导致调整带来所花费的成本巨大，每一次调整都伤筋动骨。

敏捷开发模式核心在于快速迭代，主动拥抱变化。

在项目实施过程中提高交付的频率，让客户能尽早对每个迭代的结果进行确认，提出改进意见。同时也直接导致团队内部之间、与客户之间更加频繁的沟通，保持对于正在做的事情的理解所有人都是一致对齐的。

敏捷开发最大的劣势在于团队要有很强的战斗力，需要高水平的协作能力，而且对客户依赖要求高，需要客户花费更多时间在需求对齐上。

二、敏捷转型实践

在实际敏捷开发过程中有几个重要的名词，比如站会、看板、迭代等；站会一般是一天工作开始之前进行，小队成员结合看板依次汇报昨天完成情况、今日待完成情况、受阻与风险，不细展开具体什么事情。

这样对于管理者来讲每天只需要关注看板上的卡片就能知道每个成员已经完成和未完成的事情，能够知道目前需求整体进度和在实施过程中存在的受阻和风险，提前暴露出来就有充分的时间去处理问题，而且是站着开会应该没有人想一直站着唠叨，减少了开会的时间成本。

在开发过程中是一个快速迭代的过程，在已完成需求澄清的情况下，前期定的计划在某个deadline需要交付，这也间接的使每个阶段的干系人反推进度，达到测试驱动开发，甚至业务驱动开发的效果。

三、自己的一些总结

项目组对于敏捷的概念接受度还不算太高，对于改变已有的工作方式和现有的流程心理上有不理解或排斥，这就需要项目管理者去引导、鼓励、总结，带领团队接受敏捷、融入敏捷；

我们的目标：以两周为一个迭代，在上个迭代结束末段进行下一个迭代的任务需求澄清和设计，以及任务拆解，一个迭代结束的标志是SIT测试完成；

但是在实际实施过程中会出现各种问题，比如下个迭代需求未彻底澄清，任务拆解不合理，计划时间不合理等等，间接的导致按我们既定的目标完成标志结果是迭代失败；所以我们在这个过程中不断的调整，不管敏捷也好还是瀑布也好，都只是我们项目实施的一种方式，关键还是在于交付给客户的成果是否能达到要求；

在敏捷转型实施过程中逐渐的优化，一些无法预估的任务对完成标志调准标准，不是为了敏捷而敏捷；结合一些瀑布开发模式，降低阶段性工作的颗粒度，同时又是敏捷开发的实践方式；每个迭代举行回顾会，回顾我们本次迭代的成果，以及目前项目组存在的问题，并落地方案解决；关注业务价值高的任务，合理的安排迭代计划，与业务充分沟通；

写在最后：

其实不管是何种开发模式，我们的目的都是交付给客户的结果能够满意，所以过于强调模式并没有意义，重要的是能不能提前把控风险预防问题的产生，在问题产生后能不能以最小的成本解决，这才是工作中更加需要关注的地方。