从CMMI的角度来看，怎么去控制需求变更对当前阶段开发工作产生的影响?

在软件项目开发的过程中，软件的需求变更是一个回避不了的问题，对其处理的好坏，更是决定了软件开发项目是否能够顺利、完美、高效率得到实现的关键。在开发过程中,怎么去控制需求变更时对当前阶段开发工作产生的影响？如何处理好需求这个问题，从而使客户、公司、研发人员多方达到共赢。下面，就这个关键点，结合CMMI谈谈我的一些看法。

一、必须进行需求变更管理

需求变更的出现主要是因为在项目的需求确定阶段，用户与软件项目组往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需；软件项目组以为自己清楚，但实际上他们是根据目前已知的有限了解来确定软件的具体需求。随着开发工作的不断进展，系统功能的开始展现，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色。特别是在用户已经长期使用过同类产品以后，针对一个新的测试系统，他们提的新要求就更多，需求变更因此不可避免地一次又一次出现。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目不断处于更新、待完善状态中。如果再加上没有一个完善的软件测试与发布系统，软件新的更改的质量就没法得到保证，更会让软件项目组整天处于焦头烂额中，甚至导致整个项目的失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。针对变更控制流程，通常实施需求变更管理需要遵循如下原则：

1.需求变更要有统一的归口。所有的需求变更都必须汇总到项目经理或专门负责需求变更管理的人员手中。

2.把需求分类，做个EXCEL表格，量化解决。这个需求管理表格会有下列这些项：客户名称、需求提出人、提出日期、功能模块名、客户现在版本号、需求描述、需求分类（需求、BUG）。需求描述不清晰是反复修改的罪魁祸首。对于BUG，要有错误报错整个的屏幕截图，千万不要就截那个错误消息框那么一小块。

3.对需求进行评估。一个项目中需求调研的充分与否是项目日后成败的关键要素之一。

在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。客户想要什么？要这干什么？为什么这么想？会不会有别的想法？

通过以上四步我们的目标是：搞清客户的要求，找出要求的逻辑，客户想要的结果，同时排除开发的风险，挖掘与控制潜在的要求，把客户的需求合理化，说白了就是别搞个逻辑复杂又不实用的东西出来。

4.在需求变更评估通过后，在修改需求或BUG的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改。按照模块来集中修改，你会通盘考虑所有这些需求和BUG，而不是糊窗户式的补窟窿。

5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。并妥善保存变更产生的相关文档。 

变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，建立一个简单、有效的变更控制流程，按照需求变更管理规则来实施，那么软件开发的进度、成本和质量也就有了安全的基础。

二、实施阶段性的目标管理

目标管理以制定目标为起点，以目标完成情况的考核为终结。目标管理通过专门设计的过程，将团队的整体目标逐级分解，转换为各成员的分目标。同时，目标管理是以目标的实施及完成情况的检查、奖惩为手段。其中成果考核是评定目标完成程度的标准，也是人事考核和奖评的依据。目标管理加大了对员工成果绩效的考核力度。简单点说：可能管理过程是松散的，完成目标的具体过程、途径和方法，项目经理并不过多干预，但目标成果考核是严谨的。所以，在目标管理制度下，过程监督的成分很少，但控制目标实现的能力却很强。故能降低软件开发项目的管理成本，使开发项目更易生存。

对于开发项目而言，目标管理的好处是：①目标管理对项目内易于度量和分解的目标会带来良好的绩效。例如，对于在技术上具有可分性、可量化的工作，由于责任和任务明确，因而常常能起到立竿见影的效果。②目标管理有助于改进团队的职责分工。③通过目标管理，可以明确目标优先次序。④目标管理启发了自觉，调动了各成员的主动性、积极性、创造性，强调自我控制，自我调节，将个人考核和团队利益紧密联系起来，因而提高了士气。

目标管理可以具备阶段性，并要对目标进行深度分解。一个终期目标需要由几个阶段性目标组成。这就好像驾驶飞机，需要把每一次长距离飞行任务分解成几个航程，在每一个航程预定的结束时间，检查飞机的位置、状态和航向。只有通过这种方式才能及时发现问题，进而解决问题。

