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

一、Scrum的定義和目的

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

二、敏捷宣言

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

三、Scrum中的人員角色

3個角色

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原則作為敏捷開發對於軟體開發流程的指導性綱領，也是對敏捷宣言進行了具有實際操作意義的解釋，希望大家在實際應用中仔細體會。

我們遵循以下準則：

• 我們的最高目標是，透過儘早和持續地交付有價值的軟體來滿足客戶。
• 歡迎對需求提出變更——即使是在專案開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
• 要不斷交付可用的軟體，週期從幾周到幾個月不等，且越短越好。
• 專案過程中，業務人員與開發人員必須在一起工作。
• 要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務。
• 無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
• 可用的軟體是衡量進度的主要指標。
• 敏捷過程提倡可持續的開發。專案方、開發人員和使用者應該能夠保持恆久穩定的進展速度。
• 對技術的精益求精以及對設計的不斷完善將提升敏捷性。
• 要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
• 最佳的架構、需求和設計出自於自組織的團隊。
• 團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行為。

作者：史文帥

來源：宜信技術學院