(Source: Who Should Attend Scrum Meetings? – innolution)
我經常被問到誰應該參加各種Scrum會議 – sprint計劃,每日scrums,sprint審查,sprint回顧和產品backlog修飾。
首先,讓我來定義我將用於引用潛在參與者的術語。Scrum開發工作由一個或多個Scrum團隊組成,每個團隊由三個Scrum角色組成:產品所有者,Scrum Master和開發團隊。
使用Scrum時可能還有其他角色,但Scrum框架只需要這三個。在本博客中,我將重點介紹每個Scrum會議中應該出現的這三個角色中的哪一個以及為什麼。當我使用術語“Scrum團隊”時,我將所有三個角色稱為三元組 – 意味著開發團隊,Scrum Master和產品所有者都參與其中。
SPRINT計劃
完整的Scrum團隊在sprint計劃中進行協作。產品所有者分享初始衝刺目標,提供優先級產品積壓,並回答團隊可能對產品積壓項目提出的任何問題。開發團隊努力工作以確定它可以提供什麼,然後在sprint計劃結束時做出切合實際的承諾。作為Scrum團隊教練的Scrum Master觀察計劃活動,詢問探究問題,並幫助確保成功結果。
產品所有者角色參與sprint計劃的確切時間取決於您的方法。
兩部分Sprint計劃
一種方法是將衝刺計劃分為兩部分。在第1部分(哪個部分)中,開發團隊確定其完成工作的能力,然後預測它認為在sprint結束時可以提供的產品待辦事項。因此,如果團隊認為它可以完成40個故事點,它將選擇大約40個故事點的工作量。在第1部分中,所有三個Scrum團隊角色都在整個時間內出現。
在第2部分(如何部分)中,團隊通過創建計劃獲得了對其在第1部分中預測的項目的能力的信心。大多數團隊通過將產品積壓項目分解為一組任務,然後估算(以小時為單位)完成每項任務所需的工作量來創建此計劃。然後,該團隊將任務小時的估計值與其小時的容量進行比較,以確定其初始承諾是否切合實際。
在第2部分開始時,產品所有者離開房間,留下開發團隊和Scrum Master,以便他們可以執行獲取信心活動(例如,任務分解)。在第2部分結束時,產品所有者重新加入了開發團隊和Scrum Master,因此開發團隊可以確認:“是的,我們可以提供我們在第1部分中告訴您的內容”或“不,我們不能讓您想要我們在第1部分,但這是我們可以給你的。“
單部分Sprint計劃
衝刺計劃的另一種方法是單一部分方法,該方法交錯選擇項目並獲得可以交付的信心。使用這種方法,開發團隊首先確定其完成工作的能力。接下來,團隊選擇產品積壓項目,然後獲得所選項目將合理地適合衝刺的信心,因為團隊不斷變化的承諾中已包含其他項目。然後重複這個循環,直到團隊無法完成更多的工作。在那時,承諾最終確定並且sprint計劃已經結束。在一個部分的sprint計劃中,所有三個Scrum團隊角色都在整個會議期間出現。
每日SCRUM
在每日Scrum是關鍵,每天檢查-和適應活動,以幫助一個自組織的團隊更好地管理流動衝刺期間,其工作,以完成這項工作。每日Scrum允許開發團隊成員彼此分享正在發生的事情的大局,以便他們可以共同了解工作量,開始工作的項目以及如何在團隊成員之間最好地組織工作為了滿足衝刺目標。
因此,所有開發團隊成員都必須在那裡。Scrum Master還應該擔任教練和輔導員。但產品所有者呢?我對產品所有者的規則是“盡可能參加,但我們知道你不能總是參加。”這意味著產品所有者不需要參加每日的討論。或者說另一種方式,如果產品所有者不參與每日爭議,會議可以並且仍將繼續進行。
其他人可能也想參加每日的Scrum經理,利益相關者,任何人,真的,誰想要更好地了解團隊如何朝著衝刺目標邁進。應邀請這些人參加任何日常生活,明確了解他們在那裡觀察,而不是積極參與。會議旨在讓開發團隊成員彼此共享信息,而不是向Scrum Master,產品所有者或其他任何人提供狀態報告。Scrum Master應該執行非Scrum團隊成員應該被看到而不被聽到的一般規則。
那麼產品所有者,如果他參加每日Scrum會議,他是否積極參與?許多人認為,如果產品所有者處於每日scrum,他應該處於只聽模式。在應用Scrum時,實際勝過一切!通常當產品所有者參加每日Scrum時,他沒有任何貢獻來參與討論 – 他參加的價值在於更好地了解衝刺期間發生的事情。所以,在這種情況下,產品可能是坐著聽。
但是,如果開發人員說,“今天我打算繼續完成任務5; 但我不得不承認,從商業角度來看,我對我們想要完成的工作有點模糊。“如果我是每日scrum的產品所有者,我可以通過一個非常簡短的解釋來澄清模糊性(如句子或2),我當然會為開發團隊說出來並澄清一些事情。這只是我作為產品所有者增加價值。如果需要更長時間的解釋,我可能會說,“嘿,我會很高興在日常的scrum之後留下來並澄清它!”在任何一種情況下,在這個例子中,我不會只是坐在那裡什麼都沒說。
SPRINT評論
SPRINT評論是一個會議,讓每個人都輸入到產品開發工作的機會檢查和適應什麼迄今已建成。衝刺審查提供了對產品當前狀態的透明觀察,包括任何不方便的事實。現在是時候提出問題,提出意見或建議,並討論如何在當前現實的情況下最好地前進。衝刺回顧的目標不是給出一個演示。
根據會議目的,預計會有以下與會者來源:
資源 | 描述 |
---|---|
Scrum團隊 | 產品所有者,Scrum Master和開發團隊都應該在場,以便他們都可以聽到相同的反饋,並能夠回答有關sprint和產品增量的問題。 |
內部利益相關 | 企業主,管理人員和經理應該直接看到進度,以便他們可以建議更正課程。對於內部產品開發,內部用戶,主題專家以及與產品相關的業務功能的運營經理應參加。 |
其他內部團隊 | 銷售,營銷,支持,法律,合規性以及其他Scrum和非Scrum開發團隊可能希望參加sprint評審,以提供針對特定領域的反饋或將他們自己的團隊的工作與Scrum團隊同步。 |
外部利益相關 | 外部客戶,用戶,合作夥伴和監管機構可以向Scrum團隊和其他與會者提供有價值的反饋。 |
所有開發團隊成員都需要出席嗎?
是! 所有開發團隊成員都應出席sprint審核,以便直接聽取利益相關方的反饋意見。
SPRINT回顧
雖然衝刺審查是檢查和調整產品的時間,但SPRINT回顧是一個檢查和調整過程的機會。在回顧期間,團隊可以自由地檢查正在發生的事情,分析他們的工作方式,確定改進的方法,並製定實施這些改進的計劃。任何影響團隊創建產品的方式都可以進行審查和討論,包括流程,實踐,溝通,環境,工件,工具等。
因為sprint回顧是反思過程的時候,我們需要完整的Scrum團隊參加。這包括開發團隊的所有成員,Scrum Master和產品所有者。開發團隊包括設計,構建和測試產品的每個人。總的來說,這些團隊成員擁有豐富多樣的視角,這些視角對於從多個角度識別流程改進至關重要。
Scrum Master參加,因為她是這個過程中不可或缺的一部分,也因為她是Scrum團隊的流程教練,並且可以指出團隊不遵守自己商定的流程的地方,也是團隊的知識和想法。
有人認為產品所有者不應參加sprint回顧展。他們認為,在回顧展中擁有產品所有者可能會阻止團隊完全誠實或揭露困難問題。雖然這可能是某些組織的風險,但產品所有者是Scrum流程的關鍵部分,因此應成為有關該流程的討論的一部分。如果產品所有者和開發團隊之間缺乏信任,或者安全性較低,以至於坦率地說話不舒服,那麼在Scrum Master可以幫助指導參與創建的人員之前,產品所有者可能不應該參加一個更安全,更信任的環境。
假設信任和安全合理到位,有效的產品所有者對於實現快速,靈活的業務價值流程至關重要,因此應參與sprint回顧展。例如,產品所有者是需求流向團隊的渠道或渠道。如果需求在Scrum流程中出現問題會怎樣?也許所涉方案不能很好的衝刺計劃的開始梳理。在這種情況下,如果產品所有者缺席回顧展,Scrum團隊很難集體討論潛在的流程改進。
產品BACKLOG修飾(細化)
產品積壓修飾(有時稱為產品積壓改進)是指一組三個主要活動:創建和完善產品積壓項目(PBI),估計PBI以及優先化PBI。
修補產品待辦事項是產品所有者領導的持續協作工作,包括內部和外部利益相關者以及Scrum Master和開發團隊的大量參與。
最終有一個梳理決策者:產品所有者。然而,優秀的產品所有者理解,協作式培訓可以促進所有參與者之間的重要對話,並利用不同群體的集體智慧和觀點,從而揭示可能會錯過的重要信息。
優秀的產品所有者也知道,通過讓不同的團隊成員參與修飾,他們確保每個人都能更清楚地了解產品積壓,從而減少錯誤溝通和交接浪費的時間。這種協作努力也大大有助於彌合商界人士和技術人員之間的歷史差距。
利益相關者應根據組織的性質和項目類型分配足夠的時間進行培訓。
作為一般規則,開發團隊應在每個sprint中分配最多10%的時間來協助產品所有者進行修飾活動。該團隊將利用這段時間來幫助創建或審查緊急產品待辦事項,以及逐步將較大的項目細化為較小的項目。該團隊還將估算產品待辦事項的大小,並根據技術依賴性和資源限制幫助產品所有者確定這些項目的優先級。
讓我總結三個不同產品積壓修飾活動中每個參與者的參與者。
修飾 – 創建和優化產品待辦事項
產品所有者負責確保PBI的編寫和適當改進。雖然產品所有者可能能夠自己完成這項工作,但根據我的經驗,當與開發團隊和利益相關者協作進行修飾以及在ScrumMaster的指導和促進下,PBI會更好。
修飾 – 估計產品待辦事項
如果您的團隊選擇調整產品積壓項目的大小(並非所有團隊都這樣做),那麼誰應該參與?
完整的Scrum團隊在調整產品積壓項目時參與 – 並使用像Planning Poker這樣的估算技術。在估算會話期間,產品所有者提供,描述和闡明PBI。Scrum Master指導團隊幫助它更好地應用其估算技術。Scrum Master也在不斷地尋找那些通過他們的肢體語言或他們的沉默,似乎不同意並幫助他們參與的人。開發團隊正在共同產生共識估計。需要明確的是,只有開發團隊成員才能確定項目的大小,但Scrum Master和產品所有者在活動期間會以自己的方式參與其中。
修飾 – 優先處理產品待辦事項
最終,產品所有者負責產品積壓中的項目及其訂購(優先級排序)。但是,開發團隊具有PBI的特定技術知識,這些知識可能會影響PBI在產品待辦事項中的排序方式,因此需要輸入以確定積壓的優先順序。當然,利益相關者(例如,企業高管,客戶等)將對如何優先考慮PBI以最好地滿足其業務需求提供重要的意見。產品所有者必須從所有這些來源獲取意見,並將其合成為一個連貫的產品積壓。
SCRUM會議參與者摘要
以下是誰應該參加每個Scrum會議的表格摘要。
會議 | 產品擁有者 | Scrum Master | 開發團隊 | 其他 |
---|---|---|---|---|
Sprint計劃 | 在所有單部分衝刺計劃中都是。如果使用2部分衝刺計劃,則在第1部分中使用,在第2部分結束時使用 | 是 | 是 | 可能,但僅作為觀察員 |
每日Scrum | 可選的 | 是 | 是 | 可能,但僅作為觀察員 |
Sprint評論 | 是 | 是 | 是(所有團隊成員) | 是的,內部和外部利益相關者(會議是為了他們的利益) |
Sprint回顧 | 是 | 是 | 是 | 僅限邀請 |
修飾 – 創建和完善PBI | 是(全面負責) | 是的,以指導和促進 | 是的,以幫助編寫和完善PBI | 是的,利益相關者(如客戶)幫助編寫和完善PBI |
修飾 – 估計PBI | 是的,描述和澄清PBI | 是的,促進活動 | 是的,唯一可以對PBI進行估算的人 | 沒有 |
修飾 – 優先考慮 | 是(全面負責) | 是的,指導產品所有者 | 是的,提供影響優先事項的技術投入 | 是的,提供業務優先級輸入 |
結論
最後,我要說的是,並非所有人都同意我應該參加Scrum會議的人員!而且,我沒關係。如果一個不同的方法在您的組織中運作良好,那麼請查看我對誰應該參加Scrum會議的看法,作為您不斷努力檢查和調整併使您的組織更加敏捷的一個投入來源!