隐喻在IT项目管理中的应用

隐喻在项目管理中的应用　 隐喻是极限编程方法学中的重要概念。但隐喻比较晦涩，它表示什么意思?在项目中如何应用?这值得我们深入探讨。

　　XP项目管理流程图。XP的分析设计比起RUP会少很多，因为每一次迭代的粒度不太大，每个阶段的分析与设计相对简单一些，并且在迭代的过程中可以逐步改进。

　　最近阅读了《代码大全》其中的一章“隐喻”，对隐喻在项目管理中的应用有了一定体会：它能够促进分析人员、设计人员、开发人员之间的沟通与对项目业务的理解。

 

　　项目规模决定规划

　　首先，软件工程是从建筑领域引申进来的，“设计模式”便是起源于建筑大师亚历山大所写的《建筑的永恒之道》一书。

　　我们可以把一个开发项目比喻成建造房子。很明显，建造摩天大厦和建造一层楼的准备工作是截然不同的。建造摩天大厦需要前期经过非常仔细的规划，比如成本核算、时间核算、设计模型、设计图纸等。因为如果前期不规划好，我们不可能建到一半推倒重建，它的成本太高了。这就是我们软件工程里面“瀑布模型”的由来。其实这和软件开发项目是一一对应的，项目也要经过类似的成本时间估算、分析模型、设计模型这些过程。

　　而建造一层楼就不同了，因为它涉及的成本更低，前期所做的规划肯定简单一些。但不管如何，必要的成本核算、时间核算、设计模型、设计图纸等前期规划还是需要的。那么再更进一步，如果想建一个狗窝，我们会去做仔细的规划吗?我想不会。在项目开发中，我们同样必须根据项目的规模大小，去衡量我们所需要做的前期规划的详细程度。

　　其次，无论建造什么房子—摩天大厦也好，一栋楼房也好，在前期核算、设计等准备工作完成以后，必须先打地基，只有扎实的地基，才能支撑起整栋房子。程序开发也同样如此。在编码构建阶段开始的时候，我们必须在CVS上先搭建好整个开发环境，确定整个系统的代码目录结构，确定接口、类、方法、参数的名称以及它们之间的交互关系。如果采用UML统一建模语言来描述，设计阶段必须产生包关系图、类关系图这两种制品。我们在编码初始阶段必须根据这两种制品产生相应的代码骨架，为接下来的构建打下坚实的基础。我们以前开发的时候就吃过这样的亏，在设计阶段和编码初始阶段，没有定义好这些程序架构，先由各程序员自行定义，后来重新定义的时候要耗费大量的人力物力进行代码迁移。因此无论是建房子还是程序开发，打地基都是相当重要的。

 

　　再次，建造房子的时候，经过前面所说的核算、设计、打地基，接下来会一层一层地建造房子，建造每一层之前我们可能会进一步细化、优化这一层的设计蓝图。这个过程就类似于软件开发过程的迭代开发，先集中精力对若干个特征或功能点进行详细设计和代码构建。这次开发完成以后，再过渡到另外的若干个功能点，形成一次一次的迭代。

　　迭代粒度的奥秘

　　从上面可以看到，迭代对软件开发来讲是非常重要的，其实程序算法中的“分治法”也是这个道理。毫无疑问，RUP(Rational Unified Process，统一软件开发过程)和XP(eXtreme Programming，极限编程)都是强调迭代的，但为什么XP更轻量级、更加不注重详细的分析与设计，而RUP更加重量级，需要各种文档和详细的分析设计呢?

　　同样是建造一栋摩天大厦，在RUP开发方法学里面，它是从一次建造一层楼的粒度来进行迭代开发的，因此每一次迭代仍然需要相对详细的分析与设计。而XP的方法则不同。它会以一套房子或者以一个房间的粒度去建造整栋摩天大厦，每一次迭代开发的功能点不会太多，因此所需要做的前期规划自然要少得多。软件大师Robert C.Martin在他的《敏捷软件开发—原则、模式与实践》中提到，XP理想的一个迭代周期为2周，每6次迭代形成一个可发行版本。因此，迭代粒度的大小是RUP和XP本质的区别之一。

