10分鐘讀懂Scrum與敏捷軟體開發入門／Yves Lin

江湖上軟體開發有兩個大門派，第一個門派是以流程為主軸的「瀑布式開發」，另一個門派在1990年代異軍突起，稱為「敏捷式開發」，其中最知名的武功就是Scrum； ... OpeninappHomeNotificationsListsStoriesWritePublishedin吐納商業評論|TunaBusinessReview10分鐘讀懂Scrum與敏捷軟體開發入門／YvesLin江湖上軟體開發有兩個大門派，第一個門派是以流程為主軸的「瀑布式開發」，另一個門派在1990年代異軍突起，稱為「敏捷式開發」，其中最知名的武功就是Scrum；本文以深入淺出的方式，為讀者介紹Scrum的基本概念。

敏捷黑手阿伊／YvesLinTryingbeingagileinthefunway.喜歡並相信敏捷開發，期許能帶入一些不同的思維，能讓華語圈不只軟體產業，其他產業也都可以更敏捷。

tuna.to江湖上軟體開發有兩個大門派，第一個門派歷史跟軟體一樣久，心法是以流程為主軸，正式名稱瀑布式開發（Waterfall），最具代表的武功就是CMMI，幾年前台灣政府大力推動支持。

另一個門派在1990年代異軍突起，心法是以人為主軸，正式名稱為敏捷式開發（Agile），最知名的武功是Scrum，但在台灣則是這一兩年才開始熱門起來。

（註：Scrum的原始意思是橄欖球的爭球動作，在軟體界沒有翻譯成中文，都是直接叫Scrum）兩個門派最大的不同在中心思想，用中國的哲學流派來比喻，瀑布式開發是法家，法為主、人為輔，強調「不別親疏，不殊貴賤，一斷於法」；只要規則定下去，照著做就會有好產品。

所謂「鐵打的營盤，流水的兵」，人的因素要盡可能排除，以利於產出的一致性。

而敏捷式開發是道家，人為主、法為輔，主張「道法自然」。

道沒有一定的形式，要觀察目前的情境、考量人的天性，因勢利導，以求功成事遂，百姓皆謂我自然。

總之，敏捷式軟體開發門派更注重在人的層面，講求的是「快速從經驗中學習反應」和「團隊的自我管理」。

而比起其他的武功如「看板」或「極限開發」（XP），Scrum這套武功之所以更有名，是因為一般認為它比較容易導入或入門。

因為Scrum裡角色和活動定義明確，又不提技術細節，讓不懂技術的老闆也可以聽懂（技術活也是很重要滴，請參考XP）。

很多堂口導Scrum就落入了「做敏捷，而不是變敏捷」的陷阱；如果組織已經在跑敏捷，可以看看這份清單，確認一下是真敏捷、還是拜飛機式的敏捷。

如果還沒導入，恭喜你，可以先考慮Scrum會帶你上天堂還是地獄，並可參考Scrum不包生導入指南，還有破除「敏捷=快」的迷信。

Scrum中的角色Scrum只有三種角色，至於其他角色如部門主管在Scrum框架外裝作看不到不討論。

所有成員都要抱持敏捷的精神和態度。

DevelopmentTeam（DevTeam，開發團隊）可以獨立完成任務的特種部隊，人數5–9人（7±2）。

大絕是我決定該怎麼做（How），武器是自我管理和持續改善的能力。

每個人都有自己的特長，但依任務需求自行安排工作內容。

類似射雕英雄傳裡全真七子所部的天罡北斗陣，如任一人受敵時，左右會來相救。

ProductOwner（PO，產品負責人）產品的守護者；大絕是要做什麼我說了算（What），武器是敏銳的市場嗅覺的和擺平利害關係人。

如同射雕英雄傳裡北極星位對天罡北斗陣的影響，當郭靖站到了北極星位就可以驅動全真七子。

PO要決定產品的規劃和為產品的成敗負責，可以參考一些PO常常絆倒的地方。

ScrumMaster（SM，無中文名稱）Scrum功夫的傳道者；唯一的大絕是影響力，武器是異於常人的信心與耐心。

有人覺得他是TeamLead或是PM的角色。

但其實他沒人事權，不能管人；沒財務權，不能編預算。

更可憐的是，他不能決定產品的走向，所以是個令人摧心的角色。

最常見的安排是PM直接轉ScrumMaster，或是主管自己跳下來兼ScrumMaster，會把ScrumMaster絆倒的地方也不少。

以上三者又統稱ScrumTeam或Team。

