Scrum學習小記
這幾天看了《硝煙中的Scrum和XP》,感覺不錯，做下備忘。
一. 什麼是Scrum
Scrum是一種迭代式增量軟件開發過程，通常用於敏捷軟件開發。包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。
二. Scrum名詞
Backlog: 可以預知的所有任務， 包括功能性的和非功能性的所有任務。
Sprint:一次跌代開發的時間週期，一般最多以30天爲一個週期.在這段時間內，開發團隊需要完成一個制定的backlog,並且最終成果是一個增量的，可以交付的產品。
Sprint backlog:一個sprint週期內所需要完成的任務。
Scrum Master: 負責監督整個Scrum進程，修訂計劃的一個團隊成員。
time-box: 一個用於開會時間段。比如每個daily scrum meeting的time-box爲15分鐘。
Sprint planning meeting: 在啓動每個sprint前召開。一般爲一天時間（8小時）。該會議需要制定的任務是：產品Owner和團隊成員將backlog分解成小的功能模塊, 決定在即將進行的sprint裏需要完成多少小功能模塊，確定好這個Product Backlog的任務優先級。另外，該會議還需詳細地討論如何能夠按照需求完成這些小功能模塊。制定的這些模塊的工作量以小時計算。
Daily Scrum meeting：開發團隊成員召開，一般爲15分鐘。每個開發成員需要向Scrum Master彙報三個項目：今天完成了什麼？是否遇到了障礙？即將要做什麼？通過該會議，團隊成員可以相互瞭解項目進度。
Sprint review meeting：在每個Sprint結束後，這個Team將這個Sprint的工作成果演示給Product Owner和其他相關的人員。一般該會議爲４小時。
Sprint retrospective meeting：對剛結束的Sprint進行總結。會議的參與人員爲團隊開發的內部人員。一般該會議爲３小時。
三. Scrum角色和職責
產品負責人 – 定義開發目標，需要實現的feature和優先級
Scrum Master – 保證團隊高效而不受打擾地工作，優化工作條件、過程
團隊 – 自組織地完成項目開發，使用一切可行手段保證進度和質量
四. Scrum過程
前期：產品負責人整理業務需求，形成Product Backlog庫
執行：以Sprint爲單位迭代式地完成Sprint Backlog。每個Sprint以Sprint Planning開始，通過每日例會跟蹤進度和issue。Sprint結束時交付可運行的產品
後期：每個Sprint完成後，通過Sprint回顧發現問題和改進點，制定下個Sprint要引入的新的實踐
五. Scrum的精髓
Scrum是一個“檢查並適應”的框架，在三個角色（產品負責人/Scrum Master/團隊）、三種儀式（Sprint計劃/Sprint回顧/每日例會）和三種製品（產品Backlog/Sprint Backlog/燃盡圖）的基礎上，你可以根據公司或者項目的情況，因地制宜引入任何有利於縮短開發週期、提高產品質量的實踐
六. 實施過程
實施Scrum—Sprint前
產品負責人（PM）收集整理產品需求，形成產品Backlog
產品Backlog按照統一格式定義，比較重要屬性有：名稱、重要性、估算時間、簡單描述、如何演示等，詳細的需求細節可以在其他需求文檔中定義
產品負責人可以通過任何渠道、方式獲取和確認需求
實施Scrum—Sprint
產品負責人、Scrum Master和團隊成員（包括QA）召開Sprint會議，Scrum Master主持會議
Sprint會議上詳細溝通產品負責人選定的重要性高的產品Backlog細節，確保團隊對需求的理解無誤
團隊就對需求的理解將Backlog拆分成任務，並給出每個Backlog的估算時間
產品負責人和團隊根據Sprint內可用的人天和Backlog的時間估算，選定需要排入本次Sprint的Backlog
Scrum Master和團隊分派任務，制定Sprint計劃
一個Sprint的週期是兩週到四周；一次Sprint會議時間大約一個下午
整理一面任務牆，將Sprint內的Backlog和任務按照未開始、進行中、已完成等狀態進行歸類；同時展示Sprint的燃盡圖
Scrum Master每日早上固定時間組織團隊的每日例會，確認每個成員前一天完成的工作、當天要進行的工作、工作中碰到的issue，並更新任務牆
任何需求變更都進行實時評估，超過規劃人天的Backlog視情況進行拆分或者推遲其他重要性低的Backlog
任何完成的Backlog都需要演示給產品負責人和QA後才能提交測試
實施Scrum—Sprint後
Scrum Master召集、組織Sprint回顧會議
回顧會議以頭腦風暴的方式Review Sprint過程和結果，發現和列舉存在的問題
與會人員投票決定需要在下個Sprint中解決的1-3個問題， 探討解決方案，確定實踐方式
七. Scrum精神
團隊目標重於崗位職責
團隊工作優於獨立作戰
高效溝通強於標準化的文檔
高能動性的、自組織的團隊勝於角色劃分清晰的流水線
務實的解決問題的方法好於經典理論
快速實踐，快速反饋，持續優化
八. 軟件開發的目標
在資源一定的情況下，儘可能快地完成高質量的軟件開發
九. 附：《敏捷宣言》
我們通過身體力行和幫助他人來揭示更好的軟件開發方式。經由這項工作，我們形成了如下價值觀：
個體與交互 重於 過程和工具
可用的軟件 重於 完備的文檔
客戶協作 重於 合同談判
響應變化 重於 遵循計劃
在每對比對中，後者並非全無價值，但我們更看重前者。
十. 附：《敏捷宣言》的12準則
我們的最高目標是，通過儘早和持續地交付有價值的軟件來滿足客戶。
歡迎對需求提出變更——即使是在項目開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
項目過程中，業務人員與開發人員必須在一起工作。
要善於激勵項目人員，給他們以所需要的環境和支持，並相信他們能夠完成任務。
無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
可用的軟件是衡量進度的主要指標。
敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恆久穩定的進展速度。
對技術的精益求精以及對設計的不斷完善將提升敏捷性。
要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
最佳的架構、需求和設計出自於自組織的團隊。
團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行爲。
十一. 參考資料
參考文檔：《硝煙中的Scrum和XP》及導讀PPT
相關地址：http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches
