日前針對廠商自行宣告「使用ALM工具= 敏捷2.0」的亂象，寫了一篇小抱怨。最近有前輩回應我說：「真的很懷疑你到底對人家的工具懂多少,就下此結論,雖然我也是敏捷的支持者,但實在很不能認同你」，對於前輩的指導，我真的很感謝，我以多年推動敏捷專案管理的的經驗，把我發文始末報告清楚一點。
敏捷方法來自開發實務
如果我們跳過1970年代以年的軟工歷史不說，目前席捲全球的這一波敏捷風潮，起源1990年代。當時，數位化浪潮興起，美國的一群軟體先進，覺得當時大家理所當然「先寫作文再做事」的開發方式，在帶領團隊開發時就是「卡卡的」。當時的Kent Beck、Jeff Sutherland、Ken Schwaber、Martin Fowler、Jim Highsmith...等人，有的是天才型工程師，有的是公司VP級的主管，還有些已經是業界知名的顧問，這些來自實務界的大師們，在90年代各自用實際帶隊的經驗，歸納出務實的作法，各自創立了門派。
敏捷宣言和原則，是因應變更的心法
這些共同反對「重量級」(Heavy Weight)開發方法的門派代表們，在2001年的敏捷大會上，是既合作又競爭的關係。合作的是，這些實務界的大師都同意，多數人參與的軟體開發專案，客戶變更非常頻繁，不能硬套從國防、營建和航太產業衍生出來的做事方法；競爭的是，這些大師都希望自己創立的門派，可以一統天下，成為軟體開發的新典範。後來的4句敏捷軟體開發宣言，以及12句敏捷原則，就是在這種競合的背景下誕生的「最大公因數」，因為這樣，敏捷宣言講的都是面對專案時，團隊成員(包括客戶在內)應該具備的心態，敏捷原則裡，則是刻意避開了任何一派的專有名詞，例如：與會各派都同意需求窗口很重要，應該要和團隊成員密切共事，不過在Scrum這派，需求提供者叫做Product Owner，在XP，則稱為Onsite Customer，為了不偏袒任一方，敏捷原則就說"Business people and developers must work
together daily throughout the project"。連用字遣詞都這麼注意了，敏捷宣言和原則裡面不推崇任何工具，是可想而知的事，敏捷宣言的第一句話說"Individuals and Interactions OVER Process and Tools"，就是這樣來的。
大廠不能管你怎麼想，卻能控制你拿什麼來想
在軟體產業打滾了十幾年，發現業界有個奇特的現象：大廠或大組織為了營利，持續創新技術或話題，營造出「若不跟著上車，以後就完蛋」的氣氛，從幾年前的UML、SOA、CMMI、Cloud、Mobile、Big Data一直到穿戴式裝置，一直都是這樣。大咖透過工商服務型研討會和不斷"+1"的學者專家，持續施展洗腦神功，每一波行銷攻勢的終極目標就是政府，方式就是業把界堆積出來的資訊詞彙塞給政務官，「擘劃」出大型的「政策方針」，實作就是讓廠商「申請補助」，或在政府利潤豐厚的政府標案上，放進這些浮誇的詞彙。這當中最可憐的，就是當初懷抱理想投入產業的軟體工程師，一入行就發現，怎麼開發軟體和時尚業一樣，要不斷地學新花樣，可是人家時尚業可以搞復古，宅男宅女工程師卻不能拿阿爸留下的Fortran給客戶說這是時尚。
敏捷成為主流，軟體工具廠商把握商機
每次技術改朝換代，開發相關工具就要跟著「升級」，創造更多的利潤。根據Ken Schwaber的說法，軟體生命週期管理(Application Life-cycle Manager )工具每年有50~70億美元的收益。大約從2011年開始，敏捷成功案例越來越多，Chaos Manifesto講出「使用敏捷流程的團隊，專案成功率是瀑布式流程團隊3倍」，就連一向擁抱「正式」專案管理流程的專案管理協會(Project Manage Institute, PMI)，也不惜推出容易對PMP打臉的PMI-ACP認證，來搶奪敏捷商機。看在軟體工具廠商的眼裡，敏捷當然是不能錯過的趨勢，因此，這幾年來，軟體工具廠商先是推出「支援敏捷方法」的開發工具，後來有的廠商，就把敏捷陣營裡面部分派別的實務包一包，再加上自己的獨規，做成從公司治理、開發、釋出到維護整個過程中，全部「照顧到」的大型工具。
ALM廠商大超過，敏捷大師頗有微詞
工具功能越做越多是事實，但適不適合每個團隊使用，以及好不好用，是見仁見智的問題，不過，ALM廠商為了行銷噱頭，竟然在2013年的一場工商服務「研討會」上，在沒有邀請任何一為敏捷各派大師的情況下，自己「黃袍加身」，聲稱使用該廠商的工具，就是擁抱敏捷2.0。這廠商的說法，傳到Scrum共同創始人Ken Schwaber的耳裡，覺得非常不「蘇胡」，因此寫了一篇文章來指正，Ken Schwaber指出，2001年敏捷軟體宣言推廣的那些觀念(不是工具喔)，現在都還沒有實現，測試驅動開發(Test Driven Development, TDD)、接受測試驅動開發(Acceptance Test Driven Development, ATDD)或行為驅動開發(Behavior Driven Development)，實作的人都還很少，ALM廠商把仍是少數人用的實務當成敏捷2.0的口號在喊，就像「把馬車放到馬前面」(Putting the Cart Before the Horse)，是本末倒置的行為。
後記
當初創始敏捷的這些大師，只用便條貼和白板搞定充滿變動的專案，感動了包括我在內的很多人。如果要問敏捷需要使用什麼工具，我覺得，唯一需要的是想要改變的心態，而不是任何廠商的工具產品。
沒有留言:
張貼留言