敏捷的角色主要有三個：Product Owner、Scrum Master、Scrum Team，這些角色與傳統開發都存在著一定差別，并主要體現在職責、工作方式、組織架構上。

又到了建立新組的時候了，老板提議和友組提議：開發組最（Yi）近（Zhi）人手有點不夠，不如讓小翅同學同時擔任Scrum master和Product Owner吧？

友組老板特別緊張：不不不，Scrum master怎么可以同時擔任Product Owner! 我們得想別的方案。

老板：那就讓小條擔任Scrum master吧！

友組老板：不不不，小條是開發人員，開發人員不能擔任Scrum master，product Owner不能擔任Scrum Master!?這些角色不能串！

老板：（干?。┠俏耶擲crum master行了吧！

……

在上一篇《自從用了敏捷，天天在開會？ 4大Scrum會議如何才能有意義？》中，講到Scrum之所以區別于傳統開發，主要是體現在三個方面：角色（roles），會議（Ceremonies）和產物（Artefects）。

今天我們從如何組隊來聊一聊Scrum角色，以及組建敏捷團隊的那些事兒。

概要

1. 敏捷的角色
2. 敏捷三大角色和瀑布開發角色的區別
3. 角色的主要工作（會議主導+產物對應）
4. 角色的誤區是什么

一、敏捷的角色

敏捷有一個經典但不是很好笑的的雞豬梗。

一天，一頭豬和一只雞在路上散步，雞看了一下豬說，“嗨，我們合伙開一家餐館怎么樣？”。

豬回頭看了一下雞說，“好主意，那你準備給餐館起什么名字呢？”

雞想了想說“餐館名字叫火腿和雞蛋怎么樣？”

“我不這么認為”，豬說, “我全身投入，而你只是參與而已?！?/p>

“豬”角色?是全身投入項目和Scrum過程的人。Scrum有3個“豬”角色：

• Product Owner
• Scrum Master
• Scrum Team

“雞”角色 雞角色并不是實際Scrum過程的一部分，但是必須考慮他們。 敏捷方法的一個重要方面是使得用戶和利益相關者參與到過程中的時間。參與每一個沖刺的評審和計劃，并提供反饋對于這些人來說是非常重要的。這些角色包括：

• 用戶：軟件是為了某些人而創建！
• 利益所有者 (客戶，提供商)： 影響項目成功的人, 但只直接參與沖刺評審過程。
• 管理者：為產品開發團體架起環境的人

二、敏捷角色和傳統角色的區別

一言蔽之，一個傳統開發團隊想要轉化成敏捷開發團隊，可以從以下的對應表格做出轉型。

圖片來源：一條翅膀

那么，這三大角色與傳統開發相比有什么區別呢？我們來談一談：

2.1 Scrum Master：The protector護法大師

Scrum master的角色任務是服務型領導，相當于牧師給團隊加血的薩滿或者鳥德，他主要保證：

• 對內：確保團隊友愛地協作，敏捷相關會議各種有效運行。
• 對外：為團隊撐起保護傘，掃清障礙。

這個角色與項目經理的角色非常像，然而他們在工作戰略上是有本質區別的：

SM的后綴是Master，俗稱師傅。

師傅的目標就是讓團隊踐行Scrum的思想，構成一個美麗的敏捷團隊。他們熬好一碗碗雞血，源源不斷得供給團隊，但是又獨立于項目的實質內容，跳出生產之外。

項目經理的后綴是Manager，尊稱經理。

經理的工作重點放在管理上，內容無非就是與項目相關的進度、成本、質量、范圍、風險等等內容。

在具體落實上，他們氣質的不同之處體現了團隊文化——

圖片來源：一條翅膀

2.2?Product owner：The hub of business value需求價值中心

Product Owner角色的定位和產品經理非常像，主要負責：

• 定位產品相關所有內容，包括做什么/優先級/發布時間/投資回報
• 判斷團隊的開發成果是不是所需

產品負責人可以是項目經理、業務分析師、系統設計師、用戶體驗架構師以及所有其他業務組……所有這些都集于一身。這個角色應該是無所不能和無所不在的。

由于PO是一個非常艱巨的角色，所以有時候可能PO是一個團隊組成的，這個團隊可以包括：

• 產品經理 – 與利益相關者合作，確定需求并確定優先級。
• 項目經理 – 保持對總體目標的看法。管理資源，資本支出，外部依賴等。
• 業務分析師 – 負責記錄驗收標準并記錄圍繞用戶故事的對話。 sprint期間需求澄清的主要聯系人。
• 設計師 – 準備一些屏幕截圖，線框等。

