1. 明确范围
- 如果说要把整个项目（假设持续2个月，分为4次迭代）的范围，在一开始就明确下来，对我们、对客户都很困难，因而这个期望不太现实；更可行的办法是把范围的明确，也拆分成更小的单位，譬如按照每个迭代（每两周）来明确；我们双方只要保证，对这两周要提交的内容，有明确的共同认识即可；然后不断循环；
- 明确下来的范围，要有个Task List或者Plan来作为以后判断是否发生范围改变的依据；
2. 范围变更
- 如上所述，如果每两周一个迭代，每次迭代都有明确的Task List或Plan；那么在这个过程中，任何不在这个List和Plan中的任务，都可以视为需求变更、范围变化；
- 这种变更，需要在客户刚提出来时，就进行评估，明确告诉客户这个改变所需要的额外时间，必要时，要协商延后当前版本的提交日期Timeline；
- 同时，在平时要注意把这类小变更记录起来，免得以后说不清楚哪些是变更，哪些是初始的要求；
3. 提交版本
- 如果跟客户约定在每个迭代结束时提交版本，那就相当于每次提交都跟客户商量了一个明确的提交日期；这样就不会太被动；当然如果客户觉得这个频率有问题，也可以改为每周提交一次或者每周两次提交；无论是哪种情况，都可以事先商量好，做好对应的计划和时间安排；这样就可以避免仓促提交的现象；
- 提交版本之前，内部一定要留些时间，譬如1天2天做为内部测试和修改Bug的时间；必须内部通过了才提交给客户；这个是最基本的质量保证流程；
4. 质量
- 开发人员自测是最基础的；如果测试人员得到的版本是不可测的，一看就有很多明显的Bug；通常会要求测试人员直接打回给开发人员重测； 只有过了自己这一关，下一个环节的工作才有意义；
- 如果开发人员的自测实在不知道如何才能改进，那么可以让测试人员跟其结对，一起测试；这样就能学到一些测试人员的测试方法和技术；帮助开发人员提高自测水平，在后期也可以节省整个团队的时间；
- 对于经常出现的Bug，开发人员一定要进行分析总结，看看哪类Bug是自己最常犯的错误，得到经验以后采取措施避免；