Scrum

維基百科,自由的百科全書
前往: 導覽搜尋
Scrum實施講解
軟件開發過程
核心行動
範式與模式
方法論與框架
支持行為
工具
標準與知識體系

Scrum是一種敏捷軟件開發方法學,用於迭代式增量軟件開發過程。Scrum在英語是橄欖球運動中爭球的意思。

雖然Scrum是為管理軟件開發項目而開發的,它同樣可以用於運行軟件維護團隊,或者作為計劃管理方法。Scrum之間的合作稱為「Scrum of Scrums」。

歷史[編輯]

  • 1986年,竹內弘高野中郁次郎闡述了一種新的整體性的方法 ,該方法能夠提高商業新產品開發的速度和靈活性:[1]
    • 他們將這種新的整體性方法橄欖球相比較,前者各階段相互重疊,並且由一個跨職能團隊在不同的階段完成整個過程,而團隊「作為一個整體前進,把球傳來傳去」。
    • 他們對來自汽車,照片機器,計算機和打印機等產業的案例進行了研究。
  • 1991年,DeGrace和Stahl在《Wicked Problems, Righteous Solutions》[2]一書中將這種方法稱為Scrum英語Scrum (rugby),在竹內弘高野中郁次郎的文章中提到的橄欖球術語。
  • 1990年代初,肯·施瓦伯在其公司使用了一種方法Advanced Development Methods(先進開發方法),這種方法後來發展為Scrum。
  • 同時,傑夫·薩瑟蘭在Easel公司開發了一種類似的方法,並首次稱之為Scrum。[3]
  • 1995年,在奧斯汀舉辦的OOPSLA '95上,薩瑟蘭和施瓦伯聯合發表了論文首次提出了Scrum概念。施瓦伯和薩瑟蘭在接下的幾年裡合作,將上述的文章,他們的經驗,以及業界的最佳實踐融合起來,形成我們現在所知的Scrum。
  • 2001年,施瓦伯與麥克·比竇(Mike Beedle)合著了《敏捷軟件開發-使用Scrum過程》一書,介紹了Scrum方法。

Scrum的特性[編輯]

Scrum過程

Scrum是一個包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括:

  1. Scrum Master是Scrum教練和團隊帶頭人,確保團隊合理的運作Scrum,並幫助團隊掃除實施中的障礙;
  2. 產品負責人,確定產品的方向和願景,定義產品發布的內容、優先級及交付時間,為產品投資報酬率負責;
  3. 開發團隊,一個跨職能的小團隊,人數5-9人,團隊擁有交付可用軟件需要的各種技能。

在每一次衝刺或迭代(一個15到30天的周期,其長度由開發團隊決定)當中,開發團隊創建可用的(可以隨時推出)軟件的一個增量。每一個迭代所要實現的功能來自產品訂單。產品訂單按照優先級排列工作需求。在迭代計劃會議中,產品負責人告訴開發團隊需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次迭代中他們能夠承諾完成多少訂單項。[4] 在迭代的過程中,沒有人能夠變更迭代訂單,這意味着在一個迭代中需求是被凍結的。

管理Scrum過程有很多實施方法,如即時貼、白板、甚至軟件包。Scrum最大的好處之一是它非常容易學習,而且啟動Scrum應用並不需要太多的投入。

Scrum中的角色[編輯]

Scrum當中定義了許多角色。按照對開發過程的參與情況,這些角色被分為兩組,即組和組。這個分組方法的由來是一個關於豬和雞合夥開餐館的笑話[5]

一天,一頭豬和一隻雞在路上散步。雞對豬說:「嗨,我們合夥開一家餐館怎麼樣?」豬回頭看了一下雞說:「好主意,那你準備給餐館起什麼名字呢?」雞想了想說:「叫『火腿和雞蛋』怎麼樣?」「那可不行」,豬說:「我把自己全搭進去了,而你只是參與而已。」

豬組的成員[編輯]

是在Scrum過程中全身投入專案的各種人物,他們在專案中承擔實際工作。他們有些像上邊那個笑話里的豬,要把自己身上的肉貢獻出來。

