Scrum 是一種敏捷專案管理方法,可快速開發和測試,尤其是在小團隊中。
這些團隊由Scrum Master領導,他的主要工作是消除完成工作的所有障礙。
但什麼是 Scrum?敏捷專案管理領域中的 Scrum 角色是什麼?
本文涵蓋了所有有關Scrum 方法的基礎知識,包括Scrum 方法論的定義、常見的 Scrum 角色、怎麽使用Scrum 方法、Scrum 工具推薦、Scrum優缺點等等,馬上開始閲讀吧!
什麼是 Scrum?為什麼叫 Scrum?
Scrum是一個用於組織、規劃和執行複雜專案的敏捷框架,可協助團隊將其工作建構成稱為衝刺 (sprint) 的短開發週期。
Scrum 團隊致力於在每個衝刺結束時交付工作,那為什麼叫 Scrum 呢?
Scrum 一詞起源於橄欖球,來自多個團隊的球員以非常緊密、有組織的隊形聚集在一起以實現目標。
球員們在比賽中實際上是緊密相連的,就如下圖一樣:
1986 年,Takeuchi 和 Nonaka 在《哈佛商業評論》上發表的一篇論文中首次引用了這個類比。
他們將高績效、跨職能的產品開發團隊與使用 Scrum 陣型的橄欖球隊進行了比較。
Scrum 理論簡介:Scrum 的三大支柱是什麼?
團隊選擇使用 Scrum 架構,因為它的簡單性和靈活性使他們能夠更快地採取行動,同時仍然保持組織性。
創立Scrum 背後的理論是基於三個關鍵支柱:透明、檢驗和調適。
以下支柱作為 Scrum 團隊的指導原則:
透明 Transparency
在 Scrum 中,執行工作的團隊和接收工作的團隊都必須隨時完全了解流程和狀態,流程中任何一點透明度低都可能導致做出沒有價值的決策並給專案帶來風險。
當團隊成員彼此之間以及利害關係人之間共享完全透明的資訊時,就會建立更牢固的信任,從而實現更有效的協作。
透明度也指團隊對工作流程和流程的可見性,以便對專案的目標和進度達成共識。
當所有各方都可以存取資訊時,團隊可以一起做出更明智的決策,同時對每項單獨的任務負責。
那麽在Scrum 框架中如何實現透明度?敏捷團隊實施不同的流程,讓任務更透明,例如:
- 衝刺待辦事項清單(Sprint backlog):為了使專案進度和團隊當前優先事項變得清晰可見,衝刺待辦事項清單列出了衝刺中重點關注的任務以及等待採取行動的其他任務。
- 產品待辦事項清單(Product backlog):幫助團隊始終與專案目標保持一致的優先功能目錄。
- 衝刺檢視(Sprint review):在衝刺檢視中,團隊與利害關係人分享已完成的工作,以獲得回饋並評估迄今為止完成的任務。
- 「完成」之定義 (DoD):一組明確定義的標準,描述將任務列為完成所需的條件,幫助團隊避免歧義。
檢驗 Inspection
Scrum 的第二個支柱是檢驗,涉及持續評估專案的進度,一般包括評估團隊績效、任務、最新產品和整體開發流程。
檢驗是由開發過程中的人員而不是第三方執行的,這使得團隊成員可以更輕鬆地提供回饋、檢查潛在問題並使專案回到目標。
在檢驗方面,擁有一個追蹤進度並產生像 Monday dev 這樣的報告的平台可以使收集資料的過程變得更加容易。
定期評估是 Scrum 和敏捷流程的基石,特別是需要對進度和結果進行頻繁評估,這些表現為整個開發階段的檢查點和流程,例如:
- 衝刺計畫(Sprint planning):當衝刺開始時,團隊一同檢視產品待辦事項並提前規劃衝刺
- 衝刺檢視(Sprint review):在每個衝刺結束時,團隊開放接受利害關係人的檢查和回饋
- 每日站立會議(Daily stand-ups):這些每日會議讓團隊成員有機會評估進度並找出需要注意的弱點
- 衝刺回顧/自省(Sprint retrospective):在每次衝刺結束時,團隊都會對哪些有效、哪些無效進行評估,並製定計劃以改善下一個衝刺。
調適Adaption
在檢驗之後,如果你發現流程進展不順利或結果不符合預期,則需要進行調整,團隊可以評估最緊迫的挑戰,調整他們的工作流程和策略以適應檢視和評估的結果,這樣你才不會進一步偏離最初的目標。
Scrum 團隊需要能夠根據新資訊、不斷變化的需求和回饋來調整他們的方法,當團隊適應新的變化時,他們可以完善策略以提高最終產品的質量,在未來的迭代中交付結果並實現專案目標。
適應性不一定需要新的流程,而是對現有流程的調整,這就是為什麼在 Scrum 框架內工作時始終保持靈活性至關重要。
那麽在Scrum中如何實現適應性?常見的動作如下:
- 衝刺檢視調整(Sprint review adjustments):使用衝刺檢視期間收集的見解和回饋,你的團隊可以做出調整
- 衝刺待辦事項的靈活性(Sprint backlog flexibility):當出現新的見解時,你的團隊需要能夠將它們容納在待辦事項中並根據需要進行調整
- 每日站立會議變更(Daily stand-up changes):隨著計劃或方向的變化,這些會議應保持靈活性,以便團隊成員可以根據當前的優先事項調整當天的工作
什麼是 Scrum 架構?
上面我們有一直提到 Scrum 是一個架構,但Scrum 架構到底是什麼意思?
Scrum 架構由充當專案內階段的事件(也稱為Scrum ceremonies)和充當要完成的可交付成果的產出物組成。
Scrum ceremonies
Scrum 框架內有 5 個事件:
- 衝刺
- 衝刺計劃
- 每日例會
- 衝刺檢視
- 衝刺回顧
Scrum ceremonies 旨在實現透明度,並允許在開發過程中進行檢查和調整。
什麼是 Scrum 產出物?
Scrum 產出物代表了 Scrum 團隊的工作或為最終目標提供的價值,而Scrum 的產出物用以下三種方式定義和測量:
- 產品(或任務)待辦事項清單(Product backlog):要完成的工作的完整列表,使用產品目標進行衡量。
- 衝刺待辦事項清單(Sprint backlog): 1個衝刺內要完成的工作列表,以衝刺目標衡量
- 增量(Increment):是在衝刺結束時提供供檢視的可交付成果,透過「完成」之定義 (DoD)來衡量。
Scrum 產出物使整個 Scrum 團隊的透明度成為可能。
Scrum 的 5 個階段
正如我們上面所介紹的,Scrum 方法由 Scrum ceremonies組成,而ceremonies可分為以下5個階段:
1. 預規劃階段
設定目標和願景:產品負責人需要定義總體目標,通常是與利害關係人直接合作完成產品路線圖。
創建和完善產品待辦事項:產品待辦事項是功能、需求和錯誤修復(若是軟體)的列表,概述了團隊為完成產品必須做的一切。
2. 規劃階段
召開衝刺規劃會議並選擇要包含在衝刺待辦事項中的功能(這些功能通常是從使用者角度定義的,稱為使用者故事)。
將任何大型需求分解為具體任務,並估計每個任務需要多長時間。
確保衝刺待辦事項足夠小,可以在衝刺時間範圍內實現,並將不同使用者故事和任務的所有權分配給適當的團隊成員。
3. 衝刺或開發階段
努力實現將在衝刺結束時交付的迭代或產品增量。
舉行每日站立會議或每日Scrum 會議,討論昨天的進度、今天的任務以及任何潛在的瓶頸。
4. 測試和審查階段
安排一次衝刺檢視會議(又稱產品增量檢視),讓客戶和產品的實際使用者(利害關係人)測試新的增量,如果他們接受更改,並且它們按應有的方式工作,你就可以接受新的迭代。
5. 回顧階段
與 Scrum 團隊成員進行衝刺回顧,回顧哪些方面進展順利,哪些方面還有改進的空間。
根據增量的成功(或失敗)以及利害關係人優先順序的任何變更來更新一般產品待辦事項清單。
Scrum主要角色:Scrum 團隊的成員有哪些?
一般情況下Scrum 團隊是一個由 10 人或更少人組成的小團隊,Scrum 團隊由三個主要角色組成:
- 產品負責人
- Scrum master
- 團隊成員
每個職位在確保專案成功和公司實現其策略目標和目的方面都發揮著重要作用。
當所有角色都得到有效協調和協作時,靈活性就會增加,團隊的交付也會變得更加一致。
產品負責人
產品負責人是利害關係人和團隊之間的橋樑,該角色負責確定利害關係人的需求和期望,並透過使用者故事傳達這些需求。
產品負責人的工作是創建專案願景、確定專案目的和目標並確定優先順序。
他們了解客戶的需求,本質上是創建藍圖的架構師。
Scrum Master
Scrum Master是團隊和產品負責人之間的聯絡人, Scrum Master 的角色是透過確保團隊遵循 Scrum 框架、實踐和價值觀來指導團隊。
Scrum Master 主要負責:
- 消除可能阻止團隊實現目標的障礙
- 確保團隊繼續遵循 Scrum 架構
- 防止範圍蔓延
- 推動從一個衝刺到另一個衝刺的持續改進
Scrum Master 的主要角色是促進 Scrum 流程,透過促進日常 Scrum、衝刺計畫、衝刺檢視和衝刺回顧來「服務」團隊,幫助團隊成員解決問題來完成工作。
需要注意的是,並不是每個企業都有資源(或願望)來僱用某人擔任此特定職位。
例如,新創公司的小團隊,甚至更大的公司都可以使用 Work OS 來管理其敏捷工作流程,這邊推薦使用monday.com Work OS(下文有詳細介紹),透過使用 monday.com 上的各種視圖,團隊可以堅持 Scrum 原則,讓團隊成員可以自組織完成工作,並在出現問題時協作解決問題。
當團隊進行自我管理時,每日站會提供了一個機會來確定需要改變哪些內容來解決問題以及誰會採取行動,在 monday.com 上,團隊成員可以輕鬆地相互分配專案或待辦事項,建立自動化工作流程,提醒他們即將到來的截止日期、狀態變更或是否想要在特定時間範圍內自動建立新專案。
monday.com 讓團隊一起工作、透明地溝通,並減少手動重複性工作的時間。
團隊成員
開發團隊在每個衝刺中執行工作,他們負責挑選並完成產品待辦事項中分配的任務,而 Scrum Master 則幫助他們遵循敏捷框架。
開發團隊比從事瀑布專案的傳統同行擁有更多的自主權。雖然開發團隊不設定專案目標,但他們可以規劃如何完成工作。
自組織團隊是敏捷框架的重要組成部分,因為自主權的增加意味著團隊分擔責任和責任,鼓勵他們對自己的工作有更大的主人翁意識。
開發團隊也是跨職能的,這意味著他們包括來自組織內不同部門的成員。
成員的選擇不是基於他們的頭銜,而是基於他們可以為團隊做出貢獻的技能。
在 Scrum 專案中,具有行銷、IT 和銷售等領域背景的人員作為同一團隊的一部分一起工作是很常見的。
如何使用 Scrum 方法進行專案管理?
上面我們介紹了 Scrum 的一些基礎知識,那麽如何在專案中使用 Scrum 方法呢?
第1步:選擇合適的產品負責人
產品負責人不一定是最資深的開發人員,但這個人一定是最了解你的客戶及其需求的。
產品負責人可以是產品的內部使用者,也可以是來自支援、銷售、行銷、客戶管理的人員,甚至是業務分析師。
他們是 Scrum 團隊和利害關係人之間的聯絡人,因此請謹慎選擇。
第2步:建立並完善你的產品待辦事項列表
在開始計劃任何衝刺之前,你需要概述產品應包含的所有內容。
產品負責人應與所有重要的利害關係人密切合作,以填入產品待辦事項清單。
細化所需的功能或任務,並根據你的短期和長期目標確定其優先順序。
例如,透過 Monday專案管理系統,你可以使用顏色編碼的優先標籤幫助你的專案團隊進行任務管理。
第3步:規劃你的第一個衝刺
評估所有候選任務(待辦事項中的功能)並決定在衝刺中重點關注哪些。
確定更大的衝刺目標,概述使用者體驗的整體預期變化。
在建立初始衝刺待辦事項清單時,不要忘記考慮團隊的能力。
在敏捷和 Scrum 中,我們經常專注於「使用者故事」而不是功能。
本質上,這些都是從客戶角度出發的功能,詳細說明了他們期望的結果。
擧個例子,你可以從「我想存取和編輯智慧型手機上的檔案」(從使用者角度出發)之類的內容進行思考,而不是「行動應用程式相容性」(比較主觀)這類内容。
第4步:估計每項任務的時間
你還需要估計每項任務需要多長時間,你可以設定明確的截止日期或使用故事點 (SP),這是你作為團隊決定的估計範圍。
第5步:將工作任務分配給適當的團隊成員
團隊一同討論任務和使用者故事並將其分配給適當的團隊成員,自組織是這裡的關鍵。
第6步:召開每日 Scrum 會議
敏捷團隊使用每日 Scrum或站立會議是有原因的,每日進度會議可以幫助每個人確定優先順序並就目標進行協作。
第7步:與利害關係人一起檢視衝刺增量
邀請客戶和內部利害關係人測試新的增量,該會議稱為衝刺檢視或產品增量檢視。
如果使用者覺得新功能在各方面(整體體驗)都滿足了他們的期望,那麼衝刺就是成功的;如果沒有,你需要根據使用者認為的不足來調整待辦任務。
第8步:召開回顧會議
在衝刺回顧會議中,產品負責人、Scrum Master 和團隊成員評估以下內容:
- 哪裡進展順利
- 哪裡需要改進
- 產品待辦任務列表的潛在變化
這是持續學習和改進 Scrum 流程的關鍵。
第9步:開始下一個衝刺
目前爲止,一個衝刺的流程就結束了,你可以按規劃進行新的衝刺。
在開發產品並了解有關 Scrum 的更多資訊時,重複上面的過程即可。
好用的 Scrum 專案管理軟體推薦
我們在上文好幾處有提到使用 monday.com 的專案管理系統,那麽具體來説這款工具能如何幫助敏捷團隊規劃和執行 Scrum 流程呢?
monday.com 專案管理軟體為 Scrum 和敏捷團隊提供了廣泛的完全可自訂、即用型模板選擇,因此只需點擊幾下按鈕即可使用它們來啟動你的專案,或者你也可以從頭開始建立自己的視覺化工作流程。
馬上用你的電郵注冊登入 monday.com,然後使用Scrum 衝刺計劃範本開始設定你的專案吧!
敏捷專案管理的秘訣在於三個核心 Scrum 角色之間的良好協作,透過 monday.com 的工作作業系統,Scrum 團隊可以在每一步中進行協作並保持聯絡。
在衝刺中,某些活動將依賴它們之前其他活動的完成,我們知道衝刺只能在前一個衝刺結束後才能開始。
這個Scrum 專案管理工具會在任務完成、檔案上傳、溝通等方面自動在團隊成員之間發出通知。
無論你選擇Scrum 板、看板還是Scrumban,你都可以在 monday.com 上檢視你的任務,如果你改變主意,也可以在視圖之間切換。
此外,你還可以將專案任務以時間軸的形式查看,以了解你的可交付成果是否會按時完成;如果需要深入了解特定任務,還可以以表格或甘特圖的形式檢視等等。
你的團隊可能已經依賴各種工具來完成工作,這個軟體整合了你順利運行專案所需的所有工具,如果你使用 Scrum 架構來管理開發團隊,你可以與 GitHub、JIRA 、GitLab 和 PagerDuty 等流行的開發工具整合。
Scrum VS Waterfall:Scrum 與瀑布有何不同?
Scrum 和瀑布是兩種不同的專案管理方法。
瀑布模型的特點是順序性和強調前期規劃,而 Scrum 是一種迭代且靈活的方法,優先考慮客戶回饋和適應變化。
從我們對 Scrum 流程如何運作的解釋中,我們已經可以看到與瀑布式專案管理的一些關鍵差異,這邊從幾方面進行詳細總結:
規劃和可交付成果
瀑布遵循線性和順序的規劃和交付週期,專案階段更加正式,包括需求收集、設計、實施、測試、啟動和維護,每個階段必須在下一階段開始之前完成。
然而,Scrum 專注於專案規劃和交付的迭代和增量方法,如上所說的,每個衝刺類似於一個小型任務,旨在定期向使用者發布工作軟體,而不是與瀑布相關的項目結束時的大爆炸式啟動。
靈活性
與瀑布相比,Scrum 提供了更大的變化適應性,而瀑布往往更加僵化。
在瀑布專案中,由於專案的線性和順序性質,如果需要變更通常會涉及冗長的變更請求流程。
因此,任何修改都可能代價高昂,並導致專案時程嚴重延誤。
例如,如果在實施階段請求設計變更,則可能需要放棄與設計變更相關的任何工作,從而導致時間和資源的浪費。
而scrum 旨在平滑地適應變化,工作在短衝刺內完成,允許將新想法納入下一個衝刺,等待時間最短(通常只需兩週)。
儘管在衝刺計劃期間鎖定衝刺後通常最好不要在衝刺內進行更改,但如有必要,仍然可以進行調整。
如果新工作被認為更有價值並且需要添加到衝刺中,產品負責人將評估優先級,並可能從當前衝刺中刪除其他同等規模的任務,以便為新工作騰出空間。
如果此變更發生在衝刺早期,則可能會造成最小的干擾;但如果發生較晚,則可能需要推遲到下一個衝刺。
團隊合作
Scrum 的一個基本面向是協作,這與瀑布方法形成鮮明對比。
在瀑布式專案中,不同的階段和團隊成員通常會相互獨立運作,非常強調個人的可交付成果和責任,但這種方法可能會形成一種不健康、高壓的環境,壓力普遍存在。
相反,Scrum 鼓勵所有團隊成員和利害關係人之間的廣泛協作。
擁有跨職能團隊並使每個人都參與定期討論的目標完全和瀑布方法不一樣。
Scrum VS Agile:Scrum 和Agile 有什麽分別?
當談到專案管理和軟體開發時,你可能經常會聽到「敏捷」和「Scrum」這兩個術語。
Scrum 是敏捷方法論的一部分,因此兩者不可避免地會有重疊的相似之處,比如他們都遵循迭代的交付方法、都重視合作、都融入了持續改進的理念等等。
雖然Scrum 和Agile都具有類似的解決方案來幫助團隊更有效率地工作,但它們並不是同一個東西。
了解敏捷和 Scrum 之間的主要區別對於為你的團隊或專案選擇正確的方法至關重要,下面我們來分析一下它們的不同之處:
規模
敏捷(Agile)就像一把大傘,其中包括多個架構和方法,例如Scrum、看板、極限編程等。這些架構都遵循敏捷原則,但有自己獨特的規則和實踐。
Scrum 特別是為需要將大型專案分解為可管理的區塊(稱為衝刺)的小型團隊而設計的,敏捷團隊可能會使用 Scrum,但他們也可以根據專案的要求使用其他架構。
規則
敏捷遵循一組價值觀,但沒有團隊必須遵循的特定規則。
然而,Scrum 有許多絕對不可協商的規則,例如Scrum 團隊必須每天召開Scrum 會議;團隊必須將工作流程組織成持續一週到一個月的衝刺 (sprint)等等。
團隊角色和結構
敏捷和 Scrum 之間的另一個關鍵區別在於團隊結構。
敏捷提供了靈活性,允許團隊規模大小、跨職能或專業化,對於如何根據敏捷原則組織團隊並沒有嚴格的要求。
而Scrum 的定義則更加明確,它規定了特定的角色,例如 Scrum Master、產品負責人和開發團隊。
此外,Scrum 最適合小型團隊(通常為 5 到 9 人),這種較小的團隊規模有助於快速溝通和決策。
Scrum 的優缺點有哪些?
Scrum 的優點
- 明確的角色定義:Scrum 明確定義的角色(例如 Scrum Master 和產品負責人)創建了責任並確保每個人都知道自己在團隊中的職責。
- 省時的衝刺:Scrum 的衝刺結構可以促進焦點並確保團隊朝著短期的、可實現的目標努力,每個衝刺都會帶來實際的成果,有助於保持動力。
- 提高專注度和責任感:Scrum 的每日站立會議和衝刺評審使團隊保持專注,確保每個人都與該衝刺的目標保持一致。
Scrum 的挑戰
- 對某些團隊來說可能過於僵化:Scrum 的結構可能會讓人感覺受到限制,特別是對於喜歡更流暢流程的團隊來說,預先定義的角色和儀式有時會限制靈活性。
- 擴展 Scrum 的困難:雖然 Scrum 非常適合小型團隊,但在大型組織中擴展 Scrum 可能具有挑戰性,將 Scrum 應用於更大、更複雜的專案需要額外的協調,並且可能涉及採用 Scrum of Scrums 或 SAFe(規模敏捷架構)等架構。
結論
Scrum 架構為團隊提供了迭代所需的自由,讓專案不落後於公司的目標。
在你的團隊(開發團隊或其他團隊)中實施 Scrum 架構能幫你按時完成任務和促進溝通進度,並為你的團隊提供管理自己時間的自由。
如果你正在尋找一個工具來幫助你管理 Scrum 團隊,monday.com dev可以提供你所需的一切需求(包括與你已有工具的整合、減少不必要工作的自動化、直覺的使用者介面等等)。
Scrum 相關的問題與解答FAQ
何時使用Scrum 方法?
Scrum 與其他敏捷方法論相比會比較容易使用和執行,雖然從瀑布式過渡到 Scrum 會帶來挑戰,但 Scrum 通常是轉換的絕佳第一步。
角色和職責的精確定義以及對流程控制的關注使 Scrum 有別於看板或極限編程 (XP)等其他敏捷方法。
Scrum 方法適合由小組組成的專案和團隊,簡短的檢查使團隊成員能夠保持協調,而定義的短期目標為每個團隊成員設定了明確的期望。
Scrum 的六大核心原則是什麼?
Scrum 是最受歡迎的敏捷框架之一,因此了解其關鍵概念非常重要,Scrum 的核心原則包括:
經驗過程控制:強調基於觀察、經驗和數據的決策,而不是推測或預先規劃
自組織:Scrum 鼓勵團隊聲明其工作所有權並共同做出決策,從而培養創造力和自主性
協作:促進團隊成員和利害關係人之間的密切合作,以確保每個人都朝著共同的目標努力
基於價值的優先順序:首先專注於提供最有價值的功能,以便產品逐步滿足用戶需求
時間箱(timeboxing):依靠固定的時間完成任務,例如衝刺、每日站會和回顧,為專案提供一致的節奏
迭代開發:鼓勵持續交付產品的小而功能性增量,同時允許持續回饋以進行改進
Scrum of scrums 是什麽?
Scrum of Scrums(也稱為 Scrum of Scrums 會議)是擴展Scrum 方法的方法,以便大型專案中的多個不同 Scrum 團隊可以見面並有效率地協同工作。
在典型的 Scrum 會議中,產品所有者和Scrum Master與開發團隊會面,討論進度和障礙。
理想情況下,每日 Scrum 會議應有三到九人參加。
Scrum of Scrum 將其擴展到整個組織中更大、更複雜的專案。
在 Scrum of Scrums 會議中,每個 Scrum 團隊的個人或代表與其他類似指定的代表會面,傳達高層更新並同步工作。
當組織擁有多個可能相互依賴或整合的 Scrum 團隊和專案時,召開 Scrum of Scrum 會議可以讓每個團隊的特使溝通進度和遇到的障礙。
什麼是敏捷方法論?
敏捷方法是一種協作且靈活的方法,團隊通常會採用此方法來更有效地完成任務,廣泛應用於軟體開發中,是一種讓跨職能團隊成員組織有序併步入正軌的更自然的方式,團隊使用敏捷方法進行專案的各種迭代,然後根據最終用戶的回饋將其組織成優先待辦事項。
敏捷方法論的基本原則是足夠靈活,可以根據需要進行更改。
為此,專案經理為軟體專案的每個階段分配一定的時間。