敏捷開發的角色和職責闡述

 

  敏捷開發中的PO即Product Owner，產品或業務負責人，即熟悉該產品全部業務相關的邏輯、流程、設置等方面事宜的人員，通常可由產品經理擔任，也可由熟悉業務的開發人員擔任。若是敏捷團隊是在一塊兒辦公的，建議由產品經理擔任，自己產品經理已是全部業務的接口人，熟悉業務是其本職工做；若是產品經理和開發、測試團隊是兩地辦公的，如設立的研發中心、外包服務等形式的，建議在開發團隊內指定一我的來擔任PO，這樣產品經理在第一次PRD全體review以後，只需跟這個PO講解清楚產品邏輯，後續開發和測試當中遇到的問題，均可以諮詢PO來獲得解決，PO不肯定的能夠聯繫產品經理確認，這樣能夠減小一部分的溝通成本。

    敏捷開發中的SM即Scrum Master，字面意思是敏捷專家或者敏捷大師，即熟悉敏捷開發模式及敏捷實施流程的人員，通常可由敏捷團隊當中的開發負責人擔任，部分能力很強且懂技術的產品經理也可擔任這個角色，因涉及到工做量評估和分派等工做，最好都是由技術能力較強的人員擔任。

Product Owner（PO）

Product Owner角色定義

肯定產品的方向和願景，定義產品發佈的內容、優先級及交付時間，爲產品ROI（profitability of product）負責。 是維護產品需求清單（ product backlog ）的人，表明利益相關者的利益。

Product Owner工做職責

負責最大化產品以及開發團隊工做的價值。主要職責以下：

一、肯定產品的功能；

二、決定發佈的日期和發佈內容；

三、爲產品的ROI負責；

四、根據市場價值肯定功能優先級；

五、每一個sprint中，根據須要調整功能和優先級（每一個sprint開始前調整）；

六、接受或拒絕開發團隊的工做成果；

七、參與Scrum Planning Meetings（Sprint計劃會議），Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）

Product Owner在團隊中的做用

在junior團隊中：主要的需求來源，我的肯定需求價值和優先級

在intermediate團隊中：多角度的收集需求，和團隊成員共同肯定需求的價值和優先級

在Senior團隊中：和團隊成員共同提出和收集需求，共同對產品負責

這裏的團隊分級主要是指團隊的敏捷成熟度，即產品團隊實施敏捷開發模式後，對敏捷開發模式的適應程度、接受程度和學習程度。後面會專門介紹團隊的評估標準。

一句話總結PO這個角色就是：告訴產品團隊要作什麼，作功能的前後順序是怎樣的，需求有變更時該如何處理。

Scrum Master（SM）

Scrum Master角色定義

是團隊的導師和組織者，與Product Owner緊密合做，及時爲團隊成員提供幫助。促使team按照scrum方式運行，爲Scrum過程負責的人。

Scrum Master並不是團隊的領導（由於團隊是自我組織的），而是一個負責屏蔽外界對開發團隊干擾的角色。 Scrum Master是規則的執行者，他是Scrum團隊中的服務型領導。

Scrum Master工做職責

確保scrum被理解和正確使用並使得Scrum的收益最大化。主要職責以下：

一、保證團隊資源合理利用；

二、保證各個角色及職責良好協做；

三、解決團隊開發中的障礙；

四、做爲團隊和團隊外部的接口，協調解決溝通中的問題；

五、保證開發過程按計劃進行，組織Scrum Planning Meetings（Sprint計劃會議）, Daily Stand-up Meeting（每日站會）, Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）。

Scrum Master在團隊中的做用

在junior團隊中：主導和控制

在intermediate團隊中：引導和教導

在Senior團隊中：輔導和協助

一句話總結SM這個角色就是：教整個團隊怎麼作，如何估時，跟進天天進度，風險控制，按期總結，計劃排定。
---------------------
做者：SmartBrain
來源：CSDN
原文：https://blog.csdn.net/Peter_Changyb/article/details/90319032
版權聲明：本文爲博主原創文章，轉載請附上博文連接！

 

 

 

 

Scurm敏捷開發Master的工做職責

在Scrum敏捷開發中有三種主要的角色：

Product Owner（產品負責人，簡稱"PO"）; 