產品負責人(product owner)
產品負責人代表了客戶的意願。這保證了Scrum團隊在做從業務角度來說正確的事情。產品負責人編寫用戶故事,排出優先級,並放入產品訂單。
Scrum主管(或促進者)(scrum master)
Scrum主管促進 Scrum過程,他的主要工作是去除那些影響團隊交付衝刺目標的障礙。Scrum主管並非團隊的領導(因為團隊是自我組織的),而是一個負責屏蔽外界對開發團隊的干擾的角色。Scrum主管確保Scrum過程被按照初衷使用。Scrum主管是規則的執行者。
開發團隊(dev team)
負責交付產品的團隊。一個團隊通常由5至9名具有跨職能技能的人(設計者,開發者等)組成,承擔實際的開發工作。

雞組的成員[編輯]

並不是實際Scrum過程的一部分,但是必須考慮他們。敏捷方法的一個重要方面是使得用戶和利益相關​​者參與到過程中的實踐。參與每一個衝刺的評審和計劃,並提供反饋對於這些人來說是非常重要的。

用戶
軟件是為了人而開發的。有人說,「假如森林裡有一棵樹倒下了,但沒有被人聽到,那麼它算是發出了聲音嗎?」同樣地,人們可以說,「假如軟件沒有被使用,那麼它算是被開發出來了麼?」
利益相關者(客戶,提供商)
影響項目成功的人,但只直接參與衝刺評審過程。
經理
為產品開發團體搭建環境的人。

Scrum會議[編輯]

在辦公室中間進行的「每日站立會議」,會議的位置有助於會議準時開始

在衝刺中,每一天都會舉行項目狀況會議,被稱為「scrum」或「每日站立會議」。每日站立會議有一些具體的指導原則:

  • 會議準時開始。
  • 歡迎所有人參加,但只有「豬」可以發言。
  • 不論團隊規模大小,會議被限制在15分鐘。
  • 所有出席者都應站立。(有助於保持會議簡短)
  • 會議應在固定地點和每天的同一時間舉行。

在會議上,每個團隊成員需要回答三個問題:

  1. 昨天你完成了那些工作?
  2. 今天你打算做什麼?
  3. 完成你的目標是否存在什麼障礙?(Scrum主管需要記下這些障礙)

每一個衝刺完成後,都會舉行一次衝刺回顧會議,在會議上所有團隊成員都要反思這個衝刺。舉行衝刺回顧會議是為了進行持續過程改進。會議的時間限制在4小時。

Scrum提倡所有團隊成員坐在一起工作,進行口頭交流,以及強調項目有關的規範(disciplines),這些有助於創造自我組織的團隊。

Scrum的一個關鍵原則是承認客戶可以在項目過程中改變主意,變更他們的需求,而預測式和計劃式的方法並不能輕易地解決這種不可預見的需求變化。同樣,Scrum採用了經驗方法– 承認問題無法完全理解或定義,而是關注於如何使得開發團隊快速推出和響應不斷出現的需求的能力最大化。

Scrum會議一共包含以下四種:

  1. 衝刺計劃會議
  2. 每日站立會議
  3. 評審會議
  4. 回顧會議。

文檔[編輯]

產品訂單[編輯]

產品訂單(product backlog)是整個專案的概要文檔。產品訂單包括所有所需特性的粗略的描述。產品訂單是關於將要生產什麼樣的產品。產品訂單是開放的,每個人都可以編輯。產品訂單包括粗略的估算,通常以天為單位。估算將幫助產品負責人衡量時程表和優先順序(例如,如果"增加拼寫檢查"特性的估計需要花3天或3個月,將影響產品負責人對該特性的渴望)。

衝刺訂單[編輯]

衝刺訂單(sprint backlog)是大大細化了的文檔,包含團隊如何實現下一個衝刺的需求的信息。任務被分解為以小時為單位,沒有任務可以超過16個小時。如果一個任務超過16個小時,那麼它就應該被進一步分解。衝刺訂單上的任務不會被分派,而是由團隊成員簽名認領他們喜愛的任務。

燃盡圖[編輯]

燃盡圖(burn down chart)是一個公開展示的圖表,顯示當前衝刺中未完成的任務數目,或在衝刺訂單上未完成的訂單項的數目。不要把燃盡圖與掙值圖相混淆。燃盡圖可能在一次衝刺的大部分時間內都維持平坦,但計畫仍然可以按照既定時間進行。

自適應的項目管理[編輯]

