菜鸟到老兵（程序员经历之5.2需求变更）

1.1      需求变更

     有人说软件开发是从古老的建筑学中走出来的，并学习了其不少思想、方法。但是软件的开发要比建筑学来的不明确、不具体，怎么说呢？建筑房子无非是钢筋、水泥、沙子、石头、砖块等材料根据力学或其他的原理合理的堆积组合而成的。建筑用的这些东西是看得到、摸得着的实实在在的东西，放在哪里还是那些东西，而构成软件的材料却是看不见、摸不到的、是抽象的，依赖于认识它的角度，在不同的系统中抽象出来的东西是不同的，这就一下子将软件开发中使用的“材料”增加了一个很高的认识难度。软件领域里尽管很想搞出一些无形零件，组装起来就能变身为满足各种要求的软件成品，但至少目前不是很理想，偶尔有做的比较好的也是在某一个特定的领域里，估计要造一个放在各个领域都能使用的零件的话，规格也不好定，为什么呢？原因可能是即便是同一个事物在不同的领域里的抽象角度也是不同的，比如说：手机吧，在手机销售的系统中关心的是品牌、电池容量、颜色、声音和铉、价格、是否双卡双待等功能性和方便性；而在手机生产系统中的抽象角度应该关注在材料、芯片、模具等其他的元素了；或许在其他的系统中手机由于个大、沉重而被抽象成防身用的武器了呢。再比如吧：银行系统对客户的姓名、收入情况感兴趣，而对于他的鞋子的尺寸和脚的大小不感兴趣，那是鞋子销售系统应该关心的事情，同样是一客户在不同的系统中却得到了不同的抽象元素。你说了，我考虑到所有的抽象角度来定义一个通用的手机的一个零件。先抛下不可能的因素，即便成功了，那么对不起，针对单一的系统来说，由于抽象过量造成系统增加了不必要的信息而可能复杂了。我们常说面向对象，将现实中的实物抽象成软件系统中的对象，这里更多讲究的是抽象的角度，同一个事物在不同的系统中认识的角度是不同的，如果角度选择错误了，后续的很多工作做起来很是别扭，甚至偏离方向。如果客户花钱买了的东西还感觉到别扭，提出一些变更，谁有理由怪他们呢。

     这里其实还有另外一个意思，客户花钱要买一个系统，可能他自己都不知道这个系统是什么样子的，客户的脑子里有自己想象的一个系统的样子，做系统的人的脑袋里同样也有一个系统的样子，那么这两个“样子”是不是一样的呢？如果做系统的也不及时的告诉他，像个宝似的捂着，等系统都做好了再拿给客户看，客户确实吓了一跳，不过跳的是和他想象的“样子”完全不符合。不管采用什么方法，将系统是什么样子的尽早的告诉客户，就可能将变更在早期进行，减少风险和成本。很多的时候客户真正的需求是从他看到系统的样子才开始的。

既然软件注定是“软”的、多变的，变化也就越来越被作为一个事实被更多的人接受了，并想法设法的去适应这种不可预知的“变化”，将因变化造成的伤害减到最低，甚至有的过程思想还提出拥抱变化，让变化来的更猛烈些吧。

