2015-6-5 周周
藍藍設計( paul-jarrel.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供有效的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
每一個扁平化界面設計，都是我們的心靈碰撞致力于最棒的 metro ui 設計
來源：優設網
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
@Akane_Lee ：當項目成員越多，我越不推薦敏捷開發，原因在于「當連自己要做什么事、為什么這樣做、這樣做為了解決什么問題」都搞不清楚前，就跳下去玩敏捷開發，那和比通靈還慘，通靈起碼還有個目標物在前面，搞不清楚狀況的人只能陪他跳世界迷霧開地圖了 >>>
敏捷開發 – MBA智庫百科 最下方有段「對敏捷開發的誤解」。可順便參考 敏捷軟件開發 – 維基百科。
說高不高啦，撇開實作技術不談，你覺得要找到清楚項目開發流程、知道每位項目成員的工作內容、職責范圍、產出，并清楚項目目標、需求、用戶需要的開發人員（含設計師）很容易嗎？
如果上述條件無法達成，又怎么確定運用敏捷開發方式后，所有項目成員方向都是正確的？就因為這種人太難找，所以會產生「對人要求很高」印象。
連在有企劃書、規格書、用戶研究報告的文件情況下都還不知道自己要干嘛、同事在干嘛，能談敏捷嗎？
文件撰寫與否和敏捷開發一點關系也沒有，敏捷開發強調「適應性而非預見性」，并沒有強硬規定。雖然有一句「可用的軟件：重于 詳盡的文件」，但它沒有叫你不要寫文件。
先想看看寫文件是為了解決什么問題？如果不寫文件會產生什么問題？
以 UI 設計師來講，交出 UI Flow、Wireframe 這種文件是為了解決什么問題？要敏捷開發嘛就不用寫了跳過，直接出 Mockup 吧。因為發現出包有漏改來改去改到死，和找到產品問題改良，是兩回事啊！
敏捷開發不是沒文件沒流程的包裝紙。
敏捷開發就是一直小幅度改啊改啊改啊，可以增加工作效率，讓大家工作更順利喔～～（就算是瀑布流式的傳統開發流程，設計師也是一直改啊改啊改啊，效率了什么、順利了什么啊！？）
先承認有問題，才能找出問題，之后找解決方法。而不是先有方法，再想這個方法能解決什么問題。敏捷開發只是一種「方法」，方法論用在敏捷開發上，要回答兩個問題：
敏捷開發不是萬靈丹，先找到問題點、知道為什么要采取敏捷，重點是卡在哪里需要敏捷這個「方法」來解決。設計師改來改去是為什么解決什么問題？敏捷開發的小幅度改來改去、和現況設計師的改來改去有什么不同？如果都一樣為什么要采取敏捷？（不要跟我說因為軟件開發主力是 RD 所以忘記算上設計師。）
個人與互動：重于流程與工具
開會是非常燒錢的行為，如果項目成員一多，要用什么方式降低溝通落差、盡量讓每個人理解到的都相同？怎么確保部門和部門間的信息交流順暢？靠出張嘴溝通就能辦到嗎？
可用的軟件：重于詳盡的文件
有文件產生/解決什么問題？沒有文件產生/解決什么問題？不寫文件最愛用「我們是敏捷開發」當借口了，不會寫就不會寫、不知道文件寫來干嘛就老實承認，少拿這個當說詞。
與客戶合作：重于合約協商
如果客戶沒有在好的引導下一起合作，現實狀況會變成「最后一次-確定最終版-說好不改了-V21.psd」。嗯？改來改去不就是敏捷開發嗎？（喂）
回應變化：重于遵循計劃
這不是改來改去改到死的好理由！為什么要「變化」，變化是為了解決什么問題？沒有問題改它干嘛？完全不代表可以沒計劃就上啊！
敏捷開發宣言里各種許愿…拔掉敏捷二字不也是所有項目開發的理想？所以為了解決什么問題而采用敏捷式開發？為了改善工作流程加快效率？
那設計師修改到死的工作情況在敏捷開發里要怎么被改善？
我覺得敏捷開發適用「頭腦清楚」的人，只是這種人往往是大神級的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、別人在干嘛，還能 Cover 一點別人的領域，知道解決這個問題可以往目標更進一步，這種合作模式才有辦法做到「敏捷」，而不是因為抓漏抓蟲在修改。是啦這也算朝目標邁進，但「創新改良產品」和「讓產品看起來洞沒那么大」的改來改去本質上是兩回事啊！敏捷開發只是個方法，不是萬靈丹。
敏捷式開發就是改來改去？
那「字大一點、Logo大一點、換一張照片、多出幾版讓我挑」也算啊～