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項目常用的敏捷套路。
-
業務對於敏捷方案不配合，有其合理的擔憂
-
多輪調研、測試、培訓，意味着業務需分散自己的時間，多輪次參與項目。即是總時間一樣，業務更希望集中一段時間把事情搞掂。一週完成全部業務調研，一週測試全部功能，三天培訓全部操作
-
迭代會對功能做調整。擔心之前的培訓白學了，增加學習成本
-
擔心質量。迭代1和迭代2，系統遷移完了，實施人天差不多了。到迭代3，乙方縮減資源
-
影響使用體驗。迭代1上線，意味着部分功能登錄新系統操作，部分在OA。即使兩個系統的業務無關聯，不會造成斷點，會對業務人員操作造成一定困惑。
-
-
業務成熟度不足夠支撐敏捷。業務對於自己的痛點、需求，沒有想清楚，若不借着項目方案調研階段，做全盤梳理，很多問題想不全、想不細。採用敏捷方案，碰到什麼問題，諮詢業務，業務基於該點回答，不會從系統層面思考如何優化。
-
敏捷相較瀑布的優勢，在於試錯成本低（以犧牲迭代成本爲代價），但實際試錯成本並不低。若是自研項目倒還好，發現偏差快速調整，領導層面對此包容，團隊內部容易協調。而商務項目，講究穩紮穩打，按既定計劃辦事。迭代的更改，很容易被乙方定義爲需求變更，或指責爲甲方過錯，將損失疊加回去，導致試錯成本，並不低。只要涉及到多邊關係的項目，敏捷就容易在迭代交接處產生模糊項，需花費額外溝通成本做澄清。
那麼對於B端Saas，是否適合採用敏捷？還是要看具體項目、業務現狀。若對於場景想的清楚、窮舉完全，對於流程、規則梳理清楚，業務具有充分配合意願，IT具備敏捷能力，則敏捷能發揮其獨特優勢。但若是能達到如此的先決條件，採用瀑布還是敏捷，又有什麼太大區別呢？項目目標，大概率都能在既定要求下，順利達成。
