需求的沟通
开发方与业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西，程序员按照自己理解的业务方表达的需求来开发。
在现实里，关于需求的沟通是极其困难的，其中会出现各种问题。
过早精细化
做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。
1、不确定原则
每次向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法，这种现象也叫观察者效应。
2、预估焦虑
开发人员会掉进精确化的陷阱。他们知道必须评估整个系统，而且通常认为需要精确评估。
评估可以而且必须基于不那么精确的需求，这些评估只是评估而已。开发人员通常会在评估中使用误差棒，这样业务方就能理解不确定性。
迟来的模糊性
避免过早精细化的办法是尽可能地推迟精细化。但是，这可能造成另一个问题：迟来的模糊性。
在具体的语境中看来，意思可能是非常清楚的，但是对阅读文档的程序员来说，意思可能截然不同。
验收测试
业务方与开发方合作编写的测试，其目的在于确定需求已经完成。
“完成”的定义
完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可。这才是完成。
沟通
验收测试的目的是沟通、澄清、精确化。
自动化
验收测试都应当自动进行。原因很简单：要考虑成本。
额外工作
验收测试是为了确定系统的各项指标符合要求。确定系统的指标；程序员才能确知“完成”；业务方才能确认开发的系统确定满足了需求；做到自动化测试。
验收测试什么时候写，由谁来写
在理想状态下，业务方和QA会协作编写验收测试，程序员来检查测试之间是否有冲突或矛盾。
但实际上，业务方通常没有时间，或者有时间也难以达到所需要的细致程序，所以他们通常会把测试交给业务分析员、QA甚至是开发人员。
业务分析员测试“正确路径”，以证明功能的业务价值。
QA测试“错误路径”、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题。
开发人员的角色
实现某项功能的代码，应该在对应的验收测试完成后开始。
测试的协商与被动推进
专业开发人员，与编写测试的人协商并改进测试是你的职责。每个人都需要关心错误和疏忽，并协力改正。
验收测试和单元测试
单元测试是程序员写给程序员的，是正式的设计文档，描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。
验收测试是业务方写给业务方的（可能会由开发者来写），是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。
图形界面及其他复杂因素
测试系统功能时，应当调用真实的API， 而不是GUI。
持续集成
务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。
在持续集成系统里，失败的集成应该视为紧急情况，也就是“立刻中止”型事件。