鴻海，客戶要的是敏捷

徐柏峰

日前美國亞利桑那州州長Janice Brewer來台參訪，鴻海董事長郭台銘親自接待。郭董在會後表示，「世界在改變，美國也在改變」，包括Apple在內，Amazon、Facebook和Google美國大企業，都希望鴻海能在當地提供快速樣品能力和新產品開發能力。[1]

        其實，郭董提到的這幾家世界級大咖，就是全球最具代表性的幾家敏捷企業：

        先就Apple來說，在Steve Jobs還健在的時候，就是終極產品代言人(Product Owner, PO)，負責定義Apple產品需要提供什麼功能，才能取悅消費者；Apple經常把重要的產品功能，交付給小團隊負責，例如，當年MAC上的Safari瀏覽器，就是透過2名工程師合作轉移到iPAD上面;Apple企業內部建立「擔責員工」(Directly Responsible Individual, DRI)的環境，任何一個任務出錯時，都一定找得到一個必須負責的窗口；公司文化鼓勵的是「做大事，而不是省大金」(do great work, not save dollars)。[2]

        再說Amazon吧！身為全球最大的網路線上零售商之一，Amazon成立第5年(1999年)，就開始導入敏捷實務，而在2004~2009這5年間，Amazon的開發部門徹頭徹尾轉型，大量使用Scrum的工作方法。[3]

        另外，Facebook內部敏捷管理行之有年，早在2011年初，Facebook把工程師、美工、資料專家、專案經理和行銷人員合組成Collocated團隊，以及快速開發和每日站立會議(Daily Standup Meeting)這些敏捷實務，就曾獲得Time的專題報導。[4]

擷取自 http://content.time.com/time/video/player/0,32068,712448402001_2037228,00.html

        至於已經是搜尋引擎代名詞的Google，在2006年間就首次導入Agile，執行大型的分散式專案，當年還請到Scrum的共同創始人Jeff Sutherland，在Retrospective時到場幫忙分析Google的敏捷經驗教訓。[5]

        接觸過敏捷專案管理的人都知道，敏捷是一種以人為本的工作文化，團隊由跨部門的通才組成，快速依據客戶需求，循序漸進交付客戶在每個開發期間「最急著看到的東西」(=最有價值的東西)。客戶因為經常可以看到實際的成果，因此對團隊產生信任；公司不再一昧地追求Cost down，也不鼓勵個人績效，因為團體成績重於個人成績，而團隊士氣才是產能的動力；主管不再把壓力轉嫁在團隊身上，而是挺身而出，想盡辦法幫團隊排除工作的障礙。

        世界大廠對鴻海的期盼，正是台灣轉型的契機。如果像鴻海這麼大的集團，也能夠由上而下體會到敏捷的精隨，日後其他企業再紛紛跟進，或許就能把打造出「客戶放心、團隊開心」的敏捷台灣了。

(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®，以及台灣、中國兩地首位專案風險管理師PMI-RMP®)

---

[1] 「郭台銘：美大企業盼鴻海開發能力」，2013/11/09，中央廣播電台，參考：http://news.rti.org.tw/index_newsContent.aspx?nid=463134; 「鴻海 擬赴美東西岸設總部」，2013/11/09，聯合理財網，請見http://udn.com/NEWS/FINANCE/FIN3/8285103.shtml

[2] Steve Denning, “Is Apple True ‘Agile’?” See http://www.forbes.com/sites/stevedenning/2012/02/03/is-apple-truly-agile/

[3] Alan Atlas, “Scrum at Amazon.” See http://theagileexecutive.com/2009/07/20/scrum-at-amazon-guest-post-by-alan-atlas/

[4] David Ramel, “How Facebook Does Agile,” Application Development Trends. See http://adtmag.com/articles/2011/01/14/how-facebook-does-agile.aspx

[5] Jeff Sutherland, “Agile Project Management: Lessons Learned from Google,” InfoQ. See http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland

敏捷專案管理: 寂寞星球的聰明律師

徐柏峰
        在一般人的印象中，法律工作應該很難敏捷吧？法務的工作吃緊，不但要負責制定合約制定、協商客戶，還要提供法律諮詢，而法律文字通常又要琢磨很久，想要求快求變的敏捷起來，簡直是天方夜譚。日前，全球最大的旅遊書籍出版商-寂寞星球(Lonely Planet)，有一群聰明的律師，用創意導入敏捷的工作方式，顛覆了我們對法務工作的刻板印象。

