2015年4月20日 星期一

學會和敏捷當朋友,工作機會向你招手

徐柏峰

        如果敏捷(Agile)定位為「具備快速因應變更,幫客戶解決問題的能力」,這個能力在當前的就業市場到底有多重要呢?全球最大的職缺搜尋引擎 Indeed.com ,給您直接了當的答案。

資料來源:Indeed.com

Agile職缺10年成長20倍

        從西元2006年1月起算,在短短10年間,與Agile有關的職缺數量,一路增加了20倍;同一個時期,又名瀑布式(Waterfall Model)的系統發展生命週期(System Development Life Cycle, SDLC),相關職缺卻停滯不前。
資料來源:Indeed.com

PMP證照供過於求

        在專案管理的領域,最廣為人知的認證,就是被台灣補習班當成提款機的Project Management Profession Certification認證(簡稱PMP),如果把PMP的職缺數量消長,和SDLC的職缺變化放在一起觀察,可以發現非常有趣的現象:PMP和SDLC的走勢幾乎是一模一樣。這意味著什麼呢?就業市場認為,PMP主張「先作文再做事」的種種流程,這是從營建、國防和航太產業(又稱為天龍國產業)衍生來的遊戲規則,這些規則相當於SDLC,也就是Waterfall。過去10年間,雖然假顧問公司之名的補習班,用輔考大隊當提款單、用考古題當提款卡,填鴨量產了很多PMP,不過,天龍國產業的職缺畢竟不多,證照供過於求的結果,就直接反映在薪資低落的現象上了。

PMI-ACP證照竄起,反映產業趨勢

        從2011年底開始,靠PMP證照每年營收超過60億台幣的專案管理協會(Project Management Institute, PMI),順勢推出PMI Agile Certified Practitioner(簡稱PMI-ACP)認證,用來鑑別專案從業人員是否具備「因應變更,滿足客戶需求的『敏捷』能力」。只要透過 Indeed.com的數據,觀察PMI-ACP和PMP這2個關鍵字的職缺需求變化,就會知道那些假顧問公司之名的補習班,為什麼紛紛急著拿香跟拜,開班傳授自己也沒有的「敏捷專案管理」實務了。

資料來源:Indeed.com
        如果想找國內Agile相關的職缺,不妨到Indeed.com看看


相關文章:不會敏捷?A咖公司止步





2015年2月25日 星期三

專案產業特性小調查

徐柏峰


        因為羨慕的關係,我把國防、航太和營建等產業,尊稱為天龍國產業,這些產業專案的共同特性是需求一開始就很明確,而且時程長、預算高,團隊人數又多,適合先寫作文,再開始做事的「正統」專案管理方法,需求變更對他們來說,相當於是修改合約,因此必須透過遊戲規則嚴格把關,避免變更頻繁發生。根據PMI的資料,在台灣參與天龍國產業的專案從業人員,大概是3.3%,這些令人羨慕的朋友們,工作環境比較接近PMP描述的那個理想世界。

        步入中年的我,現在轉行應該是來不及了,不過基於實事求是的精神,身為職業敏捷教練,我決定「利用職務之便」,針對接觸到的專案從業人員,開始進行近距離的調查。



        第1話,2015年2月間,滿腔熱血的台灣敏捷專家們,發起一場專案管理實務活動,共有27位從事專案相關工作的朋友前來共襄盛舉,這27人當中,有20個人持有PMP認證,13個人有PMI-ACP認證。我們在現場白板上拉出2 條線,構成4個象限,簡單透過2個問題,讓大家根據自問自答的結果,把自己的名字寫在卡片上,然後放在對應的象限。我們的2個問題是:

  • 您從事的專案,客戶開始講不清楚需求,看到需求之後還會變來變去?如果是,請往右,如果不是,請往左。
  • 您從事的專案, 結案時程在18個月以內(或金額在3,000萬台幣以內)?如果是,請往上,如果不是,請往下。

        經過簡短的3分鐘,台灣史上第一次的專案產業特性「小」調查結果出爐,統計結果和PMI的數字十分接近。參與活動的27個人當中,除了官拜副總的Jim哥以外,其餘的普羅大眾們,名字都集中在右上角的象限。這代表什麼意思呢?看來,大多數朋友在執行專案時,最需要的是在短期內因應變更的能力,這個能力就叫「擅變力」(Agility),這就是敏捷專案管理的目的。






