Scrum轉型(二) Scrum的角色

1.1 ScurmMaster

做爲Scrum流程的捍衛者和佈道者，ScrumMaster在Scrum團隊中起到相當重要的做用，他們確保團隊使用正確的流程，確保團隊正確地召開各類會議，他們訓練團隊的敏捷思惟，他們和團隊外的相關干係人溝通。根據最新的Scrum研究報告，ScrumMaster自組織中傾向於服務於多個Scrum團隊。另外一個傾向就是在組織中ScrumMaster同項目經理分擔職責。

ScrumMaster對Scrum團隊而言，是一位服務型領導。ScrumMaster幫助Scrum團隊以外的人瞭解他如何與Scrum團隊交互是有益的，經過改變他們與Scrum團隊的協做的互動方式來最大化Scrum團隊所創造的價值。
--服務於產品負責人 --服務於開發團隊 --服務於組織

ScrumMaster的職業發展路線一般有以下4個方向

(1) 服務於更多個團隊或者更具挑戰性的問題

做爲ScrumMaster,最開始通常都是從服務於一個團隊開始。在經歷過一段時間的磨合之後，團隊的成熟度愈來愈高，愈來愈穩定。ScrumMaster就能夠去尋找更多的挑戰了

(2)成爲Agile Coach

有些ScrumMaster在經歷過一段時間的工做之後，他們發現本身熱衷於激發團隊進行創造的過程，而且無所謂產品自己。在經歷了一段時間的經驗積累之後，他們很是但願能夠把這些經驗分享給其餘新手ScrumMaster，對於這種人來講，轉型成爲Agile Coach就是一個很是不錯的選擇。

若是咱們把Agile Coach的成長之路分紅三個逐步躍升的層級。那麼第一個須要達到的入門層級就是做爲敏捷團隊的協調者（在團隊中角色叫作ScrumMaster），在這個級別須要實踐者具有敏捷實踐和協調的能力。接下來第二層就是Agile Coach了，與以前的一個級別的區別是，Agile Coach具備更多的實踐知識足以支撐他們解決更復雜的問題的同時，還具有引導，教導和專業指導的技能。在這條職業發展的路徑的頂峯是企業級Agile Coach，根據每一個人背景 的不一樣他們可能會有各自很是擅長的領域，分別是技術領域（開發出身），商務領域（產品負責人出身）和變革領域（ScrumMaster）出身。可是，坦白的來說，在目前的形勢下可以作到企業級Agile Coach的人仍是不多的。由於這些人的級別和能力和公司的CEO是在同一水平的，大部分具備這樣能力的人都直接會選擇作CEO.

(3)成爲產品負責人

還有一些人，也許作了一段時間ScrumMaster之後，發現本身對構建產品的過程很感興趣，那麼成爲一個產品負責人就是他們的最佳選擇。固然，我並非說產品負責人在組織中高於ScrumMaster這個角色。在理論上，這兩個角色是平級的關係。

(4)成爲管理者

對於像你這種從傳統的項目經理轉型成爲ScrumMaster的人來講，也許作了一段時間的ScrumMaster之後，你仍舊更但願轉回到傳統的管理角色上來。若是這時候，組織裏有機會，那麼也是能夠成爲管理者的。

ScrumMaster每日工做列表

一天的開始

1.更新和檢查目前衝刺的燃盡圖報表。
2.若是團隊落後於時間表，ScrumMaster須要幫助團隊想辦法追上進度。同時，ScrumMaster須要確保全部完成的任務都已經被標記成了完成，這樣燃盡圖的數據才準確。
3.檢查Sprint待辦列表裏的條目和相應的任務狀況。
　　3.1 檢查是否有任何遺漏信息
　　　　- 遺漏條目的工做量估算信息。
　　　　- 遺漏具體任務的估算信息。
　　　　- 正在進行和已經完成的任務遺漏任務人信息。
　　3.2 檢查是否有任何不一致的信息
　　　　- 是否有已經決定了不作了的條目仍舊能夠被選中。
　　　　- 已經完成了的任務卻沒有標記成完成。
　　　　- 沒有完成的任務卻標記成完成。

 ScrumMaster須要追蹤這些問題，並提醒相應的團隊成員做出更正。

