2015年12月3日 星期四

打造人民有感的政府數位服務:英國案例分享


這是2015年發表的最後一篇研究專題了,雖然題目是打造政府數位服務,內容是真正的大型敏捷案例,想要把組織轉型敏捷的,想找敏捷專案驗收標準的,還是想為專案訂定「有感」KPI的,在這篇文章裏面都有線索。全文刊載在國家發展委員會《政府機關資訊通報》第338期,有需要的朋友直接去下載吧。
《 政府機關資訊通報》第338期

2015年9月29日 星期二

靠北不是敏捷開發,不寫文件也不是

Image Source: http://giphy.com/gifs/western-cowboy-henry-fonda-xulayf0YLcCwo


有一個問題,每次在推廣敏捷方法的場合幾乎都有人提出。被問了這們多年,我想乾脆在這裡說個清楚。

問題是:你們不做規劃,不寫文件,怎麼確保產品的品質?

我的回答是這樣...

靠北不是敏捷開發
客倌您誤會了,既不做規劃,也不寫文件的那群人,用的是散兵游勇的「靠北編程法」(Cowboy Programming),而不是團隊合作的敏捷開發法(Agile Development)。通常,施展靠北法進行開發的團隊,要不是懶惰,就是沒有能力分析問題,要不就是自我感覺異常良好的『自認型天才工程師』,不論是哪一種,最近幾年隨著敏捷方法越來越流行,這群靠北大師經常在開會時隨便講一講畫一畫,就開始動工,號稱自己用的是『敏捷開發』,所以不進行設計,直到自己對客戶承諾「包在我身上」的專案後來真的「『包』在我身上」,他們就拿敏捷當藉口說:「台灣團隊不適合跑敏捷」,「客戶不懂,所以不適合使用敏捷開發」。也因為這樣,才會有人寫出「為什麼我不推薦敏捷開發《嫁給RD的UI Designer》」的文章,真的是對敏捷誤會大了!

客倌您聽好了,開心的敏捷環境是這樣運作的:

We Are All Developers的團隊文化
每3-9個人編成1個開發團隊,如果人數超過9人,就加開1隊,依此類推。
每隊的成員當中,不論個別專長是需求、分析、設計、實作、測試、作文、作畫、道歉(這個很重要)還是其他,對外一律稱為Developers,大家的專長加一加,要能夠因應產品開發過程中,各個環節的技術要求。

Three Amigos,決定產品品質


Image Source: http://giphy.com/gifs/sY1yvrxROgCM8

產品品質好不好,要看團隊裡的「3個好朋友」能否發出1+1+1>3的聲音,其中:

    第1個朋友的聲音,叫做Customer Voice
如果Customer Voice發揮作用,不論是透過文件,還是面對面溝通,團隊成員就都能說得出「客戶目前面臨的問題」(稱為「需要」(Needs)),以及「目前來說,適合用什麼方法來解決問題」(稱為「需求」(Requirements))。

    第2個朋友的聲音,叫做Worker Voice
