二、当用户需求没有鲜明优先级时，我们可以采用功能逐步求精开发法，类似于我们早期采用快速原型开发，划分多个迭代，确定每个迭代需要达到的功能的完善层次，例如，首先第一个迭代仅完成系统的原型开发，第二迭代则紧接着完成各业务基本功能，然后逐步完善直至满足用户需求。
无论怎样划分我们的迭代过程，总之需要把握一个原则，框架尽早规划，版本快速集成。项目只要进入软件实现过程早期,建议实现周版本的概念，确保一周一个版本，一来方便项目管理人员了解项目进度、质量，从而根据前期项目完成情况和近期的用户需求变动及时调整计划。二来可以尽早将系统与用户见面，及时发现对于用户需求理解不正确之处，同时还可以激发用户潜在需求，细化需求。在软件实现过程后期，则可以根据需要调整集成版本频率。所以，虽然每个迭代开发过程中的开发活动是可以选择性的裁减，但通常软件实现、版本集成和软件测试是每个迭代不可缺少的活动，否则迭代过程将失去它的含义。
迭代过程个数和范围确定后，则需要与每个迭代过程中的开发活动相关者协商讨论进度安排，先明确各开发活动的起始、截至时间，然后在根据开发活动的具体需求进行任务细化。如果希望能将项目进度控制在计划之中，任务越细越好，每个任务跨度不要太大，一天一个任务最好。当然这种情况是很能实现的。确实，我这里说的是一种比较理想的情况，但并不是不可能。在这里我们就可以了解到迭代开发计划给我们带来的好处。项目开始了需求通常都是很泛，不太明确。与用户交流，可能他认为自己已经表达了所有需要。实际也许他确实已经充分描述了他所知道的需求(业务需求)，但完善我们的系统，除了基本业务需求外还有很多非功能性需求，比如：系统性能需求、界面显示需求、系统操作流程需求等等，尤其是目前B/S架构的开发模式，界面需求已经越显示出它的重要性。而这些需求在项目早期，在没有任何可见事务的情况下，用户很难意识到它的重要性。
我们只有逐个迭代的细化，每一个迭代过程完成既是需求进一步细化的依据又是一早期，在没有任何可见事务的情况下，用户很难意识到它的重要性。我们只有逐个迭代的细化，每一个迭代过程完成既是需求进一步细化的依据又是一个新系统的开始，每个迭代开始前都要根据上个迭代的成果和所要达到的阶段性目标细化定制。
组内成员配置
项目启动之前除项目管理者着手计划制定外，同时也需要对其项目组那成员配置进行规划，界定其职责。通常我们需要几种角色：
技术组长：负责技术难题攻关，组间沟通协调。