Scrum實施的8個步驟

Scrum實施全網最全教程！！！

 

Scrum 作爲最流行的敏捷框架，這些年已經得到廣泛的流行。但是很多團隊在落地Scrum的時候並不總是一帆風順。

 

首先Scrum 雖然是不錯的方法，但也並不是放之四海皆準，Scrum也有其適用的範圍；其次，就算團隊非常適合用Scrum 來進行開發，團隊在落地的過程中也可能因爲遇到各種問題而對Scrum 喪失信心。

 

下面就我們近百人團隊5年實施Scrum 的經驗、敏捷轉型過程中的一些常見問題和要點進行分享。

本文就以下幾個問題展開討論：

1. 什麼樣的團隊適合實施Scrum？
2. Scrum 框架構成
3. 實施Scrum 的全流程
4. Scrum 實施是否需要管理工具？好的工具有哪些？
5. Scrum 落地的13個常見的坑

 

1. 什麼樣的團隊適合實施Scrum？

 

通常來說，國內最常見的開發管理模式有四種：

• 敏捷開發
• 瀑布開發
• 看板（指精益看板）
• 混合模式

 

其中，Kanban（看板）對於需求變化非常快的項目更有優勢，比如連一週的迭代都沒辦法保證的特性開發，或者屬於支持/維護類的項目團隊。此外，看板對於不喜歡對現狀改變太大的企業，更加容易被接受。

 

而相對來說，對於那些有着清晰roadmap的特性開發團隊，以便於按照固定的節奏提交價值增量，Scrum更加有完整的套路。

 

瀑布模型一般適用於需求在規劃和設計階段就已確定，且項目開發週期內需求沒有或極少變化，對需求變更進行嚴格控制，例如航空航天、金融核心系統等；以及穩定的低風險項目（對目標、環境非常熟悉），規模小實現簡單易受控的項目等特點的項目；

 

 

2. Scrum 框架構成及實施全流程

 

Scrum 框架包括：3個角色、3個工件、5個活動和5個價值觀。

 

2.1 3個角色

 

• Scrum Master

作爲 Scrum 流程的捍衛者和佈道者，ScrumMaster在Scrum團隊中起到至關重要的作用，他們確保團隊使用正確的流程，確保團隊正確地召開各種會議，幫助每個人理解Scrum 理論、實踐、規則和價值。

 

Scrum Master 對Scrum 團隊而言，他/她是一位服務型領導。Scrum Master 幫助Scrum 團隊之外的人瞭解他/她如何與Scrum 團隊交互是有益的，通過改變他/她們與Scrum 團隊的互動方式來最大化Scrum 團隊所創造的價值。

 

 

• Product Owner

產品負責人（Product Owner）是有授權的產品領導力核心，組成Scrum團隊三個角色之一。PO擔任的是產品經理的角色。

 

作爲確保團隊做出正確產品，以便幫公司得到最高投資回報的產品負責人，在Scrum團隊中負責“做什麼”的問題。但不同公司，不同部門，不同團隊的產品負責人的具體職責不盡相同。從總體上來說，產品負責人要負責產品的願景和邊界。而具體來說，產品負責人的工作是提出正確的解決方案和確保解決方案被正確“製造”。

 

 

• Team（開發團隊）

在Scrum開發團隊，所有的人都被稱爲“工程師”，且人數不宜過多，5~7人比較理想，包含產品、設計、前端、後端、測試等多角色，是實際價值產出者；

 

在 Scrum 的每個衝刺當中，開發團隊爲了實現計劃裏的功能，他們必須完成所有的相關工作，包括產品設計，開發，集成和測試。爲此，團隊必須具備完成這些工作的所有技能。在工作中，Scrum 作爲一個整體，對功能的實現負責。區別於傳統開發方法裏的“只負責自己那一部分工作”的狀態。

 

所以在團隊開始之前就要考慮：爲了能夠完成Scrum電子任務板項目的各種需求，團隊需要具備哪些能力，哪些能力是已經具備的呢，哪些能力是我們可以從外部獲得支持。”

 

Scrum開發團隊的主要職責如下：

• 在衝刺執行期間，開發團隊完成創造性的工作，包括設計，構建，集成，測試，最終提供潛在可發佈的功能發佈。
• 每日檢視和調整（每日站會）——作爲一個自組織的團隊，團隊通過每日站會來實現自我的檢視和調整以實現衝刺目標。
• 梳理產品列表——幫助產品負責人梳理產品列表，細化產品列表條目，估算和排列優先級。
• 衝刺規劃——在每個衝刺之初，開發團隊參與衝刺計劃會議。在會議上，根據產品經理提供的信息，對產品列表條目的工作量進行估算，並在ScrumMaster的指導下，與產品負責人共同制訂衝刺目標。
• 檢視和調整產品與過程——在每個衝刺結束的時候，開發團隊都需要參加衝刺評審會議和衝刺回顧會議。在會議上，Scrum團隊檢視和調整自己的過程和技術以進一步改善團隊使用Scrum來交付業務價值的能力。

 

