有點長，期望你能通過本文徹底了解 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種會議 http://www.rzrgm.cn/jetlian/p/4160113.html

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

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

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

 

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