如果Worker Voice發揮作用,有關工期估算,以及需求的執行方式,就會「由下而上」交給實際開發的人負責,而不會交由「官大學問大的河馬」決定。(HIPPO=Highest Paid Person's Opinion)

    第3個朋友的聲音,叫做Quality Voice
如果Quality Voice發揮作用,具備測試專長的同事,從專案啟動的第1天,就會是團隊編制內的專屬(Dedicated)成員,而不是開發階段結束後才接手的「外人」。在每個需求進入開發前,扮演QA角色的人,會事先開出相關測試案例,讓其他人有所依據,而在開發告一段落後,尤其是在Release前夕,如果大家都跑光,只留QA下來加班,就不能算是真正的We Are All Developers文化。

Document Late,撰寫又快又好又便宜的文件


Image Source: http://agilemodeling.com/essays/documentLate.htm
在文件方面,很多人對敏捷軟體開發宣言(Manifesto for Agile Software Development)斷章取義,以為"Working software over comprehensive documentation" 就代表敏捷團隊不寫文件。對此,我只能說:錯,錯,錯。敏捷團隊不但會寫文件,而且寫的是很精確的文件。以我自己曾經帶領或擔任Coach的團隊為例,我們認為文件的最大用處不是用來規劃(Planning)未來,而是用來記錄結果,因此在Product Planning、Release Planning、Iteration Planning和Daily Standup這些規劃的場合,我們把相關人員聚在一起,用面對面溝通的方式,利用大面積的白板、便條貼、照片和螢幕擷取畫面,紀錄和需求相關的所有細節。在Iteration期間,Three Amigos之間只要有任何疑慮,不論是需求不清、作法不明,還是遇到卡關(Block),相關人等一律直接「踹共」,一邊塗鴉,一邊就當場把問題講開,而不必多花時間刻作文、發Mail或請聖旨。
由於每個Iteration的實際產出,不但要經過QA的驗證,還會直接給使用者測試,因此歷經幾個Iterations累積出來的開發成果,在Release前早就「準備好了」。我們知道高品質的產品,一定要搭配相關的文件,因此在實務上,我們有些團隊是在Release前預留Hardening Iteration,讓團隊成員寫文件,也有些團隊,是在確定Release「安全下莊」之後,讓成員在比較不緊張的情緒下,才開Iteration來補齊前一個Release的文件。
拿結果來寫文件,就像是把箭射出去才描靶,和以往「先寫作文再做事」的主流開發方法比起來,我們不論是需求、分析、設計、布署,還是使用者文件,都可以寫得又快、又好、又便宜,這個最佳實務,就叫做Document Late。

相關文章:敏捷開發(Agile Development)


2015年9月26日 星期六

秒懂 MoSCoW排序法,專案聚焦不再瞎忙


敏捷方法陣營中,DSDM Consortium提出的MoSCoW排序法,在「願望很多、時程很趕」的專案世界裡,是很實用的需求管理招式。


MoSCoW的作法就是在進行Iteration Planning(當期規劃)時,把需求分為4大類,其中:
1. Must Have(M): 對Iteration Goal來說,沒有交付就不能達標的事。
2. Should Have(S): 對Iteration Goal雖然重要,但目前仍有替代方案,就算沒有交付,也不影響達標的事。
3. Could Have(C): 與Iteration Goal沒有直接關係,如果交付可以加分,但就算忽略也不會影響達標的事。
4. Won't Have It Right Now(W): 和Iteration Goal完全沒有關係的事。

根據DSDM的建議,M、S、C類的需求,在規劃時應該各自配置60%、20%和20%的工時,在開發週期內,M類需求如果沒有做完,團隊就不做S類需求,S類需求沒做完,就不做C類需求,至於W類的需求,顧名思義就是要團隊敬而遠之,避免花時間在上面的事。

因此,如果用MoSCoW法管理需求,整個開發週期執行下來,就算預計的工時和實際工時有落差,也能確保「最重要的事獲得最早而且最多的資源」,這就是敏捷團隊「要事先行」(First Things First)的原理!






2015年9月9日 星期三

The Product Backlog Iceberg Revised


敏捷需求大師Mike Cohn,曾經用冰山(Iceberg)比喻專案的Product Backlog,很貼切地表達了專案的所有需求和需求之間,也有大小輕重緩急的概念。



從敏捷開發的實務來說:
1. 排進目前Iteration執行的需求,不但要控制在一期做得完的大小,而且要分解出相關的Tasks。
2. 預計下個Iteration執行的需求,需要經過Grooming(或稱Refinement),確保大小適中,而且備妥Acceptance Criteria,達到Ready的狀態。所謂的Ready Story,就是團隊在進行Iteration Planning時,不用花10鐘就能把相關的Task分解出來的Story。
3. 團隊和Product Owner同意排進Release Backlog的需求,就是Committed的狀態,這些需求當中,有的比較粗略,還需要進一步分解優化。
4. 至於當前Release以外的需求,說得好聽叫做Defer Commitment,白話的意思就是「再說啦」。


2015年8月26日 星期三

一句話一張圖 搞懂什麼是UX

UX Designer是敏捷產品開發專案中的重要角色,大力推動敏捷開發的美國政府,目前每個公家機關平均都投入2個專職人力外加2個兼職人力,執行UX相關的工作。
從敏捷的觀點來說,不論用了多少UX的招式,如果不是從解決使用者問題出發,一切都是白搭。




2015年8月13日 星期四

Scrum全球應用調查報告,搶先看

號稱有40萬會員的Scrum Alliance®,日前公布了The 2015 State of Scrum Report,針對敏捷方法在全球業界的應用概況,提供了一些有趣的統計資訊。

第一、Scrum雖然是最多人用到的敏捷開發法,不過,超過半數的受訪者表示,自己公司的團隊是混搭各門各派的實務(例如在Scrum團隊中使用Kanban顯示進度,或是應用XP的Pair Programming、Test Driven Development);聲稱自己團隊完全只用Scrum的,只有42%。



第二、使用Scrum可以改善開發團隊的工作和生活的品質,不過有趣的是,超過7成的人表示,在公司使用Scrum的團隊,和其他非Scrum的團隊之間,竟然存在著緊張的氣氛。



第三、把開發人力組成一個一個的小團隊,是主流的作法,團隊平均人數是7個人。


第四、採用短開發週期是普遍的現象,最多團隊選擇以2週為1個Sprint的長度。

第五、使用Scrum執行專案的成功率比較高,如果使用Scrum的專案是由PMO主導管理,成功率超過9成。


另外,超過95%的受訪者表示,體驗過Scrum的開發方式之後,未來還再進一步深入應用,如果這個調查屬實,Scrum應該是「黏著度」前無古人的團隊工作方式了。


本文所有資訊及圖片,取自The 2015 State of Scrum Report,該報告受訪對象超過4,400人,橫跨108個國家14個產業,如需進一步資訊,請自Scrum Alliance®官網下載全文。

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

2015年1月8日 星期四

小確幸是專案勝出的秘密

徐柏峰
        從1985年開始,知名資訊顧問公司-The Standish Group,定期用批流年的方式,公布「全球」資訊類專案的成敗比率(Resolution)。不論是資訊還是專案管理背景的人,對The Standish Group的報告,應該都不陌生。
Project Resolution(2004~2012)
Source: Chaos Manifesto 2013
敏捷專案成功率是瀑布式專案的3倍
        The Standish GroupChaos Manifesto 2011報告中說,敏捷是全球軟體開發專案的救星(The universal remedy for software development project failure),專案使用敏捷方法,成功率會是傳統瀑布式方法的3倍。
Chaos Resolution by Style
Source: Chaos Manifesto 2011
小專案勝出機會比較大
        事隔兩年,Chaos Manifesto 2013稍稍「修正」了官方說法,改口說:專案成敗的重點,是「大處著眼、小處著手」(Think Big, Act Small)的能力,因為根據The Standish Group實證的結果,人事支出(Labor Content)1百萬美元以下的專案,執行成功率是1千萬美元以上專案的7.6倍,失敗率是則是低於8分之1報告中指出,以軟體開發這個領域來說,所有的大專案都能切成多個小專案,不過,切割不是把專案分階段交付這麼簡單,真正有用的切割,是把原本一大包的專案,根據商務價值來分成模組,分割成可以個別帶來小確幸的專案。

Project Resolution by Size
Source: Chaos Manifesto 2013
        在台灣和大陸,規模1百萬美元以下的專案超過70%,應該比較具備成功的條件吧!

2015年1月7日 星期三

用減法管需求才是王道

徐柏峰

軟體功能客戶使用率統計
資料來源:Chaos Manifesto 2013, p2.
很多學過專案管理的人,都看過Standish Group的報告,Standish Group在Chaos Manifesto 2013中指出,2004到2012年之間,軟體開發專案在結案時,平均只交付了64%~74%的功能。針對這種沒有「通通都要拿去做雞精」的專案,Chaos Manifesto的解讀非常有意思,報告中指出,團隊開發出來的軟體當中,只有2成功能是用戶經常用到,5成的功能是幾乎沒有或從來沒有用到,3成功能是偶爾或不常用到。不論功能後來有沒有用,團隊都要花時間做需求、分析、設計、開發這些動作,而每個動作都要花錢。不管是誰家的專案,如果問客戶,永遠會得到「通通都要,而且很急」的需求,問團隊,每次都得到時間和成本不夠的答案,與其自怨自艾,真的有意義的作法是,用減法管需求,先集中火力,開發對客戶最有價值的功能,這就是80/20法則的應用。

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),是本末倒置的行為。

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





