开发模型确定

一个项目的好坏，开发模型优良是项目成功重要保障，有了好的开发模型我们可以很好的控制项目进度、降低风险。所以我们在项目开始前首先需要确定项目的开发模型。这里我们建议采用迭代式的开发模型。我们知道原有早期传统的开发模型是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务后才能够进入下一个阶段。项目开始首先完成系统需求规格说明书，之后才能够进入概要设计阶段，编码则在系统设计完成之后进行。这就意味着只有当所有的系统模块全部开发完成之后，我们才进行系统集成，对于一个由很多个模块组的复杂系统来说，这是一个非常艰巨而漫长的工作，且存在着潜在的风险。

如：需求或者设计中的错误无法在项目早期发现，只有在系统交付客户之后才能发现原先对于需求的理解是错误的，系统设计的错误也只有在测试阶段才能被发现。

对于项目风险的控制能力较弱，往往项目风险只能随着项目结束才能逐步降低，同时也只有经过系统测试之后，才能确定设计是否能够真正满足系统需求。

软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支。

项目管理人员专注于文档的完成和审核来估计项目的进展情况所以项目经理对于项目状态的估计往往是不准确的，当他回答系统已完成了80%的开发任务时，剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。

在传统的瀑布模型中，早期是无法发现，需求和设计中的问题，只有当系统第一次集成后，这些设计缺陷才会在测试中暴露出来，需求缺陷则需要等到系统与用户见面后，方可暴露。从而导致一系列的返工：重新设计、编码、测试，进而导致项目的延期和开发成本的上升。

为了解决传统软件开发流程中的问题，我们建议采用迭代化的开发方法来取代瀑布模型。在瀑布模型中，我们要完成的是整个软件系统开发这个大目标。在迭代化的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动，在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包含了需求调研、软件设计、软件实现、版本集成、软件测试、软件发布和产品交付等各种类型的开发活动，迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。

开发计划制定

确定好项目的开发模型，一整套配套可行的项目开发计划是开发过程中进度控制的标准，同样是用户、公司管理层了解项目进展的依据。通常项目管理人员、需求人员和用户根据用户原始需求（可以是项目方案书或者是建议书），一起定义整个项目过程中的项目迭代过程个数以及每个迭代过程的开发目标和范围。

如何进行迭代过程的划分和范围有效定义呢？是我们迭代开发计划制定的首要任务，我们这里推荐两种划分原则。

一、用户需求至上原则，也就是根据用户需求的优先级，进行逐个模块击破，每一个迭代是用户需求一个的模块，当然模块小时或者人员充足时，也是在一个迭代中完成两个或者三个模块。

二、当用户需求没有鲜明优先级时，我们可以采用功能逐步求精开发法，类似于我们早期采用快速原型开发，划分多个迭代，确定每个迭代需要达到的功能的完善层次，例如，首先第一个迭代仅完成系统的原型开发，第二迭代则紧接着完成各业务基本功能，然后逐步完善直至满足用户需求。

无论怎样划分我们的迭代过程，总之需要把握一个原则，框架尽早规划，版本快速集成。项目只要进入软件实现过程早期,建议实现周版本的概念，确保一周一个版本，一来方便项目管理人员了解项目进度、质量，从而根据前期项目完成情况和近期的用户需求变动及时调整计划。二来可以尽早将系统与用户见面，及时发现对于用户需求理解不正确之处，同时还可以激发用户潜在需求，细化需求。在软件实现过程后期，则可以根据需要调整集成版本频率。所以，虽然每个迭代开发过程中的开发活动是可以选择性的裁减，但通常软件实现、版本集成和软件测试是每个迭代不可缺少的活动，否则迭代过程将失去它的含义。

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

我们只有逐个迭代的细化，每一个迭代过程完成既是需求进一步细化的依据又是一早期，在没有任何可见事务的情况下，用户很难意识到它的重要性。

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

组内成员配置

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

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

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

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

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

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

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

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

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

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

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

项目中沟通

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

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

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