2015/3/6 「Scrum敏捷開發術」

大師NO.579

Scrum敏捷開發術

更快、更有效的專案管理方式

摘錄自：大師輕鬆讀電子報                        2015/3/6

面對快速變化的時代，你需要反應快、行動狠、判斷準的工作團隊。為此，你必須賦予團隊明確的方向、充分的自主權，讓他們隨時保持高昂的士氣、靈活的身手，在場上奮力爭球、漂亮得分。而這套帶領團隊有效執行專案的戰術就叫作Scrum。

作者 :

傑夫．蘇瑟蘭

原文書名

Scrum

The Art of Doing Twice the Work in Half the Time

原文書特色

★ Twitter 首席技術長Adam Messinger、精實創業提倡者Eric Ries 等名人推薦

★《出版者周刊》、《成功雜誌》等媒體好評推薦

本期目錄

主題看板 Scrum 團隊快、狠、準

Part 0 引言

Part 1 問題——傳統計畫行不通

Part 2 解決方案——Scrum：更好的計畫方式

Part 3 Scrum 為何有用——用Scrum 擬定計畫的優點

延伸閱讀 用對方法好研發

Scrum團隊快、狠、準

1910年左右，哈利．甘特（Harry Gantt）研發出甘特圖，以橫軸表示時間，縱軸表示活動項目，再以各種顏色的線條呈現各項活動的預定進度與實際進度，讓相關人員透過容易理解的圖形，對整體計畫的活動狀況一目了然。

但是甘特圖明顯著重時間管理，無法有效表現專案成本及範疇的特性，在管理上確實有不足之處。當計畫較為複雜，每項作業之間關係過多，紛雜的線條勢必增加甘特圖閱讀的困難度。再加上活動項目產生異動或時程延宕，即使有專業軟體工具可以立即重新繪製圖表，也仍舊無法彌補它的局限性，反而更加突顯現實環境中計畫往往趕不上變化的窘境。

更好的專案管理方式

那麼，還有其他更好的專案管理方式嗎？本書作者傑夫．蘇瑟蘭在1990 年代初期也在思考這個問題。並於1995 年在計算機協會（ACM）的年度會議Oopsla 與肯．施瓦伯（Ken Schwaber）共同發表〈Scrum 軟體開發程序〉，提出更具彈性及可行性的專案管理方式。

Scrum 是橄欖球術語，指比賽過程中的爭球儀式。是沿用日本商學院教授竹內弘高與野中郁次郎1986 年發表的〈新產品研發的新賽局〉提出的概念。該文中以橄欖球為例，強調團隊在新產品開發的重要性，主張一個傑出的團隊需要被賦予的是目標而非任務。你只要給他們方向，並授與自主權，讓他們可以自行決定自己如何朝目標推進，他們便能完成卓越的表現。

這個主張在面對快速變化及高度不確定的狀態下尤其受用，因為你面對的是未知大於已知的領域，變動是常態，應變才是王道。按邏輯推理而來的完美甘特圖明顯不切實際，通過實際驗證及不斷修正才是你最好的靠山。Scrum 的誕生無疑是呼應時代需求而來。

更好的團隊協作模式

Scrum 強調高度透明及密切的日常協同作業，而這也正是Scrum 看似簡單實則不易的關鍵所在。因為習於從上而下接受命令與控制的工作習性並不會一夕改變，強調透明的作業模式也可能形成莫大壓力。

當每個人都知道誰負責什麼，以及何時完成。每日站立會議的3 個問題：「你昨天達成什麼？」、「你今天會做什麼？」及「你遇上什麼困難？」可能更快暴露出專案規畫、團隊構成、管理甚至個別能力上的缺陷。因此真的能貫徹到底的Scrum 團隊並不容易。

