關於definition of done 完成的定義
dod在以往的說法中，常見用 退出標準 , 完成條件，成功標準，等等
典型的是迭代的dod，這也是最初dod應用的地方。 常見在scrum中，需要預先定義dod。
1，所有完成的使用者故事得到po的驗證
2，所有**得到靜態分析，糾正最高端別的不符合項，靜態分析的規則參見…
3，所有新增**得到人工評審
4，所有完成的使用者故事都有對應的測試用例
早期的迭代成果一般是為了內部或者可控範圍內的展示，相對發布而言，要求較低，所以適用時間箱方法，當然迭代本身就是時間箱，迭代內的測試本來就有時間限制。採用時間箱來安排迭代內的測試可以獲得時間箱安排的種種好處，在這樣的安排下，回歸覆蓋率就應當是乙個變數，用於觀察，而不應當是乙個要求指標。
敏捷開發發展了幾個年頭之後，人們發現進入迭代開發應當滿足一定條件，否則過於模糊的需求會導致迭代的失敗，在迭代內花費過多的時間去做需求澄清，因此給進入迭代設立門檻，就是definition of ready，簡略稱之為「dor」， 最初的ready是指準備好可以進入迭代開發。
1，使用者故事得到澄清
2，使用者故事的故事點估算已經得到
3，使用者故事的驗收條件已經給出
隨著敏捷軟體開發不斷實踐，為了保證不同物件的質量，出現了多級的不同的完成定義。
而對於發布，一般就有更加嚴格的要求，發布dod的典型條款有：
1，完成發布規劃所要求的重點內容
2，通過發布的全量測試，回歸測試範圍是全範圍，回歸比率不低於50%
3，修復所有等級為1、2、3的缺陷，4級及4級以下缺陷不超過200個。1、2級缺陷必須修復，3級缺陷經過帶缺陷發布審批後可以發布。
在以往，由於發布需要達到比迭代更高的要求，所以一般很難強制規定發布測試所需要的時間長度，也就是說敏捷中常用的時間箱方法不適宜用在發布前的測試上，因為高質量發布是第1要務，如果到了原計畫測試結束的時間，仍然留有妨礙發布的缺陷的話，應當修復後才能發布。因此出現了water-scrum-fall這樣古怪的提法，在dad裡面，恰恰容忍這樣的做法，dad把這樣的做法看成是從原瀑布模型轉向敏捷交付的起步階段。
最新為了獲得更快的時效，迭代級別的發布成為越來越多組織的選擇，也就是說每迭代都要發布。那麼這樣，就把發布的高要求帶給了迭代，迭代dod同時要滿足發布dod。這種情形下，也需要對原來的發布dod進行修改，主要在回歸測試策略和通過條件上，一般而言，原來的回歸測試策略需要過多的時間，無法在迭代內完成，需要新的回歸測試策略能夠支援迭代節奏。
為了更好的達成迭代dod，就需要提前注意，所以有些更加細節的dod得到識別並使用。
最典型的是每日dod，典型條款有：
1，搭建每日構建環境，晚上自動靜態**檢查、編譯、部署和測試，每日修復前一日構建和測試發現的缺陷和問題。
2，下班前必須檢入當天書寫的**
3，當天的**必須在當天或者第2天邀請同伴進行**評審
4，搭建持續整合環境，當天上下午必須至少各檢入**一次（這與第1條可能衝突）
5，凡是檢入的功能**必須要有對應的單元測試
還有針對使用者故事的dod，比如
1，使用者故事最終的描述符合invest
2，使用者故事得到測試用例的對應覆蓋
3，使用者故事得到對應的自動化測試用例
4，使用者故事得到使用者代表試用並初步認可
有少數組織考慮到測試集過於龐大，無法在1天之內測試完成，開展每週全量回歸自動化測試，這樣就有每週dod，典型條款有：
1，上上週發現的缺陷是否解決
2，上週新增功能的自動化測試是否加入到每週測試集。
隨著多級dod出現，多級dor也出現了，往往的前一段的dod就是後一段的dor。所以有些的dor其實就是dod。比如對於整合測試的dor就是開發聯調的dod，在使用看板的情況下，就是狀態列的移動條件。典型的從開發聯調到整合測試的條件：
1，開發跑通主成功場景，demo給到po，得到po認可
2，**合併到某某指定分支
3，持續整合通過
從最初只有迭代dod出發，dod和dor的多種形態的出現是越來越高頻交付的必然結果。在既追求質量又追求效率的情況下，值得組合選擇設定恰當的dod和dor，並且在執行中根據出現的情況，不斷調整，成為敏捷團隊的約定，進而塑造團隊文化，甚至進而影響組織文化。
敏捷DoD完畢定義的多種形態
張克強 敏捷307 關於definition of done 完畢的定義 在以往的說法中，常見用 退出標準 完畢條件。成功標準，等等 在敏捷軟體開發中，存在多級的不同的完畢定義。典型的是迭代的dod。這也是最初dod應用的地方。常見在scrum中，須要預先定義dod，常見的迭代dod條款有 1，全部...
整理 kanban 的 DoR 和 DoD
所謂 dor 和 dod 就是 definition of ready 和 definition of done。我們的敏捷團隊在需求管理上主要有兩個會 需求梳理會和需求計畫會議。需求梳理會的闡述的意向使用者故事會放到 backlog，後由研發 owner 跟進，在計畫會上，將符合 dor 放入 s...
多型（事物存在的多種體現形態）
什麼是介面 a.可以認為是乙個特殊的抽象類 b.當抽象類中的方法都是抽象的那麼該類可以通過介面的形式實現 c.乙個類可以實現多個介面 d.當子類對介面中的方法全部實現覆蓋後子類才可以例項化，否則子類是乙個抽象類 e.不可以實現多繼承是因為父類的方法有重複，而介面中的方法都是抽象方法 f.介面亦可以實...