? ? ? ?譯者序：在很多敏捷項目中，秩序誕生的標志之一是有了成文的DoR。但是項目組和需求方的折中往往也無可奈何地始于將沒有就緒的需求納入到Sprint待辦事項列表，并為Sprint實施階段帶來一系列的不可控因素。為什么市場和產品人員時常要求技術人員在Sprint里實施一些沒有充分精煉過的需求？如何制定DoR，并使之解決市場和技術之間的斷層問題？推動DoR的過程中出現問題要怎么辦？本文作者立足于自己的經驗，分享了對以上問題的看法，對正在躊躇是否制定、正在制定和推動DoR的團隊有一定的借鑒意義。

原文：

? ? ? ?您有一個精煉過的產品待辦事項列表，或者說是非常接近精煉的。與此同時，您正在準備做Sprint計劃。萬不得已的情況下，產品待辦事項列表上的某些項目依舊太模糊，開發團隊無法對它們進行實施。然而Sprint待辦事項體現了實現Sprint目標所必需的工作，同時它指導開發。因此，“ Sprint待辦事項”中的項目必須是具體的。它們不可以是模糊的。但是，開發團隊需要多“具體”才能開始他們的工作呢？

? ? ? ?如果開發團隊不能完全理解產品待辦事項（PBI），開發工作和開發時間往往會激增，從而導致Sprint目標未能達成，或者是交付無法符合利益相關者的期望。

? ? ? ?開發的挑戰在于獲得新的想法并使它們變為現實，這實際上是在開發這些想法。這是思想從根本上的一個改變：一個想法開始時很抽象，但是開發要求這個想法在每個細節中都很具體化。這種思想上的改變最終只有在開始開發的時刻才會真正的發生。但是，如果您希望可以進行詳細的計劃（并且您需要詳細的短期計劃以使您的流程保持清晰明確），那么這些需要開發的想法必須足夠具體，才能回答設計的問題。具體到什么程度？具體到足以讓團隊可以充滿信心，來進行詳細的計劃。

? ? ? ?我曾經作為自由顧問為一家小公司做一段程序。有一次，首席執行官要求我編寫一些軟件，并提出了固定價格?！拔覀兛梢赃_成一致了嗎？” 他問。“不，”我說?！霸撥浖亩x不夠精確，我無法評估完成它需要多長時間?！?/p>

? ? ? ?換句話說，在市場的世界和設計的世界之間，存在著一個斷層。他們各自創造的認知以不一樣的量級演進：市場了解逐步而緩慢，而設計往往會迅速聚焦（參考《實現規范 Enabling Specifications》）。它們之間需要一個組織級的邊界。否則，您會同時削弱了對市場和項目的焦點。理論上，您可以通過流程的邊界來實現這種分離。然而組織人員關系跨越了整個過程，因此您仍然面臨著一個問題：是關注業務和價值領域，還是關注產品和技術領域，在這兩者之間，人們可能依舊會舉棋不定。反過來，要解決該問題，您可以從時間上來劃分人員在這兩個領域之間的關注點。但這會導致人員在任務上下文之間切換，眾所周知，這會導致效率的降低。Scrum將這些問題從組織級別上區分開來，分成產品負責人和開發團隊。而它成功的關鍵點在于，在這兩個領域之間有一個接觸點。

? ? ? ?當您處于計劃的困境中時，有一種強烈的誘惑讓您想要快速做出假設，并將棘手的問題（例如詳細的估算）推遲到以后。而當一個小組一起計劃時，往往會面臨一些隱性的同僚壓力，為了使計劃過程能夠順利進行而將困難的問題推遲。要解決這個問題，團隊必須達成一致，最先解決最棘手的問題。為了避免在不確定的情況下開始工作，團隊對截止點需要有一個明確的共識，并共同遵守這個客觀標準。

? ? ? ?在精益的思維中，反復不定是造成浪費的原因之一。如果開發團隊不足以理解某些產品待辦事項的真正含義，或者不能很好的理解如何開發或評估它，那么Sprint交付成果的偏差就會增加，同時這種工作還可能會導致成本，風險和不確定性增加。

? ? ? ?因此：

? ? ? ?每個產品待辦列表上的項目必須至少滿足以下條件，開發團隊才能在Sprint計劃會議上將其選為Sprint待辦列表的候選項：

