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敏捷開發術】

2015/3/6 「為什麼我們要Scrum？」

編輯小語

為什麼我們要Scrum？

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

Scrum的功能是召集團隊做出好東西，要做到這一點，每個人不僅都得看到最終目標，也得漸進朝目標走。我們太常聽到這種故事：某個大型專案花了數百萬美元，結果計畫中止，原因除了成本超出預算，還因為計畫根本行不通。你有多少的人生，浪費在你和老闆都知道不會創造價值的事情上？