1，目的
本流程是公司過程體系文件的一部分，用於描述軟件系統敏捷開發過程，包括過程中涉及的角色和職責、主要的活動以及輸出的主要工作產品
2. 範圍
本規程適用於所有采用敏捷開發模式的軟件項目。
3. 定義
001，Product Backlog:
一個最終會交付給客戶的產品特性列表，它們根據商業價值來排列優先級。Product backlog應該涵蓋所有用來構建滿足客戶需要的產品特性，包括技術上的需求。
002，Sprint Backlog:
Sprint Backlog 是Sprint計劃會上產出的一個工作成果。當Scrum team選擇並承諾了Product backlog中要遞交的一些高優先級的產品功能點後，這些功能點就會被細化成爲
003，Sprint Backlog:
一個完成Product Backlog功能點的必需的任務列表。
004，Sprint計劃會:
根據Product Owner制定的產品或項目計劃在Sprint的開始時做準備工作。Sprint計劃會是用來細化當前迭代的開發任務的。
005，每日站會:
ScrumMaster需要組織團隊成員每天開站會. 這個會議是用15分鐘的時間來讓大家反饋三個問題：昨天做了什麼？今天計劃做什麼？遇到什麼困難？
006，Sprint演示會:
在每個Sprint的最後一天召開Sprint演示會，用於演示本Sprint開發的產品功能。
007，Sprint回顧會:
在每個Sprint的最後一天召開回顧會，由Scrum Master和Scrum Team一起回顧當前的Sprint。團隊評估大家在一起的工作方式，找出好的方式以後繼續發揚；找出需要做的更好的地方，想辦法提升；在下一個sprint中引入何種好的方法。
,008，Sprint燃盡圖:
在Sprint時間段上顯示所有剩餘工作時間逐日遞減的圖，因整體上總是遞減而得名。
009，發佈燃盡圖:
在發佈週期上堵上顯示所有剩餘工作時間逐日遞減的圖。
5. 關鍵角色及應負責任
001,ProductOwner:
確定產品的功能
決定發佈的日期和發佈內容
爲產品的profitability of the product (ROI)負責
根據市場價值確定功能優先級
調整功能和調整功能的優先級
接受或拒絕接受開發團隊的工作成果
002,ScrumMaster:
(ScrumMaster負責在團隊中正確、完整地貫徹Scrum流程，特別要對以下工作負責)：
清除擋在客戶和開發工作之間的障礙
確保團隊合理的運作Scrum
003,Scrum Team: (一個跨職能的小團隊，團隊擁有交付可用軟件需要的各種技能):
確定Sprint目標和具體說明的工作成果
在項目嚮導範圍內有權利做任何事情已確保達到Sprint的目標
自組織的團隊
向Product Owner演示產品功能
團隊成員：ProductOwner，設計師，開發人員和測試人員。
設計師：負責軟件架構、接口協議、數據字典等的設計；
開發人員：負責軟件設計、編程、測試、分析需求等任何必要的工作；
測試人員：負責軟件的測試，包括每日的集成構建測試、Sprint驗收測試等。
7. 活動描述
001,Product Backlog準備期：
參與角色：Product Owner。
主要活動：由Product Owner整理、輸出Product Backlog用於Sprint的制定。Backlog中的功能性和非功能性需求，需事先劃分優先級
輸入：市場調查、市場分析、用戶需求分析報告、立項報告等
輸出：Product Backlog
002,Sprint計劃會:
參與角色：The Team
主要活動：
Sprint計劃會議(第一重要)
1天(8小時)
sprint 項目週期，通常三週
計劃會議1 (9:00-12:00)
會議進程：9:00 - 9:30：ScrumMster對sprint 目標進行總體介紹，概括產品backlog。定下演示的時間地點。
爲每日scrum會議（以下簡稱每日例會）安排固定的時間地點（如果和上次不同的話）。
9:30-12:00：確定在本次Sprint中實現的backlog條目、添加遺漏的backlog條目、評估backlog的工作量、確定backlog的優先級、過大的backlog條目進行拆分、所有重要性高的backlog 條目都要填寫如何演示;。會議結果：爲計劃會議2的進行準備好既定產品Backlog
計劃會議2 (14:00-18:00)
會議進程：14:00-18:00：將backlog條目分解爲任務、評估任務工作量（以小時爲單位）、如果任務超過一天，嘗試將其分割成幾個小任務、考慮工作中的所有細節（編碼、測試、代碼評審、會議、學習新技術、編寫文檔）、依據情況調整Sprint backlog、團隊確認Sprint目標。
會議結果：所有人都可以獲取Sprint Backlog中的任務。由ScrumMster整理輸出Sprint需要完成的文檔清單
輸入：Product Backlog
輸出：由ScrumMaster輸出Sprint Backlog、Sprint 任務表、sprint 目標、團隊成員名單（以及他們的投入程度，如果不是100%的話）。確定sprint 演示日期。確定時間地點，供舉行每日scrum會議。Sprint文檔清單。
003, 每日站會:
參與角色：The Team
主要活動：ScrumMaster需要組織團隊成員每天在固定的時間和固定的地點開站立會. 這個會議是用15分鐘的時間來讓大家過一下scrum的狀態。在會上，每個團隊成員需要問3個問題：我昨天做了什麼，今天做什麼，遇到哪些障礙。誰都可以參加這個會議，但只有Scrum團隊成員有發言權。這個會議的目標是得到一個項目的全局觀，用於發現任何新的依賴，定位項目成員的要求，實時的調整當天開發計劃.。
輸入：Spring Backlog
輸出：更新的任務板內容、更新的燃盡圖
004,Sprint演示會
參與角色：The Team
主要活動：用來演示在這個Sprint中開發的產品功能給Product Owner. Product Owner會組織這階段的會議並且邀請相關的利益相關者參加。業務，市場，技術都要做相關的評審。由Product Owner來決定Product Backlog中的哪些功能已經開發完成。
會議進程:
團隊按照Backlog條目，逐個地介紹此次Sprint的結果和演示新功能；
如果產品負責人想要改變功能，則添加一個新條目到產品Backlog
如果對功能有一個新的想法，則添加一個新條目到產品Backlog
如果小組報告項目遇到阻礙現在還沒解決，則把障礙加入到障礙Backlog
會議結果:對這次Sprint的結果和整個產品的開發狀態的共識。
輸入：Spring完成的代碼或者完成的文檔
輸出：master更新的Product Backlog、演示會結果收集表
005, Sprint回顧會
參與角色：The Team
主要活動：Sprint回顧會議(第二重要)
時間：3小時
地點：在一個封閉的房間中
過程：指定某人當祕書。Scrum master向大家展示sprint backlog，在團隊的幫助下對sprint 做總結。包括重要事件和決策等。
輪流發言。每個人都有機會在不被人打斷的情況下講出自己的想法，他認爲什麼是好的，哪些可以做的更好，哪些需要在下個sprint 中改變。
對預估生產率和實際生產率進行比較。如果差異比較大的話，分析原因。
快結束的時候，Scrum master 對具體建議進行總結，得出下個sprint 需要改進的地方。
輸入：演示會結果收集表、bug統計表、Sprint backlog
輸出：ScrumMaster總結 Sprint項目報告
006, 輸出迭代產品
參與角色：The Team
主要活動：由團隊成員將Sprint計劃會議中確定的工作產品上傳到配置庫的指定位置。
輸入：所有工作產品的產生
輸出：軟件源碼、相關已確定的文檔、記錄
007, 驗收測試
參與角色：The Team（測試人員）
主要活動：由團隊中的測試人員對迭代產品進行全面測試並出具驗收測試報告
輸入：上傳到配置庫的迭代產品；
輸出：驗收測試報告
008, 判斷產品是否完成，結束開發
參與角色：Product Owner
主要活動：由Product owner依據既定的產品規格內容、市場情況、產品質量情況等多方面因素判斷已開發的工作產品是否符合要求，是否還需要繼續開發？
輸入：驗收測試報告
輸出：繼續開發決議
8. 其他要求
8.1 Sprint計劃會:
爲Sprint定下演示的時間地點，這個時間一旦定下就不允許改變；
要對過大的backlog條目進行拆分；
所有重要性高的backlog 條目都要填寫如何演示；
如果任務超過一天（6小時），嘗試將其分割成幾個小任務；
考慮工作中的所有細節，包括編碼、測試、代碼評審、會議、學習新技術、編寫文檔；
所有人都可以獲取Sprint Backlog中的任務。</span></li>
8.2 Sprint回顧會:
做改進的最佳時機；
在一個封閉的房間中；
在團隊的幫助下對sprint 做總結，包括重要事件和決策等；
輪流發言。每個人都有機會在不被人打斷的情況下講出自己的想法，他認爲什麼是好的，哪些可以做的更好，哪些需要在下個sprint 中改變。
8.3 Sprint演示會
確保清晰闡述了sprint 目標。 如果在演示上有些人對產品一無所知，那就花上幾分鐘來進行描述；
不花太多時間準備演示，尤其是不做花裏胡哨的演講，集中精力演示可以實際工作的代碼；
節奏要快，也就是說要把準備的精力放在保持演示的快節奏上，而不是讓它看上去好看；
讓演示關注於業務層次，不要管技術細節。注意力放在我們做了什麼，而不是我們怎麼做的；
可能的話，讓觀衆自己試一下產品；
不演示一大堆細碎的bug 修復和微不足道的特性。可以提到一些，但不要演示；
無法演示的工作以報告呈現。
8.4 Sprint站立會
15分鐘；
每個人描述三個問題：昨天做了什麼？今天要做什麼？遇到什麼困難？
如果他更新了時間估算，那就在即時貼上寫上新的時間，把舊的劃掉；
站立會上不解決問題，只提出問題；
更新燃盡圖。
8.5其它
代碼每日及時提交到SVN庫，由Hudson持續集成；
TE每日對新提交的功能進行驗證並及時更新TD庫；
SPE每日對TD庫中的bug進行修正並修改bug狀態。
每個Sprint 最短2周，最長4周，從實踐來看3周最爲合適
建議引入TDD（測試驅動開發）
提倡結對編程
以建立自組織的團隊爲目的
每個Sprint結束時，由QA輸出代碼質量報告
依據上一個Sprint的代碼質量報告，制定出本次Sprint需要改進的項目，並作爲SprintBacklog列入Sprint計劃中。
附件：
敏捷宣言：
個體和交互勝過過程和工具
可以工作的軟件勝過面面俱到的文檔
客戶合作勝過合同談判
響應變化勝過遵循計劃
雖然右項也有價值，但是我們認爲左項具有更大的價值。
敏捷遵循的原則
我們最優先要做的是通過儘早的、持續的交付有價值的軟件來使客戶滿意。
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優勢。
經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是面對面的交談。
工作的軟件是首要的進度度量標準。
敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
不斷地關注優秀的技能和好的設計會增強敏捷能力。
簡單是最根本的。
最好的構架、需求和設計出於自組織團隊。
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行爲進行調整。
ScrumMaster需要具備的品質
負責：要對最大化團隊的產出和支持團隊成員實施以及使用Scrum負責。ScrumMaster承擔這個責任，卻不具有任何有助於實現這個目標的權利。
謙遜：優秀的ScrumMaster不能以自我爲中心。他必須理解全體團隊成員的價值，並以身作則促成其他人達成共識。ScrumMaster的成就來自於看看我幫助完成了什麼而不是看看我完成了什麼
協作：保障團隊中存在一種相互協作的文化。要確保團隊成員能夠把問題拿出來公開討論，並與此同時得到他人的支持。當爭執發生時，要鼓勵團隊用共贏方式思考，而不是以贏家和輸家的方式思考。要爲團隊合作建立規範，並指出不合適的行爲。
投入：ScrumMaster不應任由問題遺留多日不予解決。
有影響力：ScrumMaster必須會影響團隊內和團隊外的人。應該懂得如何向別人施加影響，同時又避免獨裁式的，因爲我這樣說了的風格。獨裁風格的人絕對不適合做ScrumMaster.
知識淵博：ScrumMaster應還具備技術、市場和其他的專業知識，可以幫助團隊實現目標。