2015年1月5日 星期一

不會敏捷?A咖公司止步

徐柏峰

Scrum創始人之一的Jeff Sutherland,日前透過LinkedIn的公開資料,針對一些全球性「A咖公司」(Leading Companies)的現職員工,統計有多少人在履歷表提到自己有敏捷經歷。全世界導入敏捷方法的公司,當然遠遠超過這些,不過從Jeff Sutherland提供的統計數字,我們可以發現,原來從2001年以來的這波敏捷風潮,已經明顯擴散到IT產業以外的產業了。如果您也想進A咖公司,快學敏捷吧!

Source: http://www.scruminc.com/company-agile/
相關文章:學會和敏捷交朋友,工作機會向你招手



2015年1月4日 星期日

政府機關敏捷案例:美國專利商標局PE2E專案

徐柏峰



美國專利商標局(The United States Patent and Trademark Office, USPTO),負責全美專利和商標申請和核准手續,是隸屬於商務部(Department of Commerce)的重要機關。USPTO首長由美國總統任命,全銜為商務部次長暨專利商標局局長(Under Secretary of Commerce for Intellectual Property and Director of the United States Patent and Trademark Office)[1] 在美國聯邦政府中,USPTO是排名第1的幸福機關(Best Places to Work in the Federal Government)USPTO每年靠著規費,「營收」(Earned Revenue)表現非常可觀,而且一年比一年好,而收入當中超過9成,來自專利審查(Patent Examination)[2]