如今Scrum 已被公認為最具實用性的軟體開發框架，運用範疇也從軟體開發擴大到製造、行銷、營運及教育等其他領域。它提供的不只是一項應用於新產品開發的專案管理工具，同時也是一種團隊協作的模式及團隊經營理念。如果你常覺得專案執行不力，或許Scrum 敏捷開發術正是你需要的處方。

2015/3/6 「Scrum：更好的計畫方式」

新刊掃描

Scrum：更好的計畫方式

摘錄自：大師輕鬆讀電子報                        2015/3/6

Scrum建立在一個簡單的核心概念。展開專案時，應該定期和終端用戶溝通，確認你做的東西是他們真正想要的東西。Scrum的基本精神是，不斷確認自己正朝著正確方向前進，在此同時，也要尋找能把事情做得更好、更快的方法。

展開Scrum專案的方式如下：

組織：挑選產品負責人

每一個Scrum專案都需要一位產品負責人。此人必須明確理解你想做或想達成的事。

產品負責人必須持續更新待辦事項，依序排列團隊要達成的事項。他或她要為專案在價值創造上的成敗負責。優秀的產品負責人必須懂商業案例、市場與顧客，而且要隨時讓每一件事朝著正確方向前進。這是一個繁重的角色，但這是Scrum 方法的基本面向。

預想：擬定產品待辦事項

■建立路線圖

■依據價值排出順序

■改善與評估整體專案

產品待辦事項列出重要事項，寫下如果要讓願景成真，一定得做的每一件事。產品待辦事項將存在整個專案期間，而且會隨著時間變化與演進。那是每一個人都了解並使用的路線圖。

產品待辦事項是一張明確的清單，它根據附加價值的多寡，依序排出需要完成的事項。產品負責人與利害關係人及Scrum 團隊成員溝通，負責維護這張清單。至關重要的是，產品待辦事項只能有一個版本，而且每個人都清楚上面有什麼事項。

開發：進行衝刺

■計畫

■動手做

■展示或檢討

■分析與學習

團隊成員、Scrum隊長以及產品負責人聚集一起擬定衝刺計畫。衝刺有固定的時間長度，不超過1個月。多數的Scrum專案通常使用1周或2周的衝刺，這是目前為止在專案執行上證實最有效的長度。

調整：讓使用者試用產品

■得到使用者回饋

■將使用者心得納入產品待辦事項

■更新與演進

讓顧客在產品研發過程中就獲得實作經驗，乃是Scrum的重要關鍵特色之一。顯然那些早期顧客看到的東西，不會是你的完美成品，他們看到的是早期原型——你的最低可行產品（MVP）。

那沒關係。這樣可以阻止你朝錯誤方向前進，讓你不會最後研發出沒人想要的東西。

問顧客他們想要什麼，然後依照意見確實做出來，這聽起來不是什麼劃時代的概念，然而大多數的研發專案都不是如此。大部分時候，開發者會執著於在一切都大功告成之後，才讓顧客一窺產品。那有風險，因為你是在燒光自己的資源後，祈求一切順利。Scrum的方法則是先行取得早期回饋，顯然更有成效。

Scrum的設計使你能讓團隊在幾天內就開工。找出待辦事項，計畫第一次衝刺，然後就上路了。你不需要花很多的時間擬計畫、深思熟慮、寫任務說明或5年預測。這些都留給競爭者去做，讓他們吃你灰塵，永遠跟不上你。

【以上內容摘自最新出版的《大師輕鬆讀》NO.579 Scrum敏捷開發術】

2014/11/28「眼看著專案進度延遲，如果你增加更多的人手，結果是……」

管理在線

眼看著專案進度延遲，如果你增加更多的人手，結果是……

摘錄自：經理人月刊 電子報                        2014/11/27

2014年11月11日

整理 / 文及元

《鄉民都來了：無組織的力量》《下班時間扭轉未來》一書作者克雷．薛基（Clay Shirky），目前任教於紐約大學互動電訊計畫（Interactive Telecommunications Program），他針對網路世界對社會與經濟層面，特別是社會和科技網路交集帶來的影響等議題，進行寫作、教課與顧問。

