1、需求溝通——避免過早精細化
做業務的人和寫程序的人都容易過早進行精細化。
首先，業務方還沒有啓動項目，就要精確知道最後能做到什麼；開發人員還沒評估整個項目，就希望精確知道要交付什麼。很多時候，落實在紙上的需求和最終真正做出來的也是不一樣的。每次向業務方展示系統運行情況時，他們就獲得了比之前更多的信息，這些信息反過來又會影響他們對整個系統的看法。業務需求在任何階段都可能發生變化，這就是“不確定原則”。
其次，寫程序的人即使擁有全面準確的信息，評估也通常會存在變數，再加上“不確定原則”，需求是一定會變化的，所以追求那種精確性是徒勞的。所以評估可以，必須基於不那麼精確的需求，而且評估只是評估而已。
避免過早精細化的辦法就是儘可能推遲精細化，但開發人員需要在開發的前一刻把需求具體化。
2、驗收測試
驗收測試不是單元測試。單元測試是程序員寫的，描述底層結構及代碼的行爲；驗收測試是業務方和QA寫的，描述了業務方認爲系統應該如何運行。單元測試深入在系統內部，調用特定類的方法；驗收測試則是在系統外部，通過API或者UI進行。
手動測試成本高，所以驗收測試應該採用自動測試。
3、持續集成
務必保證持續集成系統中，單元測試和驗收測試每天都要運行好幾次。整套持續集成系統應該由源碼管理系統來觸發，只要有人提交了代碼，持續集成系統就會開始構建，並運行所有的測試，測試結果會用電子郵件發送給團隊所有人。