## 產品設計體會（四四）——項目外包不適合“敏捷”？ 前幾個月嘗試做了PM（這次是Project不是Product了），親身經歷了一個項目是怎樣一步步不順下去的。先說明一點：這里的“敏捷”是指甲乙雙方配合的“敏捷”，而不是說外包項目本身內部不合適“敏捷”。 ? 先說一下背景，項目時間太緊，工期是由商業談判決定的，沒有及時評估工作量，做著做著產生delay，先試圖簡單的用加班的方法趕上進度，后來被迫注入“敏捷”項目方法，但事后發現“項目外包”模式不適合敏捷。 ? 首先，項目外包使得甲方不愿意砍需求。為了敏捷靈活，公司內部的項目需求在很大程度上是可以砍的，是“保質不保量”，這是符合敏捷的原則的。但是項目外包，甲方在提需求的時候不愿把任何一個功能像平時那樣推到2期做，因為項目結束后2期在哪里都不知道，所以“保質保量”變成了“不保質保量”。 ? 其次，敏捷必然導致文檔工作不細致，甲方游離于項目之外的“驗收測試”模式難以適應。敏捷從模式上會導致提交測試的產品和最初的需求之間必然有很多變化，并且文檔很難跟上，而這種敏捷在公司內部之所以運行的很好，是因為PD、開發、tester在項目過程中可以充分交流，tester在TC（Test Case）評審的時候會叫上PD和開發，有些屬于詳細設計的細節是在評審的時候與開發直接確認，在測試執行過程中也會協助確認需求細節并迭代測試。而項目外包的時候，甲方會從一份顆粒度過粗的需求文檔上派生出“驗收測試”的TC，又因為驗收有“考試”的性質，所以不允許乙方的開發參加甲方的TC評審，導致只能和甲方需求人員確認細節，而需求人員對如此細節又沒有要求，無奈之下只能按照自己的想法說，必然導致兩邊對需求的理解有鴻溝。另一方面，驗收測試是一次性的，只有pass或false的結論，沒有迭代的過程，不符合敏捷的思想。 ? 最后，乙方沒有“敏捷”的經驗和意識。一般甲方沒有獨立軟件研發能力才選擇項目外包（否則多用開發外包），職業性質/國內的項目管理現狀決定了外包工程師的習慣是按照詳細的設計文檔開發/測試，抗拒需求改變，所以強行“敏捷”會導致失控。因為沒有一份完整的詳細設計文檔，開發人員會按照自己的想法編碼，測試人員也照自己的想法測試，沒有做TC評審的意識，加之沒有和需求人員即時溝通反饋的習慣，沒有一個迭代的過程，再為了工期的死命令削減測試強度，結果就是發現做的與需求不符的時候已經晚了。 ? 很多原因共同造成不好的結果，還有些沒說，總結下來就是不能再這么做了，對敏捷的理解很粗淺，歡迎指正。