工做期間

1.找出全部影響進度的工做
2.若是須要的話，協助團隊解決這些問題。
　　- 保護團隊成員不被團隊外的其餘人打擾。
　　- 教育團隊成員：他們應該先嚐試本身解決問題，若是解決不了的話他們須要找ScrumMaster來解決問題。
3.協調Scrum每日戰會
　　- 展現燃盡圖
　　- 聽取團隊成員關於每日站會的三個問題的回答。
　　- 明確下一步行動計劃和責任人。
　　- 和團隊分享有用的信息。
4.評審新加入產品列表的用戶故事，技術故事和問題，確保新加入的條目能夠被正確地指派到相應Scrum團隊。

每日工做結束

和天天開始時同樣： 評審狀態，查看是否有任何遺漏，錯誤的信息，跟蹤記錄團隊待解決問題的狀態。

準備計劃會議 

1.協調產品列表梳理會議。
2.統計下一個的迭代的生產能力。
    - 統計團隊成員下一個Sprint的休假計劃，公共假期和其餘影響生產力的信息。
    - 估算團隊下個迭代的生產力。
3.在各類電子和物理工具上更新相應的信息。 

計劃會議時

1.從頭至尾產看產品列表裏的條目，而且將條目一個一個地從優先級最高的開始順序念給團隊。
2.協調估算過程。
3.記錄團隊討論的內容（例如，估算的工做量，條目的詳情）。
4.將相應的條目拖拽到下一個Sprint的代辦列表。
5.建議團隊在工做量範圍之外多評估一部分用戶故事以備不時之需。

在評審會議上

ScrumMaster須要組織會議確保相應成員到場。

在回顧會議上

1.ScrumMaster組織團隊成員一塊兒回顧自上一個回顧會議之後團隊的工做狀態。
2.ScrumMaster組織，收集和記錄團隊成員討論的信息。
3.ScrumMaster協調確認下一個迭代團隊須要作的改進措施以及負責人。

ScrumMaster小結：

對於傳統的項目經理來講，他對項目負最終的責任，所以他也就同時被賦予了領導項目成員的權利。在項目當中，不管是開發，測試仍是產品經理，他們都是項目經理的下級，項目經理給他們分配任務，他們有義務按照項目經理的命令來完成任務。可是在敏捷當中，ScrumMaster和團隊成員都是平級的，不存在任何上下級關係。他雖然會承擔一部分傳統項目經理的職責，可是他並不具備命令項目成員的權利，也不像項目經理那樣對項目的成敗負全權的責任。固然他們更不會過問團隊成員的績效考覈，薪資等這些問題。他們是一個服務者，他們的服務要確保可以知足團隊最高優先級的須要。據個例子，項目經理會問：「那麼，今天你要準備爲我作什麼？」 相反，服務型領導的ScrumMaster會問：「那麼，爲了幫助你和團隊更加有效，今天我能作什麼？」

ScrumMaster相關書籍：《Scrum指南》《Scrum精髓》《Scrum捷徑》《Coaching Agile Team》《Agile Retrosectives》《看板方法》《精義思想》《SAFe白皮書》

1.2 產品負責人

做爲確保團隊做出正確產品以便幫助公司獲得最高投資回報的產品負責人，在Scrum團隊中負責「作什麼」的問題。不一樣公司，不一樣部門，不一樣團隊的產品負責人的具體職責不盡相同。可是，從整體上來講，產品負責人的工做包括：願景和邊界。產品負責人的工做包括兩個方向：提出正確的解決方案和確保解決方案被正確「製造」。 