注意，開發團隊對工作量的估算有絕對話語權，作爲一個自組織的團隊，他們不受其他角色的影響，對工作量進行估算並且按照自己的承諾去履行衝刺目標。

 

 

2.2 3個工件

 

• Product Backlog（產品待辦列表）

首先產品待辦列表永遠不會完成，它是產品所有已知需求的優先級排序表，爲了確保產品是有用的、有競爭力的，列表會不斷地變化和調整，例如當市場提供了一些反饋，需求可能會變得更詳細，PO就需要根據業務需要、市場環境和技術的變化及時進行調整，所以我們說，產品待辦列表是動態的，會隨着產品和使用它的環境發展而發展。

 

• Sprint Backblog

Sprint列表是團隊當前Sprint的任務清單。和產品列表不一樣，它的壽命是有限的，僅在一個Sprint的時間裏存活。它裏面包含所有團隊已承諾的故事以及相關聯的任務，以及此外的附加工作，例如，在回顧會議中所發現的團隊改進任務，團隊計劃要在當前Sprint完成。

 

Sprint列表在Sprint規劃會議中產生，一旦Sprint規劃會議結束，產品負責人就不能再修改Sprint列表的故事清單了。這是Scrum中業務方和開發團隊之間的基本協議，每次Sprint開始前，業務方都可以改變方向，然而Sprint開始以後，團隊則會專注於他們所承諾完成的故事。改變這個已承諾的故事清單隻有一個方式，就是由幹這個活兒的團隊成員提出變更請求。

 

• Increment（增量）

Increment是Sprint期間完成的所有Product Backlog項目的總和，以及所有先前Sprint的增量值。在Sprint結束時，新增量必須是“完成”，這意味着它必須處於可用狀態並符合Scrum團隊對“完成”的定義。增量是一個可檢查的“完成”工作，支持經驗主義在Sprint結束時。增量是邁向願景或目標的一步。無論產品負責人是否決定釋放，增量必須處於可用狀態。

Scrum的全部意義在於提供“完成”增量。

 

• 擴展工件之燃盡圖

 

衝刺燃盡圖（或燃盡圖）不是官方的 Scrum 工件，但許多團隊在衝刺期間使用它來溝通和跟蹤衝刺目標的進度。燃盡圖是顯示在衝刺期間完成的任務的圖表。燃盡圖在幫助衡量團隊的積極執行速度方面非常有用，因此他們知道他們是否會完成計劃或需要重新確定衝刺任務的優先級。

在 sprint 計劃期間，團隊可以查看之前的燃盡圖，以瞭解他們可以在即將到來的 sprint 中實際完成多少任務。團隊可以檢查正在進行的燃盡圖，以確定他們是否能夠成功完成衝刺。在 sprint 評審期間，團隊可以重新查看燃盡圖，看看他們在哪裏達到或沒有達到預期。隨着時間的推移，燃盡圖可以幫助團隊在 Scrum 的計劃階段更好地改進他們的估計。

 

2.3 5個活動

 

• Sprint（衝刺）

衝刺（有的公司叫班車，從起點站發車，到一站後需求完成下車，新需求上車，迭代的過程以此往復），一個固定的時間週期（通常爲2w~4w，新項目可以是1w）。

 

• Sprint planning meeting（衝刺計劃會）

Sprint計劃會議的主要目的是，爲了完成產品待辦列表的目標，需要設計一個有彈性的計劃來引導開發過程，來規劃我們做什麼和如何做這些事，Scrum Master要確保會議順利舉行，保證每個參會者都理解會議的目的。

Sprint計劃會議要求Scrum團隊協同合作，共同制定，PO、SM、開發團隊都要參與，不能由他人代替。在計劃會議上，我們要討論出這三個問題的答案：

第一個問題是我們這次Sprint的目標是什麼？

第二個問題是這次Sprint開發什麼功能？

最後是我們將如何去做？

 

• Daily standup meeting（每日站會）

每日站會的目的是通過對比前次每日站會後的工作，也就是過去24小時所完成的工作，檢視Sprint目標的完成度，並規劃未來24小時的工作，通過每天這樣快速反饋的循環，優化團隊協調合作和表現。

 

那麼，這15分鐘的會我們怎麼開呢？

 

會議需要聚焦在Sprint目標上，主要通過回答以下三個問題展開：

• 昨天我做了什麼事情幫助開發團隊達成Sprint目標？

• 今天我要做什麼幫助開發團隊達成Sprint目標？

• 是否有任何障礙在阻礙我或開發團隊達成Sprint目標？

 

• Sprint review（評審會）

