Scrum 協作方法論的簡單指南

已發表: 2019-02-04

理想情況下,完成一個長期項目應該涉及最少的回溯,並以滿意的客戶或客戶結束。 實際上,情況並非總是如此。 “Scrum 協作方法論”——或簡稱“Scrum”——試圖通過逐項處理項目開發來防止挫折並提高客戶滿意度。

在本文中,我們將解釋 Scrum 方法及其相對於更傳統的項目管理策略的優勢。 然後我們將提供有關如何為您的下一個項目實施 Scrum 的步驟。

讓我們開始吧!

Scrum 協作方法簡介

為了理解Scrum是什麼,我們首先要理解敏捷方法。 敏捷最初是為了幫助軟件開發人員更有效地管理項目而創建的,它指的是一組價值觀、原則和實踐。 開發團隊在完成項目時使用敏捷作為指導。

Scrum 是一種應用敏捷價值觀和原則的方法論。 與敏捷一樣,Scrum 首先被軟件開發人員使用。 然而,它已經傳播開來,現在被其他產品開發人員、企業家和其他任何試圖承擔複雜項目的人使用。

通常,Scrum 涉及一個由五到七人組成的協作團隊。 Scrum 團隊中有三個角色:產品負責人、Scrum Master 和一般團隊成員。 團隊成員將負責開發產品的工作。

產品負責人是項目的主要投資者,或您的客戶。 他們的作用是通過彙編有關最終產品基本需求的信息為一般團隊成員提供指導。 Scrum Master 有助於確保團隊正確實施方法論。

Scrum 團隊的工作時間很短,一到三週,稱為“衝刺”。 每個衝刺都會有一組特定的目標供團隊完成。 在整個 sprint 中,團隊定期舉行會議,以共享更新、委派並相互提供反饋。

Scrum 相對於傳統開發方法的優勢

除了 Scrum,最流行的項目管理策略之一是瀑布法。 它由一個線性計劃組成,其中團隊一次完成一個步驟。 使用瀑布方法的項目通常從一個計劃期開始,在此期間,團隊嘗試在進行開發之前對產品進行整體設計。

然而,這種方法的一個常見問題是團隊會從一個步驟移動到下一個步驟,卻發現他們最初的計劃不會奏效,或者是不完整的。 這使團隊退縮,因為他們必須返回到計劃階段並重新開始該過程。

有時,使用瀑布方法的團隊會將最終結果呈現給客戶,只是聽說他們構建的東西並不能真正滿足客戶的需求。 這有時會導致無法付款,或者團隊不得不從頭開始項目。

Scrum 旨在比這種方法更高效和有效,因為它為團隊提供了清晰和專注的目標。 它旨在具有適應性——敏捷的關鍵品質之一——以防止重大挫折。 此外,Scrum 在整個過程中整合了產品負責人的反饋,以防止客戶不滿。

如何實施 Scrum 協作方法(7 個關鍵步驟)

Scrum 涉及一個非常具體的過程,在此過程中包含某些文檔和會議。 雖然一開始看起來有點規範,但這些步驟實際上為團隊提供了更大的靈活性,並使適應不可預見的問題成為可能。

步驟 1:創建您的產品待辦事項列表以概述基本功能

正如我們之前提到的,Scrum 將項目劃分為多個衝刺。 一個團隊可以根據需要運行盡可能多的衝刺,以創建最終產品的最佳版本。 第一個衝刺從產品負責人創建“產品待辦列表”開始。

這是一份包含最終產品所有基本功能的文檔。 產品待辦列表不應該指定可能用於創建產品的低級任務,而應該關注大局。 最初的產品待辦列表只需要包含最終產品最基本的必要特徵。

例如,如果您使用 Scrum 建造房屋,那麼最初的產品待辦列表可能包括房屋的地基、牆壁和屋頂。 它不會指定諸如地板或燈具之類的東西,因為這些是技術上小的精加工細節。

第 2 步:召開“Sprint 計劃會議”來確定您的目標

產品負責人完成第一個產品待辦事項列表後,您的整個團隊應該召開“Sprint 計劃會議”。 在這次會議中,您將確定即將在接下來的一到三週內進行的衝刺的目標。

這個會議不應該看起來像瀑布方法中使用的廣泛的計劃會議。 相反,您的團隊應該檢查產品待辦列表,然後確定您可以在 sprint 的指定時間段內實際完成哪些目標。

