Scrum事件是敏捷軟件交付過程的重要元素。他們不僅僅是為了開會而舉行會議。相反，這些Scrum事件為團隊提供了框架，使他們能夠以結構化的方式完成工作，幫助設定期望，使團隊有效協作，並最終推動結果。但是，如果管理不當，他們就會壓倒日曆，淹沒他們打算提供的價值。

這些Scrum事件實現並實現了幾個核心/原始原則。通常，當團隊放棄某些儀式時，這是因為他們不再看到它們的價值，這表明他們可能也放棄了這些原則。

5個Scrum事件變得簡單

在本文中，我們將解開四個scrum事件，深入研究它們的目的，與會者以及使它們最有效的技巧和竅門。四個scrum事件是：

1. Sprint計劃
2. 每日Scrum
3. Sprint評論
4. Sprint回顧
5. Sprint

值得注意的是，這些事件特定於scrum框架，這是一個團隊在世界各地用來構建有效工作的敏捷過程。Scrum有意輕巧簡單，但很難掌握。它旨在為跨職能團隊提供解決複雜問題的框架。

簡單地說：scrum是實現敏捷的一種方式。

孤立地舉行這些會議不會自動使您的團隊變得敏捷。它們必須是更大，更好理解和明確的過程的一部分。他們應該促進敏捷團隊內部的對話以完成工作。什麼樣的項目經理不喜歡把事情做好？

在我們走得太遠之前，讓我們快速回顧三個scrum角色。

3個scrum角色：產品所有者，scrum master和開發團隊

1. 產品負責人 Product Owner - 此角色代表客戶和他們正在使用的產品的一般業務。他們擁有積壓工作並努力在每個衝刺之前確定要處理的項目的優先級。他們每天制定執行產品決策。最終，他們將客戶需求轉化為開發團隊的可操作工作項。
2. Scrum Master - 此人負責確保團隊擁有實現價值所需的一切。他們是一個教練，輔導員，倡導者，障礙消除者，促進者和調解員。他們設立會議並傳達進展和阻礙。提示：項目經理應該做的一切，只是通過scrum的鏡頭。
3. 開發團隊 Development Team - 這是一組跨職能的團隊成員，他們都專注於交付工作軟件。對於任何必須在產品的實際開發上進行協作的開發人員，設計人員，QA和其他技術角色，它都是單數名詞。理想情況下，這組5-9人完全致力於一個Scrum團隊。實際上，特別是在代理機構，它可能看起來有點不同。開發團隊應該自我組織並有動力提供價值，並且通過Scrum Master和產品負責人的適當協助，他們可以。

注意：有大量的在線資源和書籍可供繼續閱讀scrum和不同的角色。讓Google成為您的嚮導。

每個角色都有獨特的參與每個scrum事件。通過這些Scrum會議的應用，Scrum團隊的每個成員都應該被授權做最好的工作。每次會議都是有條不紊的，有意識的，並且為整個Scrum團隊服務。換句話說，它們的存在是為了使交付軟件成為可能。不用多說，讓我們深入了解。

Sprint計劃 (Sprint Planning)

什麼是Sprint計劃會議？

Sprint Planning是一個Scrum儀式，旨在確保團隊準備好在每個sprint中完成正確的事情。

它的目的是什麼？

此Scrum會議在新sprint開始時召開，專為產品負責人和開發團隊設計，以滿足並審核優先級產品Backlog。通過一系列的討論和談判，團隊最終應該在sprint積壓中創建，其中包含他們承諾在sprint結束時完成的所有項目。這被稱為衝刺目標。衝刺目標應該是一個可擴展的工作量，這意味著它可以在衝刺結束時進行演示。它需要得到整個團隊的一致同意。

產品負責人負責_在_ Sprint計劃開始_之前_準備好產品Backlog以供審核。這意味著為開發團隊添加驗收標準，要求和必要的詳細信息，以準確估計工作量。產品負責人還需要能夠澄清開發團隊對工作的任何問題或假設。只有這樣，開發團隊才能準確預測他們在衝刺期間可以完成的工作量。

