資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
Microsoft Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法律研究敏捷開發中的就緒定義 (DoR)
在所有敏捷框架中，Scrum 最受歡迎。Scrum 是一個用於敏捷專案管理和軟體開發的框架。它提供了一種簡單而有效的方法，以適應性和靈活的方式交付複雜的專案。Scrum 首次引入於 20 世紀 90 年代，此後已成為最廣泛採用的敏捷方法之一。
Scrum 應用於廣泛的行業，包括軟體開發、建築、市場營銷和金融。它的流行源於其靈活性和幫助團隊快速高效地交付高質量工作的能力。
DoR 和 DoD 是 Scrum 方法中使用的兩個最重要的術語，用於闡述分配的任務是否已準備好以及處於哪個階段。讓我們在這篇文章中深入瞭解 DoR。
什麼是 DoR？
就緒定義 (Definition of Ready，簡稱 DoR) 是完成定義 (Definition of Done，簡稱 DoD) 的補充。DoR 是一份全面的標準列表，在團隊在下個衝刺中開始處理產品待辦事項之前必須滿足這些標準。它概述了產品負責人必須滿足的條件，以便開發團隊在衝刺計劃會議期間接受該項。本質上，DoR 可以被認為是產品負責人必須達到的“DoD”，以確保該項已準備好進行實施。
需要注意的是，就緒定義 (DoR) 不是 Scrum 指南的正式組成部分。DoR 的目的是為團隊提供積壓精煉的指導方針，而不是充當衝刺計劃的階段門或轉移責任的工具。
大多數團隊從最小的 DoR 開始，並根據需要逐漸新增內容。最好從簡單的框架開始，根據需要逐步構建，而不是試圖立即建立一個全面的列表。
DoR 的標準
產品負責人 (PO) 和開發團隊必須就故事進行過至少一次討論。
故事必須具有明確的業務價值。
實施故事所需的努力必須進行估算。
故事必須分解成可以在單個衝刺內完成的更小任務。
故事必須至少定義一個驗收標準。
坦白地說，您不太可能需要正式記錄就緒定義 (DoR)。在積壓精煉會議期間，團隊會自然地朝著使故事“準備好進行衝刺”的方向發展。
但是，如果您正在尋找 DoR 的實用指導方針，請考慮使用 INVEST 模式。此框架建議使用者故事應：
獨立 (Independent) - 它不應依賴於任何其他故事才能完成。
可協商 (Negotiable) - 故事的細節仍然可以細化和協商。
有價值 (Valuable) - 它應該為客戶或使用者提供明確的業務價值。
可估算 (Estimable) - 應該能夠估算實施故事所需的努力。
小 (Small) - 它應該足夠小，可以在單個衝刺內完成。
可測試 (Testable) - 應該能夠編寫測試用例來驗證故事的完成情況。
簡要說明
獨立 - 使用者故事應該是獨立的，不依賴於任何其他故事。如果您堅持編寫實際的“使用者故事”而不是傳統任務，依賴項的數量自然會減少。在確實存在依賴項的極少數情況下，務必記錄下來。
可協商 - 使用者故事應該關注客戶的需求，而不是規定開發方法。開發團隊應該有靈活性來提出替代方案，以向客戶交付相同的業務價值。
有價值 - 使用者故事必須明確說明其業務價值。這通常可以透過“作為……角色，我希望……功能，以便……業務價值”的格式來捕捉。
可估算 - 開發團隊必須能夠大致估算實施使用者故事所需的努力。這可能需要團隊向產品負責人提出澄清問題，以更好地理解實施方法。
小 - 使用者故事必須足夠小，可以在單個衝刺內完成。如果估計較大，請繼續將其分解成更小的故事。
可測試 - 故事必須是可驗證的，並且其完成情況必須易於測試。這通常需要明確的驗收標準，這些標準可以轉換為測試用例。
結論
重要的是不要使 DoR 過於複雜。保持簡單，無論是遵循 INVEST 模式，還是就開發團隊在有效開始工作之前需要什麼達成基本協議。產品負責人和開發團隊都負有確保故事根據商定的 DoR 標準準備就緒的責任。
621 次瀏覽
