本文**
scrum是一種靈活的敏捷軟體開發管理過程。這個名詞**於英式橄欖球。scrum方法由ken schwaber和 jeff sutherland 提出，它將軟體開發團隊比作橄欖球隊，全隊有明確的最高目標：發布產品的重要性高於一切。團隊高度自治，隊員們熟悉開發過程中涉及到的各種技術，緊密合作，確保每個迭代都朝著最高目標推進。而且每隔2至6周，每個人都能看到能實際工作的軟體，並且據此決定是發布這個版本還是繼續開發以加強它的功能。
對於功能需求可能經常發生變化的專案來說，scrum是它們最為理想的選擇之一。在乙個採用scrum的專案中，首先要將所有需要完成的工作列在乙個產品待開發項(product backlog)中，專案開發過程中需求的改變也要寫進去。在每個迭代(sprint)開始之前，要開乙個迭代計畫會議(sprint planning meetting)。在會上，產品責任人(product owner)為 product backlog中的各功能需求確定優先順序(或者是在會前完成)，隨後scrum開發團隊按照優先順序，從product backlog中挑選出他們認為能在本次迭代中完成的任務，把它們從product backlog中挪到sprint backlog中來。在sprint進行過程中，scrum團隊每一天都要舉行乙個簡短的每日立會(daily stand-up meeting)，以便團隊成員了解開發進度。sprint結束之後，需要開評審會(review meeting)和反思會(restrospective meeting)。開發團隊在評審會上把這個sprint的開發成果展示給大家看；而在反思會上，團隊成員們會回顧過去的這個sprint，從中總結經驗和教訓。
那麼什麼是product backlog？什麼是sprint backlog？
產品待開發項(product backlog)：根據初始需求分解出的任務列表，包括功能性的和非功能性的所有功能； 由product owner為product backlog中的任務確定優先級別；當開發團隊開始做某個任務的時候，再精確定義和分解這個任務。
product backlog是產品所要具備的所有功能的總綱。當乙個專案剛剛開始時，沒人能夠事先預見到所有的任務和需求，並為之做乙個充分、詳細而又包羅永珍的計畫。可行的方式是，先為乙個專案寫下所有它應該具備的顯著特徵和功能，數量不必很多，最好夠讓團隊的第乙個sprint有活可幹。隨著sprint的進行，生產出可發布的產品增量，客戶對產品的直觀認識也隨之加深，他們可以據此建議更改或者新增產品backlog中的任務。
在sprint計畫會議上，產品負責人人為產品backlog中的任務確定優先順序，並向scrum團隊描述這些任務。scrum團隊隨後根據團隊整體情況，確定他們能在這個即將到來的sprint中完成哪些功能，並把它們挪到sprint backlog中去。
迭代計畫會(sprint planning meeting) ：在每個sprint開始之前，需要召開sprint計畫會議，一般為4至8個小時。參加人員有產品責任人、scrum master、scrum團隊和其他感興趣的人，比如管理層人員和客戶代表。product owner從產品backlog中挑選優先度高的任務，並與scrum團隊一起決定在這個sprint中需要完成多少功能；scrum團隊將這些任務分解成小的功能模組； scrum團隊成員詳細討論如何能按需求完成這些功能模組，並估計完成每個功能模組所需的大概時間。
每日立會(daily stand-up meeting)：既團隊每日例會，條件允許的話，每天都應該在同樣的時間和地點，所有成員站立著舉行。由於是站立的狀態開會，因此時間比較短，一般為15分鐘左右。這個會議最好是在每天的早晨開，有利於團隊成員們安排好當天的工作計畫。只有團隊成員可以在每日scrum會議上發言，其他人員如果對專案進度有興趣也可以參加，但只能旁聽而不能發言。
會議由scrum master主持，scrum團隊的所有成員輪流回答上圖中的三個問題，即：
昨天我完成了什麼工作；
今天我打算做什麼；
我遇到了什麼障礙。
通過這三個問題，團隊成員之間可以彼此相互熟悉工作內容，充分了解專案進度，相互幫助解決問題。scrum master除了傾聽團隊成員的發言外，他還有責任設法解決團隊成員在會上提出的困難，盡快掃除阻礙他們工作的障礙。即使有的問題scrum master沒有能力解決，例如某些技術細節問題等，他也應該找到團隊中或其他團隊的來幫助快速的解決問題。另外，還有兩點需要注意的地方：其一，這是團隊成員之間的交流，也是相互的承諾，並不是用來向老闆匯報工作進度的；其二，這也不是乙個專門用於解決各種問題的會議，成員們遇到的問題可以在會上提出來，而有能力解決這些問題的人可以在會後幫助他們解決問題。
sprint評審會(review meeting)：sprint結束時召開；由開發團隊展示這個sprint中完成的功能；長度為兩個小時左右；不需要ppt；一般是已完成的功能的demo； 誰都可以參加：客戶、管理層、product owner、其他開發人員等等。
在每個sprint結束時，應該組織乙個sprint評審會議。scrum開發團隊將在會上展示他們在這個sprint中所做的工作。一般採用向大家演示產品新功能的方式來展示。
相對來說，sprint評審會議不必很正式。通常不需要用到ppt幻燈片，而且長度最好控制在兩個小時之內。也就是說，不要讓sprint評審會議成為scrum團隊的負擔，他們不必花太多時間來準備這個會議。
sprint評審會議的參與者，可以包括所有對該產品感興趣的人：產品責任人，scrum團隊，利益相關者，管理層人員，客戶，甚至來自其他專案的開發人員等等。
在sprint評審會議上，scrum團隊用demo的形式展示產品的新功能之後，與會人員依據在sprint計畫會議上確定的本sprint的目標來評審具備了這些新功能的產品。
為什麼一定要用demo的形式來展示產品的新功能呢？因為這種方式有很多好處：
首先，參與會議的人都能直觀的看到scrum團隊的工作成果；其次，利益相關者們可以據此提出更切合實際的反饋意見；第三，為了完成demo，團隊會努力完成並發布那些功能，即使只是發布在測試環境下，也比沒完成的好。如果不做demo，也許不少功能會停留在「已完成99%」的階段。相比較起來，在有demo的情況下，也許「已完成」的功能數量會相對少一些，但它們是確確實實完成了的，否則，那些「99%」的貌似完成的功能勢必還要拖到下個sprint來解決。
假如有乙個剛從傳統的開發模式轉而採用scrum的團隊，由於不習慣這種自我約束、自組織的方式，在sprint中並沒做多少工作，那麼在會上演示的時候，他們會覺得很尷尬。沒準老闆看到他們花了這麼多時間只做了這麼少的工作而感到很生氣。發生這種情況當然是大家都不想看到的，但良藥苦口，在下乙個sprint中，這個團隊肯定會吸取教訓，他們會明白無論什麼情況下都必須demo，那麼他們必然會很好的完成這個sprint並演示給大家看
更多參考：
Scrum敏捷開發
只有實踐起來才能提出有針對性的改進建議 在這個框架中，整個開發過程由若干個短的迭代週期組成，乙個短的迭代週期稱為乙個sprint，每個sprint的建議長度是2到4周 網際網路產品研發可以使用1周的sprint 在scrum中，使用產品backlog來管理產品的需求，產品backlog是乙個按照商業...
敏捷開發（一）敏捷開發和Scrum
工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...
敏捷開發 談談敏捷開發之Scrum
最近一直在了解和學習敏捷開發的應用，主要學習的還是scrum。寫這篇文章也是為了能對這段時間的學習有個總結。在談scrum之前，我們可以先簡單了解下敏捷開發。維基百科是這樣解釋的，敏捷開發是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們...