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具備敏捷能力，則敏捷能發揮其獨特優勢。但若是能達到如此的先決條件，採用瀑布還是敏捷，又有什麼太大區別呢？專案目標，大概率都能在既定要求下，順利達成。
S1專案 專案集
s1專案實施期間，並行開展了其他6個專案，其中與3個存在關聯。碰到的問題如下，乙個業務需求，可以拖長達兩個月。兩個系統互相推脫，對於由哪個系統承載，無法達成共識 對接系統提出的要求，業務對財務 財務對上游系統，兩個專案組調研 方案不同步，進度受影響，方案面臨大改 介面開發，各系統進度不一致 都走企業...
S1專案 開發階段
因s1專案為公有雲部署，開發團隊異地集中，採用遠端辦公方式，無需客戶開發人員承接。所以開發階段主要工作一是跟進度，二是協調介面開發。遠端開發，難在進度把控。特別公有雲專案，若評審通過後定為產品標準功能開發，則要遵照產品的版本規劃。有時由於方案變更 或產品 設計團隊進一步討論，專案二開與產品開發發生轉...
S1專案 上線準備及切換階段
專案uat測試簽字通過後，準備期初資料 資料需提前收集 整理 及cutover plan。上線業務範圍，是先試點關鍵業務部門，還是全業務線使用？上線的功能範圍，先上哪幾個模組 保證業務正常流轉前提下 或者全平台上線？舊系統如何處理，是雙系統並存，在途單據在舊系統走完，還是直接關停，資料遷移到新系統中...