什麼是 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過程的一部分，但是必須考慮他們。敏捷方法的一個重要方面是使得使用者和利益相關者參與到過程中的時間。參與每一個衝刺的評審和計劃，並提供反饋對於這些人來說是非常重要的。
使用者
軟體是為了人而開發的。有人說，“假如森林裡有一棵樹倒下了，但沒有被人聽到，那麼它算是發出了聲音嗎？”同樣地，人們可以說，“假如軟體沒有被使用，那麼它算是被開發出來了麼？”
利益相關者（客戶，提供商）
影響專案成功的人，但只直接參與衝刺評審過程。
經理
為產品開發團體搭建環境的人。
經驗：
1. Scrum主管開發的時間可能不會很多，一般來說也不適合參與開發，因為排解外部干擾，解決專案組障礙都會花去很多零碎時間進行溝通以及其他事務，都會干擾個人的正常開發。
2. 建議不要讓開發主力擔任Scrum主管，應當由擅長溝通，有較深技術底蘊，對產品比較熟悉或者理解深刻的人員擔任。
3. Scrum主管與開發人員是平級的，身份對等，所做的工作更有點偏向於服務形式。其本身基本上可以看做是一個“人形文件”，專案執行中任何需要產品文件的地方，比如諮詢，需求變更，新成員培訓等等都由Scrum主管負責。
4. 對一個專案來講，Scrum主管非常重要，其他成員可以變更，但絕對要避免Scrum主管的變更。Scrum主管的責任也很龐雜，需要擅長處理併發事件的人來擔當此角色。
5. Scrum的效率核心就是“排除干擾”，開發人員可以為一個專案全力以赴。Scrum主管對干擾的排除能力直接決定了專案執行效率。
6. 所有的分歧交由Scrum主管來敲定，因此其技術能力與現實業務解決能力不能忽視，應當從開發人員中抽取人員負責此工作。考慮到離開開發崗位一段時間，技術能力會有所退化，建議輪崗。
會議
在衝刺中，每一天都會舉行專案狀況會議，被稱為“scrum”或“每日站立會議”。每日站立會議有一些具體的指導原則：
- 會議準時開始。對於遲到者團隊常常會制定懲罰措施（例如罰款，做俯臥撐，在脖子上掛橡膠雞玩具）
- 歡迎所有人參加，但只有”豬”可以發言。
- 不論團隊規模大小，會議被限制在15分鐘。
- 所有出席者都應站立。（有助於保持會議簡短）
- 會議應在固定地點和每天的同一時間舉行。
假設會議定在每天下午下班前，在會議上，每個團隊成員需要回答三個問題：
- 1. 今天你完成了那些工作？
- 2. 明天你打算做什麼？
- 3. 完成你的目標是否存在什麼障礙？（Scrum主管需要記下這些障礙）
每一個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上所有團隊成員都要反思這個衝刺。舉行衝刺回顧會議是為了進行持續過程改進。
會議的時間限制在4小時。
經驗：
- 1. Scrum會議的核心是：不要太長！應當儘量避免任何可能導致會議延長的事情。
- 2. 專案開發開始前的會議不要過長，主要確定方向，任務與最關鍵的技術細節。應提供一個技術預備期供大家分享要使用的技術知識或者制定開發規範。
- 3. 專案開發正式開始前，必須達成必要的開發共識，必須完成基本的開發約定。每個人並不是只維護自己的程式碼。
- 4. Scrum會議的督促作用非常明顯，但也會給成員帶來相當的壓力。在新版會員中心開發過程中，曾發生成員開發壓力過高而離職的事件。Scrum主管有必要注意排解成員壓力。
下面幾點有助於降低成員壓力：
- 1. 讓開發人員領取自己喜歡和擅長的任務。
- 2. 專案開始前充分預估時間，務必實事求是，並考慮到成員的開發能力。
- 3. 開發前（或者日常）最好能進行幾次技術培訓，避免成員在開發中遇到不熟悉的技術。
衝刺訂單
- 衝刺訂單（sprint backlog）是大大細化了的文件，包含團隊如何實現下一個衝刺的需求的資訊。
- 任務被分解為以小時為單位，沒有任務可以超過16個小時。
- 如果一個任務超過16個小時，那麼它就應該被進一步分解。
- 衝刺訂單上的任務不會被分派，而是由團隊成員簽名認領他們喜愛的任務。
- 一個任務分為todo ，開發中，自測，提交測試，完成幾個階段。
經驗：
WEBIM專案實施白板：
左邊的使用者故事，實際上是對衝刺訂單的分類。
訂單一開始都在 todo 的下面，每個開發人員到實施白板前，稽核還有那些訂單在todo當中，從中選擇自己喜歡或者相對擅長的訂單，寫上自己的名字，放在開發中，然後回去開發相應元件。
當元件基本開發完畢，就將訂單放在自測欄下面。
如果準備將該元件提交測試，就將訂單放在測試欄下面。
如果元件通過測試，就放在完成欄下面。這樣一個元件就走完了整個開發流程。
實際開發中發現，由於測試實際上是在所有元件都完成開發後才執行的，所以訂單放到自測階段就基本上可以視為開發完畢，開發人員就應該去領新的訂單了。
WEBIM專案中訂單用便籤實現：
WEBIM開發中，每個訂單對應的是一個開發元件，標記了元件名稱，類別，開發人員，預估時間。對應開發元件模型如下：
專案開始前的集中會議非常重要，需要所有開發成員集中在一起執行。
應當叢集體之力一起分析專案，拆解元件，但注意非關鍵性的細節不要過分追究，避免會議耗時。
應當有一個文件儲存所有畫出的元件模型。
燃盡圖
燃盡圖可以非常形象的表現專案執行進度。
以下圖舉例：
X軸原點為專案開始日期，末端為專案結束日期。每天為一格。
Y軸為預估的工作時。
- 在專案準備會議結束時，衝刺訂單已經預備好，就可以統計出預估的總工作時，將其標在Y軸頂部。
- 每天檢查實施白板，確認哪些訂單已經完成，然後計算剩下的總工作時，然後在圖上標記一個點，點的X位置為第二天的日期，Y位置為剩下的總工作時。
- 在起點座標（X為開始日期，Y為總時間）和終點座標（X為結束日期，Y為0）之間畫一條直線，這就是理想狀況下的專案完成進度曲線。
- 在專案執行中，發現曲線高於理想曲線，說明專案有可能延期，需要增派援手，或者催促成員加快進度。如果曲線低於理想曲線，說明專案有可能提前完成。
經驗：
先看一下WEBIM專案的燃盡圖：
不可思議的是曲線一開始居然還有個增高。這說明一開始時間預估就不完善，開發中增加了預估時間。
一開始認為訂單放到完成，才能從工作時中減去時間，但由於測試實際上是在所有元件開發完成後，所以當訂單放在自測，就從工作時中減去時間。
這個圖後期並沒有完成。實際上是因為專案元件提前在12日都開發完成，但是新的問題出現：元件完成後還有一個聯調的時間，未被預估在內。還好最終還是保證了專案按期聯調完畢。
燃盡圖後期的陡峭往往說明了任務分割與時間估算的不完善。但是有時這不可避免，可以考慮用完成度百分比乘以工作任務，或者將任務分階段（將預備階段，開發階段與測試階段分開）來平緩燃盡圖曲線，達到更細緻描繪工作進度的目的。
可以考慮聯調前的訂單被開發完成了70%，聯調完畢才標記為100%，然後從總工作時中減去剩下百分比的時間。
一開始預估完總工作時間後，應當乘以一個係數（大於1，從未預估過時間，建議這個係數接近甚至大於2，否則建議為1.5）。以這個時間為總工作時間，以應付專案執行中可能遇到的突發事件。
總結
Scrum 效率相當明顯，執行過程中可以使成員中開發速度緩慢的地方被迅速暴露出來，使得專案中可能存在的問題被極早暴露，以便進行鍼對性的解決。
開發中要求成員有充分的自發性，自己如果能提前完成訂單，應當負責起其他訂單的開發任務，減輕專案整體的開發負擔。
一開始的溝通會議非常重要，必須當面進行溝通會議，不可以有缺席。以保證每個成員對專案的細節都有所瞭解，可以負責任意一個元件的開發。
Scrum不僅僅用於軟體開發，它是一種計劃管理方式，適用於被限制時間，需要多人協作的團隊專案。
原文：sina ued