圖片來源: Lonely Planet Legal Affairs: smart people + lean work practices = innovation，網址http://lunatractor.com/not-just-an-it-thing-our-book/lonely-planet-legal-affairs-smart-people-lean-work-practices-innovation/

        寂寞星球的法務部門，過去也是過著死亡行軍地爆肝人生，每天加不完的班，客戶搞不清楚狀況就要訂合約，可是往往合約做出來之後需求才真的浮現，雖然工作累個半死，公司卻缺乏管理法務工作進度的機制，導致其他部門的同事，以為法務閒著沒事，因此不斷插件，造成地法務時間被嚴重切割，士氣低落。大約從2008年開始，這群法律人從IT部門學來敏捷方法，大約花了3個月，自創了一套融合Scrum、Kaban和Lean的工作方式，在辦公室豎起大大的工作看板，把每個客戶的法務需求寫在便條貼上，團隊以每周為一期，在看板上排定任務的優先順序，成員每天上班第一件事，就是開15分鐘的站立會議，根據自己的法律專長，選擇當天要執行的任務，而任務看板上，則把每個任務的進度，分為待辦、進行中、卡關、和客戶確認(相當於測試)和完工等5個狀態。自從導入這個做事方法，客戶可以視覺化看到工作進度，團隊做事也覺得有方向感，從此效能增加、士氣大振，成為非IT產業引入敏捷的知名案例。

Lonely Planet Legal Affairs: smart people + lean work practices = innovation，網址http://lunatractor.com/not-just-an-it-thing-our-book/lonely-planet-legal-affairs-smart-people-lean-work-practices-innovation/

(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®，以及台灣、中國兩地首位專案風險管理師PMI-RMP®)

敏捷專案管理：即刻救援的故事Chile Ayuda

徐柏峰
        突如其來的一場天災，讓全世界見證到敏捷的效率。

照片為 Claudio Núñez 所攝

2010年2月27日凌晨3點34分，南美洲的智利傳出芮氏規模8.8的強震，緊接著引發的大海嘯浪高3公尺，沿海地區受到重創。這場史上第6大的地震，不但奪走700條人命，也讓人口僅有1700萬的智利，多達150萬人無家可歸。地震發生後不久，一名叫佩德羅‧佛安德斯‧舒斯特(Pedro Fuentes Schuster)的智利青年，在推特(Twitter)發文徵求各方志士挺身而出，幫同胞走出難關。

摘自Agile 2011: One earthquake, 300 volunteers and 6 days to build a portal

        推文發出1天內，來自各地的60名義工，湧入聖地牙哥市馬波丘河畔(Mapocho River)的1間辦公室，啟動一個名為救援智利(Chile Ayuda)的入口網站開發專案，期望在最短時間內幫災民找到親友，並把善款和賑災物資，發放到最需要的地方。

        透過社群媒體的串聯，專案團隊2周內就膨脹到300人，所有成員依照專長不同，分為工程師(Engineer)，媒體記者(Journalists)、網頁設計師(Web Designers)和理事會(Board)等4個工作小組。如此龐大的義工部隊，讓原本只能容納20個人的辦公室，時時刻刻的擠著上百個人。從專案管理的角度來看，這是個超高難度的專案：時間緊迫、需求持續演進，雖說人多好辦事，但團隊臨時成軍，義工之間大多不認識，光是溝通協調就是一大挑戰。秉持著和時間賽跑救人的理念，佩德羅靈機一動，想到用敏捷的方式，管理這個即刻救援的大型專案。他把軟體敏捷團隊常用的Scrum Framework稍做微調，當成大家做事的框架：

• 原本最長30天1期的開發周期(稱為Sprint)，縮短1天就是1期
• 每天舉行3次站立會議(Stand-up Meeting)，讓團隊成員間匯報進度，並設定未來8個小時的優先目標
• 用看板(Kanban Boards)顯示工作和進度，讓成員自己挑任務，不必等人指派
• 由於成員眾多，為了避免亂槍打鳥的大鍋炒會議，團隊和團隊之間的溝通，透過Holacracy的雙向連結方式，各派一員代表團隊溝通，促進快速達成決策

        另外，夜以繼日的趕工，讓很多人累到睜不開眼睛，一群義工們二話不說，現場就幫夥伴們「馬一節」，成為專案溫馨的插曲。

摘自Chile Ayuda網站影片

        這個即刻救援的大型團隊，當時雖然不受外界看好，還受到政客試圖插花作秀的壓力，但透過敏捷的工作方式，只花了6個工作天，就做出Chile Ayuda入口網站，也整合了Google Person Finder、Twitter stream和Facebook的App，即時幫3500名受災者找到親友，專案的Facebook專頁迅速累積了150,000 名粉絲，成為敏捷救人的知名案例。

