有點長，期望你能通過本文徹底瞭解 Scrum。

上一篇文章《研發效能組織能力建設之特性團隊FeatureTeam（上）》，我們介紹了一個非常有意思且高效的組織模式-特性團隊。我們首先介紹了為什麼需要特性團隊，特性團隊的定義、核心價值、優勢、可能存在的問題以及帶來的成本。接著講述了特性團隊的適用範圍，開發新產品、拓展新業務和產品快速增長的產品。然後，我介紹了特性團隊的兩個角色FTO和FT隊員；最後介紹了在一個大公司裡如何多FT進行分工共同作業。看完這些你是否發現特性團隊沒有告訴我們在研發過程中如何管理需求，對外協調溝通，怎麼開會，規範流程，跟進執行，專案狀態如何視覺化等。我通常是利用 Scrum 這個管理框架來完成這些事情，這也就是本文我要介紹的內容。

在本文中，我首先介紹 Scrum 的定義、特徵、優勢，然後講述了Scrum 的3個角色，接著是框架、流程、5個會議和3個工件，最後列了一些我們在使用 Scrum 時遇到的一些問題，希望能觸發你的思考。

回顧特性團隊

特性團隊是一個長期穩定、跨職能、跨元件，持續端到端交付使用者價值的團隊，負責把一個個「以使用者為中心的功能」變成一個個可交付的產品增量。從這張圖中，我發現這個過程有點糙。有點怎麼把大象裝冰箱裡的感覺。一些問題沒有回答，比如：

這三個人都是啥角色
都負責什麼？
怎麼配合
日常工作是什麼？

下面我來介紹下Scrum 的框架，平時我就是用它幫我解決這些問題的。

Scrum的定義和特徵

Scrum 的定義

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

Scrum 的特徵

迭代開發：有固定週期的迭代，每個迭代都交付一些增量的可工作的功能。
增量交付：每個迭代結束前，完成新的增量的交付。
自組織團隊：自組織管理工程過程和進度，決定自己如何開展工作，決定誰來做什麼
高優先順序的需求驅動：研發團隊要從待辦列表最上層的高優先順序的需求開始開發

Scrum 的優勢

快速反饋：一般1-2週一個迭代週期，也是一個反饋週期
儘早交付：高優先順序需求及時滿足
風險降低：短週期持續反饋，問題及時修正
適應變化：小步快跑，不斷修正
持續改進：不斷反思、回顧、優化
客戶滿意：一直與使用者進行溝通，不斷反饋修正需求

Scrum的人員和角色

3.1 產品負責人PO(Product Owner)

PO 角色定義

確定產品的方向和願景，定義產品釋出的內容、優先順序及交付時間，為產品盈利負責。維護產品需求清單，代表利益相關者的利益，代表業務方。

一般產品經理擔任，或者由熟悉領域業務想轉產品經理的研發人員擔任。因為產品經理本身已經是所有業務的介面人，熟悉領域知識、熟悉業務是其本職工作，所以產品經理擔任PO更合理。
不建議依然寫程式碼的研發人員擔任。寫程式碼和負責整個業務都是需要全身心注入的工作。
不建議 SM 兼任

總體原則，「誰理解使用者」「誰熟悉領域業務」，「誰能代表業務方」、誰來擔任PO。

PO 主要職責

幫公司得到最高投資回報，指引團隊做最有價值的工作，為產品的ROI負責
確定產品的功能，定義完成的標準，驗證交付的工作成果
決定釋出的日期和釋出內容
根據市場價值、使用者價值調整產品功能和優先順序
接受或拒絕開發團隊的工作成果；
參與五個會議：產品待辦規劃會，迭代計劃會議, 每日站立會，迭代評審會，迭代反思會

PO 日常工作

PO參與產品規劃，對接內、外部利益干係人
對產品待辦梳理、優化、優先順序排序
PO負責制定迭代計劃，確認團隊每個迭代完成的功能、優先順序和預期交付日期
PO參加每日站立會，聽取情況，瞭解進展，澄清需求。
PO必須每天能夠解答問題，並進行驗收測試。
Sprint內，PO還要確定下個迭代的計劃，交付功能、優先順序順序以及交付日期。
Sprint結束時，PO要參與迭代展示會(show case)和 Sprint 反思會。

3.2 敏捷教練SM (Scrum Master)

Scrum Master角色定義

是團隊的Scrum 教練和組織者，與 PO 緊密合作，保證的是敏捷開發的流程和秩序。整個團隊保證進展和結果。
是規則的執行者，是團隊中的服務型領導。促使團隊按照 Scrum方式執行，為Scrum過程負責的人
一般可由更熟悉敏捷開發模式及實施流程的 PMO 來擔任

Scrum Master 主要職責

幫助員工及干係人理解並實施 Scrum
指導團隊採用 Scrum，管理 Scrum 流程，確保流程的貫徹執行
組織召開每一個會議，解決團隊在開發過程中遇到的問題
找到阻礙團隊高績效的障礙，並解決
確保團隊內部溝通順暢、高效
團隊和外部的介面人，保證團隊專注和工作節奏，保護開發團隊不受干擾
保證各個角色及職責良好共同作業
保證開發過程按計劃進行