誰出席了？

Scrum團隊 - 產品所有者，開發團隊和Scrum master。

它能持續多久？

大多數Scrum事件的長度與短跑的長度有關。在Sprint Planning方面，它應該是sprint長度的2倍（以小時為單位）。例如，如果您的衝刺時間為2週，Sprint計劃儀式的持續時間不應超過4小時。對於為期一周的衝刺，它應該持續不超過2小時。

有什麼有用的提示嗎？

• 用戶故事可以分解為較小的任務，並在sprint計劃期間分配，以便每個人都知道他們對此負責。
• 鼓勵團隊在此Scrum會議期間勾畫出任務，錯誤以及需要它的任何項目。這應該是一個非常合作的事件。
• 一旦設定了衝刺目標，就不應該被競爭工作打斷。但是，如果目標不再相關，產品負責人可以取消衝刺。
• 堅持你的時間盒。留意時鐘，一旦你準時，停下來。
• 務必記住衝刺期間的任何休假，休假，假期或其他日程安排細節，以準確反映可以完成的工作量。
• 同樣，在Sprint計劃開始之前，嘗試衡量團隊的速度。
• 記住：你計劃衝刺，而不是馬拉松！盡量不要被產品負責人尚未確定的項目所牽制。

還要別的嗎？

Sprint Planning允許Scrum團隊回答_“在下一個sprint中可以提供什麼？我們將如何完成這項工作？“_它有助於提供可預測性並創建一個協作環境，以實現每個sprint的目標。

每日Scrum（Daily Standup）

什麼是每日Scrum會議？

每日Scrum是團隊聚在一起的機會，定義當天工作的計劃，並識別任何阻擋者。

它的目的是什麼？

這個Scrum儀式為團隊提供了一個頻繁的機會，讓他們能夠聚集在一起，並將個人進展傳達給sprint目標。這不是狀態更新。相反，它應該說明團隊所遇到的任何障礙。Scrum Master負責為開發團隊清除這些障礙，以便他們專注於交付Sprint Planning中確定的工作。

每日Scrum不僅僅是狀態更新; 這是一個脈衝檢查，應該能夠解決任何阻礙團隊進步的障礙。

在每日Scrum期間，開發團隊的每個成員都應簡要回答以下問題：

• 你昨天做了什麼？
• 你今天會做什麼？
• 這方面有什麼障礙嗎？

這次Scrum會議的每個參與者都應該互相傾聽並在整個會議期間保持在場。通常情況下，開發團隊的成員將根據Daily Scrum期間的評論確定在白天一起工作的機會。

誰出席了？

Scrum Master和開發團隊。產品負責人是可選的與會者。有時，可邀請外部利益相關者傾聽每日爭議。

它能持續多久？

這個簡短！它應該持續不超過15分鐘。說起來容易做起來難。

有什麼有用的提示嗎？

• Scrum Master負責跟上這次快速Scrum會議的步伐。考慮設置一個計時器！
• 在一周中的每一天（通常在早上）舉行會議，並儘可能地將其作為scrum團隊的常規做法。
• 如果您的團隊是分佈式的，請利用視頻會議軟件，以便團隊仍然可以看到彼此。
• 對於現場直播，考慮在房間周圍扔球，以指示誰應該在任何給定時間發言。
• 如果（或者說真的時候）會議中出現了需要更長時間對話的事情，請鼓勵團隊成員在Daily Scrum結束時立即同步，以確定他們何時需要協作。可能會在會議結束後或當天晚些時候舉行。再次，讓他們自我組織。
• 有一些工具和Slack集成，例如Geekbot，它們允許立式異步發生。雖然這些會在某些情況下有所幫助，但我們鼓勵這些會議是親自或通過視頻通話進行的。
• 語氣應該輕鬆有趣，但重點是收集和傳遞信息。

還要別的嗎？

或者稱為每日站立或scrum會議，這種快速脈衝檢查應該為當天的團隊做好準備。不要讓牠吃太多時間，否則會產生相反的效果。此會議使團隊能夠同步並建立彼此的信任。讓團隊相互追究責任，每天履行承諾。