11月9日，薛基於 g0v Summit台灣零時政府年會中發表基調演講（keynote speech）。薛基從三個方向切入，探討政治運動和軟體開發都會遇到的「規模」（scale）問題，分別是：

1.模組化（Modularity）；2.串聯（Bridging）與黏附（Bonding）社會資本（social capital）；3.共識（Consensus）與決斷（Decisiveness）。

 如果你曾經好奇「為什麼人愈多，好像愈難溝通合作？」，薛基指出，答案就在下圖：

他認為，所謂政治，就是讓人們達成共識。上圖的藍圓點代表「人」、綠色線代表「共識」，共識就是指任兩個人之間需要一組共識。如果2人要達成共識，需要1組共識、3人則需要3組、4人需要6組、5人就需要10組，以此類推。當你有 10 個人的時候，就有 45 條線（需要 45 組共識）。薛基指出，這也是為什麼我們高中的經驗是正確的：當一個團體的人愈多，就愈難讓新成員加入。原因在於「團體」代表其中的每位成員都認識彼此，所以 N 個人，就需要 N+1 個關係。

福雷德里克．布魯克斯（Frederick P. Brooks, Jr.）在《人月神話》一書中，提到他觀察 IBM專案：專案交付日期總是拖延，所以 IBM 就雇用更多人「讓事情加速」，但是，根據布魯克斯的觀察，這樣的做法卻總是讓事情更慢。這就是布魯克斯定律（Brooks’s law），意指「在一個已經延遲的專案上，如果你增加更多的人手，反而只會讓專案進度更慢」，原因就在於溝通的成本太高。

薛基認為，模組化可降低規模成形之後的溝通複雜度。從事政治運動必須從累積「黏附社會資本」（Bonding social capital），過渡到建立「串聯社會資本」（Bridging social capital），並當群體快速成長後，在「凝聚共識」以及「少數人為多數人做決定」中取得平衡，而其中關鍵在於「互相照顧」 （Taking care of each other），了解彼此的需求，才能真正發揮影響力（請參考基調演講中英文對照）。

善用開源（open source）、群眾外包（crowd sourcing）

此次邀請薛基來台演講的g0v台灣零時政府，創立於2012年，11月8 ～9 日在中央研究院首度舉辦g0v Summit台灣零時政府年會，以公民科技（Civic technology）、開放政府（Open government）為主題，為期兩天的年會主題涵蓋開放國會、參與式民主、公民新科技、開放資料與環境到新媒體運動和媒體曝光下的學運大會，從多元面向探討利用科技與開源精神改變社會的可能。

年會邀請來自九國的國際講者，以及國內政府及非政府組織、學界、媒體及資訊好手，針對八大主題舉行共29場的演講與座談，兩天活動共吸引超過600位民眾參與。來自加拿大、美國、德國、紐西蘭、智利、韓國等九國長期關注開放政府運動的國際講者，來台分享在推動開放國會、組織群眾運動的努力成果。

其他精彩議程還包括「跨世紀學運論壇」，討論主流媒體與新媒體之間的交互作用，以及在抗爭運動中扮演的角色及未來展望。 除了主題議程之外，延續社群舉行黑客松（Hackathon）傳統，年會第二天舉辦全天的 Unconference 開放工作坊，由參與者提案決定議程內容，以演講、討論、自由對話等各種形式激盪、創造出的專案。

g0v.tw 台灣零時政府善用開源與群眾外包，首度舉辦的年會創下三大特色：

1.工作人員超過 100 人，全數皆為志工。無論是來自九國的國際講者，還是國內講者，都是無酬受邀來演講。

2. 年會志工來自各行各業，年齡層橫跨 18 歲到 50 歲，在長達五個月的籌備期間，90% 以上時間使用網路及軟體進行溝通與合作。