產品負責人的職責是將開發團隊開發的產品價值最大化。產品負責人是負責管理產品待辦列表的惟一負責人。產品待辦列表的管理包括：

1.清晰的表達產品待辦列表項。
2.對產品待辦列表進行排序，使其最好地實現目標和使命。
3.優化開發團隊所執行工做的價值。
4.確保產品待辦列表對全部人是可見，透明和清晰的，同時顯示Scrum團隊下一步要作的工做。
5.確保開發團隊對產品待辦列表項有足夠深的瞭解。

產品負責人能夠親自完成上述工做，或者也可讓開發團隊來完成。然而不管何者，產品負責人是負最終責任的人。

Scrum組織中項目管理職責的映射，不過下面的表格是理想的狀態，實際狀況能夠根據項目狀況適當的調整。

在項目開始的階段，產品負責人會參與組合規劃和產品規劃。組爲組合規劃的一部分，產品負責人有可能要和組合經理和其餘產品負責人一塊兒討論可能影響新產品計劃的相關問題。在產品規劃過程當中，產品負責人和項目相關干係人，用戶和客戶一塊兒共同討論，一塊兒構思新產品。作完這些之後，組織會從經濟的角度進行篩選，以肯定開發工做是否能夠獲得資金，工做什麼時候開始（批准資金）。接下來，當項目獲得組織承認後，產品負責人須要參與制訂計劃的草案。這個活動通常包含一個故事寫做研討會，目的是產生一個可供版本規劃期間使用的概要產品列表。接下來，會再召開一個估算研討會，產品負責人也要參與，在這個研討會上，開發團隊成員會對高價值的故事進行評估。再接下來，會再召開一個會議，綜合考慮故事優先級，範圍，估算，項目相關干係人共同討論，制定足夠的版本計劃，獲得一個足夠清晰的總體版本，並對交付什麼，什麼時候交付之類的業務問題給出初步解答。在肯定版本計劃後，Scrum團隊就能夠執行第一個衝刺了。接下來，咱們說在每一個衝刺中產品負責人的工做。在衝刺開始的時候，產品負責人負責提供帶有優先級排序的產品列表（有完整的接受標準）而且回答團隊問題，以便制訂衝刺計劃。在執行衝刺時，產品負責人要隨時回答團隊對於故事的問題而且當特性完成時對特性進行測試。另一方面，產品負責人還要與項目內外部干係人溝通會面，確保爲下一輪衝刺設置正確的優先級順序，並得到對從此衝刺所選特性有影響的重要信息。同時，產品負責人還須要對產品列表進行梳理，包括書寫新的條目，細化現有條目等。

產品負責人每日工做列表

產品負責人天天都要作如下這些工做。

1.天天開始都要檢查Sprint待辦列表裏的條目和相應的任務狀況，若是有任何關於進度的疑問都須要追蹤。
2.協助團隊成員解決問題，澄清需求。
3.儘早評審已經開發完成的功能，確認功能是不是指望的。若是不是則須要決定是否要在本個迭代作出更改，或者放到下一個迭代繼續完成，或者須要建立新的用戶故事。
4.編寫新的用戶故事來完成更多的功能，而且向團隊澄清新的用戶故事。
5.編寫史詩級用戶故事（若是功能太大，單個用戶故事沒法承載的話）。
6.報告任何你發現的軟件問題。
7.參加每日站會（若是你和你的團隊認爲這樣有助於完成迭代目標）。
8.聽取並回答每日站會的三個標準問題。
9.發現須要你進一步跟進的任務。
10.和團隊分享有用的信息。

準備計劃會議 

收集足夠數量的待辦列表以便團隊在計劃會議上評審，而且按優先級排好順序。
    - 要以商業價值作做爲排序的依據，同時考慮到風險，潛在失敗的可能性和其餘相關的因素。
    - 列表項的信息裏要包含它與其餘列表項之間的依賴關係。

