|
什么是 Scrum ?
Scrum是一種迭代式增量軟件開發過程,通常用于敏捷軟件開發。Scrum在英語的意思是橄欖球里的爭球。
雖然Scrum是為管理軟件開發項目而開發的,它同樣可以用于運行軟件維護團隊,或者作為計劃管理方法:Scrum of Scrums 。
相關線上資料:http://zh.wikipedia.org/wiki/Scrum
角色
Scrum定義了許多角色,根據豬和雞的笑話分為兩組,豬和雞:
一天,一頭豬和一只雞在路上散步,雞看了一下豬說,“嗨,我們合伙開一家餐館怎么樣?”,豬回頭看了一下雞說,“好主意,那你準備給餐館賣什么呢?”,雞想了想說“餐館賣火腿和雞蛋怎么樣?”,“我不這么認為”,豬說,“我全身投入,而你只是參與而已”。
這個笑話挺冷的……不過倒是比較準確的劃分了項目參與人員。
豬組
豬組的成員是在Scrum過程中全身投入項目的各種角色,他們在項目中承擔實際工作。他們有些像上邊那個笑話里的豬,要把自己身上的肉貢獻出來。
- 產品負責人
產品負責人代表了客戶的意愿。這保證了Scrum團隊在做從業務角度來說正確的事情。產品負責人編寫用戶故事,排出優先級,并放入產品訂單。 - Scrum主管(或促進者)
Scrum主管促進Scrum過程,他的主要工作是去除那些影響團隊交付沖刺目標的障礙。Scrum主管并非團隊的領導(因為團隊是自我組織的),而是一個負責屏蔽外界對開發團隊的干擾的角色。Scrum主管確保Scrum過程被按照初衷使用。Scrum主管是規則的執行者。 - 開發團隊
負責交付產品的團隊。一個團隊通常由5至9名具有跨職能技能的人(設計者,開發者等)組成,承擔實際的開發工作。
雞組
雞組的成員并不是實際Scrum過程的一部分,但是必須考慮他們。敏捷方法的一個重要方面是使得用戶和利益相關者參與到過程中的時間。參與每一個沖刺的評審和計劃,并提供反饋對于這些人來說是非常重要的。
- 用戶
軟件是為了人而開發的。有人說,“假如森林里有一棵樹倒下了,但沒有被人聽到,那么它算是發出了聲音嗎?”同樣地,人們可以說,“假如軟件沒有被使用,那么它算是被開發出來了么?” - 利益相關者(客戶,提供商)
影響項目成功的人,但只直接參與沖刺評審過程。 - 經理
為產品開發團體搭建環境的人。
經驗:
- Scrum主管開發的時間可能不會很多,一般來說也不適合參與開發,因為排解外部干擾,解決項目組障礙都會花去很多零碎時間進行溝通以及其他事務,都會干擾個人的正常開發。
- 建議不要讓開發主力擔任Scrum主管,應當由擅長溝通,有較深技術底蘊,對產品比較熟悉或者理解深刻的人員擔任。
- Scrum主管與開發人員是平級的,身份對等,所做的工作更有點偏向于服務形式。其本身基本上可以看做是一個“人形文檔”,項目執行中任何需要產品文檔的地方,比如咨詢,需求變更,新成員培訓等等都由Scrum主管負責。
- 對一個項目來講,Scrum主管非常重要,其他成員可以變更,但絕對要避免Scrum主管的變更。Scrum主管的責任也很龐雜,需要擅長處理并發事件的人來擔當此角色。
- Scrum的效率核心就是“排除干擾”,開發人員可以為一個項目全力以赴。Scrum主管對干擾的排除能力直接決定了項目執行效率。
- 所有的分歧交由Scrum主管來敲定,因此其技術能力與現實業務解決能力不能忽視,應當從開發人員中抽取人員負責此工作。考慮到離開開發崗位一段時間,技術能力會有所退化,建議輪崗。
會議
在沖刺中,每一天都會舉行項目狀況會議,被稱為“scrum”或“每日站立會議”。每日站立會議有一些具體的指導原則:
- 會議準時開始。對于遲到者團隊常常會制定懲罰措施(例如罰款,做俯臥撐,在脖子上掛橡膠雞玩具)
- 歡迎所有人參加,但只有”豬”可以發言。
- 不論團隊規模大小,會議被限制在15分鐘。
- 所有出席者都應站立。(有助于保持會議簡短)
- 會議應在固定地點和每天的同一時間舉行。
假設會議定在每天下午下班前,在會議上,每個團隊成員需要回答三個問題:
- 今天你完成了那些工作?
- 明天你打算做什么?
- 完成你的目標是否存在什么障礙?(Scrum主管需要記下這些障礙)
每一個沖刺完成后,都會舉行一次沖刺回顧會議,在會議上所有團隊成員都要反思這個沖刺。舉行沖刺回顧會議是為了進行持續過程改進。
會議的時間限制在4小時。
經驗:
- Scrum會議的核心是:不要太長!應當盡量避免任何可能導致會議延長的事情。
- 項目開發開始前的會議不要過長,主要確定方向,任務與最關鍵的技術細節。應提供一個技術預備期供大家分享要使用的技術知識或者制定開發規范。
- 項目開發正式開始前,必須達成必要的開發共識,必須完成基本的開發約定。每個人并不是只維護自己的代碼。
- Scrum會議的督促作用非常明顯,但也會給成員帶來相當的壓力。在新版會員中心開發過程中,曾發生成員開發壓力過高而離職的事件。Scrum主管有必要注意排解成員壓力。
下面幾點有助于降低成員壓力:
- 讓開發人員領取自己喜歡和擅長的任務。
- 項目開始前充分預估時間,務必實事求是,并考慮到成員的開發能力。
- 開發前(或者日常)最好能進行幾次技術培訓,避免成員在開發中遇到不熟悉的技術。
沖刺訂單
- 沖刺訂單(sprint backlog)是大大細化了的文檔,包含團隊如何實現下一個沖刺的需求的信息。
- 任務被分解為以小時為單位,沒有任務可以超過16個小時。
- 如果一個任務超過16個小時,那么它就應該被進一步分解。
- 沖刺訂單上的任務不會被分派,而是由團隊成員簽名認領他們喜愛的任務。
- 一個任務分為todo ,開發中,自測,提交測試,完成幾個階段。
經驗:
WEBIM項目實施白板: 左邊的用戶故事,實際上是對沖刺訂單的分類。
訂單一開始都在 todo 的下面,每個開發人員到實施白板前,審核還有那些訂單在todo當中,從中選擇自己喜歡或者相對擅長的訂單,寫上自己的名字,放在開發中,然后回去開發相應組件。
當組件基本開發完畢,就將訂單放在自測欄下面。
如果準備將該組件提交測試,就將訂單放在測試欄下面。
如果組件通過測試,就放在完成欄下面。這樣一個組件就走完了整個開發流程。
實際開發中發現,由于測試實際上是在所有組件都完成開發后才執行的,所以訂單放到自測階段就基本上可以視為開發完畢,開發人員就應該去領新的訂單了。
WEBIM項目中訂單用便簽實現: WEBIM開發中,每個訂單對應的是一個開發組件,標記了組件名稱,類別,開發人員,預估時間。對應開發組件模型如下:
Name | Events |
Extends | |
Property | _$events |
Methods | addEvent removeEvent addEvents removeEvents fireEvent |
SP | 0.25 |
Name為組件名稱,也是開發時的小文件名稱。
Extends 為該組件繼承自哪一個組件。
Property 為組件應當具有的屬性。
Methods 為組件應當具有的方法。
SP 為開發該組件可能的耗時。1SP表示1個工作日(單個成員8個工作時)
項目開始前的集中會議非常重要,需要所有開發成員集中在一起執行。
應當集群體之力一起分析項目,拆解組件,但注意非關鍵性的細節不要過分追究,避免會議耗時。
應當有一個文檔保存所有畫出的組件模型。
燃盡圖
燃盡圖可以非常形象的表現項目執行進度。
以下圖舉例:
X軸原點為項目開始日期,末端為項目結束日期。每天為一格。
Y軸為預估的工作時。
- 在項目準備會議結束時,沖刺訂單已經預備好,就可以統計出預估的總工作時,將其標在Y軸頂部。
- 每天檢查實施白板,確認哪些訂單已經完成,然后計算剩下的總工作時,然后在圖上標記一個點,點的X位置為第二天的日期,Y位置為剩下的總工作時。
- 在起點坐標(X為開始日期,Y為總時間)和終點坐標(X為結束日期,Y為0)之間畫一條直線,這就是理想狀況下的項目完成進度曲線。
- 在項目執行中,發現曲線高于理想曲線,說明項目有可能延期,需要增派援手,或者催促成員加快進度。如果曲線低于理想曲線,說明項目有可能提前完成。
經驗:
先看一下WEBIM項目的燃盡圖: 不可思議的是曲線一開始居然還有個增高。這說明一開始時間預估就不完善,開發中增加了預估時間。
一開始認為訂單放到完成,才能從工作時中減去時間,但由于測試實際上是在所有組件開發完成后,所以當訂單放在自測,就從工作時中減去時間。
這個圖后期并沒有完成。實際上是因為項目組件提前在12日都開發完成,但是新的問題出現:組件完成后還有一個聯調的時間,未被預估在內。還好最終還是保證了項目按期聯調完畢。
燃盡圖后期的陡峭往往說明了任務分割與時間估算的不完善。但是有時這不可避免,可以考慮用完成度百分比乘以工作任務,或者將任務分階段(將預備階段,開發階段與測試階段分開)來平緩燃盡圖曲線,達到更細致描繪工作進度的目的。
可以考慮聯調前的訂單被開發完成了70%,聯調完畢才標記為100%,然后從總工作時中減去剩下百分比的時間。
一開始預估完總工作時間后,應當乘以一個系數(大于1,從未預估過時間,建議這個系數接近甚至大于2,否則建議為1.5)。以這個時間為總工作時間,以應付項目執行中可能遇到的突發事件。
總結
Scrum 效率相當明顯,執行過程中可以使成員中開發速度緩慢的地方被迅速暴露出來,使得項目中可能存在的問題被極早暴露,以便進行針對性的解決。
開發中要求成員有充分的自發性,自己如果能提前完成訂單,應當負責起其他訂單的開發任務,減輕項目整體的開發負擔。
一開始的溝通會議非常重要,必須當面進行溝通會議,不可以有缺席。以保證每個成員對項目的細節都有所了解,可以負責任意一個組件的開發。
Scrum不僅僅用于軟件開發,它是一種計劃管理方式,適用于被限制時間,需要多人協作的團隊項目。
it知識庫:Scrum 實施經驗,轉載需保留來源!
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。