之前我寫過一篇文章，關於敏捷坑人系列不清晰的完成，在這篇文章當中，描述了完整的定義和驗收標準之間的區別，但是最近的課程當中依然有不少小夥伴在提問關於完成的定義，那今天的來說一下，為什麼我們要設定完成的定義（即其重要性）
在工作當中往往我們會說這個事情我完成了。當我們說完成的時候，每個人對於這個完成是有不同的定義。比如po認為完成是需要包含完成編碼，提交到**庫，完成單元測試，完成整合測試，完成功能測試，等等一系列的測試。
而開發小夥伴可能認為完成只包含**，以及在自己的電腦上測試，沒有問題就算是完成了。
那這兩個完成之間是有很大的乙個差距，而這個往往會造成大家對於完成的理解誤區，及同時也會造成溝通上的衝突。
在這個背景下，團隊需要對於完成有乙個統一的認識。這個完成會包含很多不同的層面及不同的步驟。
舉例說，如果說乙個產品功能完成了會包含什麼？如果開發完成了會包括什麼，如果測試完成會包括什麼，這是不同的層面。但是在scrum指南中完成預設是指的產品完成。
完成的定義就像是一道門檻
團隊一起設好了門檻，能跳過去的功能（pbi）就是完成了，跳不過去的，就是沒完成。沒有完成一半或者完成90%這樣的概念。
所以對於這道門檻我們要設多高，這個是看團隊對於自己的要求是多少，以及團隊對質量的要求是多少，這是非常重要的一乙個概念
驗收標準更像是pbi（功能）自身的一部分，或者使用者故事的一部分。驗收標準和使用者故事是完整的整體，且不可拆分的。
也就是我們在梳理使用者故事的時候，要同時梳理出這個使用者故事的驗收標準。
舉個例子，比如登入功能，如何這個登入功能才算是完成呢？最簡單的使用者名稱密碼正確就登入成功，使用者名稱密碼錯誤返回錯誤原因。這是最簡單的兩個驗收標準。這兩個驗收標準就是使用者故事的一部分。
關於使用者故事和產品待辦列表，在我之前的部落格當中也已經有詳細描述，大家可以參考。
敏捷DoD完畢定義的多種形態
張克強 敏捷307 關於definition of done 完畢的定義 在以往的說法中，常見用 退出標準 完畢條件。成功標準，等等 在敏捷軟體開發中，存在多級的不同的完畢定義。典型的是迭代的dod。這也是最初dod應用的地方。常見在scrum中，須要預先定義dod，常見的迭代dod條款有 1，全部...
《學習之道》第七章再次強調回想是最好的學習方式
請記住，已有研究表明，你越努力回想學習材料，它在記憶中植入得就越深。相比純粹的重複閱讀，回想才是學習過程中最好的刻意練習方式。我們的記憶有個奇怪的特質，即主動重複比被動重複讓人記憶更深刻。我是說，在以心記的方式學習的過程中，等明白得差不多了，如果多花些時間和精力去回想，得到的效果比再看一遍書更好。通...
「完成」的定義和測試的職責
注 本不是乙個會寫很多東西的人，偶爾寫點心裡的東西，記錄下來，可能是大家耳熟能詳，如果這樣，勿怪。在乙個敏捷開發模式下的團隊，如何定義完成的概念。其實不管什麼樣的團隊，在開發過程中都有自己的定義，以下是我在最近的畢業 中想到的一些東西。敏捷宣言中最核心的內容有一點就是頻繁的交付。所以敏捷中完成的概念...