软件开发（整体）项目管理的注意事项

申请免费试用、咨询电话：400-8352-114

引言：软件行业从20世纪60年代开始操作系统的研发，到20世纪90年代中期行业快速发展。从原有的作坊式开发到目前团队协作完成，从早期的技术力量竞争到现有的项目成本控制竞争，从面向结构到面向对象再到面向服务架构，项目管理被提到一定的高度，如何有效的经营项目来降低风险、控制成本，确保项目进度流畅，在有效的时间内保质、保量的完成验收。成为不少项目管理人士的追求目标。结合个人项目管理实践，本人有几点管理注意事项与大家一起分享。 
　　开发模型确定 
　　一个项目的好坏，开发模型优良是项目成功重要保障，有了好的开发模型我们可以很好的控制项目进度、降低风险。所以我们在项目开始前首先需要确定项目的开发模型。这里我们建议采用迭代式的开发模型。我们知道原有早期传统的开发模型是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务后才能够进入下一个阶段。项目开始首先完成系统需求规格说明书，之后才能够进入概要设计阶段，编码则在系统设计完成之后进行。这就意味着只有当所有的系统模块全部开发完成之后，我们才进行系统集成，对于一个由很多个模块组的复杂系统来说，这是一个非常艰巨而漫长的工作，且存在着潜在的风险。 
　　如：需求或者设计中的错误无法在项目早期发现，只有在系统交付客户之后才能发现原先对于需求的理解是错误的，系统设计的错误也只有在测试阶段才能被发现。 
　　软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支。 
　　项目管理人员专注于文档的完成和审核来估计项目的进展情况所以项目经理对于项目状态的估计往往是不准确的，当他回答系统已完成了80%的开发任务时，剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。 
　　在传统的瀑布模型中，早期是无法发现，需求和设计中的问题，只有当系统第一次集成后，这些设计缺陷才会在测试中暴露出来，需求缺陷则需要等到系统与用户见面后，方可暴露。从而导致一系列的返工：重新设计、编码、测试，进而导致项目的延期和开发成本的上升。 
　　为了解决传统软件开发流程中的问题，我们建议采用迭代化的开发方法来取代瀑布模型。在瀑布模型中，我们要完成的是整个软件系统开发这个大目标。在迭代化的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动，在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包含了需求调研、软件设计、软件实现、版本集成、软件测试、软件发布和产品交付等各种类型的开发活动，迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。 
　　开发计划制定 
　　确定好项目的开发模型，一整套配套可行的项目开发计划是开发过程中进度控制的标准，同样是用户、公司管理层了解项目进展的依据。通常项目管理人员、需求人员和用户根据用户原始需求（可以是项目方案书或者是建议书），一起定义整个项目过程中的项目迭代过程个数以及每个迭代过程的开发目标和范围。 
　　如何进行迭代过程的划分和范围有效定义呢？是我们迭代开发计划制定的首要任务，我们这里推荐两种划分原则。 
　　一、用户需求至上原则，也就是根据用户需求的优先级，进行逐个模块击破，每一个迭代是用户需求一个的模块，当然模块小时或者人员充足时，也是在一个迭代中完成两个或者三个模块。 
　　二、当用户需求没有鲜明优先级时，我们可以采用功能逐步求精开发法，类似于我们早期采用快速原型开发，划分多个迭代，确定每个迭代需要达到的功能的完善层次，例如，首先第一个迭代仅完成系统的原型开发，第二迭代则紧接着完成各业务基本功能，然后逐步完善直至满足用户需求。 
　　无论怎样划分我们的迭代过程，总之需要把握一个原则，框架尽早规划，版本快速集成。项目只要进入软件实现过程早期,建议实现周版本的概念，确保一周一个版本，一来方便项目管理人员了解项目进度、质量，从而根据前期项目完成情况和近期的用户需求变动及时调整计划。二来可以尽早将系统与用户见面，及时发现对于用户需求理解不正确之处，同时还可以激发用户潜在需求，细化需求。在软件实现过程后期，则可以根据需要调整集成版本频率。所以，虽然每个迭代开发过程中的开发活动是可以选择性的裁减，但通常软件实现、版本集成和软件测试是每个迭代不可缺少的活动，否则迭代过程将失去它的含义。