什么是 Scrum ?

　　Scrum是一種迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā)。Scrum在英語的意思是橄欖球里的爭球。
　　雖然Scrum是為管理軟件開發(fā)項目而開發(fā)的，它同樣可以用于運行軟件維護團隊，或者作為計劃管理方法：Scrum of Scrums 。
　　相關(guān)線上資料：http://zh.wikipedia.org/wiki/Scrum

　　角色

　　Scrum定義了許多角色，根據(jù)豬和雞的笑話分為兩組，豬和雞：

　　一天，一頭豬和一只雞在路上散步，雞看了一下豬說，“嗨，我們合伙開一家餐館怎么樣？”，豬回頭看了一下雞說，“好主意，那你準備給餐館賣什么呢？”，雞想了想說“餐館賣火腿和雞蛋怎么樣？”，“我不這么認為”，豬說，“我全身投入，而你只是參與而已”。

　　這個笑話挺冷的……不過倒是比較準確的劃分了項目參與人員。

　　豬組

　　豬組的成員是在Scrum過程中全身投入項目的各種角色，他們在項目中承擔(dān)實際工作。他們有些像上邊那個笑話里的豬，要把自己身上的肉貢獻出來。

• 產(chǎn)品負責(zé)人
  產(chǎn)品負責(zé)人代表了客戶的意愿。這保證了Scrum團隊在做從業(yè)務(wù)角度來說正確的事情。產(chǎn)品負責(zé)人編寫用戶故事，排出優(yōu)先級，并放入產(chǎn)品訂單。
• Scrum主管（或促進者）
  Scrum主管促進Scrum過程，他的主要工作是去除那些影響團隊交付沖刺目標的障礙。Scrum主管并非團隊的領(lǐng)導(dǎo)（因為團隊是自我組織的），而是一個負責(zé)屏蔽外界對開發(fā)團隊的干擾的角色。Scrum主管確保Scrum過程被按照初衷使用。Scrum主管是規(guī)則的執(zhí)行者。
• 開發(fā)團隊
  負責(zé)交付產(chǎn)品的團隊。一個團隊通常由5至9名具有跨職能技能的人（設(shè)計者，開發(fā)者等）組成，承擔(dān)實際的開發(fā)工作。

　　 雞組

　　雞組的成員并不是實際Scrum過程的一部分，但是必須考慮他們。敏捷方法的一個重要方面是使得用戶和利益相關(guān)者參與到過程中的時間。參與每一個沖刺的評審和計劃，并提供反饋對于這些人來說是非常重要的。

• 用戶
  軟件是為了人而開發(fā)的。有人說，“假如森林里有一棵樹倒下了，但沒有被人聽到，那么它算是發(fā)出了聲音嗎？”同樣地，人們可以說，“假如軟件沒有被使用，那么它算是被開發(fā)出來了么？”
• 利益相關(guān)者（客戶，提供商）
  影響項目成功的人，但只直接參與沖刺評審過程。
• 經(jīng)理
  為產(chǎn)品開發(fā)團體搭建環(huán)境的人。

　　經(jīng)驗：

1. Scrum主管開發(fā)的時間可能不會很多，一般來說也不適合參與開發(fā)，因為排解外部干擾，解決項目組障礙都會花去很多零碎時間進行溝通以及其他事務(wù)，都會干擾個人的正常開發(fā)。
2. 建議不要讓開發(fā)主力擔(dān)任Scrum主管，應(yīng)當(dāng)由擅長溝通，有較深技術(shù)底蘊，對產(chǎn)品比較熟悉或者理解深刻的人員擔(dān)任。
3. Scrum主管與開發(fā)人員是平級的，身份對等，所做的工作更有點偏向于服務(wù)形式。其本身基本上可以看做是一個“人形文檔”，項目執(zhí)行中任何需要產(chǎn)品文檔的地方，比如咨詢，需求變更，新成員培訓(xùn)等等都由Scrum主管負責(zé)。
4. 對一個項目來講，Scrum主管非常重要，其他成員可以變更，但絕對要避免Scrum主管的變更。Scrum主管的責(zé)任也很龐雜，需要擅長處理并發(fā)事件的人來擔(dān)當(dāng)此角色。
5. Scrum的效率核心就是“排除干擾”，開發(fā)人員可以為一個項目全力以赴。Scrum主管對干擾的排除能力直接決定了項目執(zhí)行效率。
6. 所有的分歧交由Scrum主管來敲定，因此其技術(shù)能力與現(xiàn)實業(yè)務(wù)解決能力不能忽視，應(yīng)當(dāng)從開發(fā)人員中抽取人員負責(zé)此工作。考慮到離開開發(fā)崗位一段時間，技術(shù)能力會有所退化，建議輪崗。