好的软件是做出来的，不是改出来的。软件必须依靠具有一定水平的开发人员集中精力开发，不可能靠反复的修改来完成。软件修改次数越多，出错的可能性就越大。因此，对于一个已经累计了许多变更需求的软件。实施一个具有阶段性的目标管理，更能将软件做好。

另外，落实奖罚是激励成员实现自己所规划的分目标的最好方式。一般来说，没有人会不受到奖赏和处罚刺激的影响，这种影响所带来的是激励人员全力以赴的工作。总之，有效的奖罚能使工作更具效率，也更为成功。

总而言之，在复杂多变软件开发项目中，项目经理应该要应用和掌握高效的项目管理方法，而以目标实现为核心的目标管理就是其中一种方法。

三、以测试为核心控制软件开发过程

软件系统往往体现一定的功能，这些功能要符合一定的使用目的。现实世界是在不断变化的，而且变化的速度是越来越快，唯一不变的就是变化的主题。这一现实也就直接影响到了实现实际功能的软件系统，体现在需求、技术实现手段、应用环境等多个方面，这些都直接影响到了软件系统自身的稳定性。如何让软件系统在不断的改进中依然表现完美，以测试为核心控制软件开发过程，是一不可缺少的环节。

测试的主要任务是控制开发人员随意提交低质量的程序。例如：在测试中有个定义叫返回，意思是当开发人员提交了问题过多的程序后，测试人员可以不用告知程序中的问题，直接返回程序要求开发人员重新修改。这样既控制了被提交程序的质量，也使测试人员把工作重点从寻找简单的低级错误，转移到寻找程序中复杂的逻辑错误。坚决反对测试人员是帮助程序人员发现问题的说法，而应该强调测试人员是站在一个更高的管理控制层面上。

在这里给一个与测试相关的建议：重视设计复查和代码复查。

很多程序员习惯于这样一种工作方式：只做不想。他们更关心每天可以写多少行代码,完成几个模块。在这种态度下，他们都很不愿意复查自己的工作，而习惯于在软件测试阶段把隐藏的错误改正过来。但设计复查和代码复查在大型的软件项目中已经有30年的应用历史，而且已经被证明在设计和代码编写阶段的复查比软件测试更能有效的消除错误。一些经验数据表明，在设计和代码复查时发现的错误是在同等工作量下软件测试发现的错误的两倍。

四、建立一个完善的、快捷的版本更新机制

有些行业客户，需要你在实施过程中就修改需求定制化软件，非要按照他们的习惯做才肯用，自然更新版本不断。

而客户端一多，自然更新一次就非常累。而且哪个更新了哪个忘了更新，更新的版本一致不一致，都会引起各种问题。所以，为了更新，咱们可以直接在软件中集成同步更新功能。客户端软件一启动的时候，先自动监测服务器上的版本一致不一致，如果不一致，就自动更新同步服务器上的软件文件。这样可以达到下面的目标：有的客户还没有发现那个BUG的时候，就已经被我们更新了。从而提高用户的满意度。

所有的管理方法，实施起来最终只有一个目的：做出好软件。

需求跟踪矩阵的具体使用方法是什么？当前大多的需求跟踪矩阵是从某个子需求关联到各个文档中的某模块（或者某章节）、代码行等，像这样比较难以操作，有没有更好的、相对简单的操作方法？

需求跟踪矩阵的作用

系统研发的困难在于其未知性，未知带来的麻烦在于任何结果，事实上都不可能在工作开始时被明确界定与理解，这就是为什么任何行业的研发工作实际上都十分强调验证与确认工作的主要原因，你必须对之前的假设做最终的确认。

如果某项未知性工作非常短促，则整个工作过程中的概念就得以保留在人们的大脑里，形成完整的概念图谱；但如果工作规模大、周期长，则概念极易丢失。在进行各种验证与确认工作时，实则再也无人可承担这份工作。

