使用 Scrum

用戶故事

用戶故事是陳述開發中軟件需求的有效方式。這些故事包含代表軟件用戶的簡短建議。

由於在 Scrum 方法中，設定目標通常是客戶或軟件所有者的特權，因此它們被認為是影響開發過程的主要方式。每個用戶故事在文本量和呈現的複雜性方面都有限制。歷史通常寫在一張小紙上，這本身就限制了體積。

借助用戶故事，您可以記錄客戶的願望并快速響應市場需求。

用戶故事應該被視為一種簡單的需求度量，因為它不包括驗收測試程序。用戶故事的編寫必須符合准入程序。這將確保用戶故事實現其目標。

故事結構如下所示：“作為用戶 <user type>，我想執行 <action> 以獲得 <result>”（作為產品所有者，我想要...）。這樣的結構不僅簡單，而且每個人都可以理解。

使用用戶故事的好處：

• 故事很小，很容易創建。
• 幫助所有利益相關者討論項目工作及其支持。
• 不需要經常維護。
• 僅在使用時相關。
• 改善與客戶的互動。
• 多虧了他們，您可以將項目分成幾個小階段。
• 促進對需求知之甚少的項目的工作。
• 簡化任務評估。

用戶故事的缺點：

• 如果沒有事先約定，程序可能難以用作協議的基礎。
• 它們的使用需要在整個項目中與客戶保持密切聯繫，這有時會使工作流程變得困難。
• 在擴展大型項目時，它們有缺點。
• 直接關係到開發人員的專業水平。
• 用於開始討論，但不能結束討論，並且不用於系統文檔。

積壓

產品待辦事項是以列表的形式，按照優先級順序編制的當前任務。該列表是根據項目的路線圖（路線圖）和其中列出的要點形成的。最重要的任務通常位於列表的頂部。這對於了解應該首先完成哪些工作是必要的。

開發團隊選擇完成積壓任務的速度而不考慮客戶的意願，而是根據他們過去沖刺的資格和經驗。“調整”程序員是極其不可取的。團隊自己根據自己的考慮和能力從backlog中選擇任務。執行不會中斷（看板）或多次迭代（Scrum）。

兩個重要的積壓條件

產品待辦事項列表的核心包括路線圖、建議和執行條件。史詩包含條件和用戶故事。讓我們仔細看看典型的路線圖示例。

創建“Teams in Space”網站是路線圖中的第一項提議。它需要分為史詩（圖中以綠色、藍色和綠松石色顯示）和每個史詩的用戶故事。

軟件客戶從多個用戶故事中形成一個列表。如有必要，他可以更改故事的執行順序，以便開發人員首先處理最重要的史詩之一（左）或檢查折扣票預訂的運作方式。為此，您需要實施史詩故事（右）。這兩個選項都可以在下面看到。

客戶應根據哪些因素優先考慮？

• 與用戶的相關性。
• 反饋的存在。
• 發展的複雜性。
• 任務之間的關係（要完成“B”，首先需要做“A”）。

工作的優先級由客戶決定，但其他方可以對此發表意見。積壓的成功取決於客戶和程序員的意見等。他們一起可以取得更好的效果，並確保成品的及時交付。

如何保持積壓

如果積壓已經創建，那麼您需要在進一步的工作過程中定期更改它。軟件客戶應確保在每次新的迭代計劃之前正確編譯積壓。這將有助於在上次迭代分析後明確優先級或更改某些內容。在敏捷中調整積壓有時被稱為“梳理”或“細化”或“積壓維護”。

如果backlog已經比較大，那麼客戶就需要按照短期和長期的執行來對任務進行分組。短期任務在被授予此狀態之前應經過仔細審查。您將必須編寫一個用戶故事，找出團隊中的所有細微差別。

至於長期任務，非常希望開發人員對其進行評估。這將更容易確定優先級。也許有些事情會發生變化，但團隊會提高他們對任務的理解並更快地完成工作。

積壓是客戶和編程團隊之間的重要組成部分。客戶始終可以根據客戶反饋、預測或新要求更改優先級。

建議避免在操作過程中直接進行更改。這對程序員的工作流程和情緒狀態都有不好的影響。

短跑

衝刺是一段很短的時間，在此期間必須完成先前商定的工作量。衝刺基於 Scrum 和敏捷方法。選擇正確的衝刺有助於敏捷團隊開發高質量的軟件。

