敏捷開發流程之Scrum：3個角色、5個會議、12原則
一、Scrum的定義和目的
Scrum是一個用于開發和維護復雜產品的框架，是一個增量的、迭代的開發過程，目的是讓開發人員像打橄欖球一樣迅猛并充滿激情，通過團隊合作，提高工作效率。通過團隊間的有效交互，為企業創造價值。
二、敏捷宣言
其實，在發表《敏捷宣言》之前，很多的敏捷實踐都已經存在且使用了，比如：Scrum、XP、KanBan等。之所以發表《敏捷宣言》，是因為這些實踐都是在單打獨斗地推進敏捷開發，而不是以一個聯合體的形式，且沒有一個統一的指導方針。所以17位敏捷聯合創始人決定發表《敏捷宣言》，共同在全世界推進敏捷開發運動。下面是敏捷宣言的4句話：
三、Scrum中的人員角色
Scrum中的人員分為3個角色：產品所有者（Product Owner）, Scrum Master，開發團隊(Team)。
產品所有者：定義所有產品功能，決定產品發布的內容以及日期，對產品的投入產出負責，根據市場變化對需要開發的功能排列優先順序，合理地調整產品功能和迭代順序，認同或者拒絕迭代的交付。
ScrumMaster ：ScrumMaster不是項目經理，他沒有分配任務的權力，沒有考核的權力，沒有下命令的權力，他指導項目組的成員按照Scrum的原則、方法做事情，領導團隊完成Scrum的實踐以及體現其價值，排除團隊遇到的困難，確保團隊勝任其工作，并保持高效的生產率，使得團隊緊密合作，使得團隊個人具有多方面職能的工作能力，保護團隊不受到外來無端影響。
開發團隊：經典團隊擁有 5-9 人，團隊成員包含程序員、測試員、用戶體驗設計等等，團隊關系在一個迭代中應該是固定的，個人的職能可以在新迭代開始時發生調整，團隊自我組織和管理（自組織，自驅動），團隊成員都全職工作。
四、Scrum的開發流程
不同于瀑布模型將開發過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發過程分為多次迭代（稱為Sprint，沖刺），一般為期2～4周，最常見的為2周。Scrum并非以一段時間集中完成一個過程，而是將所有過程中必須的每一部分集中在這段時間內完成。需求、設計、編碼、測試、上線都必須在一個迭代中完成，每個迭代必須產生一個可以工作的軟件。
4.1 五個會議
Scrum 整個開發過程分為五個會議:
1）待辦事項整理會議（Backlog Grooming Meeting）
迭代計劃會議開始之前3天召開，Product Owner與Scrum Master必須參加，關鍵開發者或架構師需要參加；時間控制在30分鐘到1小時。
由Product Owner將一批希望團隊在下次迭代時實現的用戶故事，按照實現順序描述給在場的團隊成員，Scrum Master與在場成員分析用戶故事，明確指出團隊認為需求不明確的地方，Product Owner現場記錄，會后補全，Scrum Master與架構師，還有在場成員分析用戶故事需要包含哪些技術任務，Scrum Master先把子任務建立，方便迭代計劃會議的時候團隊可以更準確地預估任務故事點。
會議結束時，Product Owner確保在迭代計劃會議開始之前團隊提出的問題都能被解決，會議重點如果團隊發現需要加強或是完善的地方，Product Owner還有兩到三天的時間可以補強，而不是浪費迭代計劃會議的時間去做這件事情。
2）迭代計劃會議（Sprint Planning Meeting）
產品負責人建立產品功能列表（Product Backlog）。產品功能列表是一組條目化需求，它必須從客戶價值角度描述，并按優先級排序。
Scrum Master召集相關人員召開迭代計劃會，迭代計劃會在每個迭代第一天召開，目的是選擇本次迭代的Backlog和估算本次迭代的工作量。
產品負責人逐條講解最重要的產品功能，開發團隊共同估算Backlog所需工作量，直到本迭代工作量達到飽和。產品負責人參與討論并回答和需求相關的問題，但不干擾估算結果。隊員認領任務（或由組長協商分發），獨立或與別人一起完成任務；會議時間控制在1-2小時內。
3）每日站會（Standup Meeting）
團隊內部利用每日立會來溝通進度，15分鐘結束，開發團隊利用燃盡圖來展示整體進度；如無特殊原因，迭代期內無變更，在每日站會上團隊成員需要回答以下3個問題：
- 昨天你做了什么?
- 今天你將要做什么?
- 你有需要幫助的地方嗎?
這些都是團隊成員的彼此承諾。
4）評審會（Retrospective Meeting）
小組向產品負責人展示迭代工作結果，產品負責人給出評價和反饋。以用戶故事是否能成功交付來評價任務完成情況。整個團隊都需要參加，ScrumMaster、產品所有者、團隊，可能還有客戶，時間控制在1-2小時內。
5）反思會（Retrospective Meeting）
在每個迭代后召開簡短的反思會，總結哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒棄。會議得出這樣的結論：開始做什么、繼續做什么、停止做什么，一般控制在15-30分鐘。
Scrum是一套開發流程，是敏捷的一種，實施主要還是看人，強調是自組織、自驅動的，只有不斷的在實際應用中仔細體會，才能理解Scrum的真諦，把Scrum用好。
4.2 12原則
下面給出敏捷開發的12原則，這12原則作為敏捷開發對于軟件開發流程的指導性綱領，也是對敏捷宣言進行了具有實際操作意義的解釋，希望大家在實際應用中仔細體會。
我們遵循以下準則：
- 我們的最高目標是，通過盡早和持續地交付有價值的軟件來滿足客戶。
- 歡迎對需求提出變更——即使是在項目開發后期。要善于利用需求變更，幫助客戶獲得競爭優勢。
- 要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。
- 項目過程中，業務人員與開發人員必須在一起工作。
- 要善于激勵項目人員，給他們以所需要的環境和支持，并相信他們能夠完成任務。
- 無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
- 可用的軟件是衡量進度的主要指標。
- 敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恒久穩定的進展速度。
- 對技術的精益求精以及對設計的不斷完善將提升敏捷性。
- 要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
- 最佳的架構、需求和設計出自于自組織的團隊。
- 團隊要定期反省如何能夠做到更有效，并相應地調整團隊的行為。
【本文是51CTO專欄機構宜信技術學院的原創文章，微信公眾號“宜信技術學院( id: CE_TECH)”】