****************************

    小菜这段时间所在的项目是个称之为“2.0”的升级改造项目，为了从客户那里挖来点银子好让大家今年生活无忧，当然最重要的还是为了满足客户在新的形式下更好、更方便的开展业务，为客户创造更大的利益。利益是互相的，任何一方没有利益都不会促成要做的事情，无论是短期的还是长期的。目前项目已经接近尾声了，大点的业务需求已经都基本结束了。这天PSM王老师将大家喊在一起，告诉大家目前基本上是一个成型的版本了，今后的工作要更加细心，后期的工作重点转移到需求变更的处理上，并强调变更是不好处理的，为了不至于因为变更造成错误问题，要求大家按照两种方式进行：

        1、“半结对编程”的方法。

        2、所有的变更都要经过CCB的评审。

    小菜知道有个“结对编程”的方法，讲究的是对于一段代码的编写任务两个人同时进行，一个人敲键盘写代码，另一个人看，看到人能检测到写代码的人的代码的完整性，保证代码没有漏洞，逻辑的、合理性的、功能性的问题等。那么“半结对编程”是怎么回事呢？后来小菜了解到是这样的：编码的工作还是由一个人单独完成，完成后的代码交给另外一个人进行代码走读（Review），为了防止Review的人敷衍了事，如果这段代码出现问题，同时追究两个人的责任。小菜觉得这种方式对代码Review的人的要求比较高，果然这类Review的人基本都是那批戴的帽子比较多的“需求分析设计人员”，原先小菜一直觉得部分人出方案还行，编写代码不怎么地，通过这次“半结对编程”的实施，小菜的想法改变了，原来这部分人也有编码的高手啊，并且有的思想也挺高的，很多的时候都能给出代码不合理的地方，给出点重构的意见。

谈到CCB（Change Control Board变更控制委员会），很多的项目团体处理需求变更的时候都有这个组织，小菜在一些书上也看到过，知道这个小组的作用是什么，虽然大家都知道这个小组的作用，但是具体的实施却是各有不同的，适合的就是合理的。2.0的需求变更分两种情况：客户提出的变更、开发人员自发提出的变更。

1、   客户提出的变更申请，此时的处理流程是这样子的：

1)         客户提出需求变更，提交给PSM。这里PSM做的是否有点多呢？可以交给配置管理员做吗？估计可能是PSM对业务较熟悉，能从客户提出的变更里获得更多的信息吧。

2)         PSM记录到需求变更文档中，并提交给CCB。

3)         CCB对变更进行评审，可行性了、影响面了、负责程度了等。评审结果分两种：

1.          不通过、更新需求变更文档，给出不可行的原因。

2.          通过，指定开发人员进行代码编写。指定的代码Review人员进行代码Review。编码人员和Review人员完成后分别更新需求变更文档，

4)         通知客户最终的结果。

2、   开发人员自发提出变更（也包括设计人员的变更），这类的变更一般都是系统存在的BUG或者为了更优化程序结构提出的。其处理流程是这样的：

1)         开发人员将变更填写到需求变更文档中，并提交给CCB。

2)         CCB对变更进行评审，可行性了、影响面了、负责程度了等。评审结果分两种：

1.          不通过、更新需求变更文档，给出不可行的原因。

2.          通过，指定开发人员进行代码编写。指定的代码Review人员进行代码Review。编码人员和Review人员完成后分别更新需求变更文档，如果涉及到客户操作性和体现元素类的变更要通知用户的，用户如果建议不改，那么也就终止了。

3)         通知客户最终的结果，通知客户这块是有选择性的，并不是所有的变更都通知客户，对于客户接触到的页面啦什么的肯定要通知客户，否则你私下改了用户还不知道，可就麻烦了。如果是后台逻辑代码重构之类的改动，就不要通知客户了，一个原因是他们不关注这些，再一个原因就是可能会引起他们对系统稳健性的怀疑：怎么总是改动呢？是不是还存在很多问题呢？别让客户引起猜测而失去对系统的信心。

    这里的CCB成员有十来个，一般是各个模块的负责人，一个变更有可能引起几个相关模块的改动，模块负责人就是要看一下变更是否对自己的模块有影响并安排相关的人员进行对应。测试负责人、系统架构师、PSM、某个关心项目的领导、一般还有个配置管理员，告诉大家文档在哪里了，什么角色的人应该填写哪些。看情形是否还包括客户，有的变更是客户提出的，有的涉及到客户看到的内容的都要通知到客户的。

友情提示： 1.          “半结对编程”的方法，保障释放的代码更准确。 2.          CCB的作用，如果一个项目成立了这样的小组，并规定了一个做事的流程，最好这么做。 3.          如果觉得哪里需要修改，如果没有CCB这样的小组，至少要告知模块负责人，你的考虑可能是欠缺的，其他的相关的模块没有考虑到。千万不要以为改动很小而偷偷的改了。