回到我們的房屋示例,在第一次 Sprint 計劃會議上,您可能會確定您的團隊只有時間在即將到來的 sprint 中打地基和構築房屋。 這些是您在會議期間將討論的唯一任務。 您將在下一個衝刺的產品待辦列表中留下其餘的目標。

第 3 步:將項目添加到您的 Sprint 待辦事項列表中以繼續執行任務

一旦您確定了第一個 sprint 的目標,您的團隊就可以創建一個“Sprint Backlog”——另一個旨在幫助您的團隊完成任務的文檔。 許多團隊使用白板和便簽創建 Sprint Backlog,這些便簽分為三列:“待辦事項”、“進行中”和“已完成”。

便利貼應該包含與 Sprint 計劃會議期間從產品待辦列表中選擇的目標相關的特定任務。 團隊成員可以在處理任務時在列之間移動便簽。 通過這種方式,每個人都始終知道正在處理什麼,還有什麼需要解決。

在我們的示例中,一些與鋪設地基和構築房屋目標相關的任務可能是收集材料、混合混凝土和將框架切割成正確的長度。 這些項目可以寫在便籤上並添加到 Sprint 待辦事項列表中。

第 4 步:合併每日站立會議以保持溝通

在每個衝刺期間,您的團隊每天都應該舉行一次不超過 15 分鐘的簡短會議。 這些有時被稱為“每日站會”,通常是站成一圈。 在這些會議期間,團隊成員可以對當前在 Sprint 待辦列表中列為“進行中”的項目進行更新。 您還可以委派仍在“待辦事項”列中列出的任務。

這是團隊討論出現的任何問題並可能導致挫折的機會。 團隊可以提供故障排除建議或重新分配資源以幫助在 sprint 結束前解決問題。

第 5 步:向產品負責人展示 Sprint 結果以獲取反饋

在衝刺結束時,團隊應該向產品負責人展示產品。 他們將評估它是否已準備好發布,或者在使產品可用之前是否需要另一個衝刺。 這就是 Scrum 將客戶反饋納入流程以幫助防止他們不滿的方式。

由於各種原因,可能需要額外的衝刺。 有時衝刺的目標只是讓產品具有最重要的功能,就像我們的房子例子一樣。 產品負責人可以選擇出售只有地基和框架的房子。 但是,如果再舉行一次 sprint 來添加功能,那將更有價值。

有時,衝刺結束時會發現基本功能實際上並不是必需的。 在這種情況下,團隊可以在下一個衝刺中修改產品以將其刪除。 產品負責人也可能意識到需要他們以前沒有想到的功能,並選擇運行另一個衝刺來合併這些新想法。

第 6 步:召開 Sprint 回顧會議,討論您的團隊可以改進的地方

在每個 sprint 結束時,團隊應該舉行一次“Sprint 回顧會議”,討論他們可以改進的地方。 這是一個討論上一個衝刺中出現的問題的機會,並指出您的團隊可以提高效率的領域。

這次會議的目的不是互相貶低或抱怨其他團隊成員。 相反,嘗試將整個群體視為一個整體。 回顧會議應該努力改善團隊成員之間的溝通,並專注於開發過程而不是產品。

第 7 步:重複前面的步驟以創建完整的最終產品

產品負責人評審產品,團隊召開 Sprint 回顧會議後,團隊就可以為下一個 sprint 做準備。 產品負責人應重新訪問產品待辦列表以添加或刪除產品審查期間討論的任何功能。 然後,新的 Sprint 計劃會議應該確定下一個 sprint 的目標。

您的團隊可以繼續運行沖刺,直到產品負責人對最終產品完全滿意。 產品負責人可能會選擇在此過程中發布產品的版本,隨著產品的改進發布更多版本。 從衝刺到衝刺,目標和任務可能會變得更加具體。

結論

如果反复的挫折導致錯過最後期限和低於標準的結果,長期項目可能以失敗告終。 您的客戶甚至可能認為您的最終產品不能滿足他們的需求,從而導致您的所有辛勤工作付諸東流。 Scrum 方法旨在通過實施客戶反饋、設定明確的目標和建立協作團隊來避免這些問題。

現在您已經了解了 Scrum 的基礎知識,您可以將其合併到您的下一個團隊項目中。 小心收集團隊成員,使用產品和 Sprint 待辦列表等文檔,主持定期會議,並結合產品負責人的反饋來創建最終結果的最佳版本。

您對 Scrum 協作方法有任何疑問嗎? 在下面的評論部分詢問他們!

文章圖片縮略圖:Andrew Rybalko / shutterstock