Sprint 評審會議在 Sprint 快結束時舉行 ，這個事件是讓開發團隊展示他們在Sprint中取得的成就，根據DoD“完成的定義”和驗收標準，驗證增量，這些增量應該是：已經開發、測試完成、經過整合的和已經記錄的。

 

Sprint 評審會議不是一個進度彙報會議，所以不推薦大家使用PPT，這是一個非正式會議，演示增量的目的是爲了獲取反饋，提出意見和促進合作，根據完成情況和Sprint期間產品待辦列表的變化，團隊和利益相關方一起討論接下來可能要做的事情，未來有可能迎接哪些新的機會/挑戰。

 

比如我們自己的一個Sprint評審會議過程：

1. 首先，會議開始，PO歡迎利益相關者來參加評審，然後由PO介紹項目的目標，以及本次Sprint的目標，根據我們在計劃會議定義好的DoD，說明產品待辦列表裏哪些已經“完成”和哪些沒有“完成”；
2. 展示產品增量，開發團隊演示Sprint中已實現的產品新功能，最好在接近生產環境的設備上進行，例如，開發在手機APP端的功能程序應該在手機端演示，而不是電腦~
3. 由來自各方代表的利益相關者提出問題或反饋。
4. 開發團隊解答交付增量的問題，並總結Sprint期間做得好和還可以改進的地方。
5. 參會的所有人就下一步的工作進行探討： 評審產品在未來的不同市場，評估潛在的使用場景，決定接下來我們要做的哪些最有價值的改變或優化；
6. 更新產品待辦事項列表，在大家討論期待發布產品的時間、預算和市場潛力等等問題，達成共識後，會更新待辦列表。也就是Sprint評審會議的輸出，是這份修訂後的產品待辦列表，爲接下來的Sprint 計劃會議提供有價值的輸入信息。

 

• Retrospective meeting

回顧會議發生在評審會議之後，下一個Sprint計劃會議之前。回顧會議的時間盒，以一個月的Sprint來說，回顧會議不超過3小時，半個月的Sprint，回顧會議不超過1.5小時。

 

回顧會議由Scrum團隊檢視自身在過去的Sprint的表現，包括人 、關係、過程、工具等，思考在下一個Sprint中怎麼樣可以表現得更好，更高效，怎麼樣可以和團隊合作地更愉快。

 

Scrum Master作爲Scrum團隊成員需要來參加會議，因爲TA對Scrum的流程負責。該會議主要圍繞以下問題展開：

• 我們在上一個Sprint中哪裏做得好？

• 接下來纔是討論我們哪裏做得不夠好？

• 第三個問題就是，我們的改進計劃是什麼？

• 我們上次計劃的改進項目進度如何？

 

2.4 價值觀

 

 

 

3. Scrum實施全流程

 

基於以上框架，團隊實施Scrum的流程如下：

 

 

 

4.Scrum 實施是否需要管理工具？好的工具有哪些？

 

根據國外機構 Digital.ai 2021年發佈的《第十五次敏捷狀態報告》顯示：自疫情發生以來，採用敏捷的軟件開發團隊有顯著增長，從2020年的37%增加到了2021年的84%。

 

除此以外，從敏捷狀態調查的早期開始，工具支持一直是決定敏捷成功的關鍵因素。在實行敏捷的團隊中有各種各樣的工具集被應用，覆蓋從通用規劃與管理工具(例如，Microsoft Office)到專門的商業產品（例如，PingCode、Jira）。

 

延伸閱讀-《國內外使用最廣泛的14個 Scrum 工具盤點》

 

 

5.Scrum 落地的13個常見的坑

 

SCRUM 作爲最流行的敏捷框架，這些年已經得到廣泛的流行。但是很多團隊在落地SCRUM的時候，通常會產生以下問題。

 

概念性問題

• SCRUM就是敏捷麼？
• SCRUM就是開各種會麼？
• SCRUM有什麼好的，能對我的團隊產生什麼作用？

 

SCRUM執行過程問題

• 計劃會和需求評審會有啥區別？計劃會時候發現需求經常有問題，並且還會有很多問題在迭代中出現。
• 站會爲什麼要每天開，每天重複3個問題很乏味。
• 評審會，業務方沒空參加，時間也很緊張了，會議乾脆被省掉了。
• 回顧會，回顧了幾次後，已經沒有了熱情，總是那幾個問題，有什麼好回顧的。
• 迭代週期如何定？版本發佈怎麼做？
• 爲什麼看起來SCRUM沒什麼內容，落地執行卻問題多多？

 

SM的角色和發展問題

• SM一定是全職的麼？
• SM對我的職業發展有什麼幫助？
• SM的發展路徑是什麼？

 

針對以上三類問題，大家可以通過下文看到詳細解答。

延伸閱讀-《Scrum 落地的13個常見的坑及解答》

 

以上就是Scrum實施全流程的介紹，希望對你有所幫助。