2015年1月11日 星期日

我看見大象在跳舞,政府也敏捷了!

徐柏峰







        如果你認為政府機關就像大象一樣,推不動求快求變的敏捷方法,哪你就錯了!美國和英國政府,在經歷許多失敗教訓之後,決定在資訊科技(Information Technology, IT)類專案,向業界學習最佳實務,用敏捷方法推行政府專案。

政府是大咖的發包業主

        政府的IT專案中,發包委外(Acquisition)是很常見的作法。根據美國白宮「行政管理和預算局」(Office of Management and Budget, OBM)的統計,美國政府光在2011年間,就花了76億美元IT相關專案上。這些政府外包專案,向來是套用瀑布式開發方式,預算龐大,執行工期也常,不過失敗的案例卻是時有所聞。

美國政府資訊專案,經常不能善終


        以美國政府專案來說,「紐約市政府自動化薪資系統」(The New York City Automated Payroll System, NYCAP ),在1999年啟動時預計投入66百萬美元,後來一直拖到2011年才結案,光是追加的預算,就超過36千萬美元,相當於原先規畫的5.5倍;紐約市政府另一項名為CityTime的薪資系統,原本打算投入563百萬美元,但實際上耗費了1077千萬美元才收場;[1] 美國國稅局(Internal Revenue Service, IRS)19942005年間,投入185百萬美元開發電子舞弊偵測系統,後來IRS因故決定棄用系統,反而在1年內造成高達8億美元的損失。[2]

英國政府資訊專案,失敗案例時有所聞

        再以英國政府為例,19921026日,「倫敦救援服務電腦輔助派遣系統」(The London Ambulance Service Computed Aided Dispatch System, LASCAD)上線,原本預計針對每天平均2000~2500通的報案電話,提供自動派遣救護車的服務,不料,因為系統功能發生異常,某些民眾甚至在報案11個小時後才等到救護車,間接造成30人死亡,當時LAS的首長John Wilby因此引咎辭職,LASCAD系統因此遭到棄用。[3] 另外,英國政府原定投入187億美元,打造「全國衛生服務系統」 (National Health Service, NHS),建立中央化的醫療資料庫,NHS系統開發到第9年,也因為成效不彰,在2011年宣布終止,已經投入的44億美元付諸流水。[4]

美國政府機關的敏捷案例越來越多,國會立法要求國防部也要跟進

大型政府專案失敗案例層出不窮,美國和英國政府不約而同地向業界學習,決定採用敏捷方法。在美國政府方面,白宮行政管理和預算局(Office of Management and Budget, OBM),建議美國政府機關在推動資訊專案計畫時,應該使用敏捷方法,把資訊系統分割成模組化的小單位,循序漸進地交付。過去幾年以來,包括美國國家航空暨太空總署(National Aeronautics and Space Administration, NASA)、商務部(Department of Commerce)、退伍軍人事務部(Department of Veterans Affairs, VA)和國稅局(Internal Revenue Service, IRS)在內,都陸續傳出使用敏捷方法執行資訊專案計畫的案例。[5] 最具戲劇性的是,美國國會在《2010年國防授權法案》(The National Defense Authorization for Fisical Year 2010),立法要求一向擁護瀑布式開發的美國國防部(Department of Defense, DoD),未來辦理資訊委外( Acquisition of Information Technology)時,必須遵守4大原則,細看這4大原則,可以看到敏捷軟體開發宣言的影子:

  • Early and continual involvement of the user
  • Multiple, rapidly executed increments or releases of capability
  • Early, successive prototyping to support an evolutionary approach
  • A modular, open-systems approach



英國政府要求機關

        在英國方面,英國政府從20113月開始,要求機關要用敏捷方法辦理資通訊(Information and Communications Technology, ICT)專案,英國政府認為,軟體開發專案中,技術發展很快,需求輕重緩急變更非常頻繁,以往在初期鎖定需求的做法,把變更當例外的做法,有先天的重大缺陷。英國國家審計局(National Audit Office, NAO)建議,在資通訊類採購案,應該採用敏捷方法降低專案失敗的風險。英國內閣辦公室(Cabinet Office)早就2011年間設定目標,要求政府機關在在20134月以前,把一半的ICT專案改成使用敏捷方法,並且希望在2014年以前,能把ICT計畫的平均交付時間縮短20%[6]




