本節書摘來自異步社群《驗收測試驅動開發：atdd執行個體詳解》一書中的第1章1.5節總結，作者【德】markus gärtner，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
1.5 總結
驗收測試驅動開發：atdd執行個體詳解
在這一章裡，我們看到了業務專家、開發人員和測試人員是如何協作，在會議中挖掘出軟體需求并對其達成共識的。雖然開始時tony并沒有貢獻太多新的想法，但是他通過把執行個體可視化幫助大家達成了共識。憑借tony獨特的測試領域知識，他的貢獻主要集中在使用表格來抽象描述各種停車方案的執行個體。
在tony拿出第一個執行個體表格後，大家對需求的讨論變得更有意義了。開發人員phyllis在他們已識别出的經濟停車場的執行個體中發現了一個bug。她還要求對6小時零1分鐘的執行個體進行了确認。圍繞這些表格化的執行個體，3人進行了一場從業務視角看軟體預期行為的對話。
bill也更加清晰地表達了他的想法。他可以直接檢視并确認這些執行個體的表述是否正确。甚至對代客泊車的執行個體，bill在看到tony建立的第一個表格之前就可以說出停24小時零1分鐘的費用是多少錢。在這個需求讨論會上，就在寫下第一個執行個體的那一刻，團隊的溝通取得了明顯的進展。
在讨論會進行的過程中，每個人都可以貢獻一己之力。在tony用批判性的思維讨論邊界情況時，phyllis給出了她的觀點。phyllis在開始寫代碼之前就發現了經濟停車執行個體中的一個bug。修正這個缺陷隻用了幾句話，而不是在走完整個開發流程之後。
tony檢查了bill最初提供的需求。他從需求中提取了執行個體，又仔細檢視了像24小時零1分鐘這樣的邊界條件，以便立刻從bill那裡得到正确答案。假如這些問題中的某一個在這個疊代前沒有被答複，那等團隊意識到這個缺陷時，bill也許會因出差在外而無法回答他們想問的問題。那時，團隊可能會為了繼續開發工作，會按自己的了解給出解釋。可是，假如他們的解釋是錯的，這個問題就隻能在為客戶做示範時才能發現，甚至更晚—在産品部署到生産環境幾個月後才被發現。
在讨論會上，作為業務專家，bill做了所有關于這款軟體的決策：哪些要保留，哪些可以删掉。當他提到代客泊車24小時零1分鐘的費用是36美元時，對他來說是很明顯的事，但是tony的問題揭開了bill的隐含假設。仰仗參與者的多元化，團隊很容易對實作的方式達成一緻的目标。
團隊讨論出5個清理後的表格，詳見表1-11至表1-15。他們很快會實作并對這些執行個體進行自動化。在靈活模式下，這可能就是下一個疊代，或3個月之内的某一個疊代要做的事。既然團隊成員已經對需求進行了讨論并了解了這些基本執行個體，那麼，即使在以後的某個時間點去實作這些已達成共識的需求故事，其過程也會是清晰的。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。