Scrum Master 日常工作

Scrum Master 指導團隊成員遵從Scrum 流程和使用敏捷工具
Scrum Master 組織召開五個會議
Scrum Master 參加每日站立會。例會上聽取情況，甄別風險和問題、提供協助。
Scrum Master 解決團隊在開發過程中遇到的問題
Scrum Master 幫團隊掃清高效能的障礙

3.3 研發團隊Team(Scrum Team)

研發團隊角色定義

負責在每個迭代的結尾交付潛在可釋出的「完成」產品增量

由組織構建並授權,來組織和管理他們的工作。所產生的協同工作能最大化開發團隊的整體效率和效力。

他們是自組織的,沒有人(即使是 Scrum Master 都不可以)告訴開發團隊如何把產品待辦事項列表變成潛在可釋出的功能。
開發團隊是跨職能的,團隊作為一個整體擁有創造產品增量所需要的全部技能。
Scrum 不認可開發團隊成員的頭銜,無論承擔哪種工作他們都是開發者。此規則無一例外。
開發團隊中的每個成員可以有特長和專注領域,但是責任歸屬於整個開發團隊
開發團隊不包含如測試或業務分析等負責特定領域的子團隊。

研發團隊的主要職責

負責自組織地交付使用者故事
做交付過程中的所有工作
支配估算流程
決策「如何完成」

研發團隊日常工作

理解迭代待辦，拆分工作項
評估工作量、開發產品、完成程式碼編寫且自測通過
團隊做技術決策：技術調研、架構設計
自領迭代任務、團隊決定任務分配
評審測試用例
產品上線交付使用者價值

Scrum 框架和流程

【PO】和所有利益相關人密切合作，從使用者角度以及公司業務思考問題和決策
【PO】建立產品願景、產品路線圖；梳理最有價值的產品功能，
【PO】把最有價值的產品功能維護到一個按照優先順序排列的產品待辦列表(Product Backlog)
【PO】負責細化產品待辦列表中的所有使用者故事
【SM】召開產品待辦規劃會，PO按照優先順序描述要做的產品待辦，團隊進行理解、提問，PO針對問題進行細化；團隊會後進行工作了的預估和安排。
【SM】召開迭代規劃會，PO按照優先順序逐條詳細講解本次迭代要完成的產品待辦，研發團隊按照優先順序挑選要完成的產品待辦，直到下個迭代工作量達到飽和，同時建立關聯的任務待辦列表，並和產品待辦關聯。
【研發團隊】自組織召開每日站立會，SM和 PO 必須參加；每個人講完自己的進度後，更新任務看板內容。PO幫助接到迭代中的問題；SM 解決影響團隊高效能的問題。
【SM】召開迭代評審會，研發團隊進行show case，接受評價；PO以使用者故事是否能成功交付來評價任務完成情況。
【SM】召開迭代反思會，總結哪些做的好，要保留；哪些做得不好，要改進

Scrum 5個會議

5.1 產品待辦規劃會（Backlog Grooming Meeting）

開會時間：通常是迭代計劃會開始前3天
參與人員：PO，SM，研發團隊
開會目標：我們下個迭代要做的內容，開發團隊確認任務故事點
PO把下次迭代將要實現的使用者故事、按照優先順序描述給在場的人員
團隊明確指出需求不明確或者有問題的地方，PO記錄，會後補全、澄清
開發團隊評估任務故事點
開發團隊建立子任務並關聯

5.2 迭代計劃會（Sprint Planning）

開會時間：迭代開始的第一天
參與人員：PO，SM，研發團隊
會議目標：決定我們下個迭代要做哪些內容。
PO確認待辦事項整理會議上的問題都已經解決，功能已經完善或者不足。產品功能列表已經按照客戶價值優先順序排序。
PO 逐條詳細講解要完成的產品待辦，尤其是之前存在問題的待辦。
開發團隊根據待辦事項整理會議會後評估的工作量，從高到低挑選待辦，直到本次迭代工作量達到飽和。
PO 參與討論並回答和需求相關的問題，但不干擾估算結果。
最終產生迭代待辦事項列表（Sprint Backlog）
隊員認領任務

5.3 每日站會（Daily Scrum）

參與人員：PO，SM，研發團隊
會議目標：瞭解團隊現狀
每日Scrum通常不超過15分鐘。
每日Scrum中可能有簡要的問題澄清和回答，但不討論。每日Scrum既不是向管理層彙報，也不是向產品負責人或者ScrumMaster彙報。它是一個開發團隊內部的溝通會議，來保證他們對現狀有一致的瞭解。

開發團隊是自組織的，通過每日站會來確認他們仍然可以實現迭代的目標。每一個開發團隊成員需要提供以下三點資訊：

昨天我完成了什麼
今天我計劃完成什麼
有什麼問題

5.4 迭代評審會（Sprint Review）

