最近把之前學習 scrum 的資料整理為一篇文件，在接下來的團隊和專案開發中，根據專案的情況引入 scrum 的一些實踐，提高團隊成員之間的協作能力和專案的交付質量。
scrum 工具
scrum 中的角色
scrum master——專案負責人、專案經理
保護團隊不受外界干擾，是團隊的領導和推進者，負責提公升 scrum 團隊的工作效率，控制 scrum 中的「檢視和適應」週期過程。與 product owner 一起將投資產出最大化，他確保所有的利益相關者都可以理解敏捷和尊重敏捷的理念。
team——開發人員、測試人員、美工設計、dba等全職能性團隊
團隊負責交付產品並對其質量負責，團隊與所有提出產品需求的人一起工作，包括客戶和終端使用者，並共同建立 product backlog 。團隊按照大家的共識來建立功能設計、測試 backlog 條目交付產品。
product owner——產品負責人、產品經理、運營人員
從業務角度驅動專案，傳播產品的明確願景，並定義其主要特性。product owner 的主要職責是確保團隊只開發對於組織最重要的 backlog 條目，在 sprint 中幫助團隊完成自己的工作，不干擾團隊成員，並迅速提供團隊需要的所有資訊。
user——終端使用者、運營人員、系統使用人員
很多人都可能成為終端使用者，比如市場部人員、真正的終端使用者、最好的領域專家，也可能是因其專業知識而被僱傭的資訊顧問。終端使用者會根據自己的業務知識定義產品，並告知團隊自己的期望，提出請求。
manager——管理層、投資人
管理層要為 scrum 團隊搭建良好的環境，以確保團隊能夠出色工作，必要的時候，他們也會與 scrum master 一起重新組織結構和指導原則。
customer——客戶、系統使用人員、運營人員
客戶是為 scrum 團隊提出產品需求的人，她會與組織簽訂合同，以開發產品。一般來說，這些人是組織中的高階管理人員，負責從外部軟體開發公司購買軟體開發能力。在為內部產品的公司中，負責批准專案預算的人就是客戶。
scrum 中的產出物
product backlog——backlog 待開發項，積壓的任務。
產品 backlog 包括了所有需要交付的內容，其內容根據業務需求的價值順序排列，每個 backlog 的優先順序是可以調整的，需求是可以增減的，因此產品 backlog 將根據不斷增長來持續驅動維護。
sprint backlog——sprint 本意為「衝刺」，指迭代週期，長度通常是一至六周。
在 sprint 開始前，定義本次 sprint 要討論的「sprint backlog」，從中產生本次 sprint 要完成的 「已定 product backlog」。
已定 product backlog
sprint 計畫會議的產物，它定義了團隊所接受的工作量，在整個 sprint 過程中它將保持不變。
user story、task——使用者故事、任務
用 user story 來描述 sprint backlog 裡的專案，user story 是從使用者的角度對系統的某個功能模組所作的簡短描述。乙個 user story 描述了專案中的乙個小功能，以及這個功能完成之後將會產生什麼效果，或者說能為客戶創造什麼價值。乙個 user story 的大小和複雜度應該以能在乙個 sprint 中完成為宜。如果 user story 太大，可能會導致對它的開發橫跨幾個 sprint，此時就應該將這個 user story 分解。
為了能夠及時，高效地完成每個 story，scrum 團隊會把每個 story 分解成若干個 task。每個task 的時間最好不要超過8小時，保證在1個工作日內完成，如果 task 的時間超過了8個小時，就說明task的劃分有問題，需要特別注意。
障礙 backlog——問題列表，積壓的待處理事務。
列舉了所有團隊內部和團隊相關的和阻礙專案的進度的問題，scrum master 需要確保所有的障礙 backlog 中的問題都已分配並可以得到解決。
通用會議規則
基本要求
會前準備
會議推進
會議輸出
讓團隊坐在一起！
團隊建設
每日立會（daily standup meeting）——建議下班前開始
會議目的
構成部分
基本要求
會議輸出
會議過程
每個人三個問題：
注意事項
任務板
任務板有4列：
燃盡圖（burn down chart）
release 燃盡圖：記錄整個scurm專案的進度，它的橫軸表示這個專案的所有sprint， 縱軸表示各個sprint開始前，尚未完成的工作，它的單位可以是個（story 的數量），人天等。
sprint 規劃會議——第一部分（上午）
會議目的
基本要求
構成部分：
會議輸出
會議過程
流程檢查：詢問團隊能否快速回答下列問題，只需要簡要回答即可：「我們能在這個 sprint 中完成第乙個 backlog 條目嗎？」如果能得到肯定的回答，那麼繼續詢問下乙個 backlog 條目，一直到已經分析完的最後乙個 backlog 條目。——接下來，休息一下。在休息後，對下乙個 backlog 條目展開上述流程。
結束流程：
注意事項：不要改變 backlog 條目大小，不要估算任務。
sprint 規劃會議——第二部分（下午）
會議目的
基本要求
構成部分：
注意事項：不要估算任務，不要分配任務。
會議輸出
會議過程
當團隊明確知道自己應該如何開發該功能後，就可以轉向下乙個 backlog 條目了。在會議的最後 10 分鐘，團隊成員使用即時貼寫出初步的任務。這能幫助團隊成員知道接下來的工作從**開展，將這些任務放在任務板上。
估算會議——根據專案情況合併到 sprint 第二部分會議
會議目的
基本要求
構成部分：
注意事項：
會議過程
會議輸出
撲克牌估算（planning poker）
具體步驟：
常見問題
1、為什麼任務要分給組而不是個人？
答：因為怕出錯了牌又說不出所以然，這樣即使日後他不做這個功能，也對這個功能很了解。
2、為什麼不讓最後領任務的人自己估算？
答：因為他很可能因為不知道某**可用、不知道某軟體不行....而選擇了錯誤的實現方法。
3、為什麼不讓師傅估算大家採納，他不是最厲害嗎？
sprint 評審會議（review meeting）——根據專案需要舉行
會議目的
基本要求
構成部分
會議輸出
會議過程
產品開發團隊展示新功能，並讓終端使用者嘗試新功能。
scrum master 推進會議程序。
終端使用者的反饋將會由 product owner 和/或 scrum master 記錄在案。
注意事項：
會議目的
構成部分
基本要求
注意事項
會議輸出
會議過程
附兩張流程圖（資料截圖）
Scrum敏捷開發
只有實踐起來才能提出有針對性的改進建議 在這個框架中，整個開發過程由若干個短的迭代週期組成，乙個短的迭代週期稱為乙個sprint，每個sprint的建議長度是2到4周 網際網路產品研發可以使用1周的sprint 在scrum中，使用產品backlog來管理產品的需求，產品backlog是乙個按照商業...
敏捷開發（一）敏捷開發和Scrum
工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...
敏捷開發 談談敏捷開發之Scrum
最近一直在了解和學習敏捷開發的應用，主要學習的還是scrum。寫這篇文章也是為了能對這段時間的學習有個總結。在談scrum之前，我們可以先簡單了解下敏捷開發。維基百科是這樣解釋的，敏捷開發是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們...