敏捷開發流程之Scrum：3個角色、5個會議、12原則

本文主要從Scrum的定義和目的、敏捷宣言、Scrum中的人員角色、Scrum開發流程、敏捷的12原則等幾方面幫助你們理解Scrum敏捷開發的全過程。

1、Scrum的定義和目的

Scrum是一個用於開發和維護複雜產品的框架，是一個增量的、迭代的開發過程，目的是讓開發人員像打橄欖球同樣迅猛並充滿激情，經過團隊合做，提升工做效率。經過團隊間的有效交互，爲企業創造價值。

2、敏捷宣言

其實，在發表《敏捷宣言》以前，不少的敏捷實踐都已經存在且使用了，好比：Scrum、XP、KanBan等。之因此發表《敏捷宣言》，是由於這些實踐都是在單打獨鬥地推動敏捷開發，而不是以一個聯合體的形式，且沒有一個統一的指導方針。因此17位敏捷聯合創始人決定發表《敏捷宣言》，共同在全世界推動敏捷開發運動。下面是敏捷宣言的4句話：

3、Scrum中的人員角色

3個角色

Scrum中的人員分爲3個角色：產品全部者（Product Owner）, Scrum Master，開發團隊(Team)。

• 產品全部者：定義全部產品功能，決定產品發佈的內容以及日期，對產品的投入產出負責，根據市場變化對須要開發的功能排列優先順序，合理地調整產品功能和迭代順序，認同或者拒絕迭代的交付。
• ScrumMaster ：ScrumMaster不是項目經理，他沒有分配任務的權力，沒有考覈的權力，沒有下命令的權力，他指導項目組的成員按照Scrum的原則、方法作事情，領導團隊完成Scrum的實踐以及體現其價值，排除團隊遇到的困難，確保團隊勝任其工做，並保持高效的生產率，使得團隊緊密合做，使得團隊我的具備多方面職能的工做能力，保護團隊不受到外來無故影響。
• 開發團隊：經典團隊擁有 5-9 人，團隊成員包含程序員、測試員、用戶體驗設計等等，團隊關係在一個迭代中應該是固定的，我的的職能能夠在新迭代開始時發生調整，團隊自我組織和管理（自組織，自驅動），團隊成員都全職工做。

4、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原則做爲敏捷開發對於軟件開發流程的指導性綱領，也是對敏捷宣言進行了具備實際操做意義的解釋，但願你們在實際應用中仔細體會。

咱們遵循如下準則：

• 咱們的最高目標是，經過儘早和持續地交付有價值的軟件來知足客戶。
• 歡迎對需求提出變動——即便是在項目開發後期。要善於利用需求變動，幫助客戶得到競爭優點。
• 要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
• 項目過程當中，業務人員與開發人員必須在一塊兒工做。
• 要善於激勵項目人員，給他們以所須要的環境和支持，並相信他們可以完成任務。
• 不管是團隊內仍是團隊間，最有效的溝通方法是面對面的交談。
• 可用的軟件是衡量進度的主要指標。
• 敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該可以保持恆久穩定的進展速度。
• 對技術的精益求精以及對設計的不斷完善將提高敏捷性。
• 要作到簡潔，即盡最大可能減小沒必要要的工做。這是一門藝術。
• 最佳的架構、需求和設計出自於自組織的團隊。
• 團隊要按期檢討如何可以作到更有效，並相應地調整團隊的行爲。

做者：史文帥

來源：宜信技術學院