S1项目采用敏捷实施方法,分三个迭代完成。之所以弃用瀑布式,原因有三。一是管理原因,业务前期无法参与,先平迁,再根据业务需求,迭代优化;二是公有云Saas,产品适合迭代实施;三是传统IT学习互联网,向敏捷靠拢,以此项目作试点。
计划迭代1和迭代2,将OA系统相关功能迁移,迭代3上线新模块,同时对迁移过来的功能做优化。设想很美好,实际结果不理想。迭代1消耗了超额的精力,费力不讨好,质量不高。算下来时间并没有节省,小步并未快跑。同时由于前期没有业务的重复参与,无法获得认同,通过业务验收(这点是违反敏捷原则的,是项目的政治原因,不是敏捷的错)。
S1项目不适用敏捷的原因,在于
-
由OA迁移到新系统,因两个系统本质的不同,导致不能采用增量模式。打个比方,搬家,若A与B结构类似,那可以老鼠搬家,从A原样放到B即可。先搬一部分,请主人检查。根据主人实际感受调整后,再搬一部分,再调整。而若A与B结构迥异,且B空间有限,就需要先盘点A一共有多少物品,然后与主人确定B整体布置方案,再做实施,最后做微调。因此S1项目,需先全面调研、确定完整蓝图方案后,再做实施。而不能先调研迭代1功能,迭代1开发,同时调研迭代2功能,迭代2开发,迭代1测试,迭代1上线,迭代2测试,迭代2上线(若按两个迭代的话)。换言之,敏捷应存在于开发、测试阶段。从项目全周期来看,仍是瀑布式,这也是目前传统企业IT项目常用