时被广泛应用，在此情况下，客户的参与也非常关键。皮尤认为：“使用应用程序快速开发法时，通常没有足够的时间或知识来创建一份详细需求说明书。最终产品可能基于在开发过程中学习到的东西。既然需求不确定，那么开发人员和客户必须一起工作来开发产品。”
汤普森认为快速开发法本身很少能导致工作更快地完成。相反，产生最大价值的那部分系统的开发工作会更加高效。他说：“我想，当人们把快速开发作为一项技术实践来对待时，他们误会了关键问题。如果你揭开快速开发背后的故事，开发的重点在于将工作的耗时固定，然后控制范围以适应固定的时间。通过理解整体规划和自己的工作如何融入整体，上述说法可以实现，此外，还要进行经常性地沟通，当威胁到时间的事务发生时，设定期望值亦为必要。”
快速开发的成功可以部分地归功于开发团队的小型化，开发人员和客户在同一地点工作并关注于手头的事情，这样会自然而然地将沟通的挑战减至最小。
谨慎但不乏灵活地规划和开发
像需求规范、架构规范和详细设计等工作成果用来记录复杂的思想，这样它们可以经过评审以确保明确一致，然后会被提上议案讨论。当进度的高压导致工作内容不明确时，误解会蜂拥而至。
为了避免返工，开发人员应顶住压力以完成那些相对简单的部分直到整体规划得以清晰定义。罗伯特·卢如是说，他是萨克拉门托市的加州政府的一名程序开发经理。卢描述了最近的一个开端困难的项目，此项目目的是通过互联网提交客户数据，他解释道：“我们获得的最重要的经验是尽早的开始着手开发架构规范，这样，此后划分系统时，人们会清楚各部分之间的相互关联。”
这需要训练，很重要的问题是，在开始时花时间记录那些在开发流程和交付物的质量标准上达成的共识，并且在质量标准被准确无误的达成之前抵制住宣称“完成”交付物的诱惑。
Sapient公司的格雷厄姆·奥克斯领导了成功的快速开发项目的同时，对沟通和计划做出了正确的决定。为了取得成功，他给出如下建议：
结构化的计划。只有当一份完善的计划存在时，每日的进展汇报才会有比对的标准。状态周报需要有完整定义的结构，这样可以迅速的完成周报而不致遗漏要点。
高透明度。Sapient采用了项目作战室来确保所有计划的高透明度和可获得性，包括高层计划、中层计划、每日计划、风险列表、项目总目标、标注了负责人和时限的待完成事项列表和进度度量标准。
频繁但简短的沟通。Sapient每天会有站立进行的进展会议，这种会议不会超过15分钟，每位与会成员针对每日计划来汇报进展。
清晰、公认的目标。人们在不工作时会做出很多决定，但他们必须知道他们自己的项目难题如何影响整体目标。
一项最有挑战性的沟通问题是创建和维持关键干系人和项目发起人对开发流程的共识。在开发过程中提供可见的和易理解的里程碑是个关键，这样发起人和干系人会对进展有所了解。这些方法有助于管理他们的期望并有利于事务和进展的沟通。
团队如是说
以下提及的是有助于促进沟通的团队组织和管理的一些基本指导：
保持团队小型化。针对完善定义的子系统工作的四到五名成员的规模能够促进沟通。
迅速处理问题型员工。那些不能或不愿成为团队一部分的成员会迅速地造成比他们本身价值浪费多很多的士气问题。
避免使用兼职人员。与其他项目共享人员会使成员同时兼顾太多的工作，而两个项目都会遇到问题。尝试获取项目所需要的全职员工。
避免通过添加开发人员来解决进度问题。如果项目落后于进度目标，不要试图向现有团队加人。团队重新定位和吸收新成员的代价很少会带来短期的进度跟进。
安排团队的座位。开发团队要设置在同一座建筑物、同一层、同一区域
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
