淺談即時驗收在敏捷開發中的應用

[注]：這是2008年末寫的一篇關於即時驗收（即常說的BA sign off）的文章，原文發表於《程序員》雜誌。從去年剛開始加入ThoughtWorks，對敏捷懵懂了解，到如今隨着經歷的增多，對敏捷的瞭解也有了愈來愈多的體會。即時驗收是敏捷中很小、很容易被人忽視的實踐，甚至不少人都不知道。但我參加了幾個項目以後，愈來愈體會到了即時驗收的重要性：每當項目中的bug數量明顯增多，我都會提醒本身以及團隊：是否是忽略了BA sign off這一環節？

 

敏捷軟件開發相對於傳統軟件開發過程，在生產效率、 項目質量、成本控制等方面均有不一樣程度的改進與創新。這得益於敏捷開發方法中許多好的實踐，僅技術相關的最佳實踐就有結對編程、測試驅動開發、持續重構與 持續集成等。這些實踐能夠提升代碼質量、提升生產效率，並最終提升項目按時交付的成功率。敏捷實踐中還有另一個比較好的實踐──即時驗收，它能夠儘早檢 驗代碼實現與業務需求是否契合並能協助及時發現、修復並驗證bug，從而有效地提升開發效率、保證質量。

什麼是即時驗收 
即時驗收也叫BA signoff，是指迭代開發過程當中，每一個story開發完成之後，開發人員並不立刻開發下一個story，而是由BA快速驗收測試。若是驗收時發現了明顯的bug，或者驗收條件沒有達到，開發人員能夠當即進行修改。如此反覆，直到BA驗收經過爲止。
具體說來，其通常步驟包括：  
1.開發人員初步完成story的開發；
2.BA在開發環境進行驗收；
3.在BA的快速驗收過程當中，若是發現明顯bug或代碼實現沒有徹底覆蓋story中的所有業務邏輯，則開發人員當即修改代碼以修復bug、補全業務邏輯。從新從步驟1開始；
4.在BA的快速驗收過程當中，若是沒有發現bug，則開發人員能夠提交代碼，認爲此story開發完成，進入迭代中的下一步驟：產品環境中的測試。
在即時驗收過程當中，特別強調簡單和快速：一是驗收直接在開發機器上進行，不須要搭建產品環境；二是BA不須要測試每個細節，而只關注於story的基本功 能是否實現、開發人員是否無心中漏掉了某些狀況、寫入story中的驗收條件是否所有知足等問題。除此以外，若是發現一些沒有寫入story中的業務邏 輯，也能夠由BA和開發人員甚至客戶討論是否修改。
通常來講，即時驗收花費幾分鐘到十幾分鐘的時間便可完成。

即時驗收與QA測試的區別 
即時驗收強調的是簡單和快速，這是爲了與QA的測試區分開來，由於它並不能取代QA的測試，而是對QA測試的一個有益補充。從實踐上來看，它與QA測試的區別在於：
1.即時驗收是在開發者的機器上（也即開發環境下）進行，而不須要從新部署測試環境（即模擬的生產環境）；
2.BA不須要準備測試用例以及複雜的測試數據，只需經過鼠標點擊或其它簡單的方式驗收。而QA通常須要準備詳細複雜的測試用例以及完備的測試數據，按照測試用例的步驟測試；
3.BA發現問題以後，不須要建立bug，直接由開發人員修復。而QA測試通常須要建立bug，經過bug跟蹤管理系統進行修復、驗證與關閉；
4.從時間上來講，即時驗收是在story剛剛開發完成之後當即進行，能夠當即收到BA做爲用戶業務表明的質量反饋。而QA通常會有本身的測試計劃，測試會比story的開發完成滯後必定的時間段，反饋也會較慢。

爲何採用即時驗收 
那麼，採用即時驗收有什麼好處呢？
1.充分發揮了BA對story的業務理解與把握。通常狀況下，BA對story瞭解的更全面、更接近於真實用戶。BA能夠從業務用戶表明的角度對story進行驗收，利於檢驗代碼實現是否契合業務需求；
2. 即時驗收使得反饋更及時。傳統軟件開發中，極可能在項目完成之後才能收到客戶的反饋，而這時的反饋對開發人員的代碼修改來講每每是費時而致命的。敏捷採用 迭代式開發，每次迭代均可以有可運行的產品讓客戶體驗，並根據用戶反饋進行及時修改。而即時驗收讓反饋更及時，頻率更高。若是開發現場有客戶合做而且願意 協助進行即時驗收，那麼用戶反饋的效果更好；
3.以最低的成本儘早發現並修復bug。在開發過程當中發現的bug是最容易修復的，由於此時代碼的邏 輯對開發人員來講新鮮而清晰。及時驗收中BA不須要部署測試環境，也不須要像QA同樣經過bug跟蹤系統建立bug，包括錄入複雜的bug主題、重現步驟 以及優先級等。開發人員當時就能明確bug的所在，不須要根據描述重現bug或找QA確認bug。這不只僅節省了大量時間和人力，也儘早發現了潛在的 bug，並以最低的成本修復，確保了QA在產品環境下測試的代碼的基本功能與質量；
4.可以提升代碼質量和開發效率。BA的即時驗收與QA的測試，雙重保證了發現問題和bug，從而有效提升代碼質量。經過提早發現並修復bug，減小了後期QA測試階段發現的bug量，能夠減小陷入開發-測試發現bug-修復bug-再測試-再修復的糟糕循環的概率。
即時驗收的以上優勢，充分體現了它在敏捷開發過程當中的重要性。固然，即時驗收也有一些問題須要注意：
首先就是把握好尺度。每一個story完成之後，能夠花費幾分鐘到十幾分鍾進行即時驗收。從花費的成本與得到的收益來講，是徹底值得的。可是若是即時驗收花費的時間過長，反而形成時間和人力成本太高，可謂過猶不及。
其次，即時驗收不是BA一我的的事情，須要開發人員的支持和配合。雙方一塊兒驗收，一塊兒討論交流，會使得驗收過程更加順利並能發現更多bug。
除此以外，分佈式團隊如何使用即時驗收？每一邊的分佈式團隊最好擁有本身這邊的BA（事實上絕大多數的分佈式團隊都有本身這方的BA），保證每一個story開發完成之後，均可以進行即時驗收。
即時驗收在實際項目中的應用介紹

結論 
即時驗收做爲敏捷開發過程的一個重要實踐，對提升敏捷開發效率有重要的做用。可是在實際的敏捷開發的實踐過程當中，有的團隊爲了節省時間，有意無心間忽視了這一最佳實踐。
即時驗收的本質是投入儘量低的成本，收到儘量快的反饋，儘早的發現並修復bug，從而達到提升生產效率、保證產品質量的目的。但願全部的敏捷團隊都能嘗試或者堅持（若是已經在使用）這一實踐，體驗即時驗收給項目帶來的好處。