　　會議

　　在沖刺中，每一天都會舉行項目狀況會議，被稱為“scrum”或“每日站立會議”。每日站立會議有一些具體的指導(dǎo)原則：

• 會議準時開始。對于遲到者團隊常常會制定懲罰措施（例如罰款，做俯臥撐，在脖子上掛橡膠雞玩具）
• 歡迎所有人參加，但只有”豬”可以發(fā)言。
• 不論團隊規(guī)模大小，會議被限制在15分鐘。
• 所有出席者都應(yīng)站立。（有助于保持會議簡短）
• 會議應(yīng)在固定地點和每天的同一時間舉行。

　　假設(shè)會議定在每天下午下班前，在會議上，每個團隊成員需要回答三個問題：

1. 今天你完成了那些工作？
2. 明天你打算做什么？
3. 完成你的目標是否存在什么障礙？（Scrum主管需要記下這些障礙）

　　每一個沖刺完成后，都會舉行一次沖刺回顧會議，在會議上所有團隊成員都要反思這個沖刺。舉行沖刺回顧會議是為了進行持續(xù)過程改進。

　　會議的時間限制在4小時。

　　經(jīng)驗：

1. Scrum會議的核心是：不要太長！應(yīng)當(dāng)盡量避免任何可能導(dǎo)致會議延長的事情。
2. 項目開發(fā)開始前的會議不要過長，主要確定方向，任務(wù)與最關(guān)鍵的技術(shù)細節(jié)。應(yīng)提供一個技術(shù)預(yù)備期供大家分享要使用的技術(shù)知識或者制定開發(fā)規(guī)范。
3. 項目開發(fā)正式開始前，必須達成必要的開發(fā)共識，必須完成基本的開發(fā)約定。每個人并不是只維護自己的代碼。
4. Scrum會議的督促作用非常明顯，但也會給成員帶來相當(dāng)?shù)膲毫ΑＴ谛掳鏁T中心開發(fā)過程中，曾發(fā)生成員開發(fā)壓力過高而離職的事件。Scrum主管有必要注意排解成員壓力。

　　下面幾點有助于降低成員壓力：

1. 讓開發(fā)人員領(lǐng)取自己喜歡和擅長的任務(wù)。
2. 項目開始前充分預(yù)估時間，務(wù)必實事求是，并考慮到成員的開發(fā)能力。
3. 開發(fā)前（或者日常）最好能進行幾次技術(shù)培訓(xùn)，避免成員在開發(fā)中遇到不熟悉的技術(shù)。

　　沖刺訂單

• 沖刺訂單（sprint backlog）是大大細化了的文檔，包含團隊如何實現(xiàn)下一個沖刺的需求的信息。
• 任務(wù)被分解為以小時為單位，沒有任務(wù)可以超過16個小時。
• 如果一個任務(wù)超過16個小時，那么它就應(yīng)該被進一步分解。
• 沖刺訂單上的任務(wù)不會被分派，而是由團隊成員簽名認領(lǐng)他們喜愛的任務(wù)。
• 一個任務(wù)分為todo ，開發(fā)中，自測，提交測試，完成幾個階段。

　　經(jīng)驗：
　　WEBIM項目實施白板：
　　左邊的用戶故事，實際上是對沖刺訂單的分類。

　　訂單一開始都在 todo 的下面，每個開發(fā)人員到實施白板前，審核還有那些訂單在todo當(dāng)中，從中選擇自己喜歡或者相對擅長的訂單，寫上自己的名字，放在開發(fā)中，然后回去開發(fā)相應(yīng)組件。

　　當(dāng)組件基本開發(fā)完畢，就將訂單放在自測欄下面。

　　如果準備將該組件提交測試，就將訂單放在測試欄下面。

　　如果組件通過測試，就放在完成欄下面。這樣一個組件就走完了整個開發(fā)流程。

　　實際開發(fā)中發(fā)現(xiàn)，由于測試實際上是在所有組件都完成開發(fā)后才執(zhí)行的，所以訂單放到自測階段就基本上可以視為開發(fā)完畢，開發(fā)人員就應(yīng)該去領(lǐng)新的訂單了。

　　WEBIM項目中訂單用便簽實現(xiàn)：
　　WEBIM開發(fā)中，每個訂單對應(yīng)的是一個開發(fā)組件，標記了組件名稱，類別，開發(fā)人員，預(yù)估時間。對應(yīng)開發(fā)組件模型如下：