需求跟踪矩阵的目的便在于此：

1.作为各个环节的负责人沟通的桥梁；

2.作为一根线条将概念与最终的实现串联在一起；

3.作为一种检验的手段，确认需求是否被实现（虽然不能保证没有错误）。

需求跟踪矩阵的有效使用原则

关于如何使用需求跟踪矩阵，一成不变的方法是不存在的，一旦我们理解了需求矩阵作为一种方法所要达到的目的后，我们就能理解：

1.不同的项目类型，需求矩阵所要跟踪的内容项不尽相同。

如，在绝大多数的信息系统中，由于其实现主要是由大量Class和Interface组成，考虑到高内聚低耦合的原则，需求矩阵只要关联到相关的Class就可以了（哪一个Class对应了某一个需求的实现）。

考虑到，不是所有的代码都能写的那么完美，适当的跟踪到某一个Class的某一个Function或者Method也是可行的，但是如果大多数都要跟踪到这个级别，实际上已经反映出系统的设计存在问题。因为一个Class原则上所承载的功能应该是相当内聚的。

2.跟踪的颗粒度到达某个功能进入的入口即可。

实际的软件系统，一个功能的实现往往是通过众多的Class、Interface、Method等的互相调用来完成的。考虑到大多数程序工程师都更乐意直接去理解代码，因此作为一种良好的沟通工具，需求矩阵维护了系统功能所对应的代码的起始入口，从而使得每个功能的代码从哪里开始变得清晰明了，没有歧义。

3.跟踪需要注意成本效益原则。

对于那些通用模块，如基础Class、通用Method等，依据项目实际情况，如果这些它们是十分重要且意义重大的，则可列入特殊跟踪；否则，在大多数情况下，是没有必要去跟踪的。。

以上三者是有效使用需求跟踪矩阵的原则和要点。在需求跟踪矩阵的实际运用过程中，实效性是异常重要的原则，不应为了跟踪而跟踪，而应该将这些信息作为系统的重要资产，只有对系统的设计、开发等工作意义重大的才予以追踪，从实际需求出发也是CMMI过程改进的一贯出发点。

软件测试力度不够，没有发现软件缺陷，造成返工怎么办？

此问题必须分成3个现象来看，一个是测试力度不足；一个是缺陷遗漏严重；最后一个是返工多。在此我对这些现象比较困惑的是其之间是否存在必然的因果关系。即：是否因为测试力度不足导致缺陷遗漏严重，又因为缺陷遗漏造成了返工多。我先假设这个逻辑成立，那么必须要解决的就是测试力度不足的问题了。

测试力度不足，又存在4个最常见的现象：测试人员不足；测试深度不足；测试技能不足；测试时间不足。由于我不知您所指具体现象。因此只能依次简单看：测试深度不足，往往由于测试人员技能不足，或者业务理解不够，且以后者可能性更大。如果是业务理解能力不足，那必须在测试之前，开展有效的需求培训，此需求培训必须达到这样的效果：测试人员能够很好的理解此系统，能够描述系统功能间的逻辑关系、业务流程顺序、业务目的性。如果测试人员无法有效理解，那么肯定无法深入测试软件系统。而如果是测试技能不足，那就只能加强技能培训了。对于测试人员不足和测试时间不足，如果前两点无法改变，那只能采取抓大放小的方式进行，即：对于测试进行分级，有效解决客户经常使用的、客户业务核心两方面功能的测试，而对于其他方面的测试，保证其基本的正确性即可。对于测试人员的增加，大忌在项目测试进度不足的情况下，盲目添加人员，对于人力资源的使用，一定要在项目开始前有效规划。即使必须紧急临时添加，也必须保证添加人员对于业务的理解到位，再进入项目组，否则只能是更多的缺陷遗漏，而这些遗漏又会随着进度推进被暂时掩盖。

以上的回答全部基于3个现象的基本推理，如果要得到较为准确的解决策略甚至于方案，可联系我公司安排CMMI过程改进咨询师对贵公司进行诊断。