2015年1月6日 星期二

我再說一次!你嘛卡拜託,ALM哪是敏捷?

徐柏峰


        日前針對廠商自行宣告「使用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),是本末倒置的行為。

後記
        當初創始敏捷的這些大師,只用便條貼和白板搞定充滿變動的專案,感動了包括我在內的很多人。如果要問敏捷需要使用什麼工具,我覺得,唯一需要的是想要改變的心態,而不是任何廠商的工具產品。