計劃會議中

1.和研發團隊，ScrumMaster一塊兒使計劃會議變得更有效。
2.產品負責人必須參加會議。
3.回到問題以澄清和解決有可能影響實施和估算的問題。
4.若是須要的話，須要更新用戶故事的主題和描述以免歧義和誤解。
5.若是須要的話，從新更改用戶故事的排序以便Sprint能夠更有效。

評審會議中

評審團隊在過去的一個迭代中提交的功能是符合指望，肯定是否接受團隊提交的潛在可發佈增量。

回顧會議中 

ScrumMaster主持會議，團隊共同決定產品負責人蔘與該會議是否對團隊實現目標更有幫助。

產品負責人小結：

 

 產品負責人相關書籍：《Scrum指南》《Scrum精髓》《人人都是產品經理2》《用戶故事》《Scrum產品經理》

1.3 開發團隊

Scurm的開發團隊應該由T型技能的成員組成。所謂的T型的意思就是團隊的成員在廣度（知識結構和能力）和深度（專業知識）兩個維度都有發展。

在傳統的軟件開發方法裏，定義了不一樣的工做類型：軟件主任工程師，程序員，測試工程師，UI工程師，數據庫工程師。可是，在Scrum裏面定義了「開發團隊」的角色，這個角色是全部這些工做類型的集合。在Scrum裏面，全部這些人都被稱爲「工程師」。一些Scrum成熟度很高的公司和團隊，甚至在和員工簽定合同的時候也只是寫了這個員工是工程師，而弱化傳統軟件開發方法裏面的工做類型區別。

在Scrum的每一個衝刺當中，開發團隊爲了實現計劃裏的功能，他們必須完成全部的相關工做，包括產品的設計，開發，集成和測試。爲此，他們必須具有完成這些工做的全部技能。區別於傳統開發方法裏的「只負責本身那部分工做」，做爲一個總體，團隊對功能的實現負責。經過模糊title的方式咱們但願可以弱化傳統項目職能分工的「撇清責任」，促進團隊的內部集體協做的積極互動，當目標實現出現問題的時候，全部人均可以起到積極的做用。舉個例子，衝刺的最後不免測試的壓力會大一些，這時候有空於的時間的工程師都應該幫助作測試，不管你的專長是研發，架構，UI。只要有時間，有能力，就都要幫忙。最終咱們是要組織這樣一個團隊：團隊成員擁有合適的技能，覆蓋各個領域，而且整體上技能有一些重疊，以便團隊有必定的靈活性。經理們有責任和義務去爲團隊創造一個促進學習的增長技能組合的環境，不管是領域知識，專業知識，思考技能或者其餘能力。經理要支持團隊成員花時間學習。

在自組織的團隊裏面，團隊成員經過討論達成共識而且最終制定規則和流程。因爲每一個團隊成員均可以對全部議題發表本身的意見而成爲規則和流程的制定者，所以當最後達成一致意見後，團隊成員就會更加主動的去履行他們的承諾。在執行期間，經過每日站會和平常的充分溝通，若是有團隊成員在履行承諾的時候出現問題，其餘成員也有充分的機會提醒和幫助他。在傳統的控制管理中，團隊成員是被動接受者，可是在自組織的環境裏你們是規則制定者，監督者和履行者，這樣的身份變化，致使全部團隊的成員都是團隊的「領導者」。

團隊須要具有的能力：產品，Scrum，架構，研發，手工測試，自動化測試，XP實踐，自動化集成和自動化部署，UI，數據庫。

須要外部支持能力包括：Scrum, 自動化測試，XP實踐，自動化集成和自動化部署，數據庫。

Scrum開發團隊每日工做列表

一天的開始