Scrum中的物件Scrum中常會提到的物件與中文名稱如下：Item（物件）又稱Story，是PO定義的產品產出。

Item大小要講究，要可以讓團隊在一般的速率下，可以完成3–5個。

太多太繁雜，太少萬一沒做完就感覺整個Sprint一事無成，對團隊信心是個打擊。

Task（工作）是DevTeam針對Item（不是PO也不是SM）列出完成Item所需的工作；工作分配則是開發團隊自己安排。

ProductBacklog（產品待辦清單）由PO負責整理的產品願景圖，以Item為單位，施工順序由上而下。

SprintBacklog（衝刺待辦清單）DevTeam向PO承諾這個Sprint會盡力完成的ItemList；以Task為單位。

PotentiallyShippableProductIncrement（潛在可交付產品增量）開發團隊的產出，簡單的說就是PO說要上線就可以馬上上線的東西才算數。

BurndownChart（燃盡圖）有點類似怪物的血條，看看還剩多少血怪（SprintBacklog）才死。

以Task大小為單位。

Scrum活動每一個Scrum活動都有其目的和時間限制（TimeBoxed）。

主要活動如下：Sprint（衝刺）顧名思義，當團隊決定要哪些Item後，就著手去衝。

Sprint長度定義上是1–4個禮拜，但實務上不要多過2個禮拜。

而且Sprint長度應該要保持穩定盡可能不變。

這樣才容易讓團隊掌握節奏，也容易預估和比較Sprint內的工作量。

大原則是Sprint內的SprintBacklog不改變（有原則就有例外）。

DailyScrum（每日站立會議）每天10–15分鐘不能超時，目的是讓團隊資訊同步。

一定要站著罰站為了讓大家長話短說。

SprintPlanning（衝刺規劃會議）Sprint開始時，討論一下這個Sprint團隊可以交付哪些Item。

Item優先順序PO決定，要選多少Item由DevTeam決定。

ProductBacklogRefinement/PBR（產品待辦清單精煉會議）PO跟Team一起討論近期內會開始施工的Item，主要是從商業和使用者角度切入，盡可能不觸及技術細節。

SprintReview（衝刺檢視會議）Sprint結束時針對產品的會議，PO邀請利害關係人對產出給意見，是要可用的軟體才算產出。

不準備PowerPoint或其他簡報，單純就軟體操作取得回饋。

SprintRetrospective/SprintRetro（衝刺回顧會議）我偏好稱這一項為「自省」會議。

在SprintReview後，ScrumTeam成員（DevTeam或包含PO）針對這個Sprint團隊的工作模式討論改善，並定出下個Sprint改善事項。

為了創造一個安全的環境，原則上只有團隊成員才能參加。

Scrum是個易學難精的架構，導入一個月就似模似樣入門了，但背後的精神如團隊自我組織、持續改善要數個月到數年才能見效。

持續學習是必要的。

Scrum的架構適合一個產品配合1–3個開發團隊。

如果一個產品需要更多人打群架，有兩套基礎於Scrum的終極陣法，一套是同樣以人為本的LeSS（LargeScaleScrum），另一套是加入流程控制的SAFe（ScaledAgileFramework）；可以參考LeSS和SAFe的比較，和兩者運用組織權力的差異。

本文作者近期出版關於敏捷變革的譯作。

本文已獲作者授權並經本站重新編輯，未經書面許可禁止轉載。

本站文章提供付費授權轉載或出版，請參閱授權說明、或來信[email protected]洽詢。

如果您喜歡這篇文章，請多按下方的「拍手」圖像幾次、或是分享到社群網站上！Morefrom吐納商業評論|TunaBusinessReviewFollow以科技產業、管理、數位媒體出版等主題為核心，由多位資深產業作者撰稿、並授權編輯與刊登的原創共筆網站。

主站已搬遷至http://tuna.mba，歡迎參考。

Readmorefrom吐納商業評論|TunaBusinessReviewAboutHelpTermsPrivacyGettheMediumappGetstarted吐納商業評論6.7KFollowers以科技產業、管理、數位媒體出版等主題為核心，由多位資深產業作者撰稿、並授權編輯與刊登的原創共筆網站。

FollowMorefromMediumJuanManuelAgileScrumMasterbyJimSullivanfromLearnQuest—ScrumBasics(week1)NagarjoonBNailyourAgileScrumprojectswiththerighttoolsforthejobCentredgeServicesPvtLtdImplementingAgileinBidandProposalsSalvatoreRinaldoinBeyondValueDemo,noreviewHelpStatusWritersBlogCareersPrivacyTermsAboutKnowable