“使用 Scrum，您可以在具有明確持續時間的多次迭代中開發產品 - 衝刺。它有助於將大型項目分解為更小的任務，”Atlassian 的 Jira 負責人 Megan Cook 說。

Scrum 如何計劃和執行沖刺？

按照 Scrum 方法論的作者的說法，為了規劃未來的衝刺，每個人都需要單獨開會。在這次活動中，團隊成員必須找到兩個主要問題的答案：在這個衝刺中需要做什麼以及如何做到最好？

軟件客戶、Scrum 管理員和程序員參與確定工作任務列表。客戶從積壓中解釋了衝刺的目標和任務。

然後團隊制定一個計劃，根據該計劃完成衝刺中的任務。該計劃與選定的工作項一起稱為 sprint 待辦事項列表。計劃會議結束後，團隊開始工作。開發人員從 backlog 中選擇任務，隨著工作的完成，每個任務的狀態從“In Progress”變為“Done”。

在衝刺期間，團隊每天舉行 Scrum 會議（站會）來討論當前的問題和進展。需要這樣的會議來確定可能影響衝刺完成的困難。

如果衝刺完成，則團隊會在結果審查（演示）上顯示他們的工作結果。該項目的每個參與者都可以熟悉結果。熟悉應該在完成的代碼合併到生產環境之前完成。

回顧會完成衝刺週期。在上面，團隊確定了在未來的衝刺中需要改進的領域。

什麼該注意什麼不該做

大多數年輕團隊第一次發現很難將衝刺引入他們的工作流程。為避免出現問題，我們建議您查看需要優先註意的操作列表。

我們該做什麼：

• 檢查團隊是否了解衝刺的目的以及如何取得成功。這對於每個人共同走向成功的結果是必要的。
• 您應該有一個清晰易懂的積壓工作。如果未正確維護積壓，這可能會成為破壞工作流程的問題。
• 確保您對工作節奏的估計是正確的，同時考慮到暑假和其他因素。
• 積極參與衝刺計劃。鼓勵團隊成員擴展故事、錯誤和任務的計劃。
• 拒絕開發人員無法解決依賴性問題的任務。
• 計劃獲得批准後，任命一名員工負責將數據輸入項目管理程序（Jira 卡等）。

避免什麼：

• 不要過度使用大量的故事，清醒地評估工作節奏，不要分配在衝刺中難以完成的任務。
• 注意你的工作質量。檢查您是否有足夠的時間進行質量控制和修復代碼中的錯誤。
• 確保所有團隊成員清楚地了解衝刺的內容。不要追求速度。整個團隊必須齊心協力。
• 不要讓開發人員承擔額外的工作。另一個衝刺即將到來。
• 如果團隊對工作量或截止日期表示擔憂，您應該考慮他們的意見。處理問題並在必要時糾正它們。

爭球板

Scrum 看板是一個顯示 Scrum 團隊如何完成工作的工具。您可以在紙上、牆上或電子形式（JIRA、Trello）的此類板上顯示信息。

Scrum 看板至少包含三列：待辦事項、進行中和已完成。這是一個示例板：

Scrum 看板包含積壓工作中的所有信息，這些信息之前已批准用於計劃。通常，業務任務卡按從上到下的優先級固定在看板上。您可以將它們劃分為特定類型的工作（代碼、設計等工作）。

部分工作完成後，將卡片全線移至下一欄。為了顯示團隊工作進度的可見性，燃盡圖上按天顯示的“剩餘工作”會有所幫助。

您也可以使用活動掛圖板。在上面，作品的名稱寫在貼紙上並貼在板上。工作完成後，貼紙會立即移至另一列。

燃盡圖

燃盡圖顯示已完成的工作量和剩餘的工作量。它每天更新，並可供所有感興趣的各方使用。需要該圖來顯示衝刺工作的進度。

有兩種類型的圖表：

• 燃盡圖顯示衝刺中的工作進度。
• 燃盡圖顯示產品發布之前的工作進度（數據是從幾個衝刺中總結出來的）。

圖表示例：

這個例子用到了心理學：圖表顯示的不是完成任務的數量，而是剩餘（未完成）的數量。

也就是說，如果團隊完成了 100 項任務中的 90 項，那麼可能會有一種萬事俱備的錯覺。畢竟，從 90 項任務進展到 100 項任務並沒有真正改變任何事情。

如果您顯示剩餘任務的數量，那麼您會情不自禁地註意到它們是如何變得越來越少的。這下意識地刺激項目參與者更快地實現目標——看板上不應該有未完成的任務。