開會時間：迭代結束前，通常1小時
參與人員：PO，SM，開發團隊、利益感謝人
在衝刺結束前，團隊成員給產品負責人展示專案成果，接受評價
PO 給出評價和反饋。以使用者故事是否能成功交付來評價任務完成情況。

5.5 迭代反思會（Sprint Retrospective）

開會時間：迭代結束後，通常1小時
參與人員：PO，SM，研發團隊
簡短的反思會，總結哪些事情做得好，哪些事情做得不好。
做得好的要保留，做得不好的要摒棄。
會議得出這樣的結論：開始做什麼、繼續做什麼、停止做什麼

Scrum 3個工件

產品待辦列表

產品待辦是對產品功能的詳細描述。
產品待辦的來源可以是產品功能需求、缺陷、改進、技術升級等
產品待辦列表是一個具有優先順序的需求列表，並對每個需求進行了粗略的估算。
產品待辦列表是產品需求的唯一來源，開發團隊所有工作都來自產品待辦列表
只有PO有權對產品待辦列表更改優先順序、刪除、新增。

好的產品待辦列表要做到DEEP

粗細適宜的（Detailed appropriately）：待辦事項列表頂端的百分之十可能包含非常小且分析得很詳細的事項，而其他的百分之九十則不是那麼具體。
估算過的（Estimated）：團隊提供給產品負責人產品待辦事項列表中每個事項的工作量估算和技術風險估算。
湧現式的（Emergent）：為了響應學習和變化，要定期梳理產品待辦事項列表。產品負責人會不斷地更新產品待辦事項列表，以反映客戶需求的變化、新想法或見解、競爭而導致的變化、出現的技術障礙等。
排好優先順序的（Prioritized）：在產品待辦事項列表頂端的事項具有最高優先順序，或者是從1開始順序排列。

迭代待辦列表

來源於產品待辦列表：在迭代計劃會議上，自組織團隊在會議中生成迭代待辦列表。團隊從產品待辦列表中挑選出要在本輪迭代要完成的使用者故事，將使用者故事轉化為具體的任務，每項任務落實到具體的責任人。
迭代待辦列表是當前迭代需要完成的產品待辦列表。

可交付產品增量(Increment)

可工作的軟體功能增量。
需要在迭代評審會議上進行演示
迭代結束前，功能增量需要達到團隊「完成」的定義的標準
無論PO決定釋出它與否，增量必須可用

Scrum的思考

學習完了 Scrum，下面的問題，你是否思考過？

PO 的老闆是誰、誰來給PO打績效、考核的標準是啥？
SM 的老闆是誰、誰來給SM打績效、考核的標準是啥？
SM 是教練，團隊成員表現不好，SM 是否有權讓其下場休息？
SM 是服務型領導，除了服務, 還能領導什麼？
SM 確保團隊實施和使用Scrum。團隊成功一定要採取 Scrum 麼？是否可以採取一部分？
Team 老闆是誰、誰來給團隊成員打績效、考核的標準是啥？團隊內部的人還是外部的人？內部的人是否公正，外部的人是否瞭解其工作內容、成果和狀態？
團隊績效和個人績效啥關係？
整個團隊執行 Scrum 很好，但產出不及「雞」的預期怎麼辦？
PO負責產品代辦列表的內容、優先順序和交付日期，期望Sprint 代辦上的內容能儘快解決，但Team在做不在「Sprint 代辦列表上」的事情如何解決？
PO期望每個有價值的增量做完驗證後能及時上線交付，Team 只想每週三釋出一次，誰來決定？
業務線剛建立初期，PO想團隊能跑得更快些，儘快釋出功能收集使用者反饋；Team 想打牢基礎做好架構將來好維護，一個需求做了兩星期，怎麼破解？
業務有一定業務量後，PO想把產品功能完備；Team 想重構優化產品效能，如何？
SM在其它團隊帶來的需求是否具有更高優先順序？
迭代中，團隊需要出一個報告，現在需要查詢資料，這個誰來支援？
安全團隊掃除了安全漏洞，這個誰來負責？
線上系統告警了，處理流程是啥？誰來負責？
使用者期望用我們系統的時候，希望事先有檔案、中間有培訓，後續有支援，這個怎麼辦？
公司的所有系統要申報智慧財產權，申請專利，誰來負責？
非「按部就班」的工作放到產品代辦列表中，PO去跟進？還是 SM 去跟進？
需要立刻處理的事情，是否可以插入迭代中？還是插入一個然後抽出一個同工作量的待辦？

上面的很多問題，都是實際工作中的問題。你是否思考過？

參考文章

Scrum 的 4種會議 https://www.cnblogs.com/jetlian/p/4160113.html

敏捷開發流程之Scrum：3個角色、5個會議、12原則 https://juejin.cn/post/6844904039822409735

敏捷開發方法——XP及SCRUM https://zhuanlan.zhihu.com/p/61217539

研發效能組織能力建設之特性團隊FeatureTeam（上）
陳宗綿｜關於研發效能的理想與現實

感謝點贊、轉載
關注我，瞭解最新研發效能發展動向
歡迎進入「DevOps研發效能群」一起探討

什麼是Scrum？Scrum的核心要點和精髓