S1项目-敏捷实施

S1项目采用敏捷实施方法，分三个迭代完成。之所以弃用瀑布式，原因有三。一是管理原因，业务前期无法参与，先平迁，再根据业务需求，迭代优化；二是公有云Saas，产品适合迭代实施；三是传统IT学习互联网，向敏捷靠拢，以此项目作试点。

计划迭代1和迭代2，将OA系统相关功能迁移，迭代3上线新模块，同时对迁移过来的功能做优化。设想很美好，实际结果不理想。迭代1消耗了超额的精力，费力不讨好，质量不高。算下来时间并没有节省，小步并未快跑。同时由于前期没有业务的重复参与，无法获得认同，通过业务验收（这点是违反敏捷原则的，是项目的政治原因，不是敏捷的错）。

S1项目不适用敏捷的原因，在于

1. 由OA迁移到新系统，因两个系统本质的不同，导致不能采用增量模式。打个比方，搬家，若A与B结构类似，那可以老鼠搬家，从A原样放到B即可。先搬一部分，请主人检查。根据主人实际感受调整后，再搬一部分，再调整。而若A与B结构迥异，且B空间有限，就需要先盘点A一共有多少物品，然后与主人确定B整体布置方案，再做实施，最后做微调。因此S1项目，需先全面调研、确定完整蓝图方案后，再做实施。而不能先调研迭代1功能，迭代1开发，同时调研迭代2功能，迭代2开发，迭代1测试，迭代1上线，迭代2测试，迭代2上线（若按两个迭代的话）。换言之，敏捷应存在于开发、测试阶段。从项目全周期来看，仍是瀑布式，这也是目前传统企业IT项目常用