當專案成員越多,我越不推薦敏捷開發,原因在於「當連自己要做什麼事、為什麼這樣做、這樣做為了解決什麼問題」都搞不清楚前,就跳下去玩敏捷開發,那和比通靈還慘,通靈起碼還有個目標物在前面,搞不清楚狀況的人只能陪他跳世界迷霧開地圖了。

敏捷開發 - MBA智库百科 最下方有段「對敏捷開發的誤解」。可順便參考 敏捷軟體開發 - 維基百科

誤解一:敏捷對人的要求很高

說高不高啦,撇開實作技術不談,你覺得要找到清楚專案開發流程、知道每位專案成員的工作內容、職責範圍、產出,並清楚專案目標、需求、使用者需要的開發人員(含設計師)很容易嗎?

如果上述條件無法達成,又怎麼確定運用敏捷開發方式後,所有專案成員方向都是正確的?就因為這種人太難找,所以會產生「對人要求很高」印象。

連在有企劃書、規格書、使用者研究報告的文件情況下都還不知道自己要幹嘛、同事在幹嘛,能談敏捷嗎?

誤解二:敏捷沒有文檔,也不做設計

文件撰寫與否和敏捷開發一點關係也沒有,敏捷開發強調「適應性而非預見性」,並沒有強硬規定。雖然有一句「可用的軟體:重於 詳盡的文件」,但它沒有叫你不要寫文件。

先想看看寫文件是為了解決什麼問題?如果不寫文件會產生什麼問題?

以 UI 設計師來講,交出 UI Flow、Wireframe 這種文件是為了解決什麼問題?要敏捷開發嘛就不用寫了跳過,直接出 Mockup 吧。因為發現出包有漏改來改去改到死,和找到產品問題改良,是兩回事啊!

敏捷開發不是沒文件沒流程的包裝紙。

誤解三:敏捷好,其他方法不好

敏捷開發就是一直小幅度改啊改啊改啊,可以增加工作效率,讓大家工作更順利喔~~(就算是瀑布流式的傳統開發流程,設計師也是一直改啊改啊改啊,效率了什麼、順利了什麼啊!?)

先承認有問題,才能找出問題,之後找解決方法。而不是先有方法,再想這個方法能解決什麼問題。敏捷開發只是一種「方法」,方法論用在敏捷開發上,要回答兩個問題:

  1. 現有模式為何不能滿足你的需求?
  2. 敏捷式開發為什麼可以?

敏捷開發不是萬靈丹,先找到問題點、知道為什麼要採取敏捷,重點是卡在哪裡需要敏捷這個「方法」來解決。設計師改來改去是為什麼解決什麼問題?敏捷開發的小幅度改來改去、和現況設計師的改來改去有什麼不同?如果都一樣為什麼要採取敏捷?(不要跟我說因為軟體開發主力是 RD 所以忘記算上設計師。)

現實的扭曲

##個人與互動:重於 流程與工具 開會是非常燒錢的行為,如果專案成員一多,要用什麼方式降低溝通落差、盡量讓每個人理解到的都相同?怎麼確保部門和部門間的資訊交流順暢?靠出張嘴溝通就能辦到嗎?

可用的軟體:重於 詳盡的文件

有文件產生/解決什麼問題?沒有文件產生/解決什麼問題?不寫文件最愛用「我們是敏捷開發」當藉口了,不會寫就不會寫、不知道文件寫來幹嘛就老實承認,少拿這個當說詞。

與客戶合作:重於 合約協商

如果客戶沒有在好的引導下一起合作,現實狀況會變成「最後一次-確定最終版-說好不改了-V21.psd」。嗯?改來改去不就是敏捷開發嗎?(喂)

回應變化:重於 遵循計劃

這不是改來改去改到死的好理由!為什麼要「變化」,變化是為了解決什麼問題?沒有問題改它幹嘛?完全不代表可以沒計劃就上啊!

結論

敏捷開發宣言裡各種許願…拔掉敏捷二字不也是所有專案開發的理想?所以為了解決什麼問題而採用敏捷式開發?為了改善工作流程加快效率?

那設計師修改到死的工作情況在敏捷開發裡要怎麼被改善?

我覺得敏捷開發適用「頭腦清楚」的人,只是這種人往往是大神級的了。和大神 PM、大神 Planner、大神 RD 合作,都清楚知道自己在幹嘛、別人在幹嘛,還能 Cover 一點別人的領域,知道解決這個問題可以往目標更進一步,這種合作模式才有辦法做到「敏捷」,而不是因為抓漏抓蟲在修改。是啦這也算朝目標邁進,但「創新改良產品」和「讓產品看起來洞沒那麼大」的改來改去本質上是兩回事啊!敏捷開發只是個方法,不是萬靈丹。

敏捷式開發就是改來改去? 那「字大一點、Logo大一點、換一張照片、多出幾版讓我挑」也算啊~

comments powered by Disqus