以下是一些Scrum的通用實踐:

  • 客戶成為開發團隊中的一部分。(例如客戶肯定對開發的結果真正感興趣。)
  • 和所有其他形式的敏捷軟件過程一樣,Scrum有頻繁的包含可以工作的功能的中間可交付成果。這使得客戶可以更早的得到可以工作的軟件,同時使得項目可以變更項目需求以適應不斷變化的需求。
  • 開發團隊經常評估風險並制定緩解計劃。在每一個階段根據承諾進行風險緩解,監測和管理(風險分析)。
  • 計劃和模塊開發要保持透明,讓每一個人知道誰負責什麼,以及什麼時候完成。
  • 參與者要經常開會以跟蹤項目進展 – 平衡的(發布,客戶,員工,過程)儀錶板更新 – 利益所有者更新。你必須擁有預警機制,例如在可能延期交付時提出警告。
  • 不要隱藏問題。認識到或說出任何沒有預見到的問題並不會受到懲罰。
  • 在工作場所和工作時間內必須全身心投入。– 完成更多的工作並不意味着需要工作更長時間。

Scrum術語[編輯]

下面是Scrum用到的術語[6]:

角色[編輯]

產品負責人 
負責維護產品訂單的人,代表利益相關者的利益。
Scrum主管 
為Scrum過程負責的人,確保scrum的正確使用並使得Scrum的收益最大化。
開發團隊 
由負責自我管理開發產品的人組成的跨職能團隊。
Scrum團隊
產品負責人,Scrum主管和開發團隊。

工件[編輯]

衝刺燃盡圖 
在衝刺長度上顯示每天進展的圖。
產品訂單 
按照優先級排序的高層需求。
衝刺訂單
要在衝刺中完成的任務的清單。

其他[編輯]

衝刺 
一個時間周期(通常在2周到1個月之間),開發團隊會在此期間內完成所承諾的一組訂單項的開發。

Scrum在其他領域的應用[編輯]

雖然Scrum最初只應用於軟件開發,它也可以被成功地應用於其他產業。現在Scrum通常被認為是一種用於開發任何產品或管理人和工作的迭代式的,增量的過程。

Scrum用於產品開發[編輯]

將Scrum應用於產品開發是在《T新新產品開發遊戲》(哈佛商業評論 86116:137-146, 1986年)第一次提出,之後野中郁次郎竹內弘高合著的《創造知識的企業》(牛津大學出版社,1995年)進行了詳細的闡述。今天Scrum被用於開發金融產品,互聯網產品,以及醫藥產品。

Scrum用作營銷項目管理方法[編輯]

由於市場營銷通常以專案的方式運作,許多一般專案管理的原則應用在市場營銷上。市場營銷也可以像專案管理技術那樣進行優化。以Scrum方法進行市場營銷被認為有助於克服市場營銷經理們所遇到的問題。短時和固定的會議對於小的市場營銷團隊來說很重要,這是因為團隊的每一個成員都可以了解其他人在做些什麼,以及整個團隊在朝着什麼方向前進。Scrum在市場營銷中應用可以:

  • 在早期發現可能的問題,可以更快地,最小損失地應對問題。 根據Scrum的主要原則 「沒有問題被掃入地毯下」,Scrum鼓勵每一個團隊成員描述他所遇到的困難,而這個困難可能會對整個團隊的工作造成影響。
  • 降低財務風險。 在每一個衝刺周期的開始,企業所有者可以不付出任何代價的改變任何市場營銷的因素:包括增加投資以擴大顧客數量,減少投資直至未知風險被減輕,或用於支持其他活動。
  • 使得市場營銷計劃更靈活。採用衝刺的短期市場營銷計劃可以更加有效。如果一種促銷方法在衝刺過程中顯示無效,市場營銷經理有機會將其換成另一種促銷方法。向每一個團隊成員說明每一個小的,但重要的任務的交付時間也變得更容易。
  • 使得客戶以不同的方式參與。

參見[編輯]

外部連結[編輯]

參考文獻[編輯]

  1. ^ Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)
  2. ^ Peter DeGrace, Leslie Hulet Stahl, Wicked problems, righteous solutions, 1990, ISBN 0-13-590126-X
  3. ^ Jeff Sutherland, AGILE DEVELOPMENT: LESSONS LEARNED FROM THE FIRST SCRUM, 2004
  4. ^ Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004年1月: 163. ISBN 0-7356-1993-X. 
  5. ^ Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004年1月: 7. ISBN 0-7356-1993-X. 
  6. ^ page 141-143