1.團隊可以針對這項工作立即采取行動。

2.預計的交付物具有價值。

3.產品負責人和開發團隊對它進行過討論。

4.開發團隊對它估算過。

5.它是可測試的，并且產品負責人對此測試有具體說明。

6. Scrum團隊已經把它調整到合適的大小（請參閱縮小項目Small Items）。

? ? ? ?如果產品待辦事項列表的頂部具有滿足這些條件的產品待辦事項，而這些產品待辦事項多到足以填充一個Sprint，那么它就是“就緒”的。

? ? ? ?良好的就緒定義可以幫助指導團隊處理外部依賴性。如果某個待辦項取決于團隊無法控制的外部事件，將其放入Sprint待辦事項列表中會大大增加在Sprint結束時不能交付潛在的定期產品增量（Regular Product Increment）的風險，而您對此無能為力！您需要自始至終的在產品待辦項級別上進行依賴性分析，而不能僅僅在定期產品增量級別上粗糙的管理依賴性；團隊最終都需要了解產品待辦項級別的依賴性，才能在生產過程中對工作進行排序。您需要考慮將涉及外部依賴性的標準作為“就緒定義”的一部分。

? ? ? ?定義就緒與實現規范之間存在重要的相互作用。下一個Sprint的待辦候選項必須最遲在該Sprint計劃期間準備就緒。Sprint計劃的產出物，包括產品待辦事項連同產品負責人的說明和澄清，必須能讓團隊無所畏懼地開始實施。

? ? ? ?Scrum團隊的目標是要滿足所有就緒標準，因為它致力于精煉產品待辦列表，并爭取在Sprint計劃之前制定實現規范。這項活動的目的是使PBI不受干擾地通過“就緒門”，每個待辦項僅需遵守簡短的清單即可。清單對于不成熟的團隊來說，允許他們能夠“停止生產線”，這很重要，但更大的好處來自于可預期的約束條件，以及提前籌備PBI，讓它們在Sprint開始時已完全準備就緒，從而使得整個流程暢通無阻 。

? ? ? ?請注意，并非產品待辦事項列表中的所有PBI都需要準備就緒，但隨著它們在產品待辦列表中的上移，它們應該朝著就緒狀態邁進?！熬途w”定義了那些可以進入Sprint的PBI；?與此相對，“完成”定義了那些在Sprint期間或結束時可以交付的PBI。

? ? ? ?如果PBI沒有準備好怎么辦？盡管整個團隊都致力于PBIs，產品負責人有責任充分做好Sprint Planning的準備，以使得團隊能夠不受阻礙地為當前Sprint的開發PBI候選項。在大多數情況下，“未準備就緒”表示產品負責人必須回去做更多的分析，再將PBI帶回團隊。Scrum的傳統是，如果在Sprint計劃時沒有準備就緒的產品待辦列表，則開發團隊有權“去海邊度假”，就如同于Jeff Sutherland在《 Scrum：一半的時間內完成兩倍工作的藝術》（第137頁，“準備完成”）中所描述的一樣。這讓產品負責人沒有把待辦列表準備好的事實變得顯而易見。如果您總是“在海灘上”，則可能是工作流出了問題。您對未就緒的產品待辦列表有何貢獻？團隊能如何幫助產品負責人？

? ? ? ?為了區分Scrum中的就緒概念是一種與語言中的“就緒”不同的術語，Scrum的人有時會使用短語“ 就緒的就緒（Ready-Ready）”，而不是單個單詞“ 就緒”。理查德·科隆法爾特（RichardKronf?lt）在2008年最先發布了關于“就緒定義”的正式描述。25

非常感謝Peter Gfader的評論！

【25】. Richard Kronf?lt. “就緒的就緒: 為可以進入Sprint計劃的用戶故事定義就緒.” Blogspot.dk, 2008年10月, http://scrumftw.blogspot.nl/2008/10/ready-ready-definitionof-

ready-for.html (訪問于2017年11月1日).

譯者：Emma

校對：Suzzi?

參考資料：

（1）A Scrum Book：65 Definition of Ready

總結

以上是生活随笔為你收集整理的【Scrum模式语言9】准备就绪的定义(Definition of Ready - DoR )的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。