畫面取自 http://www.chileayuda.com/

(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®，以及台灣、中國兩地首位專案風險管理師PMI-RMP®)

親愛的，我們家變敏捷了

(圖片取自Bruce Feiler個人網站)

徐柏峰

對從事文字工作的人來說，如果能寫出一本書登上紐約時報(New York Times)暢銷書排行(Best Sellers)，這輩子就已經揚名立萬了，如果能夠寫出好幾本暢銷書，後半輩子就有接不完的通告，跑不完的演講。已經達到這個境界的美國名人布鲁斯．法伊勒(Bruce Feiler)，頂著暢銷作家的光環，既主持節目，又在紐約時報擔綱寫家庭版專欄，上有高堂下有一雙稚女的他，深感要在這個時代當爸媽，壓力實在太大，因此他花了3年的時間，跑遍大江南北，走訪很多專家學者，希望求得讓家庭快樂美滿的妙方。在偶然的機會下，布魯斯聽說有1位宅爸肩負全家6口的經濟重擔，家裡有4個正在「轉大人」的小孩，其中有1個是自閉症，還有1個是過動兒，但全家在混亂中透過另類的方式運作，孩子們會自動自發管理自己，不必爸媽操心。布魯斯既羨慕又驚奇，決定一探究竟，經過一番訪查後發現，原來宅爸是非常熱愛工作(或說中毒很深)的軟體工程師，竟然把全家老小編成「家庭團隊」，把親子關係當成專案來管理，宅爸把公司開發產品專案的遊戲規則拿回家用，這套方法就是敏捷式專案管理！

        學國際關係出身的布魯斯，立刻決定發揮跨界精神，把宅男宅女管理軟體專案的方法學起來，拿自己的妻小來做實驗，研發讓家庭和樂融融的密技。布魯斯沒有花大錢請顧問來做AS IS TO BE分析，而是把老婆小孩集合起來，先土製了一個簡易看板，全家一起規劃每日待辦工作清單(Morning Checklist )，接下來的每1天，2個女兒每天對著工作清單，做完1件就自己消掉1件，這樣過了1個星期，家裡吼小孩的聲音頓時減少了大半，受到這個實驗成功的激勵，布魯斯這一家人又把敏捷的定期展示會議，改造成家庭會議(Family Meeting)，還參考敏捷軟體開發宣言，制定了自己的敏捷家庭宣言(Agile Family Manifesto)。布魯斯後來把自己家裡導入敏捷方法的點點滴滴，彙整成上百個最佳實務，寫成1本《快樂家庭的秘密》(The Secrets of Happy Families)，這本書推出沒多久，就登上紐約時報暢銷排行榜前5名，也幫布魯斯寫下10年內連續6本書上榜的紀錄，也成為敏捷最另類的導入案例。
(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®，以及台灣、中國兩地首位專案風險管理師PMI-RMP®)

敏捷專案管理: 素人造車的故事 WikiSpeed

徐柏峰

圖片取自 WikiSpeed 網站

汽車排放的廢氣，一直是溫室效應的元兇之一，國內外很多汽車製造大廠，都投入開發低油耗、低排放的環保節能車，希望能在市場上攻城掠地。2012年8月間，美國政府宣布未來的車輛平均油耗標準 (Corporate Average Fuel Economy Standards, CAFE)，要求汽車業者出廠的家用車，在2025年前要達到每英里54.5加侖(miles per gallon, MPG)，相當於加1公升的油要能跑23.17公里(Kilometers per liter, KPL)的水準。用風險管理的術語來說，如果業者能提前做出新產品，符合這個未來法規的要求(Regulatory Compliance)，就是一個創造買氣的正面機會，如果業者反應慢半拍，不能快速推出新產品，這就是一個負面威脅了。對汽車製造業來說，推出新車就是一種改變，不過既有改變流程非常緩慢，從企劃、研發到生產，每個階段都是以年為單位，等到成品銷售到客戶端，收到回饋意見，已經過了好幾年。因此有人比喻說，如果有設計工程師想改門的規格，要花上10年，等到投資在舊門模組生產線的1億美元都回本，才能再做下一個。[1] 如果您在汽車大廠的明日之星，奉高層指示，需要帶隊開發1輛油耗 100 MPG (42.51 KPL)、5秒加速到100公里、極速239公里的原型車，您覺得要花多少時間呢？有人用敏捷專案管理法，3個月就做到了！

