本次项目因众多因素，各方均提出提前发布的计划，于是PM决定采用敏捷的开发模式希望能压缩整体项目时间，初计划时，还以为是整体敏捷呢，不过在后面的几天讨论中，明白了其实只是部分敏捷。

敏捷模式一直都比较适用于需求容易变动的项目，另外它也采用了增量式开发的模式，一方面可以提供给需求方初步的模型&基本功能，另外也让需求方对需求的定位有一个缓冲的阶段，当然很重要的一点是制定backlog，并在每个阶段同时制定出sprint backlog，这样的一种制定方式有利于开发人员在限定的时间内完成需要开发的功能点，在开发过程中团队的凝聚力要求相当高，以及不像传统的开发模板开发任务由PM来一步步分配，什么时候该做什么？接下来该做什么事情？敏捷的模式要求每个团队成员自我团结，自我互动，自我凝聚，这才能发挥整个团队的大功效。

不过经历了半个月所谓的敏捷，似乎已经有点承受不住需求的浮动了，经常性的漂浮不定，应该也不能算是敏捷吧，我理解的敏捷应该是每个阶段初期需求是确定的，只不过在一个spring后，初步提交给需求方确认后，这个过渡阶段会出现一些变动点。需求的漂浮不定让我一直悬着心里特憋闷。

这个项目其实是敏捷&传统W模型的组合，部分采用敏捷，部分采用W，这个中间过程给测试这边的带来的压力也是挺大的，在提交敏捷部分版本时，测试人员需要抽取出时间来验证上一个版本的功能是否符合，并且也需要抽取时间听取下一版本的需求&优化点，这其中已经占去了一定的时间，而同时这中间阶段又是需要理解其余非敏捷模式需求&完成设计和用例，时间上的安排和在功能之间来回切换，给测试人员造成了一定的思维跳跃，会不会导致考虑点不全容易遗漏呢？

项目还在继续中，估计接下来的一个月会让我更加深入理解敏捷的精髓，敏捷一直都没有固定的模式、方法，他提供给大家更多的是一种思路，一种态度。