敏捷開發框架Srum例項
一、Scrum 簡介
1.1Scrum 定義
Scrum是跨職能團隊以迭代、增量的方式開發產品或專案的一種開發框架。在這個框架中人們可以解決複雜的自適應問題，同時也能高效並有創造性地交付儘可能高價值的產品。它不是產品開發的一種流程或者技術，而是一個框架，在這個框架裡可以應用各種流程和技術。Scrum能使產品管理和開發實踐的相對功效（relative efficacy）顯現出來，以便進行改進。（《Scrum權威指南》）
1.2 Scrum特點
Scrum總體特點就是快，迭代式開發，迭代週期在4周以內。靈活多變，依據專案的特點以及專案中遇到的問題，不斷改進專案流程和優化人員合作交流效率，在混亂中尋找有序，讓每一個人發揮最大的價值，具體如下：（個人理解，具體可參加《Scrum理論與實踐的輕量級指南
- 迭代開發，週期短且不可改變
- 敏捷開發，最短時間交付最有價值的部分
- 經驗開發，開發流程根據經驗不斷調整和優化
- 以人為本，責任感和主人翁意識
1.3 Scrum理論
Scrum基於經驗型流程控制理論，或者稱為經驗主義。經驗主義主張知識源於經驗，而決策基於已知的事物。Scrum採用迭代增量式的方法來優化可預測性和管理風險。
透明性、檢視、調整是經驗型流程的三大支柱，支撐起每個經驗型控制流程的實施。（《Scrum權威指南》）
透明性
流程中的關鍵環節必須為那些對產出負責的人可見。要擁有透明性，就要為這些關鍵環節制定統一的標準，這樣所有留意這些環節的人都會對觀察到的事情有統一的理解。
檢視
Scrum的使用者必須經常檢視Scrum的工件和完成Sprint目標的進度，以發現不必要的偏差。檢視不應該過於頻繁而阻礙了工作本身。當熟練的檢視者認真履行檢視工作時，效果最佳。
調整
Scrum指定了進行檢視和調整的4個正式事件，將在“Scrum事件”一節中詳細描述：
- Sprint計劃會議
- 每日Scrum站會
- Sprint評審會議
- Sprint回顧會議
1.4 Scrum團隊
- 產品負責人
- 開發團隊
- Scrum Master
1.5 Scrum 事件
Sprint計劃會議
Sprint計劃會議的目的就是要為這個Sprint的工作做計劃。這份計劃是由整個Scrum團隊共同協作完成的。
對於週期為一個月的Sprint，計劃會議的時限為8小時。對於較短的Sprint，會議時間通常會縮短。Scrum Master要確保會議順利舉行，並且每個參與者都明白會議的目的，同時還要教導大家遵守時間盒的規則。
Sprint計劃會議要解決以下兩個問題：
- 接下來的Sprint交付的增量中要包含什麼內容？
- 要如何完成交付增量所需的工作？
每日Scrum站會是以15分鐘為限的事件，開發團隊成員在這裡分享各自的工作情況，併為接下來的24小時制定計劃。這需要檢視上個每日站會以來的工作和預測下個每日站會之前所能完成的工作。每日站會在同一時間同一地點進行來降低複雜度。會議上，每個開發團隊成員都需要說明：
- 昨天我為開發團隊達成Sprint目標做了什麼
- 今天我準備如何幫助團隊達成Sprint目標
- 有什麼事情阻礙了我幫助團隊達成Sprint目標
Sprint評審會議在Sprint結束時舉行，用以檢視所交付的產品增量並按需調整產品待辦事項列表。在Sprint評審會議中，Scrum團隊和相關干係人討論Sprint中完成的工作。然後，根據完成情況和Sprint期間產品待辦列表的變化，與參會人員討論接下來可能要做的事情來優化價值。這是一個非正式會議，而不是一個進度彙報會議，演示增量的目的是為了獲取反饋並促進合作。
對於週期為一個月的Sprint，評審會議的限時為4小時。對於時間少於一個月的Sprint來說，會議的長度會有所縮短。Scrum Master要確保會議順利舉行，並且每個參與者都明白會議的目的，同時還要教導大家遵守時間盒的規則。
Sprint評審會議包含以下內容：
- 產品負責人邀請Scrum團隊以及相關干係人蔘加會議
- 產品負責人說明哪些工作“完成”了，哪些工作沒有“完成”
- 開發團隊討論在Sprint中哪些工作進展順利、遇到了什麼問題、問題是如何解決的
- 開發團隊演示完成的工作並解答關於所交付增量的問題
- 產品負責人描述當前產品待辦列表的完成情況，並根據進度推測可能的完成日期（如果有需要的話）
- 參會的所有人就下一步的工作進行探討，這樣，Sprint評審會議就能為接下來的Sprint計劃會議提供有價值的資訊。
- 評審市場或者潛在的產品使用方式所帶來的接下來要做的最有價值的東西的改變
- 為下個產品版本的釋出評審時間表、預算、潛在功能和市場
Sprint回顧會議是Scrum團隊檢視自身並建立下個Sprint改進計劃的機會。
Sprint回顧會議發生在Sprint評審會議結束之後，下個Sprint的計劃會議之前。對於長度為一個月的Sprint，會議限時為3小時。對於較短的Sprint，會議時間通常會縮短。Scrum Master要確保會議順利舉行，並且每個參與者都明白會議的目的，同時還要教導大家遵守時間盒的規則。Scrum Master作為Scrum流程的監督者，也需要作為團隊的一員參加該會議。
Sprint回顧會議的目的是：
- 對前一個Sprint週期中的人、關係、過程和工具進行檢視
- 找出做得好的和潛在需要改進的主要方面，並進行排序
- 制定改進Scrum團隊工作方式的計劃
1.6Scrum工件
- 產品待辦列表
- Sprint待辦列表
二、專案介紹
當前我們從事的是一個網際網路產品（某某安卓模擬器），該產品符合大眾級的網際網路產品特徵，快速開發、不斷迭代，使用者體驗驅動開發。當前從事該專案的人員較少同時團隊組建十分年輕。人員組成如下：
產品策劃一人：負責使用者問題收集、競品分析、以及研發遺留問題的評估，同時兼任測試。
產品經理一人：負責專案管理、Sprint任務的制定、專案的跟進、產品釋出風險評估。
測試二人： 負責產品測試
研發三人：1人負責UI設計開發、1人Android系統開發、1人虛擬機器開發
UI設計運營等（包括社群的開發）複用其他專案成員。
三、專案流程
3.1 專案管理工具
- 禪道：bug管理
- 白板：Sprint每日進度跟蹤
3.2 專案流程
整個專案流程基本符合Scrum開發框架；不同的是我們沒有一個嚴格的產品負責人，而是採用的兩個產品人員，一個專心與需求分析、一個專心與專案的跟蹤和風險的評估。整個團隊執行較為流暢，但由於OEM版不斷打斷主機板本的開發，主機板本出現過專案延期的情形，但平均保持在4周出一個版本的進度。
流程不詳解了，具體如下圖（其中Sprint評審會議和回顧會議未能做有效的區分，二者合二為一，待改進）：
專案開發流程圖