然而我们面对这样一个现实，不完整的敏捷：需求变更频繁，项目迭代时间短，文档不完整，人员不齐全这样一个窘境。
在经过一段时间的项目经历之后，我开始思考经常遇到的问题：为什么原本做好的计划经常被打乱？为什么开始时做好的规划，在测试过程中却不能被遵守？为什么对于项目的预期往往不够？
怎样才能在各项资料并十分不完备情况下进行快速迭代开发和测试？我认为可以从如下几个方面去努力：
1、需求沟通不能被简化
在某个产品的项目周期中，我们知道需要有一个反复的需求阅读与需求确认的过程，然后会去了解开发实现，设计测试用例，准备测试计划等。但是在当我们面临的并不是一个大的或者完整的需求，而是某两个产品周期之间的突发性需求或者某个细微的需求该进时，流程在这里往往就被我忽略了，需求不再被追根问底，不再被融入到整个产品流程的思考逻辑中，“说什么是什么”就产生了！
这样的一个直接结果就是，当将这个小的需求融入到整个产品逻辑中时，出Bug了，而且往往是主路径上的问题。
因而，面对这种境况时，请不要将需求沟通的过程给简化了！
在这个过程中我们至少需要整理如下信息：
a）需求的目的是什么？
b）需求在整个产品逻辑中的位置是怎样的？
c）需求是否有判断分支？如果有，那么不同的分支所覆盖的具体需求都有哪些？
d）符合需求的数据/路径是什么？不符合需求的数据/路径是什么？
e）非产品描述中的结果是否符合产品预期？
2、做好充分的测试准备
在我们所讨论的测试过程中，测试用例同样被忽略了，我们往往是“写什么测什么”，到产品上线或者连调时会发现，怎么还有这样一个影响因素？
其实对于这种情况，测试用例或者测试大纲显得更重要了。因而如果测试人员一旦被时间，产品催着拼命往前时，对于测试检查点和影响因素的考虑往往是不充分的！那么怎么能即保证产品进度的要求，同时又兼顾质量呢？
我认为可以从如下几个方面去努力：
a）合理组织测试相关文档：你需要结构清晰的保存该任务的所有需求文档，需求沟通记录，测试计划，测试用例/大纲，测试数据，测试发现问题，测试说明文档，开发实现文档等。
b）进行完整的测试用例/大纲设计：什么时候在什么情况下谁以什么方式对谁的什么位置以何种方式进行了什么操作产生了什么结果
c）明确检查点：哪个测试对象发生了什么变化？
