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

江湖上軟體開發有兩個大門派,第一個門派是以流程為主軸的「瀑布式開發」,另一個門派在1990年代異軍突起,稱為「敏捷式開發」,其中最知名的武功就是Scrum;本文以深入淺出的方式,為讀者介紹Scrum的基本概念。

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

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

註:Scrum的原始意思是橄欖球的爭球動作,在軟體界沒有翻譯成中文,都是直接叫Scrum)。

兩個門派最大的不同在中心思想,用中國的哲學流派來比喻,瀑布式開發是法家,法為主、人為輔,強調「不別親疏,不殊貴賤,一斷於法」;只要規則定下去,照著做就會有好產品。所謂「鐵打的營盤,流水的兵」,人的因素要盡可能排除,以利於產出的一致性。

而敏捷式開發是道家,人為主、法為輔,主張「道法自然」。道沒有一定的形式,要觀察目前的情境、考量人的天性,因勢利導,以求功成事遂,百姓皆謂我自然。

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

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

因為Scrum裡角色和活動定義明確,又不提技術細節,讓不懂技術的老闆也可以聽懂(技術活也是很重要滴,請參考XP)。很多堂口導Scrum就落入了「做敏捷,而不是變敏捷」的陷阱;如果組織已經在跑敏捷,可以看看這份清單,確認一下是真敏捷、還是拜飛機式的敏捷。

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

Scrum中的角色

Scrum只有三種角色,至於其他角色如部門主管在Scrum框架外裝作看不到不討論。所有成員都要抱持敏捷的精神和態度

  • Development Team(Dev Team,開發團隊)

可以獨立完成任務的特種部隊,人數5–9人(7±2)。大絕是我決定該怎麼做(How),武器是自我管理和持續改善的能力。

每個人都有自己的特長,但依任務需求自行安排工作內容。類似射雕英雄傳裡全真七子所部的天罡北斗陣,如任一人受敵時,左右會來相救。

  • Product Owner(PO,產品負責人)

產品的守護者;大絕是要做什麼我說了算(What),武器是敏銳的市場嗅覺的和擺平利害關係人。

如同射雕英雄傳裡北極星位對天罡北斗陣的影響,當郭靖站到了北極星位就可以驅動全真七子。PO要決定產品的規劃和為產品的成敗負責,可以參考一些PO常常絆倒的地方

  • ScrumMaster(SM,無中文名稱)

Scrum功夫的傳道者;唯一的大絕是影響力,武器是異於常人的信心與耐心。

有人覺得他是Team Lead或是PM的角色。但其實他沒人事權,不能管人;沒財務權,不能編預算。

更可憐的是,他不能決定產品的走向,所以是個令人摧心的角色。最常見的安排是PM直接轉Scrum Master,或是主管自己跳下來兼Scrum Master會把Scrum Master絆倒的地方也不少。

以上三者又統稱Scrum Team或Team

Scrum中的物件

Scrum中常會提到的物件與中文名稱如下:

  • Item(物件)

又稱Story,是PO定義的產品產出。Item大小要講究,要可以讓團隊在一般的速率下,可以完成3–5個。太多太繁雜,太少萬一沒做完就感覺整個Sprint 一事無成,對團隊信心是個打擊。

  • Task(工作)

是Dev Team針對Item(不是PO也不是SM)列出完成Item所需的工作;工作分配則是開發團隊自己安排。

  • Product Backlog(產品待辦清單)

由PO負責整理的產品願景圖,以Item為單位,施工順序由上而下。

  • Sprint Backlog(衝刺待辦清單)

Dev Team向PO承諾這個Sprint會盡力完成的Item List;以Task為單位。

  • Potentially Shippable Product Increment(潛在可交付產品增量)

開發團隊的產出,簡單的說就是PO說要上線就可以馬上上線的東西才算數。

  • Burndown Chart(燃盡圖)

有點類似怪物的血條,看看還剩多少血怪(Sprint Backlog)才死。以Task大小為單位。

Scrum活動

每一個Scrum活動都有其目的和時間限制(Time Boxed)。主要活動如下:

  • Sprint(衝刺)

顧名思義,當團隊決定要哪些Item後,就著手去衝。Sprint長度定義上是1–4個禮拜,但實務上不要多過2個禮拜。

而且Sprint長度應該要保持穩定盡可能不變。這樣才容易讓團隊掌握節奏,也容易預估和比較Sprint內的工作量。大原則是Sprint內的Sprint Backlog不改變(有原則就有例外)。

  • Daily Scrum(每日站立會議)

每天10–15分鐘不能超時,目的是讓團隊資訊同步。一定要站著罰站為了讓大家長話短說。

  • Sprint Planning(衝刺規劃會議)

Sprint開始時,討論一下這個Sprint團隊可以交付哪些Item。Item優先順序PO決定,要選多少Item由Dev Team決定。

  • Product Backlog Refinement / PBR(產品待辦清單精煉會議)

PO跟Team一起討論近期內會開始施工的Item,主要是從商業和使用者角度切入,盡可能不觸及技術細節。

  • Sprint Review(衝刺檢視會議)

Sprint結束時針對產品的會議,PO邀請利害關係人對產出給意見,是要可用的軟體才算產出。不準備PowerPoint或其他簡報,單純就軟體操作取得回饋。

  • Sprint Retrospective / Sprint Retro(衝刺回顧會議)

我偏好稱這一項為「自省」會議。在Sprint Review後,Scrum Team成員(Dev Team或包含PO)針對這個Sprint團隊的工作模式討論改善,並定出下個Sprint改善事項。為了創造一個安全的環境,原則上只有團隊成員才能參加。

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

Scrum的架構適合一個產品配合1–3個開發團隊。如果一個產品需要更多人打群架,有兩套基礎於Scrum的終極陣法,一套是同樣以人為本的LeSS(Large Scale Scrum),另一套是加入流程控制的SAFe(Scaled Agile Framework);可以參考LeSS 和 SAFe的比較,和兩者運用組織權力的差異