1.查看目前衝刺的燃盡圖報表。
2.若是團隊落後於時間表，你須要確認本身是否能夠幫助團隊追上進度（尤爲是當你的手中的任務落後於進度的時候）。你須要確認全部你已經完成的任務在相關的系統和任務板上都標記爲完成。
3.檢查今天你要作的工做。
4.若是你今天沒有能夠作的工做，你須要和團隊成員一塊兒找到你能夠幫忙的工做。

一天當中 

1.當你完成一個任務的時候，要當即更新任務狀態。
2.更新全部相關項的信息。
3.若是你開始了一個新的任務，請把任務狀態更新成「進行中」而且填寫任務人。
4.若是你的任務完成了，請將任務標狀態記成完成。
5.更新完成任務須要的剩餘時間信息。
6.完成你領取的任務，若是須要幫助，請不要憂慮，當即讓你們知道。
7.和你們一塊兒寫做完成任務。和你們討論你的工做以即可誒完成任務。
8.參加Scrum每日站會。
9.彙報你的工做信息。
10.從上次站會以後你都作了些什麼
11.你計劃在下次次會議以前都作些什麼
12.你遇到了什麼阻撓你工做的進度的須要他人幫助的問題。
13.確認是否能夠幫助他人
14.幫助產品負責人完成需求的更新
15.回答產品負責人的問題並提供你的理解
16.編寫技術故事
17.報告產品缺陷（例如，你在完成任務進行的時候進行的驗收測試中發現的缺陷）
18.和產品負責人澄清Sprint待辦列表中的用戶故事的細節（越早越好）。若是用戶故事沒有按照產品負責人的指望完成的話，產品負責人會做出決定是否在當前迭代中當即修改或者之後在改。

一天結束時

1.更新你的工做狀態
2.查看燃盡圖確認團隊工做進展

準備計劃會議

1.梳理產品列表（和產品負責人討論以澄清對條目的理解）
2.建立技術用戶故事

計劃會議中

討論而且估算每一個列表條目

計劃會議結束後

在計劃會議結束後須要當即將用戶故事分解爲任務。這對正確完成工做很是重要。
    - 和團隊成員一塊兒分解任務（全部的用戶故事和缺陷）而且提供任務工做量的估算。
    - 對於新的團隊來講，這一般須要整組人員一塊兒開會討論決定。
    - 對於有經驗的團隊，作法相對靈活；能夠一我的負責進行全部的估算，而後其餘組員進行檢查以確保一致。

在評審會議上

團隊成員負責向產品負責人演示功能

在回顧會議上

1.在ScrumMaster的組織下，團隊成員一塊兒回顧自上一個回顧會議之後的工做狀態。
2.在ScrumMaster的協調確認下，團隊成員一塊兒確認下一個迭代團隊須要作的改進措施以及負責人。

Scrum開發團隊小結：

 

Scrum開發團隊的主要職責：

1.在衝刺執行期間，開發團隊完成創造性的工做，包括設計，構建，集成，測試，最終提供潛在可發佈的功能發佈。
2.每日檢視和調整（每日站會）——做爲一個自組織的團隊，團隊經過每日站會來實現自個人檢視和調整實現衝刺目標。
3.梳理產品列表——幫助產品負責人梳理產品列表，細化產品列表條目，估算和排列優先級。
4.衝刺規劃——在每一個衝刺之初，開發團隊參與衝刺計劃會議。在會議上，根據產品負責人提供的信息，對產品列表條目的工做量進行估算，並在ScrumMaster的指導下，與產品負責人共同制定衝刺目標。
　　注意，開發團隊對工做量的估算是有絕對話語權，做爲一個自組織的團隊，他們不受其餘角色的影響，對工做量進行估算而且按照本身的承諾去履行衝刺目標。
5.檢視和調整產品與過程——在每一個衝刺結束的時候，開發團隊都須要參加衝刺評審會議和衝刺回顧會議。在會議上，Scrum團隊檢視和調整本身的過程和技術進一步改善團隊使用Scrum來交付業務價值的能力。

