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项目常用的敏捷套路。

2. 业务对于敏捷方案不配合，有其合理的担忧

   1. 多轮调研、测试、培训，意味着业务需分散自己的时间，多轮次参与项目。即是总时间一样，业务更希望集中一段时间把事情搞掂。一周完成全部业务调研，一周测试全部功能，三天培训全部操作

   2. 迭代会对功能做调整。担心之前的培训白学了，增加学习成本

   3. 担心质量。迭代1和迭代2，系统迁移完了，实施人天差不多了。到迭代3，乙方缩减资源

   4. 影响使用体验。迭代1上线，意味着部分功能登录新系统操作，部分在OA。即使两个系统的业务无关联，不会造成断点，会对业务人员操作造成一定困惑。