USPTO歷年營收
金額單位:百萬美元

資料來源:USPTO, FY2013 Performance and Accountability Report, pp. 77.

1. 專案背景

        USPTO的專利審查程序,分為審查前(Pre-Examination)、審查(Examination)和審查後(Post-Examination)3個階段,每階段內都有重要的流程:
 USPTO專利審查階段
資料來源:USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, p. 1.

1.1 早期使用大量紙本

        從19世紀到20世紀初期的專利審查流程,使用大量的紙本文件。專利申請案從申請案分類(Classification of Claims)、先前技術搜尋(Prior Art Search)、審查(Examination)、初步審查意見(Drafting of Office Actions)、回應申請審查意見(Responding to Applicants Replies to the Office Actions),一直到核發證明(Issuance of a Paper Patent),每個步驟使用的都是實體的紙本檔案,審查的動作慢,而且要花很多空間來存放紙張。[3]

1.2 80年代開始數位化

        隨著申請案越來越多,紙本審查的效能漸漸跟不上時代腳步。1981年間,美國的專利申請數為114,710件,而同年度的專利領證量為71,010件,由於審查流程必須大量調閱卷宗,翻閱紙張,審查官工作忙不過來,積案(Backlog)越來越多。[4] 為了改善專利審查發證的效率,USPTO198212月,向美國國會提出「無紙化辦公室」(Paperless Office)計畫,從那時候起,USPTO在將近30年內,陸續投入了超過10億美元,建立起將近50個相關的資訊系統,並把紙本的申請文件,陸續數位化成圖片檔案,讓相關同仁把原本要翻文件的動作,改成調閱圖片檔,來提升專利審查的工作效能。[5]

1.3 近年專利業務暴增

        最近幾年來,紙本文件確實數位化了,透過數位圖檔審查申請案的工作流程,卻和以前的紙本審查一樣,遇到效能瓶頸。時至2010年,USPTO建立的「專案檔案包裹」(Patent File Wrapper)系統,堪稱全球最大的專利資料庫,每年向USPTO申請專利的件數,超過50萬筆。不過,USPTO局裡6千多名審查官,在處理專利申請案件時,最多要從16個相關資訊系統,搜尋相關資料,然後再用手工剪貼文件,才能執行業務,而且有些資訊系統的效能不佳,找一筆專利申請資料要等上好幾分鐘,讓審查官想快也快不起來,而USPTO的積案數量,也逐步攀升到72萬件。
        根據USPTO自己的統計,從2006年到2010年間,雖然電子化申請的比率,從原本的14%,拉高到將近9成,但專利申請人平均要等上25.7個月,才能拿到首次通知(First Office Action),而平均待審時間甚至將近3年。[6] 不僅如此,歷經30年陸續建立的相關系統,已經變成「歷史共業」,不論是系統維護、檔案備份,還是人員訓練,都是頭痛的問題。