　　Name為組件名稱，也是開發(fā)時的小文件名稱。
　　Extends 為該組件繼承自哪一個組件。
　　Property 為組件應(yīng)當(dāng)具有的屬性。
　　Methods 為組件應(yīng)當(dāng)具有的方法。
　　SP 為開發(fā)該組件可能的耗時。1SP表示1個工作日（單個成員8個工作時）

　　項目開始前的集中會議非常重要，需要所有開發(fā)成員集中在一起執(zhí)行。
　　應(yīng)當(dāng)集群體之力一起分析項目，拆解組件，但注意非關(guān)鍵性的細節(jié)不要過分追究，避免會議耗時。
　　應(yīng)當(dāng)有一個文檔保存所有畫出的組件模型。

　　燃盡圖

　　燃盡圖可以非常形象的表現(xiàn)項目執(zhí)行進度。
　　以下圖舉例：
　　X軸原點為項目開始日期，末端為項目結(jié)束日期。每天為一格。
　　Y軸為預(yù)估的工作時。

• 在項目準備會議結(jié)束時，沖刺訂單已經(jīng)預(yù)備好，就可以統(tǒng)計出預(yù)估的總工作時，將其標在Y軸頂部。
• 每天檢查實施白板，確認哪些訂單已經(jīng)完成，然后計算剩下的總工作時，然后在圖上標記一個點，點的X位置為第二天的日期，Y位置為剩下的總工作時。
• 在起點坐標（X為開始日期，Y為總時間）和終點坐標（X為結(jié)束日期，Y為0）之間畫一條直線，這就是理想狀況下的項目完成進度曲線。
• 在項目執(zhí)行中，發(fā)現(xiàn)曲線高于理想曲線，說明項目有可能延期，需要增派援手，或者催促成員加快進度。如果曲線低于理想曲線，說明項目有可能提前完成。

　　經(jīng)驗：
　　先看一下WEBIM項目的燃盡圖：
　　不可思議的是曲線一開始居然還有個增高。這說明一開始時間預(yù)估就不完善，開發(fā)中增加了預(yù)估時間。

　　一開始認為訂單放到完成，才能從工作時中減去時間，但由于測試實際上是在所有組件開發(fā)完成后，所以當(dāng)訂單放在自測，就從工作時中減去時間。

　　這個圖后期并沒有完成。實際上是因為項目組件提前在12日都開發(fā)完成，但是新的問題出現(xiàn)：組件完成后還有一個聯(lián)調(diào)的時間，未被預(yù)估在內(nèi)。還好最終還是保證了項目按期聯(lián)調(diào)完畢。

　　燃盡圖后期的陡峭往往說明了任務(wù)分割與時間估算的不完善。但是有時這不可避免，可以考慮用完成度百分比乘以工作任務(wù)，或者將任務(wù)分階段（將預(yù)備階段，開發(fā)階段與測試階段分開）來平緩燃盡圖曲線，達到更細致描繪工作進度的目的。

　　可以考慮聯(lián)調(diào)前的訂單被開發(fā)完成了70%，聯(lián)調(diào)完畢才標記為100%，然后從總工作時中減去剩下百分比的時間。

　　一開始預(yù)估完總工作時間后，應(yīng)當(dāng)乘以一個系數(shù)（大于1，從未預(yù)估過時間，建議這個系數(shù)接近甚至大于2，否則建議為1.5）。以這個時間為總工作時間，以應(yīng)付項目執(zhí)行中可能遇到的突發(fā)事件。

　　總結(jié)

　　Scrum 效率相當(dāng)明顯，執(zhí)行過程中可以使成員中開發(fā)速度緩慢的地方被迅速暴露出來，使得項目中可能存在的問題被極早暴露，以便進行針對性的解決。

　　開發(fā)中要求成員有充分的自發(fā)性，自己如果能提前完成訂單，應(yīng)當(dāng)負責(zé)起其他訂單的開發(fā)任務(wù)，減輕項目整體的開發(fā)負擔(dān)。

　　一開始的溝通會議非常重要，必須當(dāng)面進行溝通會議，不可以有缺席。以保證每個成員對項目的細節(jié)都有所了解，可以負責(zé)任意一個組件的開發(fā)。

　　Scrum不僅僅用于軟件開發(fā)，它是一種計劃管理方式，適用于被限制時間，需要多人協(xié)作的團隊項目。

it知識庫：Scrum 實施經(jīng)驗，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。