3. 開放透明、協作與共享是 g0v.tw 台灣零時政府社群的核心精神，兩天議程內所有演講內容、討論成果與文字照片，以共筆方式完成，讓所有活動參與者都能成為貢獻者。

 （資料與圖片來源：g0v.tw 台灣零時政府）

2014/10/24「別光喊冤，你的專案要裝「行車紀錄器」！」

管理在線

別光喊冤，你的專案要裝「行車紀錄器」！

摘錄自：經理人月刊 電子報                        2014/10/23

作者 / Bryan Yao

前兩天跟老爸吃飯，他跟我抱怨有次和幾位朋友去聚餐，點了菜之後足足等了40分鐘才上第一道，老人家反正聊天聊得開心，也不以為意，但沒想到上第二道菜的時候（又過了10分鐘），服務生竟過來「善意提醒」：本店用餐時間一律90分鐘，請問還需要加點的嗎？結果眾家杯杯們當場傻眼！接下來就是一場七十歲老人們跟十七歲工讀生間的隔代交鋒，在此也就不多提了！

為什麼英文中最後期限要叫作Deadline？Dead + LINE？我也不知，但凡是有限時的東西總是讓人特別在意，有時更會讓人緊張得要「死」。有專案經驗的朋友，尤其是從事過委外專案（非公司內部專案）的人，相信都會認同這句「Deadline不留意，急起來要人命！」因為在很多合約當中，專案逾期往往代表著可觀的罰款，像是公共工程合約規定，承包商每延誤一天完工，就得罰合約總價的千分之一，假設總經費一億元的案子，一不小心延誤個10天，100萬就這麼不見了。很多案子在最低標的制度下原本已是微利，一億的案子能否賺500萬都是問題，難怪不時聽到有些廠商眼看追不上進度了，乾脆尾款也不要了，直接落跑先！

不過這類型的專案，往往有非常多的廠商共同參與，也有很多工作是業主自己負責執行的（好比制定規格、審核文件等）。因此當專案進度落後時，到底是誰的責任就變得很重要。否則就像布爸的聚餐一樣，明明上菜慢吞吞，卻要人客大口吞，這實在是not fair啊！事實上，在專案管理中有個領域叫作專案排程（Project Scheduling）就是在處理這類的爭議。通常專業的PM會採用Microsoft Project或是Oracle P6這類電腦軟體來進行進度追蹤。

一般人以為排程軟體只是用來排定工作計畫，事實上，它們更關鍵的角色是扮演專案的「行車紀錄器」，把專案執行的過程忠實地記錄下來，萬一爭議發生（我的經驗是大專案幾乎都會發生），就可以調出「監視器畫面」來釐清責任。我有個客戶是承包商，原本因為工程延誤被業主要求罰上千萬，後來就是透過「專案紀錄器」澄清了自己的責任，不但不用賠款反倒還有盈餘。這也就是為什麼在國外所謂的時程工程師薪水都不低的原因。

這裡舉個簡單到不能再簡單的例子來說明一下這個概念。

假想一下，你是位勇猛而且有人魚線的台灣水電工，客戶要求你和設計師配合，在7/10號前完成一個案子。客戶因為剛考上PMP，特別喜歡玩新花樣，所以在合約裡加了一條慘絕人寰的罰則：如果專案無法在10號前準時完成，每延誤一天就要彈10下耳朵，而且是很用力的那種。和你合作的設計師說她只會畫圖不會排時程，加上她長得很像郭雪芙，所以你就花了兩天排了以下的schedule：

上面這圖你應該看得懂（因為這就是你排的），這專案總共有兩個工作，首先郭雪芙，不是，是設計公司要完成設計（5天），然後換你接手進行施工的動作（也是5天）。照計畫是1號開始，所以預計是10號可以完成。其中藍色的垂直線叫作資料日期，代表這份schedule是在1號的狀態！

