Scrum通常被認為是一個敏捷開發專案管理框架，它描述了一組協同工作的會議、工具和角色，以幫助團隊組織和管理其工作。
一、什麼是Scrum
Scrum是一個幫助團隊協同工作的框架。就像橄欖球隊（它的名字的由來）為大型比賽進行培訓一樣，Scrum 鼓勵團隊從經驗中學習，以自組織的方式去處理問題，並對他們的勝利和失敗反思以不斷改進。
雖然我們說Scrum 最常被軟體開發團隊使用，但它的原則和經驗教訓可用於各種團隊合作，這也是 Scrum 如此受歡迎的原因之一。Scrum通常被認為是一個敏捷開發專案管理框架，它描述了一組協同工作的會議、工具和角色，以幫助團隊組織和管理其工作。
二、常用的敏捷開發框架：Scrum
人們通常認為 Scrum 和敏捷開發是同一回事，因為 Scrum 關注持續改進，而這是敏捷開發的核心原則。
但是，Scrum 是完成工作的一種框架，而敏捷開發是一種思維模式。
僅憑 Scrum 你無法真正“敏捷化”，因為這需要整個團隊一致努力才能改變其向客戶交付價值的思維方式。
但是，您可以使用 Scrum等框架來協助您開始思考這一方式，並在日常溝通和工作中實踐如何構建敏捷工作流原則。
Scrum框架是一種基於持續學習和波動因素調整的啟發式框架。它承認團隊在專案開始時並不瞭解所有內容，並通過吸取經驗教訓不斷髮展。Scrum的結構旨在幫助團隊自然而然地適應不斷變化的條件和使用者要求，並在流程和較短的釋出週期中重新調整優先順序，以便您的團隊不斷學習和改進。
雖然 Scrum是結構化框架，但它並不是完全僵化的，你可以根據組織需求調整其執行。關於 Scrum 團隊如何才能成功有很多的理論。
但是，十多年來，在幫助 PingCode 敏捷開發團隊完成工作的過程中，我們發現，無論您選擇何種框架，清晰的溝通、透明度和致力於持續改進始終都是框架的核心。
1、Scrum獲得成功所需的三個重要角色
Scrum 團隊需要三個特定角色：產品負責人(Product Ower)、ScrumMaster和Scrum 團隊。由於 Scrum 團隊為跨職能部門，因此除開發人員之外，開發團隊還包括測試人員、設計人員、使用者體驗 (UX) 專家和運營工程師。
主要負責構建正確的產品，確定 Scrum 團隊交付什麼並解釋為什麼做這些工作。產品負責人是產品方面的佼佼者。他們專注於瞭解業務、客戶和市場要求，然後相應地確定工程團隊需要完成的工作的優先順序。高效的產品負責人應能：
- 構建和管理產品待辦事項。
- 與企業和團隊密切合作，以確保所有人都能瞭解產品待辦事項中的工作項。
- 明確指導團隊接下來提供哪些功能。
- 確定何時釋出產品，且傾向於更頻繁地交付產品。
產品負責人並不一定是產品經理。產品負責人專注於確保開發團隊為企業帶來最大價值。此外，產品負責人是一個個體，這一點非常重要。沒有開發團隊需要多個產品負責人所提供的的混合指導。
主要負責幫助產品負責人和開發團隊中的每個人理解和擁抱Scrum的價值觀、原則和實踐。Scrum master 是其團隊中在 Scrum 方面的佼佼者。
他們負責對團隊、產品負責人和企業進行 Scrum 流程方面的培訓，並尋找方法細調他們在此方面的實踐。高效的Scrum 主管應深入瞭解團隊正在執行的工作，並可協助團隊優化其透明度和交付流程。作為最主要的推動者，此角色負責安排衝刺規劃、每日短會、衝刺稽核和衝刺回顧所需的資源（人力和物力）。
負責以正確的方式構建產品，執行具體工作任務。Scrum團隊是具體工作的執行者，成員通常為 5 到 7 名。確定團隊規模的一種方法是亞馬遜執行長 Jeff Bezos提出的著名“兩個披薩原則”（團隊應該足夠小，以便分享兩個披薩）。團隊成員具有不同的技能，並且彼此互相錘鍊，因此沒有人會成為交付工作的瓶頸。
強大的Scrum 團隊遵循自我組織原則，且會在處理專案時採取明確的“我方”立場。團隊的所有成員會互相幫助，以確保成功完成衝刺。
Scrum團隊可推進每個衝刺的計劃。他們將自己的歷史速度用作指導，預測他們認為自己在迭代過程中可以完成的工作量。保持迭代長度固定可為開發團隊提供有關其預估和交付流程的重要反饋，進而使其能隨著時間的推移做出更加準確的預測。
2、Scrum 工件
工件是我們完成的事情，就像是解決問題的工具。在 Scrum 中，這三個工件分別是產品待辦事項、衝刺（Sprint）待辦事項，以及對“已完成”定義的增量變化。
它們是 Scrum團隊中的三個常量，我們會不斷地對其進行重新審視，並投入額外的時間進行改進。
產品待辦事項（Product Backlog）
產品待辦事項集合，整個產品的使用者故事集合，這些使用者故事可以來自甲方客戶、終端使用者、PO自己對產品的理解、研發團隊等。
本質上，這是團隊的“待辦事項”列表。產品負責人對產品待辦事項進行不斷反思、重新排定優先順序和維護，因為隨著我們瞭解的更多或隨著市場的變化，列表中的專案可能不再相關，或是可能會以其他方式解決問題。
產品目標：Product Goal
Product Goal 描述了產品的未來狀態，可以作為Scrum Team 制定計劃的目標。Product Goal 在Product Backlog 中。Product Backlog 的其餘部分湧現，用來定義“做什麼”將實現 Product Goal。
產品是傳遞價值的載體，它具有明確的邊界、已知的利益攸關者和定義明確的使用者或客戶。產品可以是一種服務、實體產品或其他更抽象的東西。Product Goal 是 Scrum Team 的長期目標。他們必須先實現（或放棄）一個目標，然後再開始下一個目標。
衝刺待辦事項（Sprint Backlog）
衝刺待辦事項列表，一個衝刺目標階段內的使用者故事列表。這些使用者故事來自Product Backlog，每次衝刺前，PO根據交付價值，將優先順序最高的使用者故事放入迭代。
每次衝刺之前，在衝刺規劃會議（我們將在後文進行討論）中，團隊從產品待辦事項中選擇為進行衝刺而處理的專案。衝刺待辦事項可能較為靈活，可以在衝刺期間發展。但是，基本的衝刺目標（團隊希望通過在當前衝刺中實現的目標）不能受到影響。
衝刺：Sprint Goal
Sprint Goal 是 Sprint 的單個目標。儘管 Sprint Goal 是 Developers 的承諾，但它為實現該目標所需的確切工作方面提供了靈活性。Sprint Goal 還創造了連貫性和專注點，鼓勵 Scrum Team 一起工作而不是分開獨自行動。
Sprint Goal 在 Sprint Planning 事件中確定，然後新增到 Sprint Backlog 中。當Developers 在 Sprint 期間工作時，他們將 Sprint Goal 銘記在心。如果需要做的工作與預期的不同，他們將與Product Owner 協作，在不影響 Sprint Goal 的情況下，協商本次Sprint Backlog 的範圍。
增量
增量是一個 Sprint 完成的所有產品待辦列表項的總和，以及之前所有 Sprint 所產生的增量的價值總和。在 Sprint 的最後，新的增量必須是“完成”的，這意味著它必須可用並且達到了 Scrum 團隊“完成”的定義的標準。
在完成以上三個工件的時候，團隊可以選擇定義很多變體，因為工件維護最好保持開放態度。比如“已完成”、“故事點”重新定義能更好的提升效率和品質，那你完全可以根據需求進行新的定義。
你應該像處理產品一樣敏捷地處理 Scrum 框架，花一些必要的時間來檢查事務的進展情況（無論是通過PingCode 這樣的工具或者是其他），並在必要時做出調整，而不要僅僅為了一致性而強迫自己執行某些事項。
3、Scrum 儀式
Scrum 框架中一些更為人所知的元件包括 Scrum團隊定期舉行的一系列會議。在這些儀式中，我們可以看到團隊之間的最大差異。
例如，有些團隊發現舉行所有這些儀式既繁瑣又重複，而另一些團隊則將這些儀式作為必要的登記手段。我們的建議是，在兩次衝刺階段使用所有儀式，然後看看其效果。接著，你可以進行快速回顧，看看可能需要進行哪些調整。
以下是Scrum 團隊可能參加的所有重要儀式清單：
需求梳理會(Backlog Grooming Meeting)
有時也被稱為待辦事項梳理，它由產品負責人負責。產品負責人的主要工作是協助實現產品願景，並持續關注市場和客戶。因此，客戶可根據使用者和開發團隊的反饋來維護此列表，以協助確定列表的優先順序並保持整潔，同時準備在任意給定時間進行工作。
Sprint計劃會(Sprint planning meeting)
由整個開發團隊在本次會議期間規劃當前衝刺期間要執行的工作（範圍）。本次會議由 Scrum MAster主持，而團隊則在會議期間決定衝刺目標。接著，可將產品待辦事項中的特定用途故事新增到衝刺中。這些故事應與目標始終保持一致，且 Scrum 團隊也承諾可在衝刺期間完成。 在規劃會議結束時，每位 Scrum 成員均需清楚在衝刺期間可以交付的內容，以及如何交付增量變化。
衝刺（Sprint）
衝刺是 Scrum團隊共同完成增量的實際時間段。兩週是一個相當典型的衝刺時長，儘管某些團隊發現一週更容易確定範圍，或是一個月更容易提供有價值的增量變化。
但國外知名敏捷教練 Dave West 建議，工作越複雜，未知因素就越多，而衝刺就應該越短。但事實上，這取決於團隊，而如果不起作用，團隊也可以進行改變！ 所有事件（從規劃到回顧）都是在衝刺期間發生的。
一旦確定了衝刺的特定時間間隔，就必須在整個開發期間保持一致。這有助於團隊吸取經驗教訓，並將這些洞察應用於未來的衝刺。
Scrum每日站會(Daily Standup Meeting)
這是每天在同一時間（通常是早晨）和地點舉行的超短例會，以確保此會議簡潔明瞭。很多團隊試圖在15 分鐘內完成會議，但這只是一個參考。此會議也被稱為“每日短會”，它強調需快速舉行會議。
每日 Scrum 旨在讓團隊中的每一個成員都保持同步，共同朝著衝刺目標努力，並制定未來 24 小時的計劃。 你可在每日短會上說出自己在實現衝刺目標或解決任何障礙時遇到的問題。
每日短會的其中一種常見舉行方法是讓每個團隊成員在實現衝刺目標的過程中回答三個問題：
• 我昨天做了什麼？
• 我今天打算做什麼？
• 是否存在障礙？
然而，我們發現會議很快會變成大家陳述昨天和第二天的日程表。每日短會的理論基礎是：它可以分散日常會議的注意力，這樣團隊就可以在當天剩下的時間裡專注於工作。
因此，如果它不幸淪為了每日日程表閱讀會，則應果斷做出改變以求創新。
Sprint評審會(Sprint Review Meeting)
在衝刺結束時，團隊聚集在一起進行非正式會議，以觀看增量演示或檢查增量。開發團隊向利益相關者和團隊成員展示目前處於“已完成”狀態的待辦事項，以徵求他們的反饋意見。
儘管在多數情況下都會發布增量，但產品負責人仍可決定是否釋出增量。此次稽核會議也是產品負責人根據當前衝刺重新處理產品待辦事項之時，當前衝刺可為下一次衝刺規劃會議提供相關資訊。
對於為期一個月的衝刺，可考慮將您的衝刺稽核時間限制為最長四個小時。
Sprint回顧會(Sprint Retrospective Meeting)
是指團隊聚集在一起共同記錄和討論衝刺、專案、人員或關係、工具甚至在某些儀式中哪些有效以及哪些無效。
我們的思路是創造一個地方，讓團隊能夠專注於哪些工作進展順利和哪些地方有待改進，而不是專注於出了什麼問題。