Scrum 框架是何方神架？
前言
之前有一個朋友轉行說要去做 Business analyst（商業分析師），給我打電話說他們公司用的是敏捷開發，讓他兼任 Scrum Master，於是他問我什麼是敏捷？敏捷和 Scrum 的關係？Scrum Master 是幹嘛的？看來有不少人不太了解敏捷，不了解 Scrum，那今天小編就來跟大家簡單嘮嘮 Scrum 框架是何方神架？
PMP 和 ACP 的區別
學過項目管理的同學肯定都知道 PMP，了解過敏捷的同學肯定聽說過 ACP，這裡小編不會深入探討他們之前的區別，只是簡單的從字面意思上解釋一下。
PMP，英文全稱 Project Management Professional，「專業項目管理」，也就是說取得了 PMP 證書，PMI 就認為你是專業項目管理從業者啦。ACP，英文全稱 Agile Certified Practinoner，「經過敏捷認證的實踐者」，也就是說取得 ACP，只是你去做敏捷實踐的敲門磚，這就與 PMP 有本質區別！
敏捷宣言
探索敏捷本質，不得不從敏捷洋蔥圈說起。2001 年 2 月，敏捷聯盟成立，就是在這一年，敏捷宣言正式發表，包括 4 種核心價值觀和 12 條原則，代表了 21 世紀互聯網軟體開發模式的一種先進理念和價值觀的建立。（如圖所示，十分感興趣的同學可自行 Google，在這就不一一贅述了），這也就是洋蔥圈的最裡面兩層，最外面一層為敏捷實踐，包括 Scrum、XP、Lean、FDD 等，這也就意味著如果對敏捷核心價值觀和原則理解的不夠深入，洋蔥從裡面就爛了，不管表皮如何健康都無法再用作食材！
以上給大家介紹一下背景，下面正式進入今天的主題。
Scrum 原則
Scrum 是橄欖球里的用語，正常翻譯是並列爭球的意思，現在被引用到敏捷實踐中，代表一種敏捷框架。Scrum 並不是一個特定產品開發的流程或技術，而是一個容納其它流程和技術的框架，是一個迭代和增量的產品開發框架！通常來說，Scrum 由 3355 原則組成的全流程框架，所謂 5533 值得是 Scrum 中的3種工件、3 種角色、5 個會議以及5種價值觀。
Scrum 的 3 種工件為 Product Backlog（產品待辦列表）、Sprint Backlog（迭代待辦列表）、產品增量，這個會在後面提到。
Scrum 的 3 種角色需要重點說明一下，包括 PO（產品負責人），他是負責管理產品待辦列表的唯一責任人，他需要做到以下 5 條；
Team（開發團隊），一般情況下由3~9人組成，包含了各種專業人員，負責在每個 Sprint（迭代）結束時交付潛在可發布並且「完成」的產品增量，只有開發團隊成員才能創建增量， 需要注意以下幾點：
Scrum Master，負責保證所有人都能正確地理解並實施 Scrum。Scrum Master 要確保 Scrum 團隊遵循 Scrum 的理論、實踐和規則，對 Scrum 團隊而言，他是一位服務型領導。Scrum Master 幫助 Scrum 團隊之外的人了解他們如何與 Scrum 團隊交互是有益的，通過改變他們與 Scrum 團隊的互動方式來最大化 Scrum 團隊所創造的價值。
Scrum 的 5 個會議同樣需要重點說明一下，主要包括：
產品梳理會：主要對整個產品的需求進行梳理，一般由客戶（如果可能）、PO、團隊以及相關干係人共同參與，重要的是輸出之前提到的第一個工件產品待辦列表（product backlog），包含對用戶故事大小的估計和優先順序別的設定。
迭代計劃會：規劃這個迭代的目標和具體任務安排，它標誌著一個迭代的開始，團隊必須按照 PO 設定的產品待辦列表的優先順序別，從高到低選擇，如因實現上的依賴關係，要調整需求選擇的順序，也需要和PO進行確認，以確保團隊始終工作在最有價值的需求上。團隊選擇並承諾了接下來迭代中要完成的產品待辦列表中的用戶需求，並且將每一個需求分解成具體的多個開發任務。這些開發任務的列表被稱為迭代待辦列表（sprint backlog），這就是我們之前提到的第二個工件，它是迭代計劃會最重要的輸出，接下來的工作，就是完成這些開發任務，交付對應的用戶需求。
每日站會：Scrum 團隊每天都會進行一次信息同步 -- Scrum 站會，會議被限定在 15 分鐘之內結束，每天在同樣的時間，同樣的地點舉行，旨在溝通同步項目開發狀態，建立團隊對項目的整體認識，並發現項目中的問題。會議上，每一個人都向團隊回答三個問題：我昨天做了什麼？我今天計劃做什麼？在前進的道路上有什麼障礙? Scrum 會議結束後，要更新迭代燃盡圖以反映團隊的工作進度，和離迭代目標的距離。
迭代評審會議：一個迭代結束，團隊構建了包含新的用戶需求的產品增量（之前提到的第三個工件），團隊在這個會議上展示過去的一個迭代構建的產品。sprint評審會議是開放的，應儘可能邀請相關人員參加，ScrumMaster、團隊、PO、市場人員、客戶、管理人員、維護人員、領域專家以及關聯團隊等。在會議上團隊對照產品待辦列表依次演示剛剛構建的用戶需求，獲取參與者的反饋，這些反饋將成為未來的產品設計和規劃調整的依據，以使產品更好的滿足客戶的需求，更好的服務於組織的業務目標。
迭代回顧會議：作為迭代的最後一個會議，迭代回顧會發生在評審會議結束之後,迭代計劃會議之前，其目的在於：
1）檢視前一個 Sprint 中關於人、關係、過程和工具的情況如何;
2）找出並加以排序做得好的和潛在需要改進的主要方面 ；
3）制定改進 Scrum 團隊工作方式的計劃 ；
在迭代回顧會議結束時，Scrum 團隊應該明確接下來的迭代中需要實施的改進。在下 一個迭代中實施這些改進是基於 Scrum 團隊對自身的檢視而做出的適當調整。雖然改進可以在任何時間執行，迭代回顧會議提供了一個專註於檢視和適應的正式機會。
Scrum 的 5 種價值觀包括承諾、勇氣、專註、開發和敬重，價值觀是做任何事情的根本，大家按字面意思理解即可，在這就不做過多解釋
以上介紹了一些概念，那麼 Scrum 具體框架是什麼樣的呢？可見下圖所示：（此圖來自於互聯網）
Step1：在產品梳理會中進行需求梳理，優先順序排序等並輸出產品待辦列表
Step2：產品待辦列表生成後由 Scrum Master 組織召開迭代計劃會議，確定迭代目標即完成產品待辦列表中的幾項需求（一般用 User story-用戶故事表示），然後進行任務分解，小組成員領取任務，形成迭代待辦列表，然後就開始了迭代執行
Step3：在迭代執行的過程中，每天早上固定時間，固定地點由 Scrum master 組織召開站立會，同步項目信息，更新看板與燃盡圖
Step4：迭代末期由 Scrum master 組織召開迭代評審會，邀請相關干係人參加評審，會議室需展示迭代產出（產品增量），這是一個非正式會議，可以不用正式的PPT進行講述，但需要用最簡單的Demo展示成果，根據會上反饋制定調整計劃，並促進合作。
Step5：Scrum 框架中最後一個會議是迭代回顧會，也是由 Scrum master 組織召開的，回顧會上主要對好的與不好的經驗進行回顧，也是團隊自檢的機會，回顧會並不是吐槽大會，切忌不能再會議上批評教育團隊成員，在會議中需要明確 Scrum 團隊後續改進計劃，持續改善！
最後給大家普及一個關於時間的概念：時間盒，從 Scrum 框架可以看到，我們在執行 Scrum 的過程中要開不少會呢，其實每個會議要遵守固定的會議時間，對於一個兩周的迭代迭代計劃會議通常控制在 4 個小時，每日站會通常控制在 15 分鐘，迭代評審會通常限時為 2 個小時，迭代回顧會限時為 1.5 小時，Scrum Master 作為 Scrum 過程的負責人，務必督促大家遵守時間盒的規則！
總結
以上就是 Scrum 框架的簡單介紹，俗話說，實踐出真理。理論知識再豐富也得實地演練一番。如果大家對 Scrum 真的感興趣，建議可以先從站立會開始進行實踐！
以上內容主要參考了《敏捷實踐》、《Scrum 指南》等書籍！
實踐出真知，如果你對文章還算感興趣的話，歡迎來擾！與你互動，實則我幸！
推薦閱讀：