[2] Robert D. Schneider, Tony Higgins and Keith Barrett, Requirements Definition & Management for Dummies(Mississauga: John Wiley & Sons Canada, Ltd, 2013), p.p. 24-25.
[3] 有關LASCAD系統失敗的分析,請參考ErichMusick網站,網址為http://erichmusick.com/writings/technology/1992-london-ambulance-cad-failure.html
[4] 有關NHS系統失敗案例的報導,請參考Neil Versel, U.K. Scrapping National Health IT Network. See http://www.informationweek.com/regulations/uk-scrapping-national-health-it-network/d/d-id/1099364?
[5] GAO, Software Development: Effective Practices and Federal Challenges in Applying Agile Methods, July 2013, pp. 29-30.
[6] NAO, Governance for Agile Delivery, P 7.

2015年1月10日 星期六

Build It with The Whole Team

Percy Pofeng Hsu

In my company, the diagrams below illustrate how "Business People" collaborate with Developers in every single Sprint.




2015年1月9日 星期五

敏捷團隊跑得快,上面坐個老太太

徐柏峰
使用敏捷方法可以提升團隊開發速度,這是千真萬確的事,不過,如果團隊接的是政府標案,就算提早開發出成品,也不見得可以提早驗收請款。

使用敏捷方法,可以縮短問世時間,提升開發效能
        VersionOne的年度敏捷調查報告指出,公司考慮導入敏捷方法的頭號理由,就是希望縮短「面市時間」(Time to Market, TTM),也就是產品從概念產生到上市銷售之間的時間。對承接政府標案的廠商來說,TTM可以比喻成拿到標案到開發票請款之間的時間。想當然,TTM越短,對廠商越有價值。QSM Accociates曾經出具報告指出,使用敏捷方法的團隊,TTM可以提升50%、產能(Productivies)可以提升25%[1] VersionOne對實際使用敏捷方法的團隊進行調查,結果發現,高達87%的團隊成員認為,開發的速度確實比以往還要快。[2] 撇開這些有商業色彩的報告不說,身為Scrum共同創始人的Jeff Sutherland在國際學術研討會上發文指出,Yahoo導入敏捷方法後,平均開發速度(Velocity)比以往的瀑布式方法增加了35%。由於使用敏捷方法提升後速度提升的案例實在太多,因此Jeff Sutherland訂出超高標準說,導入敏捷方法後效能要達到瀑布式方法的400%,才稱得上是真正的高產能(Hyperproductive State)[3]

公部門的辦事心態,不見得適合敏捷
      敏捷團隊跑得快,這是親身經歷的事。筆者在2009年剛接觸敏捷方法的時候,在政府委外開發軟體的專案上,應用Iteration PlanningIteration ReviewFace to Face CommunicationWorking Software這些技巧,把原本7個月要結案的專案,提前在5個半月內就全部「打完收工」,而且從測試報告、使用手冊到結案報告也全都做完。筆者原本以為提早做完就可以請求驗收付款,結果就在請求驗收文送出之前,機關承辦人來電訓誡說,絕對不可以讓上面覺得進度超前,以後也絕對不要做這種「找麻煩的事」。承辦人的理由是,當初專案講好7個月做出來,如果提前就能完工,就表示專案「不應該花那麼多錢」,因此承辦人怕被指責說在圖利廠商。後來,專案從第5個半月起, 繼續演了5次的每周進度報告,會議上除了聊天打屁,就是刻意在會議紀錄上寫說哪份文件的格式不對,需要退回重改,一直到法定時間,專案才進入驗收請款程序。到了第2年,筆者接了其他政府機關的專案,同樣的戲碼依舊上演。原來,提早把事情做完,並不是每個組織都歡迎的事!冏




[1] Ned Kremic, Why is Agile Time to Market(TTM) delivery 50% faster? See http://www.deltamatrix.com/agile-time-to-market
[2] VersionOne, 8th Annual State of Agile Servey, p. 9.
[3] S. Downey and J. Sutherland, Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft, IEEE HICSS 46th Hawaii International Conference on System Sciences, Maui, Hawaii, 2013