迭代过程个数和范围确定后，则需要与每个迭代过程中的开发活动相关者协商讨论进度安排，先明确各开发活动的起始、截至时间，然后在根据开发活动的具体需求进行任务细化。如果希望能将项目进度控制在计划之中，任务越细越好，每个任务跨度不要太大，一天一个任务最好。当然这种情况是很能实现的。确实，我这里说的是一种比较理想的情况，但并不是不可能。在这里我们就可以了解到迭代开发计划给我们带来的好处。项目开始了需求通常都是很泛，不太明确。与用户交流，可能他认为自己已经表达了所有需要。实际也许他确实已经充分描述了他所知道的需求(业务需求)，但完善我们的系统，除了基本业务需求外还有很多非功能性需求，比如：系统性能需求、界面显示需求、系统操作流程需求等等，尤其是目前B/S架构的开发模式，界面需求已经越显示出它的重要性。而这些需求在项目早期，在没有任何可见事务的情况下，用户很难意识到它的重要性。

　　我们只有逐个迭代的细化，每一个迭代过程完成既是需求进一步细化的依据又是一个新系统的开始，每个迭代开始前都要根据上个迭代的成果和所要达到的阶段性目标细化定制。

　　组内成员配置

　　项目启动之前除项目管理者着手计划制定外，同时也需要对其项目组那成员配置进行规划，界定其职责。通常我们需要几种角色：

　　技术组长：负责技术难题攻关，组间沟通协调。

　　需求人员：负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化。

　　设计人员：负责对需求规格说明书，进行系统设计。

　　开发人员：实现设计，完成用户功能。

　　集成人员：负责整套系统的编译集成，督促小组系统功能提交，及时发现各模块集成问题，起到各小组之间的沟通的纽带。

　　测试人员：对于集成人员集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计。

　　文档整理人员：负责对小组内产生文档的整合，统一。

　　系统环境人员：负责系统编译环境、运行环境规划。编制系统环境说明书。

　　维护人员：系统验收后，维护人员，建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。

　　项目组启动初期需求人员首先根据迭代计划第一个迭代计划进行需求调研编制功能需求规格说明书，通过项目下到工序人员评审后进入软件设计、编码。注意，这里需求确认并不是指项目中的整体需求，仅仅是指该迭代过程中体现的需求。整个过程类似如项目开发流程，这里只是细小流程，逐步完善，渐进提交。

　　三、项目中沟通

　　通常项目中口头沟通是最为常见的，包括项目组内部、外部沟通，这种沟通快捷、方便。一般的小问题或者是简单问题的理解非常有效，但问题复杂或是此次沟通需要后续使用，那么该种沟通则存在问题，则需要以书面方式加口头相结合最为有效。即可在本次沟通中方便、快捷的领会，也可以为后续工作提供依据。

　　通常用户对于项目进度却是有要求，不仅需要提交周计划和总结，还需要定期汇报项目的完成情况，对于即将延时的里程碑，需要提前至少三天时间提出项目延时申请。那么从这里我们可以吸取，与用户的沟通间隔除每周进行项目计划和总结外，对于用户认可的项目开发计划，需要在里程碑需要向用户汇报，对于即将延时的开发进度，尽可能早的通知用户方的项目负责人知道，方便用户方的项目负责人有准备的与其领导沟通，可以有效预防工作被动状态出现。

　　项目组内部沟通不是越多越好，你会发现当内部的沟通时间没有规律或是沟通时间过长，这样其实也会严重影响项目成员的开发进度，但沟通又是必不可少，何种间隔最为适宜了?这是不好定的，我们通常以评审作为沟通的基础，平日的沟通建议项目组成员在每天工作过程遇到问题，将其记录下来，然后在以邮件方式发送给需要沟通或者询问者。大家可以每天下班之前收取邮件，对于可以直接回答的问题则直接以邮件方式回复，对于无法直接答复而只需与提出问题者讨论的问题，则可以在第二天上班前进行商议确定。而需要众人一起讨论的问题，则放到每周会议上讨论。非常紧急的话则可以马上约齐人员讨论，通常有良好的沟通方式话，这种非

上一页  [1] [2] [3] 下一页