敏捷的角色主要有三個：Product Owner、Scrum Master、Scrum Team，這些角色與傳統(tǒng)開發(fā)都存在著一定差別，并主要體現(xiàn)在職責(zé)、工作方式、組織架構(gòu)上。

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

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

老板：那就讓小條擔(dān)任Scrum master吧！

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

老板：（干?。┠俏耶?dāng)Scrum master行了吧！

……

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

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

概要

1. 敏捷的角色
2. 敏捷三大角色和瀑布開發(fā)角色的區(qū)別
3. 角色的主要工作（會議主導(dǎo)+產(chǎn)物對應(yīng)）
4. 角色的誤區(qū)是什么

一、敏捷的角色

敏捷有一個經(jīng)典但不是很好笑的的雞豬梗。

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

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

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

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

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

• Product Owner
• Scrum Master
• Scrum Team

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

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

二、敏捷角色和傳統(tǒng)角色的區(qū)別

一言蔽之，一個傳統(tǒng)開發(fā)團(tuán)隊想要轉(zhuǎn)化成敏捷開發(fā)團(tuán)隊，可以從以下的對應(yīng)表格做出轉(zhuǎn)型。

圖片來源：一條翅膀

那么，這三大角色與傳統(tǒng)開發(fā)相比有什么區(qū)別呢？我們來談一談：

2.1 Scrum Master：The protector護(hù)法大師

Scrum master的角色任務(wù)是服務(wù)型領(lǐng)導(dǎo)，相當(dāng)于牧師給團(tuán)隊加血的薩滿或者鳥德，他主要保證：

• 對內(nèi)：確保團(tuán)隊友愛地協(xié)作，敏捷相關(guān)會議各種有效運行。
• 對外：為團(tuán)隊撐起保護(hù)傘，掃清障礙。

這個角色與項目經(jīng)理的角色非常像，然而他們在工作戰(zhàn)略上是有本質(zhì)區(qū)別的：

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

師傅的目標(biāo)就是讓團(tuán)隊踐行Scrum的思想，構(gòu)成一個美麗的敏捷團(tuán)隊。他們熬好一碗碗雞血，源源不斷得供給團(tuán)隊，但是又獨立于項目的實質(zhì)內(nèi)容，跳出生產(chǎn)之外。

項目經(jīng)理的后綴是Manager，尊稱經(jīng)理。

經(jīng)理的工作重點放在管理上，內(nèi)容無非就是與項目相關(guān)的進(jìn)度、成本、質(zhì)量、范圍、風(fēng)險等等內(nèi)容。

在具體落實上，他們氣質(zhì)的不同之處體現(xiàn)了團(tuán)隊文化——

圖片來源：一條翅膀

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

Product Owner角色的定位和產(chǎn)品經(jīng)理非常像，主要負(fù)責(zé)：

• 定位產(chǎn)品相關(guān)所有內(nèi)容，包括做什么/優(yōu)先級/發(fā)布時間/投資回報
• 判斷團(tuán)隊的開發(fā)成果是不是所需

產(chǎn)品負(fù)責(zé)人可以是項目經(jīng)理、業(yè)務(wù)分析師、系統(tǒng)設(shè)計師、用戶體驗架構(gòu)師以及所有其他業(yè)務(wù)組……所有這些都集于一身。這個角色應(yīng)該是無所不能和無所不在的。

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

• 產(chǎn)品經(jīng)理 – 與利益相關(guān)者合作，確定需求并確定優(yōu)先級。
• 項目經(jīng)理 – 保持對總體目標(biāo)的看法。管理資源，資本支出，外部依賴等。
• 業(yè)務(wù)分析師 – 負(fù)責(zé)記錄驗收標(biāo)準(zhǔn)并記錄圍繞用戶故事的對話。 sprint期間需求澄清的主要聯(lián)系人。
• 設(shè)計師 – 準(zhǔn)備一些屏幕截圖，線框等。

PO和PM有什么區(qū)別呢？

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

落實到具體操作，大型養(yǎng)老公司才把角色分那么細(xì)吧！

PO這個詞被引入的時候大概是20年前，那時候PM的概念可能是偏向?qū)ν?，但是放到現(xiàn)在，這兩個角色的責(zé)任已經(jīng)差別不大了。

2.3 The development team：懂更多的開發(fā)團(tuán)隊

Scrum的開發(fā)團(tuán)隊，差不多和傳統(tǒng)還是同一批人。但是他們需要懂更多！

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

對比如下：

圖片來源：一條翅膀

三、理想與現(xiàn)實：敏捷角色主要在做什么

我們在敏捷指導(dǎo)的很多概念手冊中， 可以看到很多一串串的角色任務(wù)。其實，團(tuán)隊的具體職責(zé)可以用會議（Ceremonies）和產(chǎn)出（Artefacts）來定位。

3.1 敏捷5大會議與角色職責(zé)

圖片來源：一條翅膀

3.2 敏捷產(chǎn)物和工作的職責(zé)

圖片來源：一條翅膀

四、敏捷角色定義案例

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

敏捷開發(fā)試圖構(gòu)架一個美好的烏托邦：

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

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

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

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

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

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

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

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

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

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

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

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

這個提議會被很多把Scrum教材放到頭頂?shù)呐笥炎钃稀?/p>

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

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

只要組織能接受，效果能出來，誰管你有沒有完全符合Scrum的標(biāo)準(zhǔn)定義？

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

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

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

就像你走路或開車一樣，都是邊走邊修正腳步，或邊開車邊調(diào)整方向盤，最后才能準(zhǔn)確地到達(dá)目的地。

本文由@一條翅膀 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議