　　RUP更适合大型的开发项目，因为针对每一个项目，从跨越整个项目的广度上来讲，它制定了九大规程，每个规程对应若干个角色，每个角色需要产生若干个制品;从每一次迭代的深度上来讲，它强调把项目开发分成若干次迭代，每一次迭代都分成初始阶段、细化阶段、编码构建阶段和移交用户阶段，每一个阶段都强调形成若干制品，都对应多种不同的角色。

　　初始阶段要求生成项目计划、风险评估、需求模型等制品，这个阶段基本不需要经历几次阶段本身的迭代;细化阶段主要进行分析设计工作，需要生成分析模型、设计模型、迭代计划等制品，这个阶段可以根据项目情况进行1～3次小的迭代;编码构建阶段主要是进行编码，需要生成测试计划、本次迭代的可运行版本等制品，这个阶段也可以根据项目情况进行1～3次小的迭代;移交用户阶段主要是进行测试并提交给用户试用的阶段，需要生成产品测试文档、用户支持文档等制品，这个阶段可能由于性能测试不通过、出现bug、用户不满意，会有1～3次小的迭代。

　　从上面可以看到，如果要完全实现RUP的项目管理流程相当繁琐。这是它的一个缺点。但如果是大型项目，比如一个项目组超过30人，我们按照XP的做法，更多地强调人与人之间的沟通来代替RUP的各种制品和文档，它的沟通成本可能会远远高于撰写各种制品和文档的成本。所以这种情况下我们必须更多地采用RUP的方式来进行项目组织管理。

　　但如果一个比较小的项目组，XP的开发方法学就比较适用。国外某著名研究机构的研究数据表明，如果一个开发团队小于或等于12人，团队将能够保证成员间充分的沟通。

 

　　在开发过程中分析设计文档非常重要，但如果迭代的粒度足够细，比如，XP创始人Kent Beck研究认为，一个15人的项目组其迭代粒度为2～4周比较合理，按照这么细的粒度，就像前面讲的建房子的隐喻一样，那么，我们所需要的前期准备工作，包括分析设计的工作量肯定会大大减少。

　　在XP的“穿刺”过程中，如果按照现在采用的RUP的“用例驱动原则”，我们可以抽出里面对用户具有足够价值的若干个用例形成第一次迭代的内容。因为该次迭代涉及到的业务逻辑相对比较简单，开发人员可以更好地理解，因此在做分析设计时，我们完全可以更加简化各种文档，并通过迭代过程中人员之间的良好沟通，“隐喻”的运用，在迭代中对简化了的分析设计模型的逐步修改，来减少编码之前的工作量。

　　用例须正确和稳定

　　不过这里有两个问题：第一，在每一次迭代期间，我们必须对所选择的用例进行详细分析，尽量保证它的正确性。《代码大全》中讲到，IBM、HP公司发表的研究文章表明，在需求阶段的一个缺陷没有被发现，在设计阶段的修复成本会是需求阶段发现该缺陷的3倍，在构建阶段会是5～10倍，在用户移交阶段会是10～100倍。可见随着时间的推移，不正确的用例的修复成本会越来越高。第二，迭代期间用例必须保持稳定。因为本次迭代的计划、人员任务分配都是根据它来制定的，迭代期间的用例如果任意改变，就会使得计划无法完成。采用粗粒度的迭代无法保证迭代期间用例的稳定性，因为需求总会不断改变，但细粒度的迭代比如以两周为周期的迭代则完全可以做到这一点。

　　另外，在迭代期间出于优化程序结构、增强程序扩展性等目的，设计模型应该是允许修改的，代码是允许重构的，因为它对我们迭代计划的完成影响较小。

　　知识库

　　隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也即我们常说的行业术语。因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此要先明确双方使用的隐喻，避免歧义。

　　瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型软件开发分为分析与编程两部分。像工厂流水线一样，把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少，进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。

　　敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。它也称轻量级开发方法。

　　极限编程要求加强开发者与用户的沟通，让客户全面参与软件的开发设计过程，保证变化的需求及时得到修正。

光环国际转自PM圈子网