1、需求沟通——避免过早精细化
做业务的人和写程序的人都容易过早进行精细化。
首先，业务方还没有启动项目，就要精确知道最后能做到什么；开发人员还没评估整个项目，就希望精确知道要交付什么。很多时候，落实在纸上的需求和最终真正做出来的也是不一样的。每次向业务方展示系统运行情况时，他们就获得了比之前更多的信息，这些信息反过来又会影响他们对整个系统的看法。业务需求在任何阶段都可能发生变化，这就是“不确定原则”。
其次，写程序的人即使拥有全面准确的信息，评估也通常会存在变数，再加上“不确定原则”，需求是一定会变化的，所以追求那种精确性是徒劳的。所以评估可以，必须基于不那么精确的需求，而且评估只是评估而已。
避免过早精细化的办法就是尽可能推迟精细化，但开发人员需要在开发的前一刻把需求具体化。
2、验收测试
验收测试不是单元测试。单元测试是程序员写的，描述底层结构及代码的行为；验收测试是业务方和QA写的，描述了业务方认为系统应该如何运行。单元测试深入在系统内部，调用特定类的方法；验收测试则是在系统外部，通过API或者UI进行。
手动测试成本高，所以验收测试应该采用自动测试。
3、持续集成
务必保证持续集成系统中，单元测试和验收测试每天都要运行好几次。整套持续集成系统应该由源码管理系统来触发，只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试，测试结果会用电子邮件发送给团队所有人。