PO和PM有什么區別呢？

理論上，PM會更加傾向外界溝通、市場和客戶分析、指定長期產品戰略。PO會比較傾向于內部的需求執行。

落實到具體操作，大型養老公司才把角色分那么細吧！

PO這個詞被引入的時候大概是20年前，那時候PM的概念可能是偏向對外，但是放到現在，這兩個角色的責任已經差別不大了。

2.3 The development team：懂更多的開發團隊

Scrum的開發團隊，差不多和傳統還是同一批人。但是他們需要懂更多！

• Scrum要求開發團隊成員由一批跨職能的人組成，他們擁有完成每個產品增量所需的全部技能。
• 他們也需要以自組織的方式實現Sprint目標，根據Sprint的計劃完成產品增量
• 他們要有能力和客戶溝通討論解決方案，也要和PO確定產品是什么

對比如下：

圖片來源：一條翅膀

三、理想與現實：敏捷角色主要在做什么

我們在敏捷指導的很多概念手冊中， 可以看到很多一串串的角色任務。其實，團隊的具體職責可以用會議（Ceremonies）和產出（Artefacts）來定位。

3.1 敏捷5大會議與角色職責

圖片來源：一條翅膀

3.2 敏捷產物和工作的職責

圖片來源：一條翅膀

四、敏捷角色定義案例

案例1： 客戶愿意花多少時間解決問題

敏捷開發試圖構架一個美好的烏托邦：

客戶和整個開發團隊包括研發、測試、架構師把酒言需求，大家一起在白板上涂鴉，最后，在場的人統一，這是一個足夠好的解決方案，雖然很有可能和一開始的圖已經很不一樣了。

整個方法最妙的地方是通過溝通，加分客戶爸爸可以一起思考類似于五彩斑斕的黑的需求可能會怎樣實現，前期定調，最后的產品大概率可以通過驗收。

那么問題來了，客戶爸爸很有時間嗎？

• 很多時候，客戶只希望透過幾次的文件討論，就能溝通好需求。
• 而開發團隊也未必有那么多時間陪客戶玩兒。

這時候就是考驗一個PO是不是一個好PO的時候了！

他需要足夠好的溝通能力，讓客戶理解既要馬兒跑（需求被100%了解），又要馬兒不吃草（又不想花時間好好討論）」是不能解決問題的。

一個好的PO, 也需要有“忠實傳達客戶需求和即時決策”的能力，并平衡好客戶和團隊理解需求的數據！

傳統的方法之所以會常常出問題，就是對客戶的窗口（PO）經常被內部開發團隊一問三不知，糾纏在需求的厘清中。在來來回回多趟之后，仍然是不清不楚，這才是最大的問題！

如果PO有能力領導一個小組（也許是2-5人不等）去跟客戶/用戶面對面地討論需求，不論是在使用者經驗（User?Experience）的設計層次上，或是在系統分析、架構設計（Architecture Design）、實作性、驗證性等技術層面上，都能考慮得夠周詳、夠務實、夠讓客戶/用戶滿意，那么這位PO就是一位成功的PO了。

此后，PO就有足夠可靠的代表性來代表客戶/用戶做對內的溝通。這樣小組能夠做到即時又有效率的各層面決策，無形之中就大幅縮短了客戶被不斷打擾問需求的總時間，客戶也會樂于接受這樣的互動方式。

案例二：到底PO可不可以同時是Scrum master

我們在一開始聊到在組隊之初很有可能因為人手不夠，一個人安排兩個職位。

這個提議會被很多把Scrum教材放到頭頂的朋友阻撓。

事實上，很多崗位的操作是可以和Scrum的標準定義有些不一樣。沒人禁止PO帶著DT的成員去跟客戶見面討論事情，更沒人說專案經理不能是SM！也沒有人規定DT人數一定要在9人以下！

一切的說法都只是“原則”（guideline），而不是“規定”。

只要組織能接受，效果能出來，誰管你有沒有完全符合Scrum的標準定義？

敏捷開發的核心是什么？是敏捷呀?。?！是解決任何問題是靈活的思路！

所以，請不要被任何人的定義綁住思維，只要能夠符合組織現況，能夠改善問題，甚至是徹底解決問題，這才是引用一個新方法架構的重點！

尤其是，當你想要解決一個組織內的陳疴之時，最好也能像Scrum的Sprint（沖刺）那樣，逐步漸進式地，看看效果如何之后，再修正一下，然后再往前進一步。

就像你走路或開車一樣，都是邊走邊修正腳步，或邊開車邊調整方向盤，最后才能準確地到達目的地。

本文由@一條翅膀 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議