項目成員越多，越不推薦敏捷開發。原因在於：當連「自己要做什麼、為什麼這樣做、解決什麼問題」都搞不清時，就跳下去玩敏捷，比通靈還慘——通靈起碼有目標物，搞不清狀況的人只能陪著跳「世界迷霧開地圖」。

四大「偽敏捷」誤區

誤區一：敏捷對人要求很高？

撇開技術，找到清楚開發流程、知曉全員職責產出、明確項目目標需求用戶的人有多難？條件不具備，怎麼保證方向正確？因為這種人太難找，才產生「要求高」印象。有企劃書、規格書、用研報告還不知自己幹嘛、同事幹嘛，能談敏捷？

誤區二：敏捷沒文檔、不做設計？

文檔與否與敏捷無關。敏捷強調「適應性而非預見性」，從未禁止文檔。「可用軟件重於詳盡文檔」≠ 不寫文檔。
先問：寫文檔解決什麼問題？不寫會產生什麼問題？
UI 設計師交 UI Flow、Wireframe 是為了解決什麼？敏捷不代表跳過直接出 Mockup——發現漏改改到死，和找到問題改良，本質不同。敏捷不是「無文檔無流程」的包裝紙。

誤區三：敏捷好，其他方法不好？

敏捷就是小幅度持續迭代，瀑布流下設計師也是一直改。先承認問題，才能找方法，而非先有方法再找問題。敏捷只是「方法」，須回答：
① 現有模式為何不能滿足需求？
② 敏捷為什麼可以？
設計師改來改去解決什麼問題？敏捷的小幅迭代與現狀盲目修改有何不同？若無異，何必用敏捷？

誤區四：敏捷宣言 = 萬靈丹？

拔掉「敏捷」二字，宣言不也是所有項目開發的理想？為解決什麼問題用敏捷？為改善流程提效？
那設計師「改到死」在敏捷裡如何被改善？

現實中的四大價值觀扭曲

敏捷宣言	現實扭曲
個人與互動 重於 流程與工具	開會燒錢，人多怎麼降低溝通落差？靠張嘴就能辦到？
可用軟件 重於 詳盡文檔	有文檔解決什麼問題？沒文檔解決什麼？不寫文檔最愛用「我們是敏捷」當借口
客戶合作 重於 合約協商	客戶未被良好引導時：最後一次-確定最終版-說好不改了-V21.psd。這叫敏捷？
回應變化 重於 遵循計劃	變化是為了解決什麼問題？沒問題改什麼？完全不代表可以沒計劃就上！

結論

敏捷適用「頭腦清楚」的人——往往是大神級。大神 PM、Planner、RD 合作，清楚自己/別人在幹嘛，能覆蓋他人領域，知道解決問題能推進目標，這纔是「敏捷」，而非抓漏修 Bug。

敏捷只是方法，不是萬靈丹。
「字大一點、Logo 大一點、換張圖、多出幾版讓我挑」——這也算敏捷式改來改去嗎？