USPTO 2010年專利審查概況

資料來源:USPTO, FY2010 Performance and Accountability Report

2. 導入過程

2.1 Patent File Wrapper遭到列管

        USPTO的窘境,受到白宮當局的關切。2010年,負責幫美國總統編制和審核預算OMB,把Patent File Wrapper系統列為聯邦高風險專案,要求USPTO限期提出解決措施,才能再拿到預算繼續進行系統開發。對此,USPTO幾經研商,終於在2010年第4季提出因應方案,打算建構一個新的資訊平台,取代既有的Patent File Wrapper,並把既有資訊系統主要功能都整合進來,讓審查專利在單一資訊系統裡面串起來,成為一貫化的流程。

2.2 提出PE2E平台解決效能瓶頸

        USPTO提出的新構想,叫做「專利端到端」(Patent-End-to-End, PE2E)平台。根據USPTO觀察,要改善既有資訊系統的效能,就要把原本透過圖片檔呈現的申請文件,改成使用「可擴充標記語言」(eXtensible Markup Language, XML)格式來記錄,建立起以文字為基礎的作業流程(Text-based Processing),才能提升互動性(Interactive),並進一步提升審查效率。為了達到這個目標,USPTO當局決定,導入敏捷開發方法中的Scrum來建立PE2E,幫USPTO改善審查專利的流程。

2.3 引入敏捷概念取代瀑布式規劃

        根據USPTO前局長David Kappos的回顧,USPTO資訊長John B. Owen20105月起,就在局裡推動敏捷開發的想法,不但在內部針對資訊同仁和使用單位同仁,辦理敏捷的教育訓練,而且也招募了一些具備敏捷素養的計畫經理(Program Managers)David Kappos表示,傳統上,USPTO 走的是瀑布式開發法,把系統切割成一個階段接著一個階段,專案交付時程都很長,同仁要等上好幾個月,甚至好幾年,才能收到「不見得符合需要的」新功能。相反地,敏捷不但強調快速交付,還要使用者從頭就參與,可以確保專案成功地做出使用者想要(Want)和需要(Need)的工具。[7]

2.4 PE2E2階段開發策略

        針對PE2E系統,USPTO當局規劃投入13千萬美元,進行系統開發,並編列每年15百萬美元的維護費用,讓專案成果在2013年上線。由於系統架構非常龐大,相關技術十分複雜,USPTO決定向業界「借力」,把PE2E平台分為2階段開發:第1階段先發包一個雛型開發專案,同時委託3家廠商,各自針對UPSTO未來需要的資訊系統,先建立起核心基礎設施的原型(prototype),讓參與PE2E的相關同仁「有感覺」。到了第2階段,再評選出1家系統整合商(System Integrator, SI),根據第1階段的成果,透過敏捷方法,由優勝廠商「統包」,一個開發週期接著一個開發週期,「先求有,再求好」,逐步打造出PE2E需要的各個功能。

2.5 USPTO自己做系統整合

        20113月, PE2E1階段的3家廠商進行成果發表,USPTO評估後發現,沒有一家廠商做出的雛形,符合USPTO的預期。USPTO毅然決定,在第2階段「自己動手做」,擔當整個PE2E平台的「統包」,主導架構設計和的系統整合。
        根據規劃,PE2E必須在2011年底前,釋出(Release)1次的開發成果。為了達到這個時程目標,USPTO決定縮減範圍,打消原先要先開發核心架構(Core Architecture)的念頭,轉而先做專利審核流程中最明確的需求,讓審查官能先看到被分派到的申請案清單,以便根據審閱每個案件的主張,在申請案上加上註解。第1次釋出的範圍名稱,叫做「中央複審單元」(Central Reexamination Unit, CRU)USPTO規劃投入80名真正的使用者,試行新的工作流程,如果系統功能成熟,再把功能開放給局裡6千多名審查官的使用。
        20114月,PE2E開始規畫使用介面,到了6月中,開始進行架構設計和開發,為了加速開發速度, USPTO 把第1次釋出的需求獨立整理成一個專案,發包給一家廠商開發,不過,後續的釋出要做些什麼,要怎麼發包,USPTO都沒有提出具體的作法。[8]

