敏捷團(tuán)隊(duì)內(nèi)部的角色與分工
ScrumMaster、Product Owner和Dev Team在Scrum中扮演的角色是不同的,本篇文章分別為大家介紹了團(tuán)隊(duì)中這三種角色需要承擔(dān)的職責(zé),希望通過本文大家能夠了解Scrum團(tuán)隊(duì)是如何構(gòu)建的,其作用又是什么。
關(guān)于敏捷開發(fā)的問題,被提及最多的便是關(guān)于團(tuán)隊(duì)和人員的問題。
定義里會告訴你:Scrum團(tuán)隊(duì)是自組織、跨職能的完整團(tuán)隊(duì)。
那么究竟怎樣的團(tuán)隊(duì)才是自組織的團(tuán)隊(duì),什么樣的分工算是跨職能?我們將在本文中為您詳細(xì)介紹。
Scrum團(tuán)隊(duì)里的三種角色
Scrum團(tuán)隊(duì)中包括三種角色,分別是ScrumMaster、Product Owner和Dev Team。
- Product Owner主要負(fù)責(zé)構(gòu)建正確的產(chǎn)品;
- Dev Team負(fù)責(zé)以正確的方式構(gòu)建產(chǎn)品;
- ScrumMaster則主要負(fù)責(zé)幫助產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)中的每個人理解和擁抱Scrum的價值觀、原則和實(shí)踐。
所謂Scrum團(tuán)隊(duì)的自組織,就是說他們會在內(nèi)部決定如何最好地完成他們的工作,而不是由團(tuán)隊(duì)外的其他人來指揮他們。
關(guān)于Scrum團(tuán)隊(duì)和流程的基本框架,可以參考下圖:
(Scrum團(tuán)隊(duì)框架)
1. Scrum Master
ScrumMaster是Scrum的教練和領(lǐng)隊(duì)人。
關(guān)于Scrum Master的認(rèn)知有一個誤區(qū):這個角色在許多的項(xiàng)目開發(fā)中會被視為項(xiàng)目經(jīng)理。
Scrum Master保證的是敏捷開發(fā)的流程和秩序。對于項(xiàng)目的進(jìn)展和結(jié)果,整個團(tuán)隊(duì)都需要負(fù)責(zé)。
團(tuán)隊(duì)主要且唯一的任務(wù)是開發(fā)產(chǎn)品,不是來照著規(guī)范、教條來做敏捷,敏捷開發(fā)只是工具。而做產(chǎn)品的是 “人”不是 “角色”。
比如在Worktile的敏捷團(tuán)隊(duì)中,Scrum Master就是由開發(fā)團(tuán)隊(duì)的成員輪流擔(dān)任,他們是對產(chǎn)品最熟悉的人,也是對Scrum流程最熟悉的人,他們每一個人都具備成為ScrumMaster的潛力。
同時,Scrum Master的工作可以提升每位成員軟件開發(fā)能力之外的管理能力。
作為一個合格的Scrum Master,需要擔(dān)起以下職責(zé):
① 需要領(lǐng)導(dǎo)和指導(dǎo)團(tuán)隊(duì)采用 Scrum,并管理Scrum流程;
這是Scrum Master最核心的職責(zé),Scrum Master需要維護(hù)每個sprint的流程,確保每個sprint能夠順利的實(shí)施。
Scrum Master負(fù)責(zé)組織召開sprint期間的每一個會議,并且Scrum Master還需要幫助開發(fā)團(tuán)隊(duì)清除在開發(fā)的過程中遇到的障礙。
Scrum Master應(yīng)該有一個block list用來記錄開發(fā)團(tuán)隊(duì)在開發(fā)中遇到的問題障礙,由Scrum Master自己進(jìn)行管理并最終使得列表中的每一問題得到及時處理。
② Scrum Master要保護(hù)開發(fā)團(tuán)隊(duì)不受干擾;
我們都知道,需求變更對于每一個開發(fā)人員來說都是噩夢,而敏捷誕生的其中的一個很重要的原因就是為了解決這一問題。然而在我們采用敏捷開發(fā)的項(xiàng)目中,經(jīng)常會遇到某位領(lǐng)導(dǎo)直接找到開發(fā)團(tuán)隊(duì), 對他們指手畫腳,發(fā)號施令。
這時Scrum Master應(yīng)該及時阻止,因?yàn)樾枨箅m然可以變更,但是不應(yīng)該在sprint的過程中干擾開發(fā)團(tuán)隊(duì), 可以在Daily scrum meeting或者Sprint plan meeting上提出,大家共同商討解決方案。
③ Scrum Master要說服開發(fā)團(tuán)隊(duì)幫助員工及干系人理解并實(shí)施 Scrum;
這就需要Scrum Master有很強(qiáng)的溝通能力和領(lǐng)導(dǎo)能力,他需要幫助 Scrum 團(tuán)隊(duì)外的人員了解他們?nèi)绾闻c Scrum 團(tuán)隊(duì)交互是有益的。Scrum Master 通過改變這些交互來最大化 Scrum 團(tuán)隊(duì)所創(chuàng)造的價值。
④ 建設(shè)好團(tuán)隊(duì),使團(tuán)隊(duì)成員處于一個愉悅的工作氛圍中。
團(tuán)隊(duì)建設(shè)是項(xiàng)目開發(fā)中絕對不容忽視的一環(huán)。團(tuán)隊(duì)凝聚力如何,直接影響了整個團(tuán)隊(duì)的戰(zhàn)斗力。
因此,建設(shè)好團(tuán)隊(duì),是每個Scrum Master的重要使命。
比如,開發(fā)團(tuán)隊(duì)最近的工作狀態(tài)不佳,或者工作氛圍苦悶,Scrum Master可以主動提議組織一些出行活動,既能為團(tuán)隊(duì)成員們解壓,提高站斗力,也能增加團(tuán)隊(duì)的凝聚力。
除此之外,還可以打造學(xué)習(xí)型團(tuán)隊(duì)。比如通過團(tuán)隊(duì)內(nèi)部知識定期分享的方式,使得每個人都能可以學(xué)到新的知識,從而逐步使得團(tuán)隊(duì)成長;比如Worktile每周五的下午4點(diǎn),可以利用一小時的時間,讓團(tuán)隊(duì)的成員舉辦知識講座。
通過這種形式,大家的積極性會變的很高??梢约s定分享的內(nèi)容并非一定是技術(shù)方面的,也可以是生活娛樂等,只要大家感興趣就好。這樣做的好處在于不僅提高了團(tuán)隊(duì)的技術(shù)能力,也使得團(tuán)隊(duì)之間能夠更輕松愉快的交流,從而提升團(tuán)隊(duì)的凝聚力和戰(zhàn)斗力。
2. Product Owner
Product Owner(PO)就是產(chǎn)品負(fù)責(zé)人,Product Owner需要明確產(chǎn)品的愿景。這個角色對于團(tuán)隊(duì)非常重要,決定“Why”和“What”。一般可以對應(yīng)為現(xiàn)有的產(chǎn)品經(jīng)理的角色。
Product Owner主要負(fù)責(zé)以下幾項(xiàng)工作:
①負(fù)責(zé)對Product Backlog的梳理、優(yōu)化、優(yōu)先級排序等;
② 負(fù)責(zé)決定團(tuán)隊(duì)每個Sprint要完成哪些任務(wù);
③負(fù)責(zé)最大化產(chǎn)品以及開發(fā)團(tuán)隊(duì)工作的價值,而實(shí)現(xiàn)這一點(diǎn)的方式會隨著組織、Scrum 團(tuán)隊(duì)以及單個團(tuán)隊(duì)成員的不同而不同;
④Product Owner要對產(chǎn)品的質(zhì)量把關(guān)。質(zhì)量決定了產(chǎn)品的命運(yùn)。
要注意一點(diǎn),不要過于強(qiáng)調(diào)速度,應(yīng)保持合理的開發(fā)節(jié)奏,才會使得產(chǎn)品質(zhì)量具有一定的保障。Scrum流程在每個sprint應(yīng)統(tǒng)一完整,使得開發(fā)團(tuán)隊(duì)形成習(xí)慣,最終達(dá)到良好的開發(fā)節(jié)奏。
(Product Owner的工作內(nèi)容)
作為Product Owner,在工作過程中要注意以下幾點(diǎn):
①不要把交付能力作為團(tuán)隊(duì)的唯一評價標(biāo)準(zhǔn):速率雖然是對敏捷團(tuán)隊(duì)的衡量,但不應(yīng)該是唯一標(biāo)準(zhǔn)。因?yàn)镈ev Team的交付能力是隨著團(tuán)隊(duì)成熟度的上升而達(dá)到一個平衡,不能無限增加。
②要避免過多參與開發(fā)細(xì)節(jié):因?yàn)镻roduct Owner只需要負(fù)責(zé)決定產(chǎn)品要做成什么樣子,要有那些功能,而不具體參與開發(fā)團(tuán)隊(duì)如何實(shí)現(xiàn)這些功能,否則容易造成不能客觀的決定產(chǎn)品好壞,對Sprint的進(jìn)度也會有影響。
③要避免同時領(lǐng)導(dǎo)多個團(tuán)隊(duì):有些企業(yè)在轉(zhuǎn)型的時候,由于企業(yè)文化和產(chǎn)品架構(gòu)的問題,往往讓一個PO帶領(lǐng)多個團(tuán)隊(duì),這樣的好處是PO可以對多個有關(guān)聯(lián)的團(tuán)隊(duì)的工作進(jìn)度有總的把握,而且能夠更好的移除團(tuán)隊(duì)之間的相互依賴,但是同時帶來不好的一點(diǎn)是由于精力有限,可能無法同時兼顧多個團(tuán)隊(duì)的PO工作,顧此失彼。
(Product Owner與團(tuán)隊(duì)及干系人的關(guān)系)
根據(jù)PO的工作性質(zhì),我們可以發(fā)現(xiàn),PO必須具備良好的溝通能力,這是必要的。并且還有一點(diǎn)也很重要,PO必須是一個對項(xiàng)目十分了解的人,這樣才能夠?qū)拥降男枨筮M(jìn)行優(yōu)先級的排序。
PO的角色在團(tuán)隊(duì)中非常重要,如果溝通不到位,需求理解不正確,或者優(yōu)先級決定有問題,都可能導(dǎo)致Dev Team無法及時給出階段性的產(chǎn)品,就算給出,可能也達(dá)不到客戶所要的需求。
為保證產(chǎn)品負(fù)責(zé)人的工作不受影響,組織中的所有人員都必須尊重他的決定。
產(chǎn)品負(fù)責(zé)人所作的決定在Product Backlog的內(nèi)容和排序中要清晰可見。任何人都不得要求開發(fā)團(tuán)隊(duì)按照另一套需求開展工作,開發(fā)團(tuán)隊(duì)也不允許聽從任何其他人的指令。
3. Dev Team
在敏捷開發(fā)中除了PO跟SM之外,另外一個非常重要的角色就是Dev Team,也就是我們的開發(fā)團(tuán)隊(duì)。
開發(fā)團(tuán)隊(duì)包含了專業(yè)人員,Sprint中需要完成的Product Backlog數(shù)目、做多少工作都完全由開發(fā)團(tuán)隊(duì)決定,PO或任何其它人都不能給開發(fā)團(tuán)隊(duì)強(qiáng)加更多的工作量。
開發(fā)團(tuán)隊(duì)的大部分時間都花在Sprint執(zhí)行上,他們負(fù)責(zé)在每個 Sprint 的結(jié)尾交付潛在可發(fā)布的“完成”產(chǎn)品增量,只有開發(fā)團(tuán)隊(duì)的成員才能創(chuàng)造增量。
開發(fā)團(tuán)隊(duì)有以下幾個特點(diǎn):
①他們是自組織的,沒有人可以決定開發(fā)團(tuán)隊(duì)如何把Product Backlog變成潛在可發(fā)布的功能;
②開發(fā)團(tuán)隊(duì)是跨職能的,團(tuán)隊(duì)作為一個整體,擁有創(chuàng)造產(chǎn)品增量所需要的全部技能;
③Scrum 不認(rèn)可開發(fā)團(tuán)隊(duì)成員的頭銜,無論承擔(dān)哪種工作他們都是開發(fā)者。此規(guī)則無一例外;
④開發(fā)團(tuán)隊(duì)中的每個成員可以有特長和專注領(lǐng)域,但是責(zé)任歸屬于整個開發(fā)團(tuán)隊(duì)。
要知道,將一個新的團(tuán)隊(duì)磨合成敏捷開發(fā)所要求的自組織團(tuán)隊(duì)是非常重要的,也是非常困難的,尤其是在實(shí)際的開發(fā)進(jìn)度和需求等不定因素的影響下。
因此,提高團(tuán)隊(duì)的凝聚力是創(chuàng)建自組織團(tuán)隊(duì)一個重要因素,而團(tuán)隊(duì)的凝聚力就來自于大家都在為一件事而努力,每天都在做,而且經(jīng)常有提高。
為了提高團(tuán)隊(duì)凝聚力,有很多途徑可以實(shí)施,例如在每天的站立會議,Dev Team成員除了介紹每天的工作,還可以快速形成某個團(tuán)隊(duì)級別的決議,例如將某個方法作為公共模塊,臨時調(diào)整資源等,解決阻礙團(tuán)隊(duì)的重大問題。開發(fā)團(tuán)隊(duì)成員每天進(jìn)行集體溝通,每個人都有機(jī)會發(fā)言,都可以感受到其他人對項(xiàng)目的貢獻(xiàn),會有一種是整個項(xiàng)目和產(chǎn)品的主人翁的感覺。
總結(jié)
ScrumMaster、Product Owner和Dev Team三個角色在Scrum中各自承擔(dān)不同的責(zé)任,每個Sprint的按期交付,都要靠團(tuán)隊(duì)齊心協(xié)力、相互配合,才能真正的將需求實(shí)現(xiàn)為用戶需要的產(chǎn)品。
Scrum也有其自身的先天缺點(diǎn),就是對團(tuán)隊(duì)要求高,團(tuán)隊(duì)成員有能力且相互信任度高,不會相互推卸責(zé)任。新團(tuán)隊(duì)使用該方法,起初會有各種問題,需要多多磨合。
#專欄作家#
袁林,人人都是產(chǎn)品經(jīng)理專欄作家。分享SaaS運(yùn)營和企業(yè)管理/協(xié)作/辦公的相關(guān)知識
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于 CC0 協(xié)議
對“po(產(chǎn)品負(fù)責(zé)人)一般可以對應(yīng)為現(xiàn)有的產(chǎn)品經(jīng)理的角色”這個觀點(diǎn)有點(diǎn)疑問,是不是需要分場景來定?
A場景(假設(shè))張曉龍要做微信產(chǎn)品,他決定用scrum來實(shí)施,那么po是張曉龍,不是因?yàn)閺埵钱a(chǎn)品經(jīng)理,而是因?yàn)閺埵菫楫a(chǎn)品的價值負(fù)責(zé)的人,是最了解產(chǎn)品愿景的人。
B場景 某公司邀請某軟件開發(fā)團(tuán)隊(duì)(團(tuán)隊(duì)包括產(chǎn)品經(jīng)理和技術(shù)開發(fā)人員)協(xié)助某產(chǎn)品開發(fā)。這種情景下,po是不是不應(yīng)該為這個被邀請團(tuán)隊(duì)的產(chǎn)品經(jīng)理,而應(yīng)該是這個項(xiàng)目的發(fā)起人或者是發(fā)起人指定的人員,因?yàn)楸谎垐F(tuán)隊(duì)的產(chǎn)品經(jīng)理其實(shí)也應(yīng)該歸屬為開發(fā)團(tuán)隊(duì),同時項(xiàng)目發(fā)起人或者是發(fā)起人授權(quán)的人員(客戶方)才是真正了解產(chǎn)品愿景的人 。
請大佬指教(求知.jpg)