美好的時光總是特別快，事實上是出乎意料的快，當你和正妹設計師準備開啤酒慶祝完工時，日子已經來到了12號，也就是說，你比當初承諾客戶的Deadline足足晚了兩天。這時候客戶早已面露奸笑緩緩走向你，並將拇指和食指彎成一個圈，準備好要彈人的手勢了！

你腦海中立刻浮現出一個疑問：是該讓他彈左邊還是右邊呢？當然不是，真正的問題應該是，這20下彈耳朵酷刑真該是我這個勇猛又有人魚線的水電工要扛的嗎？你想起李組長曾說過，這案情並不單純。事實上以這個個案，至少有三種可能的偵辦方向，來，我們繼續看下去！

情況一：設計師造成延誤

上圖代表著專案到了12號時的狀態，我們可以看到代表資料日期的藍線移到了12號的地方。另一個觀察的重點是黃色細桿，它們代表原本預期的時程，也就是所謂的基線（Baseline）。而深藍色的粗桿則代表工作實際執行的狀況。這個圖明顯地呈現一件事情，就是設計師的工作原本應該在5號完成（看黃桿），實際上卻到7號才完工（看藍桿），共延誤了2天。而你，也就是水電工是「被迫」比原定晚2天開始，但你仍維持5天做完，所以最後雖然專案延誤兩天，但顯然人不是你殺的。雖然有點不捨，但該被彈20下耳朵是正妹設計師才對！

情況二：水電工造成延誤

這是你最不想看到的情況。上圖很明顯地告訴我們，設計師的工作完全符合原定計畫，藍桿和黃桿是完全重合的，至於你自己施工部分則足足花了7天才完成，也因此造成整個專案2天的延誤。所以這20下彈耳朵無疑地該由你獨享！

情況三：設計師、水電工一人一半

經過上面兩種情況的訓練，這張圖應該很容易理解。也就是設計工作和施工各自比計畫延誤1天，所以這20下彈耳朵的處罰理應由兩人分擔，一人10下！相同的結論我們也可以用下面表格的方式呈現：

【設計】和【施工】這兩個工作。原來的計畫工期都是5天，但實際工期卻增加到6天，所以在「差異」這行數據各自顯示有「-1」天的延誤。

值得一提的是，在實際的商業環境裡，業主的懲罰不一定是硬梆梆地依據上面這些排程的結果來進行，就像情境一，大家可能都捨不得真的去彈正妹20下耳朵一樣（當然大家搶著去彈也是有可能）。畢竟真的去嚴懲承包廠商通常不是業主的本意，業主最希望的還是專案如期完成。

不過這樣的分析數據仍然是極重要的「談判籌碼」，比如說，當專案延誤，客戶要求你加班趕工時，你可以把這份時程拿出來，瀟灑帥氣地告訴客戶：我可以替你趕工，但既然延誤不是我造成的，所以你要給我適當的補貼（或者欠我一個人情）！這就像是行車紀錄器的作用，當發生問題時，至少可以用來保護自己的權益，尤其遇上「助跑姊」這種惡質的廠商時！

如果你的專案涉及多家廠商、合約有懲罰條款、或者你純粹覺得身為PM的專業度很「虛」，不妨認真考慮學習排程和專案控制的技術。

後記：

為了幫助大家理解，本文用了十分簡化的案例。或許有讀友會質疑，真正簽約時設計師和施工部分可能是兩個分開的合約，各自有各自的deadline要遵守。但我這裡想表達的是，專案通常牽涉到多個主體，而且彼此間的工作是相互交錯的，唯有利用完整的時程追蹤才能釐清各自的績效和責任。

本文獲「專案管理生活思維」授權轉載，原文於此。

【作者簡介】Bryan Yao

西北大學專案管理碩士。目前為識博公司合夥人與紐約市環保署顧問。喜愛的電影是Pulp Fiction，喜歡的樂團是Linkin Park。座右銘是Steve Jobs的Stay hungry, stay foolish!

圖片來源 / /\/\ichael Patric|{ via Flickr, CC Licesned