Loading...

談到「敏捷開發」很多人就會聯想到 Scrum。的確 Scrum 是敏捷管理產品開發的架構之一,它能幫助團隊解決複雜、困難的問題,同時提升開發速度,創造更多的價值。

Scrum 這個詞則是源自於橄欖球 (Rugby) 中的術語:

A scrum (short for scrummage) is a method of restarting play in rugby that involves players packing closely together

文字與圖片來源:Wikipedia

就像圖片那樣,指的是重新發球時選手會排成陣列緊密靠在一起,在裡頭進行搶球。

Scrum 的精神

1986 年,兩位日本教授竹內弘高與野中郁次郎,在哈佛商業評論發表了「The New New Product Development Game」文章以及關於新的產品開發管理研究。

在文中他們提到,有別於過去「大隊接力」般的開發團隊,新的開發團隊就好像橄欖球隊一樣,從比賽的最一開始「一起努力」到最後,在團隊內部成員們「不斷地互相傳球」,同時整個團隊在賽場上又是「隨時變化進攻策略」、「一步步向前推進」直到達陣。

和敏捷精神一樣,Scrum 並不是某個人在某個特別的時間點發明出來的,早在 Scrum 這個詞出來之前,已有許多團隊嘗試執行這種新的管理方式,而如今你看到的 Scrum,更是過去團隊的努力與經驗累積。

現在就讓我們來介紹如何將 Scrum 應用在軟體產品的開發上。

如何用 Scrum 管理專案?

Scrum 是一個全面的產品開發架構。從團隊組合、協助模式、到文件的格式,都有清楚的設計目的與描述。

在 Scrum 中,通常以 1-4 週為一個開發週期,這個週期稱作 sprint,也就是快速衝刺的意思。在一個 sprint 當中,開發團隊必須要在限定的時間之內,完成計畫目標。

透過每一次的 sprint,開發團隊將快速發布可運作的產品去測試市場反應,收集關於產品的回饋,然後持續調整產品的開發方向,最終目標是打造最能滿足客戶需求的產品。

接下來,我們帶你一一認識 Scrum 架構中的人物角色、物件與流程。

成為有協作能力的工程師,3 分鐘小測驗,找到你的入場券

學會在軟體開發中協作、累積團隊經驗,前後端工程師專修課程免費試讀

Scrum 的人物、物件、與流程

圖片來源:Scrum.org

人物角色

在 Scrum 裡,有三個主要的角色:

1. 產品擁有者 (Product Owner)

Product owner 代表客戶參與開發流程,確保開發團隊的產品符合客戶需求。

Product owner 負責規劃使用者故事,並與開發團隊討論,決定產品功能開發的優先順序。在開發過程中,協助開發團隊釐清產品需求,同時,product owner 也負責整合客戶的意見、使用者的回饋,做為未來改善產品的基礎。

2. Scrum Master

Scrum Master 負責確保開發團隊依照 Scrum 的方式進行產品開發,並排除任何會影響 Scrum 流程的障礙,協助改善開發流程。Scrum Master 不是以「領導者」的姿態帶領專案,而是 Scrum 規則的「執行者」。

3. 開發團隊 (Development Team)

開發團隊負責開發與交付產品。開發團隊為跨領域團隊,可由設計師、工程師等不同的專業人士所組成。

以上這三個角色是 Scrum 裡的有權限做事的人,其他與專案相關但沒有實際參與的角色被統稱為 Stakeholder(利益關係者),可能是客戶、使用者或任何人,至多只能觀察產品並給意見,不能干擾開發過程及決策。

文物 (artifacts)

在執行 Scrum 時,需要準備一系列文件 (英文稱為 artifacts)。不同的團隊會根據他們的開發環境跟習慣選擇不同的文件,一般來說會包括以下幾種:

1. 使用者故事 (user stories)

由 Product owner 負責規劃,做為以使用者為核心的開發基礎。

2. Task-board

由開發團隊根據使用者故事,列出所有需要被完成的任務,然後分配給開發團隊的成員。

3. Product backlog

Product backlog 為產品待辦清單,包含了所有需要被完成的使用者故事。Product owner 會決定開發的優先順序。

4. Sprint backlog

Sprint backlog 為衝刺待辦清單,列出開發團隊需要在一個 sprint 裡完成的開發目標。

5. Burndown chart

Scrum 團隊在開發過程中,會每日追蹤進度,將未完成 Task 的剩餘工時加總起來,再依照日期紀錄下來,然後跟專案一開始的時程計劃作比較,便能得到一張長得像這樣的 burndown chart:

圖片來源:eLearning Industry

在上圖,淺藍色線是計專案一開始時預估的時程,單純把 task 的總時數除以專案的天數。綠色線是實際進度紀錄。這兩條線幾乎是不可能一樣的。製作 burndown chart 的目的,是讓團隊了解這個 Sprint 的進度狀況,以及還有多少小時的 Task 要完成。如果進度受到嚴重的阻礙,團隊就要及早作出應對和調整。

活動

衝刺規劃會議 (Sprint Planning Meeting)

在每個 sprint 開始的第一天,團隊全體成員都需要參與這個會議,討論這次 sprint 的開發目標。Product owner 決定開發的優先順序,而開發團隊可以決定要完成多少的開發量。

圖片來源:Shutterstock

每日衝刺會議 (Daily Scrum)