Scrum Master（敏捷教練）; 

Team（團隊）。

其中，Scrum Master是其重要的角色之一。那麼今天咱們就來探討一下如何作一個合格的Scrum Master。

Scrum Master在許多的項目開發中被視爲項目經理，這實際上是個誤區。同時我也常常看到有人主張將Scrum Master與項目經理徹底區分，對於此我也不太贊成。在我看來Scrum Master雖然並不是項目經理，可是仍然肩負着不少項目經理的職能。那麼Scrum Master的職責到底是什麼呢？該怎樣作才能成爲一名合格的Scrum Master呢？如下六項，供您參考。若有不妥之處，歡迎探討；）

管理Scrum流程

---

這是Scrum Master最核心的職責，也是Scrum Master區別於項目經理的最顯著的特徵。Scrum Master須要維護每一個sprint的流程，確保每一個sprint可以順利的實施以及完成。

首先，Scrum Master負責主持召開sprint期間的每個會議，包括sprint plan meeting， daily scrum meeting， sprint grooming meeting，sprint review meeting以及sprint retrospective meeting。

另外，Scrum Master還須要幫助PO創建product backlog與sprint backlog，並確立其中每一個story的優先級。

最後，Scrum Master還須要幫助Team清除在開發的過程當中遇到的障礙。Scrum Master應該有一個block list用來記錄Team在開發中遇到的問題障礙，由Scrum Master本身進行管理並最終使得列表中的每一問題獲得及時處理。

保護團隊

---

Scrum Master應該最大限度的保護Team，以確保Team不會被外界，尤爲是PO干擾。那麼Scrum Master該如何保護團隊呢？Team在什麼狀況下須要保護呢？

在每一個sprint的初期制定計劃的時候，Scrum Master應合理的根據Team的工做能力以及過往經驗，承諾工做量。不要盲目樂觀的給PO承諾過量的工做。我就遇到過有的Scrum Master多是對於Team的能力估計不足，也多是但願經過承諾更過的工做獲取老闆的芳心，承諾了太多的工做，結果致使Team在sprint的後期連續加班，導致Team的效率嚴重下降。同時因爲時間的匆忙，急於交付，致使了項目的質量很低，最終造成了惡性循環。一個好的Scrum Master在這個時候是應該要懂得如何與PO「周旋」，獲取合理的工做量。這裏的「周旋」並不是消極怠工，故意減小Team的工做量，這實際上是經過安排合理的工做量來使團隊達到最大的工做效率，同時不會傷害Team的積極能動性。這是一個良性的循環。

咱們都知道，需求的變動對於每個開發人員來講都是噩夢，而敏捷誕生的其中的一個很重要的緣由就是爲了解決這一問題，讓開發者擁抱變化。然而在咱們採用敏捷開發的項目中，常常能夠遇到Product Owner越過Scrum Master，直接找到Team, 對他們指手畫腳，發號施令。這個時候，Scrum Master應該像「猛獸」同樣將PO「吼開」，以免Team受到「傷害」。需求改變能夠，可是不該該在sprint的過程當中干擾Team, 能夠在daily scrum meeting或者sprint plan meeting上提出，共商解決方案。我以爲Scrum Master對Team在不少時候都應該有一種「護犢子」的精神。確保Team神聖不可侵犯。

有效溝通

---

不少時候Scrum Master起到了一種「承上啓下」的做用。一頭面對的PO以及本身的老闆，另外一頭面對的是Team。很容易令人感受Scrum Master彷彿在夾縫中求生存，容易兩邊都不討好。所以，溝通藝術的重要性不言而喻。如何說服PO，使得老闆滿意，而且讓Team開心，這是一門學問。對於此，下面幾點能夠做爲參考：

1. 面向老闆：

應按期及時的通報項目的狀態與進展，不要等到老闆親自來問，能夠經過表格以電子郵件的方式發送。主要彙報進展狀態，避免過於細節的內容；
遇到問題，應及時上報，使得問題在出現時就能獲得重視，並被及時解決。若是等到截止時間才發佈壞消息，那麼就給了你的老闆對你進行微觀管理的機會。

2. 面向Team:

最重要的一點，應以身做則，態度端正；
充分了解Team中每一個成員的能力情況，防止出現工做量盲目承諾的問題；
經過daily scrum meeting讓Team中每一個人都能明確瞭解最新的進展與形勢；
遇到問題，應對事不對人。

把關質量

---

此刻開始，Scrum Master更像是一個項目經理。不管是質量，進度仍是團隊建設都更像是項目經理的職責。對於Team來說，這時的Scrum Master再也不是那個「保護」咱們的人，而變成了那個「收保護費」的大佬。然而，在實際項目中，Scrum Master確實要承擔這些職責，只不過有些已經融入到平常的scrum流程中去了。

關於質量的管理，我想其重要性不言而喻。質量是決定了產品的命運。那麼如何把關質量了。在敏捷實踐中，以下的經驗可供參考：

1）欲速則不達。不該過於強調速度，應保持合理的開發節奏，纔會使得產品質量具備必定的保障。Scrum流程在每一個sprint應統一完整，使得Team造成習慣，最終達到良好的開發節奏。

2）制定coding style，並堅持代碼審查。代碼的規範很是重要，好的代碼能夠提升總體團隊的開發與溝通的效率。好的代碼會說話。代碼審查能夠結對完成，只有審查經過，才能夠提交代碼。能夠經過建立pull request來進行代碼的審查，經過以後，再merge到代碼庫中去。

3）寫單元測試。單元測試的重要性我想你們都明白，只是不少人以爲寫起來痛苦，麻煩，佔用開發時間。有了單元測試，你的代碼纔是經得起考驗的代碼。

4）冒煙測試。在天天下班以前，中止push代碼，而後進行冒煙測試。冒煙測試成功以後，纔會下班回家。這是一種很好的方法，它保證了天天功能都是可用的，從而確保了質量。

5）自動化測試。它的好處，不用多說，誰用誰知道：）

6）提前集成，以便頻繁獲取反饋。這樣的好處在於咱們能夠及時的獲得用戶的需求反饋，進而可以及早修正。

7）最後，我要強調一句：不要加班，不要加班，不要加班。

跟蹤進度

---

進度管理是Scrum Master的又一項項目經理職責。對於scrum中進度的監控，咱們有不少的方法，也很是有效。

先說工具，敏捷開發中，比較傳統的跟蹤進度，同時使用也很是普遍的一種方式是Story Board（故事版）。這種方式簡單直觀，很是有效。即便如今已經涌現了不少很是優秀的電子管理工具，許多團隊仍然對它情有獨鍾。近些年一些電子的跟蹤進度的srcum工具出現了不少。比較有名的像是jira. 它的使用也很是的簡單直觀，並且功能很是豐富強大，強烈推薦你們使用。

另外，咱們能夠經過daily scrum meeting獲取到Team天天的工做進展。此時咱們能夠根據進展進行一些必要的調整。

團隊建設

---

團隊建設是項目開發中絕對不容忽視的一環。團隊凝聚力如何，直接影響了整個團隊的戰鬥力。所以，建設好團隊，是每一個Scrum Master的重要使命。

那麼如何有效的進行團隊建設呢？

1）放權。敏捷開發的其中的一個重要的特徵就是團隊自組織。團隊自組織的優點就在於，經過放權給團隊，讓它們自主的思考，設計開發，不對其干預，從而使得團隊中每一個人具備成就感，進而提升整個團隊的積極能動性。

2）打造學習型團隊。一個方法就是經過團隊內部知識按期分享的方式，使得每一個人都能能夠學到新的知識，從而逐步使得團隊成長。好比每週五的下午4點，能夠利用一小時的時間，讓團隊的成員舉辦知識講座。經過這種形式，你們的積極性會變的很高。能夠約定分享的內容並不是必定是技術方面的，也能夠是生活娛樂等，只要你們感興趣就好。這樣作的好處在於不只提升了團隊的技術能力，也使得團隊之間可以更輕鬆愉快的交流，從而提高團隊的凝聚力，戰鬥力。

3）最後，提升團隊最有效的一個方法，那就是一個字：吃；）這是拉攏吃貨們的大好時機。固然這個須要經費，不過方法總會有的，你懂的；）

做者：Ifdef_Max連接：https://www.jianshu.com/p/72a5c42cec8b