Masterpiece

    项目完成以后回顾了一下项目中的问题，列举如下：
    1.项目中有的时候PM提出了改进意见或者添加了新的需求，或者客户的反馈要求一些改进，这些情况的发生以及协调没有任何流程以及记录，从而导致了变更没有通知到该通知的人，如QA根本就不知道有这样的变更。
    2.变更的审批流程不明确，基本上是口头达成一致，并没有做出审批流程以及审批过程的文档记录，没有记录也就没有跟踪。
    3.变更的分析以及权衡，变更的影响只做了沟通，而没有任何记录，这也就不会对以后再做类似变更的时候提供参考，也就是没有实现项目管理经验的知识化。
    4.变更没有记录也就没有分类，没有统计的功能。
    ....等等等等，其实还有很多的问题，其实归根结底，我们并没有对变更管理有一个统一的流程设计和管理办法，所以导致这一切都是这么的混乱，今天看了一点资料，写下自己的一些改进建议：
    总的来说，变更管理可以分为以下几个管理点：
    1.变更管理的定义，优先级别定义以及分类定义。
    2.变更管理的流程设计（包括流程中的角色，以及各类变更的流程上的角色责任矩阵）
    3.变更管理记录设计与管理
    其流程也依次为：根据变更管理优先级别以及分类的定义，设计出各种分类，各种优先级别变更的审批流程，设计流程过程中要考虑各种分类的变更的特殊性，比如紧急变更的处理就不能太烦琐，一般变更的处理就应该精简，而对于影响大的变更就应该慎重且审批流程要严格，并做记录。在流程中各个变更管理角色的职责矩阵的定义也很重要，如下图；
   
   

    在上一篇The first glance of Template Method Pattern中我提到了用模板方法模式来重构以前写过的代码，在看到 田春峰 的留言后，我重新审视了一下自己的代码，到底用策略模式呢，还是模板方法呢？她们之间有没有共性可以抽取出来？
    从策略模式的定义中可以看出，策略模式是对一组相似算法的包装，使得算法的实现与算法使用环境相隔离，在父类中提供算法的统一接口以供环境对象Context调用，以最瘦小的策略模式实现来说实际上是不满足我的需求的，因为我的算法中还包含更多的子操作、子流程，而这些流程又很相象，她们的调用逻辑框架也是相象的，怎么办？把这些逻辑直接写在Common接口中？重构逻辑？将子逻辑独立出来给出统一定义并由子类实现？呵呵！越说越象Template Pattern了。
    那么我们就把The first glance of Template Method Pattern中的代码重新构造一下：
   

实际上从代码中可以看出，从整体结构上讲应该算是策略模式的应用，实现了策略实现与环境的分离，由环境决定采用什么策略（当然这也是策略模式的一个缺点，环境必须知道所有的策略，并知道应该用什么策略），但从策略的统一接口来说又可以说是一个模板方法，不知道把这个运用说成是策略模式和模板方法的结合是否牵强？
    其实归根结底，在这两种模式的运用中最原始的东西是什么？正如 idior在他的再谈多态 中所讲的一样，是多态的运用。