在 sprint 當中的每一天,都得召開衝刺會議,約 10- 15 分鐘,由 Scrum Master 主持,確保會議時間不會過長與失焦。為了簡短會議時間、讓大家保持專注,通常會站著開會,因此也稱作 stand-up meeting。

在會議中,開發團隊成員須報告三件事:

  • 昨天完成的工作
  • 今天準備要做的工作
  • 是否遇到任何阻礙,需要請求幫忙?
衝刺檢視會議 (Sprint Review Meeting)

在 sprint 的最後一天舉辦,除團隊所有人需要參加之外,也可邀請 stakeholders 參與。開發團隊將展示開發「成果」並讓 product owner 驗收,團隊藉此檢視產品是否需要調整。

衝刺自省會議 (Sprint Retrospective Meeting)

在 sprint 結束後召開,跟 sprint review meeting 不同的地方是,這個會議回顧與檢視 Scrum 開發「流程」,看看是否有需要改善的地方。

8 週軟體工程師課程,養成工程師業界實戰能力

Scrum 的核心價值

在介紹完 Scrum 的架構之後,最後我們來看看執行 Scrum 所需要的核心價值:

1. 專注

在 sprint 期間,Scrum Master 會協助排除所有的外在干擾,因此開發團隊必須心無旁騖地全力開發產品,發揮最大的潛能。

2. 勇氣

在 Scrum 中以團隊為單位,為了共同完成目標,團隊成員之間會互相學習、支持,會比單打獨鬥的開發者更有勇氣面對困難的挑戰。

3. 開放

跨領域的成員在同一個團隊裡面一起工作,而非分散在企業大樓的不同角落,促成了開放溝通、學習的機會,讓產品開發更為順利。

4. 承諾

為了完成目標, Scrum 團隊裡面的成員都要有很強的自主性,承諾完成被分配的任務,才能推動一起團隊前進。

5. 尊重

所有成員一同分享團隊的成功與失敗,因此得尊重彼此不同的意見,並互相給予協助,才能共同完成目標。

Scrum 中的敏捷精神

Scrum 在許多方面體現了敏捷精神,在流程上,強調快速發布可運作的產品,以及持續收集回饋並改善;在團隊上,強調每位成員須具備積極的心態與承諾,在相互尊重下以開放的溝通提升產品開發效率。

在下一個單元裡,我們將談到適合 Scrum 的使用情境,以及你可以如何在未來的專案中使用 Scrum。

雖然 Scrum 有較為完整的架構,但一樣有其適合使用情境以及局限性,我們列出了一些常見的陷阱讓你觀摩:

Scrum 適合的使用情境

產品需求不明確

當產品需求不明確時,團隊可以透過 Scrum 快速發布產品、盡快驗證需求,並能夠與客戶、利益關係者緊密合作。

產品需要快速迭代

Scrum 的框架可以容納不同專業的成員緊密合作,像是使用者體驗研究員、介面設計師、程式開發者、行銷人員等,並且有定期的共同會議聚焦團隊方向。

Scrum 不適合的使用情境

團隊成員分處多地

由於 Scrum 流程強調團隊的密切合作與即時溝通,若有成員採取遠距工作的方式,那麼就容易降低團隊溝通的效率,或造成資訊不對稱。

團隊成員習慣被動等待指令

Scrum 強調團隊合作,專案依賴每一位成員的積極性與解決問題的能力。若有成員不夠積極主動,那麼就會降低 Scrum 的整體效果。

開發過程需大量依賴外在資源

當開發團隊無法獨立完成產品開發,得依賴較多外在資源或條件時,就難以執行 Scrum。

軟體業PM 談專案管理3 大能力:溝通、管理、技術能力

使用 Scrum 時常見的問題

Sprint 目標設定太高

設定困難的目標,可以驅使 Scrum 團隊發揮最大潛力,而偶爾無法達到目標也是可以接受的。但如果時常無法達成目標,那麼就要進一步去思考,目標是不是真的太困難了,又或者是否需要調整團隊組成。

會議失焦

每天的衝刺會議的重點在於凝聚團隊、排除困難,若流於流水帳式的報告,那麼就會失去它的意義。

無法排除的外在阻礙

在執行 sprint 的時候,Scrum Master 會協助排除外在影響因素,但實際上有時候可能會出現緊急狀況,無法等到下一次的衝刺規劃會議才排入開發。團隊可能需要做合適的調整 ,譬如指派一名「救兵」在 sprint 進行中處理緊急狀況,以因應快速變化的狀況。

團隊成員疲乏

最後,在 sprint 時間限制的壓力下,加上高度專注,雖然產能會大大提升,但也容易導致團隊成員身心的疲累。所以在使用 Scrum 高速開發的同時,也要緊密注意團隊的狀況。

ALPHA Camp 的 Simple Twitter 專案實戰

Simple Twitter 專案是【全端網路開發課程】的最後一項里程碑,呼應到「模擬實戰」的設計理念,在此專案中,你會需要運用敏捷開發「綜合運用全部所學,在多人協作下,交付出符合需求的 app」。

成功關鍵在於:

  • 在任務導向的情境中,體驗實務的「軟體開發流程」
  • 透過小組分工來完成任務,克服多人協作下的任務調度與程式碼管理

在模擬專案中跑 scrum,AC Twitter 專案幫你累積多人協作經驗