3. 執行成效

3.1 PE2E開發初期遭到批評

        PE2E專案內部怎麼使用敏捷開發,相關資料並不多見,不過,批評PE2E「不夠敏捷」的聲音,已經先傳開來。20119月,PE2E的第1次釋出進行到一半,美國商務部督察長辦公室(Office of Inspector General, OIG),就對PE2E專案發出稽核報告指出,PE2E專案雖然導入敏捷方法,不過實際做法卻不符合敏捷的要求。針對OIG的評論,在USPTO主導推動敏捷的資訊長John B. Owen虛心受教,表明會逐一改善。[9]
OIGPE2E的稽核結果
資料來源:USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, pp. 4-7.

        截至2015年初為止,PE2E平台仍在開發中,導入敏捷的專案成效,目前還難有定論。不過,針對USPTO政策、目標、成效和規費等營運事務,負責向USPTO局長提出建言的「專利公眾諮詢委員會」(Patent Public Advisory Committee, PPAC),從2010年起,不但每年都在年度報告上提到敏捷,也非常肯定USPTO引入敏捷的作法。[10] USPTO前局長David Kappos在官方的網誌上表示,敏捷和USPTO以往的瀑布式方法比起來,有3個根本上的差異:首先,敏捷擁抱變更,把變更視為常態。在敏捷團隊中,不但預期變更發生,而且還刻意規畫變更,並且根據商務的需要,及時改變計畫來因應;其次,敏捷透過1~3個月的衝刺期,把風險降到最低。在落實敏捷的環境中,團隊氣氛鼓勵盡早失敗,執行上發生的問題或是產品品質的缺失,會在衝刺期內就顯現,不用等到後面。最後,透過敏捷可以讓團隊一步一腳印地把高品質的成品做出來,並且根據使用者實際的需要來改善功能。David Kappos站在局長的高度呼籲,推動敏捷就要改變文化。專案團隊成員當中,一定要包括使用者這個角色,負責在開發期間,實際操作並測試系統功能。使用者提供的回饋意見,要能快速地整合到未來的開發週期當中,如此一來,在幾個月內就能看到改善的成果。[11]3.2 USPTO由上而下推動敏捷文化

3.3 PE2E1.0版預計2015年上線

        USPTO2014-2018戰略計畫中,把持續開發PE2E列為重要的資訊科技目標。根據USPTO對美國國會提出的《2015年預算說明書》(Fiscal Year 2015 President’s Budget: The USPTO Congressional Budget Justification)PE2E系統發展的進程如下:
PE2E系統主要進展和未來展望
資料來源:USPTO, Fiscal Year 2015 Presidents Budget: The USPTO Congressional Budget Justification.


[1] 經濟部智慧財產局,《美國專利須知》,民國935月,第5頁。
[2] USPTO, FY2013 Performance and Accountability Report, p. ii.
[3] USPTO, PATENT PUBLIC ADVISORY COMMITTEE ANNUAL REPORT 2011, p 20.
[4] Hon. Gerald J. Mossinghoff and Stephen G. Kunin, New Post Grant Administrative Trials Before the USPTO’s Patent Trial and Appeal Board.
[5] USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, p. 1.
[6] USPTO, FY2010 Performance and Accountability Report, p 12; 2013年度,USPTO的電子化申請比率已經突破98%,請見USPTO, FY2013 Performance and Accountability Report, p i.
[7]  David Kappos, “USPTO Gets Agile.” http://www.uspto.gov/blog/director/entry/uspto_gets_agile
[8] USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, p. 2.
[9] USPTO, ibid, pp. 10-13.
[10] 1999年美國發明人保護法案》,詳見USPTO官網http://www.uspto.gov/patents/law/aipa/
[11] David Kappos, “USPTO Gets Agile.” http://www.uspto.gov/blog/director/entry/uspto_gets_agile