Scrum開發團隊的特徵：

1.自組織
沒有項目經理或者其餘經理告訴團隊怎樣開展工做；團隊在沒有外部力量干預的狀況下，爲了共同的衝刺目標而工做，逐漸達成默契，相互理解，不斷改進。
2.跨職能
爲了提交潛在可交付的增量，團隊須要具有全部相應知識和技能的成員。
3.規模適中
5～9人的規模。

1.4 實踐類問題

1.4.1 一我的能同時即作產品負責人又作ScrumMaster嗎？

絕對不能！產品負責人和ScrumMaster這倆個角色在Scrum團隊裏是兩個很是重要的角色。產品負責人負責產品要作成什麼樣，但不負責指導團隊。
ScurmMaster則負責另一個維度的工做，即專一於幫助團隊以正確的方式和流程來執行Scrum項目。在團隊中，產品負責人表明組織對經濟利益的追求，
而ScrumMaster則表明團隊的利益。若是要求一我的來同時完成這兩個角色是很困難的，更重要的是常常會遇到這兩個角色出發點不一樣致使的衝突而無從選擇，‘
最終一個角色會凌駕於另外一個角色之上，而是整個團隊利益受損。

1.4.2 Scrum裏任務是如何分配給團隊成員的？

團隊成員們一塊兒識別，評估每個用戶故事的工做量。一旦衝刺開始，每個團隊成根據優先選擇他們認爲合適的工做。
所以，咱們說團隊成員本身給本身分配任務。具體的分配方法由每一個團隊的成員一塊兒討論而決定。

1.4.3 開發團隊能夠有多少我的，爲何要限制團隊人數

一個Scrum開發團隊能夠有多少工程師？對於這個問題來講，並無標準的答案。2003年，Jeff Sutherland說一個Scrum開發團隊的人數不能超過7個。
如今，根據最新的《Scrum指南》，一個Scrum開發團隊的人數應該爲3~9.若是團隊裏的人太少，團隊會面臨能力缺少的困境。
雖然人越多，團隊能完成的工做就越多，但若是人太多了又會對團隊計劃，溝通和協調帶來巨大的挑戰。正如咱們所知，
在IT項目中，越多的工程師並不能意味着能夠帶來越多的產品功能發佈。並且常常會帶來相反的結果。若是你的項目有超過9個工程師的資源，
那麼請把他們分解成兩個Scrum團隊。並且，請不要忘記，Scrum強調的實驗！你的組織和項目團隊合適的團隊規模須要你本身去尋找。

1.4.4 若是項目工做太多，一個Scrum團隊作不完怎麼辦

正如我剛纔所說，若是你有足夠的工做和足夠的資源，那麼就請你經過組建新Scrum團隊的方法來加速你的速度。若是你的工做太多可是資源不足，
那麼就請你經過給特性排列優先級的方式，保證團隊只開發最重要的功能。

1.4.5 迭代和衝刺的區別是什麼

迭代的英文爲Iteration。迭代是一個通用的敏捷術語，指的是單個開發迭代。衝刺的英文是Sprint。做爲敏捷的一種方法的Scrum，衝刺是指Scrum的一個迭代。

1.4.6 爲何在開發團隊只有工程師而不是開發，測試呢？

在Scrum裏，責任和成果屬於整個團隊。爲了強調團隊的總體性，Scrum開發團隊裏只有一種角色，就是工程師。
但這並不意味着每一個人都擁有相同的技能，或者是說作相同的工做。這也許對每一個人未必徹底公平。例如，一個初級工程師和高級工程師能力就不相同。
可是，仍是那句話，Scrum強調團隊做爲一個總體承擔責任。

1.4.7 產品負責人和ScrumMaster都是全職的嗎

