【IT168 技术文章】
问题的提出：笔者近几年一直从事信息系统的开发，特别是有关国家机关和企业信息系统的开发工作，取得了许多的经验和教训。其中一个深切的体会是，需求的不断变化，如果不能很好的应对，会导致整个项目的进度和质量都难以控制，最终使整个系统失败。特别是在我国，用户对于如何应用计算机软件并没有一个成熟的经验，在项目进行中用户会频繁的改变和增加各种要求。当最终完成系统的建设时，却发现企业的业务需求已经发生了很大的改变，一方面是系统的设计已经无法很好地满足新的需求，另一方面是项目周期大大超过预期，项目发生亏损。
据美国软件工程实施现状的调查，软件研发的情况也是很难预测，大约只有10%的项目能够在预定的费用和进度下交付。在商用软件产业中，这一现象尤为严重。
因此如何从软件工程的角度，通过采用适当系统设计方法和加强项目管理来解决需求不断变化的问题，是各个软件开发商的一个重要课题。通过实践，感到采用敏捷方法的基本思想和原则来设计系统和处理需求变化问题，能够产生较好的效果。
下面就从系统设计和项目管理等方面谈一下这方面的体会。
需求变化带来的问题
作为软件开发商，当接到一个项目后，一般的做法是首先由用户提出需求，然后开发商根据用户的需求作出一个系统实现方案，而用户通常并没有实质地理解方案，随即通过了方案，开始了软件的开发工作。根据笔者所开发过的多个系统，开发前期，大多数单位并没有明确的想法，也提不出确切的需求，因为业务人员不了解计算机技术是怎样实现业务流程的。用户总是希望开发单位根据当前的业务流程先做出一个样板来，然后再进行改造，而多数用户认为软件修改很容易。
尽管已经做好了系统规划，签订了功能较明确的合同，然而随着系统分析、系统设计和系统实施的进展，当客户在项目部署后看到真正的软件系统的界面及操作方式，客户的需求就被激发起来，会根据自己的对软件的理解和日常工作的习惯，对软件的处理及操作方式提出修改，而这种修改往往比较随意，因此导致开发方需要对流程、界面、以及相关文档经常的大量的修改，这些成为开发方的一个很大的负担，而这种负担对用户基本是看不见的。
用敏捷方法方法应对需求变化
1．敏捷建模（Agile Modeling）进行系统设计
软件开发过程一般是要尽早完成需求分析，停止需求的变动，将这些需求作为设计的基础，然后开始构筑系统，这是瀑布方法————基于计划的生命周期。这种方法是通过大量的前期工作来减少变化。
一旦前期工作完成，当需求变化时，这样的方法就会有很大的问题。
另外一个重要原因是，许多单位的管理模式都处在探索阶段，可能引起变动的因素很多，因此根据现行的管理模式设计出的信息系统将面临使用单位管理模式的变化的考验，包括许多的工作流程的细节处理方式式否合乎工作人员的习惯等问题。
系统在设计时要充分考虑这些不确定因素，才能适应这些变化。特别是数据结构要以系统灵活性为主，其次才是考虑系统性能的提高。
在软件开发出现工期或bug等问题时，开发人员常抱怨是由于需求的变化造成的，对于软件的修改存在抵触情绪。实际上在商业软件开发领域，需求变化是很正常的，问题是我们该怎样对待它。为了适应需求的变化，必须采取不同的设计态度。这里介绍敏捷方法的几点思想，对如何应对需求的变化很有教益。
主张简单、递增的变化、拥抱变化是敏捷建模方法的核心原则之中的三个。
敏捷建模主张当从事开发工作时，最简单的解决方案就是最好的解决方案，尽可能的保持模型的简单。
对无法在项目一开始就固化的需求进行演进型的设计。你现在不必要对这个系统进行过分的建模，只要基于现有的需求进行建模，随着项目的进行，项目环境和需求发生变化时，再来完善和重构这个系统。
递增的变化是指你不用在模型中包容所有的细节，你只要开发一个小的模型或是概要模型，打下一个基础，然后慢慢的改进模型。
敏捷建模采取不同的设计态度来“拥抱变化”。它认为需求时刻在变，人们对于需求的理解也时刻在变。随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。
对于易变的需求，敏捷方法使用了一系列实践。其核心则是迭代式开发，寻求快速的反馈，用户经历过一次或几次的迭代之后，对软件开发和业务需求如何实现已经有了形象的认识，用户提出的需求基本上可以代表他们的真实需求。这时，就可以将需求进行冻结。后面如果还有修改，将是细节的调整，不会对软件的架构产生重大的影响。
按照上述的敏捷方法的原则来设计系统，则能够使我们正确的看待用户需求的变动，从而较好的适应需求的变动。如果项目管理者和程序开发人员真正的理解并贯彻这种方法，用这种思想去管理项目，那么就能有效的避免出现项目后期软件架构混乱、补丁加补丁、系统性能大大减低的情况。
2.项目管理的作用
1）推动技术与需求“匹配”
上面提到要采用敏捷方法的迭代式开发，尽快的冻结需求，那么通过项目管理的手段，可以控制和缩短需求冻结的时间。
项目管理是一种管理手段，目的是在指定时间和资源的条件下，保质、按时地完成预定的任务。作为一个项目管理人员，必须注意有些需求的变化是由于业务与设计的“不匹配”造成的，即用户一方可能对信息系统的开发和实现方法，缺乏全面的了解，不懂得如何将传统的业务模式转换为信息系统所要求的处理模式。
另一方面，也可能开发商对用户方的需求、细节了解不充分等因素，使得用户方与开发方对工程的理解从一开始就存在着差异。因为业务人员开始提不出实际的需求来，而只是把大致的工作流程介绍一遍。而这种认识上的差异与理解的不同往往在开发初期并没有表现出来，当软件基本成型，给用户演示时，显出较大的差异。
作为开发商，过去经常将开发的注意力集中在“技术”上，即计算机软硬件、操作系统平台和数据库等技术实现上。而对于信息系统的开发，则必须首先考虑到用户的理念、方针和及其对技术方法的领会等各方面因素。往往这些因素对系统成败所起的作用，比技术实现的因素更重要。
首先，项目设计组人员要向需求方的领导及业务人员阐述信息系统是如何实现的，什么样的业务模式适合于网络，怎样处理和解决什么问题，需要在传业务模式上做哪些改进，建立基本的操作规范等等。必须明确，信息系统改变了现行的工作管理模式，使工作人员失去了一定的灵活性和随意性。如果不建立新的操作流程和规范，在传统手工处理方式上，实现信息系统是不可能的。
其次，详细的了解全盘业务流程之后，用基本用户界面原型向需求方演示和说明方案，使业务人员真正理解技术实现的思路，能够及时发现与实际不吻合或存在的困难，这样才可能从工作流程上或技术上来解决这些问题。
当出现问题时，项目管理人员应迅速分析问题，正确判断哪些问题属于不适应新的工作模式引起的，哪些问题属于操作不当引起的，哪些问题属于系统本身不完善引起的。对于那些由于不适应新的工作模式引起的问题，项目管理人员应引导使用人员迅速适应新的工作模式，必要时也要说服用户方的决策层采用行政手段推动实施；项目管理人员时刻注意取得决策层的理解与支持，帮助工作人员尽快地适应新的工作方式。
项目管理者就像是一个枢纽，由他来决定需求的分类、工作量、需求变化对现有软件的影响程度等因素，从而安排需求变更的计划――是在本次迭代中完成，还是在下一次迭代中完成。
2）开发文档的更新
软件开发文档对与软件项目来说是一个很大的工作量。很多软件项目的开发，在初期文档比较正规，随着项目的深入，特别是需求发生多次变化之后，要保持软件开发文档的一致性就感到非常困难了，因为需求改变的各种信息没有记录下来，最后不得不蒙混过关，草草了之。
但如果我们按照敏捷方法的原则，在需求冻结之前，不要过分的把精力投入到文档的制作上，而是将有关的信息记录和保留下来，在需求基本冻结之后，化一定的时间来创建和对文档进行格式化。
3）合同的考虑
尽管按照敏捷方法的原则是拥抱变化，但还是应该在签定开发合同时，一方面对项目的费用和时间估计时一定要考虑用户需求的变化，另一方面把用户需求的改动的条款写清楚，如果用户增加或改动了需求，那么软件的交付日期可以推迟，费用也应增加。这样可以限制用户的随意改动。
结束语
每个项目的开发环境及实施环境各不相同，在系统设计和项目管理方面所面临的问题不尽相同，但需求发生变化是所有项目都会遇到的问题。信息系统的建设由于会改变原有的传统工作模式，需求的内容因而会随时变动，给开发工作带来很大的难度。本文提出了应用敏捷方法的思想来应对软件开发过程中需求变化的问题，希望能对系统开发人员和项目管理人员有所帮助。