2008年間，美國知名汽車保險公司(Progressive Insurance)主辦了一場汽車設計大賽，祭出總獎金1億美元，吸引各方車壇好手，打造「油耗100 MPG而且真的能開上路」的原型車。當時一名叫做Joe Justice的年輕人，決定投入這場賽事，起初他孤軍奮戰，拼裝出一個不是很理想的雛型，達不到比賽的高規格，來自軟體業的他並不氣餒，決定用開放原始碼(Open Source)的方法，在部落格上詳述自己閉門造車的過程，廣召有志之士共襄盛舉。Joe的熱血打動了很多網友，不到幾天的時間，Joe從「撞鐘的校長」，升格為Team Leader，帶領來自4個國家的44名志工，以WikiSpeed為隊名，向100 MPG的方向邁進。

當時WikiSpeed這一隊，既沒有財團挹注、也沒有知名大學的研究資源，更慘的是，Joe從學校畢業以後，一直待在軟體產業用敏捷開發法工作，對於怎麼憑空造出一輛車，根本就沒有頭緒。個性樂觀的Joe，索性把出社會以來學過的所有敏捷「招式」，全部用在WikiSpeed這個專案上。

第一，Joe採用Scrum框架，以7天為1個衝刺期，每隔7天他就召集WikiSpeed的團隊成員，檢視大家共同開發的實際成果，並決定未來7天需要修改或是新增的部分。

第二，X-Prize主辦單位強調，參賽車都要符合道路安全規定，針對這個需求，Joe二話不說，用User Story搭配測試驅動開發(Test Driven Development, TDD)來解決。當時他在一張便條貼上寫道：身為一個使用者，我開的車子二氧化碳排放要低於每100公里100公克，如此一來我才能減少氣候變遷(As a user I can drive a car emitting less than 100g of CO2 per 100km driven so that I can reduce climate change)。為了滿足這個需求，WikiSpeed團隊DIY了一個測試儀器，先從達不到排氣標準的案例開始測試，然後邊做邊改，做出符合大會排氣規定的版本。[2]

第三，極致開發法(Extremely Programming, XP)知名的配對工作(Pair Programming)，在Joe的團隊發揮到淋漓盡致。在WikiSpeed專案中，團隊謹守「2個臭皮匠勝過1個諸葛亮」的心法，所有的工作都是2人1組，執行工作時都是邊做事邊說話，一方面腦力激盪，也讓彼此都能掌握技術細節，省掉傳統開發流程中先寫詳細文件再開會說明的時間。

第四，WikiSpeed雖然是跨國團隊，溝通效率卻出奇的好。Joe深知可見度(Visibility)在團隊開發中的重要性，因此他在工廠裡面放了一大面白板，貼上專案開發的願景和里程碑，讓團隊成員抬頭就看到為何而戰，同一面牆上也用便條貼組成產品功能清單(Release Backlog)和本期功能清單(Iteration Backlog)，讓大家知道彼此正在做什麼、還要做什麼、有什麼問題，以及做完了什麼。這個直覺的作法，正是精實(Lean)專案管理教科書上鼎鼎有名的看板(Kaban)。另外，因為WikiSpeed成員橫跨多個國家，不能隨時見到面，因此Joe也利用社群網路聯繫團隊，透過雲端儲存空間交換文件電子檔，充分做到溝通無障礙。

圖片取自 WikiSpeed 網站

在Joe的熱情鼓舞下，WikiSpeed這支汽車製造業者眼裡的雜牌軍，用敏捷拼盤的作法，在3個月做出一輛原型車，竟然拿到X-Prize主流汽車類的第10名，把一百多家各國汽車廠和知名大學團隊甩在後面，跌破很多專家眼鏡。X-Prize這一仗聲名大噪後，WikiSpeed團隊受邀在2011年參加北美汽車大展(North American International Auto Show)，主辦單位把他們的車子放在主樓層展示，位置排在福特和雪佛蘭的中間，讓他們出盡了鋒頭，而探索頻道(Discovery Channel)、紐約時報(New York Time)和國家地理頻道(National Geographic Channel)這些主流媒體，都爭相報導這個敏捷團隊素人造車的故事。

圖片取自 WikiSpeed 網站

(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®，以及台灣、中國兩地首位專案風險管理師PMI-RMP®)

---

[1] Steve Denning, Wikispeed: How A 100 mpg Car Was Developed In 3 Months, Forbes, http://www.forbes.com/sites/stevedenning/2012/05/10/wikispeed-how-a-100-mpg-car-was-developed-in-3-months/

[2] TDD for Hardware, 請參考 http://wikispeed.org/2013/07/tdd-for-hardware/