爲了保證Scrum團隊的工做，ScrumMaster和產品負責人須要有足夠的時間來完成他們的工做。一個比較常見的陷阱是，除了平常工做之外，
組織會給某我的分配產品負責人的新角色，讓他同時兼顧平常工做和產品負責人的角色。這樣作的結果一般都並很差。
咱們比較推薦的作法是讓產品負責人和ScrumMaster成爲全職的工做。

1.4.8 質量控制在Scrum怎麼體現

在Scrum裏，質量控制不是一個在產品發佈之後才執行的工做。相反，在Scrum當中，質量控制應該是包括在全部的從開始到結束的衝刺過程當中。
在項目的每一個衝刺開始的時候，團隊就應該注意如何檢查各個工做的進行。所以，咱們說質量控制從用戶故事的定義就應該已經開始了。全部的功能和非功能的測試都應該被覆蓋到。
所以有人說，在Scrum團隊裏不須要一個叫作QA的角色。固然若是你們都認爲有幫助的話，公司級別有專門的QA角色也是能夠的。
可是咱們要強調，在Scrum團隊裏面整個團隊對質量負責，而不該該將質量的責任只記在QA的名下。

1.4.9 新任ScrumMaster應該怎麼辦

美國第28任總統威爾遜說過：「若是你想樹敵，就嘗試改革吧」。對於大多數人來講，變化老是使人生畏。由於變化會把人從熟悉的環境拉出到一個充滿「驚嚇」的新世界。
所以，做爲一個新任的ScrumMaster，你須要注意的是，在一開始請千萬不要急於求成，一古腦兒地改變全部東西。要有耐心，好好準備。
當準備好之後，慢慢開始，並且以開始的時候先引入一兩個實踐（例如Scrum的每日站會和修整產品列表），當取得了一兩個雖然小但有決定性意義的勝利後，再公開宣傳而且繼續改進。

1.4.10 Scrum的核心價值觀

怎樣才能經過挑戰團隊成員來確保團隊不會由於各自強烈的自我意識和持續不斷被的爭吵而分崩離析呢？最好的辦法就是全部的團隊成員都要有用戶Scrum的核心價值觀，
而且以此造成他們的職業特質。
Scrum的核心價值觀：活力，共情，好奇，友善，尊重。

1.4.11 開發團隊的人員配備

沒有一個放之四海而皆準的規則能夠定義開發團隊的人員組成，由於項目和項目的都是各不相同的。若是你對團隊組建毫無頭緒，我向你推薦一個比例（固然須要你根據實際狀況進行檢查和調整）：
2個研發，1個測試，0.5個專家（若是你的項目已經實現了高度的自動化，那麼研發的比例能夠更高）。
項目之初，項目中的高級工程師和初級工程師的比例爲2:1 (隨着項目進行這個比例能夠下降)。
有Scrum經驗的成員與沒有Scrum經驗的成員比例爲1:1.

1.4.12 一個ScrumMaster能夠同時和多個團隊一塊兒工做嗎

一個ScrumMaster能夠同時在幾個團隊中工做這個問題有不少的討論。雖然，咱們一直強調ScrumMaster這個角色很重要，全職的ScrumMaster對於Scrum團隊的重要性。
可是，咱們必須靈活起來，根據2018年年年初公佈的最新的Scrum報告，一個ScrumMaster同時在多個團隊工做的目前已經成爲一種普偏現象。
固然，若是資源容許，尤爲是在團隊剛剛組建的時候，一個全職的ScrumMaster是最好的。隨着團隊的成熟，
同時擔任兩個團隊的ScrumMaster也是能夠的（一個ScrumMaster服務於兩個團隊，是比較推薦的解決方案）。
若是Scrum團隊已是自組織的，成熟的精英團隊，一個ScrumMaster能夠爲三個這樣的團隊服務。

1.4.13 Scrum有沒有一套流程，有沒有標準

對不起，Scrum不提供流程或者最佳實踐。Scrum的遊戲規則就是它的標準，這些都包含在《Scrum指南》當中。