Sprint評論 (Sprint Review)

什麼是Sprint評論會議？

Sprint Review是一個Scrum儀式，在sprint期間完成的所有工作都可以向利益相關者展示。

它的目的是什麼？

在每個sprint結束時，Sprint Review為開發團隊提供了一個平台，以展示已完成的所有工作。這使得利益相關者能夠比以後更快地看到事物並在產品出現時檢查或調整產品。Sprint評論可以在休閒的“Demo Friday”性質中進行，也可以設置為更加結構化。這完全取決於Scrum團隊的幾個變量，例如產品生命週期和發布計劃。

最重要的是，在此期間展示的所有工作都應該是完全可以證明的，並且符合團隊運作的完成定義 (Definition of Done DoD)。團隊應該感到有權展示他們在衝刺過程中能夠完成的工作。它不應該感覺他們正在接受審判或捍衛他們所做的工作。相反，它應該關注通過產品開發提供的商業價值。

誰出席了？

Scrum團隊 - 產品所有者，開發團隊和Scrum master - 通常是管理層，外部利益相關者，客戶甚至其他項目開發人員的混合體。關於誰_需要_在那裡，這個scrum儀式比其他人更流暢。產品負責人和Scrum Master應該在Sprint評審之前討論誰應該參與並努力確保他們參加。

它能持續多久？

衝刺每週一小時。例如，應該安排兩個小時的Sprint Review進行為期兩週的衝刺。

有什麼有用的提示嗎？

• Scrum Master承擔任何管理職責，確保預訂會議室，提供額外的演示輔助工具（例如白板或活動掛圖），並且會議時間適當。考慮提供茶點。
• Sprint Review期間收到的可操作反饋應轉換為新產品待辦事項，以便以後確定優先級和討論。
• 準備這次會議是個好主意！由於Scrum團隊以外的利益相關者經常出席，因此請務必在任何排練時間或其他準備工作中建立團隊以取得成功。
• 圍繞用戶體驗和業務價值關注Sprint評論。不應該覺得開發團隊只是證明事情有效。
• 產品負責人應向利益相關者提問，收集反饋，並為出現的任何問題提供答案。

還要別的嗎？

或者稱為Sprint Demo，這個Scrum會議有助於在利益相關者和Scrum團隊之間建立信任。這是收集早期和頻繁反饋並最終添加到產品待辦事項中的最直接方式。盡你所能讓團隊大放異彩。

Sprint回顧 (Sprint Retrospective)

什麼是Sprint回顧會議？

在Sprint回顧的是讓球隊回首剛完成的工作，並確定可以改進的項目序列中的最後混戰儀式。

它的目的是什麼？

在進行Sprint評審之後，Scrum團隊需要有機會反思剛剛展示的工作並討論改進的方法。衝刺回顧是那次見面。它為scrum團隊提供了一個平台，可以討論進展順利的事情，可能變得更好的事情以及一些變更建議。一些常見問題是：

• 最後一次沖刺的進展順利嗎？
• 有什麼不好的？
• 我們可以做些什麼改進？

最終，這個Scrum儀式應該為團隊成員提供一個無可指責的空間，以提供他們誠實的反饋和改進建議。它應該推動變革。應收集並分配所有可操作的反饋，以便scrum團隊的成員了解誰負責什麼。

敏捷就是不斷改進，這個儀式專門用於幫助Scrum團隊做得更好。

誰出席了？

Scrum Master和開發團隊。產品負責人是可選的與會者。回顧中不應涉及外部利益相關者。

它能持續多久？

通常情況下，為期兩週的衝刺回顧應持續不超過1.5小時。如果你的衝刺是一個月，回顧應該持續不超過3個小時。

Scrum最佳在線圖表軟件 ( 完全免費 )

VP Online是一個基於Web的圖表軟件。它支持廣泛的業務和技術圖表，如ArchiMate，BPMN，UML，ERD，組織結構圖，平面圖，PERT等。圖編輯器非常直觀，具有許多出色的編輯功能，使用戶能夠快速創建圖表。