Scrum 中的流程

衝刺計劃

Sprint 計劃是 Scrum 衝刺的初始階段。它決定了衝刺期間的工作範圍和工作方式。整個 Scrum 團隊都參與計劃。

衝刺是明確定義的時間段，在此期間必須完成指定的工作。衝刺需要在開始之前進行計劃。首先，您需要確定衝刺的持續時間和目標。

在規劃研討會上，任務列表和衝刺目標達成一致。為團隊注入正確的工作動力非常重要，這樣每個成員都專注於成功。

如果衝刺計劃不周，那麼這可能會導致團隊失敗。開發人員將無法滿足對他們的期望，因為事實證明這些任務是不切實際的。

計劃衝刺時要考慮的問題：

• 客戶或軟件所有者宣布衝刺的目標，同時解釋如何實現它。Scrum 團隊找出在未來的衝刺中可以完成哪些任務來實現這個目標。
• 開發人員在他們之間分發工作計劃，並與軟件客戶達成一致。
• 產品的客戶（所有者）始終參與製定衝刺計劃。他設定了一個目標，編程團隊必須找出是否可以在衝刺中實現。
• 該計劃應使用產品待辦事項列表，可以將其中的信息添加到計劃中。
• 團隊成員在結束計劃會議時應該清楚地了解他們需要什麼來實現結果。您可以在衝刺積壓工作中顯示未來行動的順序。

計劃每週不應超過兩個小時。Scrum Master 必須向每個人解釋，有時間限制。如果所有工作問題都迅速解決，那麼會議可以比平時提前結束。此類會議沒有最短持續時間限制。

任務評估

評估工作的複雜性不需要過分。規劃過程不需要對開發的複雜性進行精確的評估，但至少需要進行大致的評估。團隊不僅要了解衝刺的目標，還要將目標與團隊的能力進行比較。

要評估複雜性，您可以使用每個人常用的衣服尺碼（L、XL、XXL）。當然，這並不能保證準確性，但仍然如此。

為了更準確地評估複雜性，需要相互理解。團隊成員應該公開分享他們的意見，不要害怕向產品負責人提問。

工作完成後對團隊的批評可能會導致在計劃下一個衝刺時，預測會變得不那麼樂觀。這將幫助團隊避免重蹈覆轍，並防止其在未來受到負面評估。

分、分、時分難度評估

通常，開發團隊會隨著時間的推移估計他們工作的複雜性。但是一些敏捷團隊選擇以分或分來評價難度。這是實施積壓項目或其他分配任務所需總成本的更好指示。

積分是根據工作的複雜性和數量來授予的。此外，還考慮了可能的風險。使用此方法評分有助於有效地將工作分解為小步驟。

通過在計劃時定期使用評分方法（分數），團隊可以更好、更準確地了解他們需要多少時間才能完成工作。此外，還有其他優點。

• 時間估算不考慮與項目不直接相關的工作，儘管它肯定會出現。通過信使討論工作問題，召開會議——所有這些對團隊成員來說也需要時間。
• 情緒會影響日期的選擇。評估工作時的評分消除了這個因素。
• 每個團隊對工作複雜性的評估以及相應的完成任務的速度可能不同。有分數的工作不能被視為速度的任何指標。也就是團隊沒有心理壓力。
• 通過正確分配勞動力成本和復雜性，您可以快速且無衝突地為參與者之間執行的工作劃分點。
• 完成任務獲得的點數取決於其複雜性，而不是花費的時間。所以，程序員會想著提高效率，而不是想著要花多長時間。

複雜性估計的缺點是它經常被誤用。例如，此方法不能用於評估員工。

團隊應該使用評分系統來更好地了解分配給他們的工作量並正確確定優先級。

每日 Scrum 會議

研討會很重要：在研討會上，團隊成員分享他們的意見、交流並就進一步的行動達成一致。還需要每日召開例會以提高團隊精神並發佈時事新聞。

站會是主要項目參與者的簡短會議：軟件所有者、程序員和 scrum master。站會的結構由三個問題組成。

• 昨天我們能做什麼？
• 我們今天在做什麼？
• 是什麼阻礙了我們取得成果？

提出這些問題可以促進發展，並有助於發現團隊內部的問題。當每個參與者交流他/她如何幫助實現共同目標時，這會增進團隊內部的相互理解。

重要的是要記住，沒有單一的模板來指導如何進行站立會議。每個團隊根據團隊的特點，按照自己的模式召開會議。

現在讓我們討論完美的站立需要什麼，並熟悉有效的站立示例。

首先，您需要選擇適合每個人的時間。通常，來自同一辦公室的團隊的站立會在工作日開始時舉行——早上 9 點到 10 點之間。這使您有時間更好地計劃當天的日程安排。如果團隊成員在不同地區工作，則選擇適合每個人的時間。例如，如果一些團隊成員居住在加利福尼亞和悉尼，那麼站立會議將在加利福尼亞時間 15:30 開始。當然，晚飯後站起來對每個人來說都不方便，但可以讓我們與大洋彼岸的同事保持聯繫。

跟踪站立的生產力。不要開會太久——注意力應該保持在最佳狀態。如果可能，站立的時間不要超過 15 分鐘。

用球。可以依次扔給對方。因此，每個人都會參與討論。這個遊戲有助於保持團隊的注意力。使用團隊回顧。許多敏捷方法中都使用了站會，這並不妨礙我們在回顧會議上討論站會的有效性。有人每天見面，其他團隊 - 一周幾次。如果團隊很難從站立會議中獲益，找出原因並做出改變。

衝刺回顧

Spring Review 在衝刺的最後階段進行。有必要檢查產品增量並裁剪積壓。整個 scrum 團隊和所有利益相關者參與對沖刺結果的審查。會議以輕鬆的形式舉行，以增進項目參與者的互動。

Sprint 結果評審包括以下要素：

• 軟件所有者顯示積壓工作中哪些已完成，哪些尚未完成。
• 程序員討論什麼進展順利，困難出現在哪裡，以及它們是如何消除的。
• 開發團隊展示他們在衝刺期間的工作成果，以及他們收到的產品增量。
• 產品負責人分享他對當前積壓的想法。它還給出了下一個目標的預測及其實施的截止日期。
• 大家根據市場評估和用戶興趣討論下一步最好做什麼。
• 就增加積壓工作的時間、預算和前景交換了意見。

結果是更新的待辦事項列表，其中包含後續衝刺的新目標。如果情況需要，可以更改積壓。

衝刺回顧

Sprint Retrospective 是一個討論如何改進工作流程的研討會。它還為下一個衝刺創建改進計劃。會議通常在 sprint 評審之後舉行，持續時間不超過三個小時。主持會議的是 Scrum Master。

Sprint 回顧的主要目標包括：

• Sprint 分析（參與者的工作、結果和問題）。
• 討論可能的解決方案以改進後續衝刺中的工作流程。
• 在項目實施期間為團隊成員制定改進實施計劃。

Scrum Master 邀請團隊成員就如何提高開發效率提出建議。該團隊討論這些建議並提出實施建議的某些方法和技術。

在 Sprint 回顧結束時，團隊應該強調一些改進建議，以便在下一個 sprint 中實施。建議可以隨時實施，但 Sprint 回顧提供了一個機會，可以從團隊的角度更深入地審視他們可能的適應。

這是我們結束對 Scrum 方法論的討論的地方。您可以在專題文檔或您的第一個工作場所了解更多信息。