项目管理知识用敏捷方法应对解决用户提出的需求变化

1、用敏捷方法应对解决用户提出的需求变化问题的提出：近几年一直从事信息系统的开发，特别是有关国家机关和企 业信息系统的开发工作，取得了许多的经验和教训。其中一个深切的体会是， 需求的不断变化，如果不能很好的应对，会导致整个项目的进度和质量都难以 控制，终使整个系统失败。特别是在我国，用户对于如何应用计算机软件并没 有一个成熟的经验，在项目进行中用户会频繁的改变和增加各种要求。当终完 成系统的建设时，却发现企业的业务需求已经发生了很大的改变，一方面是系 统的设计已经无法很好地满足新的需求，另一方面是项目周期大大超过预期， 项目发生亏损。据美国软件工程实施现状的调查，软件研发的情况也是很难预测，大约只

2、 有10%的项目能够在预定的费用和进度下交付。在商用软件产业中，这一现象 尤为严重。因此如何从软件工程的角度，通过采用适当系统设计方法和加强项目管理 来解决需求不断变化的问题，是各个软件开发商的一个重要课题。通过实践， 感到采用敏捷方法的基本思想和原则来设计系统和处理需求变化问题，能够产 生较好的效果。下面就从系统设计和项目管理等方面谈一下这方面的体会。需求变化带来的问题作为软件开发商，当接到一个项目后，一般的做法是首先由用户提出需 求，然后开发商根据用户的需求作出一个系统实现方案，而用户通常并没有实 质地理解方案，随即通过了方案，开始了软件的开发工作。根据所开发过的多 个系统，开发前期，大多

3、数单位并没有明确的想法，也提不出确切的需求，因 为业务人员不了解计算机技术是怎样实现业务流程的。用户总是希望开发单位 根据当前的业务流程先做出一个样板来，然后再进行改造，而多数用户认为软 件修改很容易。尽管已经做好了系统规划，签订了功能较明确的合同，然而随着系统分 析、系统设计和系统实施的进展，当客户在项目部署后看到真正的软件系统的 界面及操作方式，客户的需求就被激发起来，会根据自己的对软件的理解和日 常工作的习惯，对软件的处理及操作方式提出修改，而这种修改往往比较随 意，因此导致开发方需要对流程、界面、以及相关文档经常的大量的修改，这 些成为开发方的一个很大的负担，而这种负担对用户基本是看不

4、见的。用敏捷方法方法应对需求变化1.敏捷建模(AgileModeling)进行系统设计软件开发过程一般是要尽早完成需求分析，停止需求的变动，将这些需求 作为设计的基础，然后开始构筑系统，这是瀑布方法 基于计划的生命周期。这种方法是通过大量的前期工作来减少变化。一旦前期工作完成，当需求变化时，这样的方法就会有很大的问题。另外一个重要原因是，许多单位的管理模式都处在探索阶段，可能引起变 动的因素很多，因此根据现行的管理模式设计出的信息系统将面临使用单位管 理模式的变化的考验，包括许多的工作流程的细节处理方式式否合乎工作人员 的习惯等问题。系统在设计时要充分考虑这些不确定因素，才能适应这些变化。特别

5、是数 据结构要以系统灵活性为主，其次才是考虑系统性能的提高。在软件开发出现工期或bug等问题时，开发人员常抱怨是由于需求的变化 造成的，对于软件的修改存在抵触情绪。实际上在商业软件开发领域，需求变化是很正常的，问题是我们该怎样对待它。为了适应需求的变化，必须采取不 同的设计态度。这里介绍敏捷方法的几点思想，对如何应对需求的变化很有教 益。主张简单、递增的变化、拥抱变化是敏捷建模方法的核心原则之中的三 个。敏捷建模主张当从事开发工作时，简单的解决方案就是的解决方案，尽可 能的保持模型的简单。对无法在项目一开始就固化的需求进行演进型的设计。你现在不必要对这 个系统进行过分的建模，只要基于现有的需求进行建模，随着项目的进行，项 目环境和需求发生变化时，再来完善和重构这个系统。递增的变化是指你不用在模型中包容所有的细节，你只要开发一个小的模 型或是概要模型，打下一个基础，然后慢慢的改进模型。敏捷建模采取不同的设计态度来 拥抱变化它认为需求时刻在变，人们 对于需求的理解也时刻在变。随着项目的进行，项目环境也在不停的变化，因 此你的开发方法必须要能够反映这种现实。对于用户的反馈，要勇于对自己的 代码进行修改，丢掉坏的代码。对于易变的需求，敏捷方法使用了一系列实践。其核心则是迭代式开发， 寻求快速的反馈，用户经历过一次或几次的迭代之后，对软件