4.1 面向构件的项目计划

业务构件是最重要的项目管理单元

——Peter Herzum，《业务构件工厂》

所谓项目，是指为完成某类特定目标，在一定时期内所做出的努力。所有的项目都有一个明确的开始和结尾。

项目管理就是将各种知识、技能、工具和技术应用于项目之中，以达到项目的要求。《项目管理知识体系指南》指出：“项目和项目管理是在一个大于项目本身的环境中进行的。项目经理必须理解这个大于项目的环境”。下面我们通过“建模”来描述上述“大于项目本身的环境”（如图4.1所示）。

图4.1 项目环境

从上图中，可以看出项目管理中应当注意的一些问题：

◆项目的具体实施依赖于人，因为人是项目的真正参与者。一方面，项目不同，对项目成员的要求会有很大差异，招募到合适的人，对项目的实施可谓至关重要。另一方面，项目的具体实施也应重视与项目有关的其他涉众，比如客户（客户代表）、外包方等，他们的技术水平、实际经验、软件工程知识水平、个性等等，都应作为考虑的因素。

◆项目的实施势必采用某种过程。抽象而言，任何过程都是承担某种职责的特定角色，进行某组活动，以达到生产或加工    某些工作产品的目的；但实际上，过程还涉及更具体的工作，例如：

◆和角色相关的工作如何规划一整套角色，不同角色的职责分配，角色之间的工作制约关系、上下游关系等。

◆和活动相关的工作如何以“风险驱动”的思想来安排前期工作内容、后期工作内容，设置里程碑的密度，以及设置哪些里程碑等。

◆和工作产品相关的工作工作产品要不要提交到“配置管理库”进行版本控制，阶段性的产品包仅仅是内部发布、还是要发布到外部等。

◆项目的诸多投入，最终要换来产出的产品。项目管理中应重视产品需求的范围、功能需求与非功能需求完成的质量等等，这些因素都会影响产品是否能够成功。

项目经理的主要职责包括但不限于以下四个方面：

◆项目计划；

◆项目组织；

◆项目实施；

◆项目度量。

具体而言，项目计划可以分为不同的子计划。里程碑计划是要确定项目的关键交付物或者项目交付产品的具体时间表。项目的实施计划表现为整个项目实施的所有步骤，包括项目管理的各个方面。涉及到要制订完成的目标及其相应的工作，以及怎样为保证工作的实施提供相应的领导支持和指导。其中包括进度计划和成本预算、成本管理计划与风险管理计划等。项目进度计划就是根据项目实施具体的日程安排，规划整个工作进展。

项目经理还需要负责项目组织工作。例如，根据项目实际情况决定需要设置哪些角色、组建哪些小组（如架构组、开发组、测试组等）、并招募或调配具体的人员组建其相关小组。

项目实施过程是项目计划的执行，其间涉及资源分配、进度跟踪、计划调整等各种不同的工作，并要对各种突发情况进行果断处理。

4.1 面向构件的项目计划

在弄清开发团队到底要做哪些工作前制定的计划，很难执行下去。

——Per Kroll，《Rational统一过程：实践者指南》

在软件这个圈子里我们一再看到，老板希望项目经理在项目启动伊始就提供详细的项目计划——否则他就觉得不踏实；项目经理如果这样做，老板会很高兴——但这对实际的项目实施并无意义；项目经理如果不这样做，老板会觉得项目经理不是“自己的人”。苦哉，项目经理！

敏捷方法的流行，使更多的人认识到“务实”的才是最好的。在我们提出的面向构件的项目管理中，我们推荐项目计划和迭代计划分开。

1．项目计划

《项目计划》应在项目的早期阶段制定，其主要目的是评估项目规模、估计项目在财力、时间和人力上的投入。

那么，项目的进度表在项目计划中应做到什么程度呢，我们建议做到阶段级即可。

任何有经验的项目经理都知道，根据所谓的项目管理“铁三角”来制定项目计划是远远不够的。根据我们的实践，认为Ambler在其《过程模式》一书中归纳的“铁六边形”显然更成熟，如图4.2所示。

图4.2  项目计划“铁六边形”

（图片来源：《过程模式（上册）》）

2．迭代计划与并行开发计划

Per Kroll指出，迭代计划需要以下四个步骤：

◆决定迭代的范围；

◆定义迭代的评估标准；

◆定义迭代的活动；

◆分配任务到人。

上述是一般性的迭代计划的制定过程，而面向构件的项目管理，有两点重大的不同之处：

◆迭代开发和并行开发相结合

◆以构件为中心的计划

可以认为，面向构件方法在迭代周期内部，又进行了基于构件的并行开发；但无论如何，迭代周期结束，应该提交用户可感知的业务功能的变化——一个对用户来说没有任何有意义的新成果的迭代是令人失望的，因为不能得到用户的反馈，就失去了迭代的大部分意义。

每个迭代周期内部都是并行的：不仅负责不同业务构件的小组之间是并行的，而且负责不同的服务构件的工程师之间也是并行的，因为构件之间的接口已明确，如图4.3所示。

图4.3  并行开发计划（部分）

值得指出，我们推荐面向构件的软件项目采取迭代开发方式。迭代式开发对计划工作造成了根本性的影响，具体计划工作将分为两个级别，如表4.1所示。

表4.1  项目计划与迭代计划

4.2 面向构件的项目组织

也就是说，开发环境是围绕业务构件概念进行组织的，项目规划是围绕业务构件进行组织的，工具把业务构件当成一等公民，

另外任务分配也是以业务构件为中心的。

——Peter Herzum，《业务构件工厂》

任何项目都是由一批相互合作的人来完成的，要找到合适的人，并把他们组织在一起成为一个团队，这需要项目经理的组织管理能力。

1．团队组织

项目经理是开发团队中特殊的角色，他需要掌握的技能和大多数人不同。项目经理的职责之一是“管人”。

面向构件项目的团队组织，应当是动态性的，如图4.4所示。这样做的好处之一是“有利于和外部团队协同”，当项目开发任何涉及外包子系统时非常易于管理；另外，很常见的情况是需求和总体设计由最终客户和中间件厂商共同完成，而后期工作由最终用户的开发人员进行。此时，“动态团队”的灵活性就十分明显。

总的来说，团队的上述组织方式也体现了对资源投入的谨慎性（如    图4.5所示），这是基于风险驱动原则的考虑，在目标未明确之前，仅投入5％的工作量；在架构和主要技术风险明确之前，再投入20％工作量。待所有高风险因素明确之后，全面将工作铺开，投入项目组所有人力资源。

图5

图4.4  动态的团队组织方式

图1

图4.5  风险驱动的资源投入策略（图片来源：RUP）

2．开发角色分工

随着时间的推移，相信软件行业也会步入传统制造行业现在的生产方式——大规模定制。而这其中，开发人员在面向构件项目中的角色分工有了很大变化。

面向构件软件过程提倡的“为复用而生产，为使用而组装”改变了开发时的情形。本质上，开发人员可以分为构件开发者和应用组装者（参见图4.6）。构件开发者负责构件本身的开发，并由测试等相关人员验证构件的完整性和正确性。应用组装者是构件的使用者，将现有构件按照用户所提需求进行个性化组装，以“按单定做”的方式快速生产应用系统。

图2

图4.6  开发角色的细分

4.3 面向构件的项目实施

整个开发过程，及该方法的所有架构性考量和所有其他方面，都应围绕着构件粒度的各种等级展开。

比如，需求和分析可交付工作产品是尽可能围绕业务构件组织的，设计、实现和测试是由一个团队围绕一个业务构件组织的。

——Peter Herzum，《业务构件工厂》

项目实施过程是项目计划的执行，其间涉及资源分配、进度跟踪、计划调整等各种不同的工作，并要对各种突发情况进行及时处理。

项目经理担负着整个项目负责人的重任，其工作是充满挑战性的，而不是一成不变的。为了项目的顺利实施，项目经理应积极为各种生产活动做好配合和管理工作。如图4.7所示，以需求阶段为例，说明了项目管理工作和项目生产工作之间的关系。

图3

图4.7  需求阶段的项目实施

我们推荐采用迭代的方式进行项目计划的实施。但是，必须提醒项目经理的是，相对于瀑布式的开发模式，迭代式开发对项目经理的要求更高，项目经理的工作量也要大出数倍。因此，特别是对关键度高的项目，我们强烈建议项目经理应当有迭代开发的管理经验。

4.4   面向构件的项目度量

向开发人员要任务的完成率，只会得到毫无意义的答复。

——Kent Beck，《规划极限编程》

这些开发人员通常在几天内就完成90%，一个月内完成95%，6个月内完成99%，然后在12个月以内另谋高就，留下的是“已完成99.9%的工作”。

——Stephen R. Palmer，《特征驱动开发方法原理与实践》

根据项目计划，应制定相关度量标准，作为项目开发的目标。这些目标包括：根据人力资源计划制定的项目预算、根据进度计划制定的重要里程碑评审点，当然还有项目规模度量，以及项目质量度量标准等。需要强调的是，项目度量必须依赖一套“折衷决策”，它必须是因项目而异的；项目度量的结果是否满意，不是绝对的，而是相对于“折衷处理”过的“期望结果”而言的。

1．进度管理

传统项目管理中，进度的度量往往靠主观估计，很不科学。面向构件的软件过程主张通过评审、走查、测试等确认活动来决定构件的完成进度，如图4.8所示。

图4

图4.8  基于评审、走查和测试的进度度量机制

同时，任务的分配以构件为单位，每个构件都会分配到具体的开发者。这样一来，开发者的考核，可以通过其负责的所有构件的完成进度统计而来，如图4.9所示。

图5

图4.9  面向构件的进度管理

2．项目进度的图形化表示规范

Peter Coad作为建模大师，他对颜色的利用达到了炉火纯青的地步。我们参考了Peter Coad等人的特征驱动软件开发（FDD，Feature Driven Developent）的优秀创造，定义了构件进度的图形化表示规范。

状态：

◆未开始（白）

◆进行中（黄）

◆已完成（绿）

◆已延期（红）

完成百分比：进度条＋文字说明

完成日期

◆已完成（绿）

◆未完成（标明计划完成日期）

示例如图4.10所示。

图1

图4.10  构件进度图形化表示规范（本规范参考FDD方法）

4.5   案例研究

神州电信为确保业务支撑系统的成功实施和维护，成立了企业信息中心部门，以面向构件的IT建设思想进行团队建设。而该部门主要负责业务支撑系统全生命周期的管理。该部门的组织结构图如图4.11所示。

需求管理部是与业务部门的接口部门，主要负责需求的收集、管理和需求分析、需求的变更管理、管理业务部门的反馈，并与业务部门签订SLA（Service Level Agreement，服务水平协议）。由于采用了面向构件的方法建设神州电信的IT系统，为SLA的实施提供了更好的保障。

规范标准部负责神州电信IT建设的规划，同时制定业务和技术规范，负责技术架构的选型。采用面向构件方法建设神州电信IT系统的规划，正是在规范标准部的主导下经过多方合作严格验证后确定的。在确立了这个方法后，该部门围绕该方法结合神州电信的具体状况，制定了神州电信的构件库建设方案和构件规范，用于指导面向构件系统的建设、管理和维护。

图2

图4.11  神州电信信息中心部门职能图

应用开发部是具体采用面向构件方法进行应用系统建设的部门，负责在需求管理部提供的业务需求基础上，采用面向构件的方法组织系统开发，并负责系统建设过程中的项目管理。

知识管理部主要负责IT系统资产的管理，包括软件资产（以构件为载体）和数据资产。

系统维护部主要负责IT系统的维护和管理，包括应用系统运行的软硬件环境，系统的配置、优化等内容。

而业务支撑系统是在信息中心这个神州电信常规部门的主持下按照项目方式建设的。由于这是一个复杂的系统，系统的涉众较多，包括了业务部门、信息中心、基础平台厂商、咨询公司、开发商、设备厂商等多方面的人员；项目的周期也相对较长，从初期的IT规划咨询到最终完成所有地市的系统割接上线，经历了将近2年时间，因此项目管理的复杂性很大，本书的案例研究主要描述应用系统设计开发过程中与面向构件方法这一主题相关的部分内容。

在咨询公司ATrue完成了系统规划的咨询后，神州电信成立了项目领导小组，正式启动业务支撑系统的建设项目。项目领导小组在神州电信和合作伙伴中指定或选派形成了项目执行小组，项目执行小组负责项目的具体实施工作，由业务部门、信息中心和咨询公司、开发商的人员构成，包括项目经理、技术经理、主任架构师及各个下辖部门的经理等角色。在项目执行小组下，按照项目实施职能，又分为项目支持部、质量保证部、系统开发部、系统集成部、用户文档和培训部，其中主要由系统开发部采用面向构件方法进行应用的开发，项目团队的组织结构图如图4.12所示。

图3

图4.12  业务支撑项目组织结构图

在项目实施中，项目执行小组制定总的项目计划以及各个阶段的项目实施计划，而系统开发团队则制定详细的构件系统开发计划。开发部门在对业务需求进行WBS（Work Breakdown Structure）分解时，结合面向构件的方法，按照构件系统（对应到应用系统）、构件子系统（对应到业务主题域）、业务构件（对应到业务模块）、业务构件接口（对应到用例）4个层次进行分解，产生了系统的系统功能分解矩阵，如图4.13所示。

图4

图4.13  应用系统构件分解矩阵及进度表

在完成这个矩阵后，就确立了系统的业务构件列表和业务构件的接口，构件的数量表明了系统的规模和工作量的大小，同时这个矩阵也体现了系统的需求范围。于是，开发部将功能分解矩阵作为贯穿系统实施过程的需求范围、工作分配、进度监控的重要工作产品。对于每个业务构件及其接口，按照面向构件项目度量的方法，设立了设计、实现、走查、测试4个阶段。进度计算采用保守算法，以完成阶段工作对应某个百分率来进行度量。这样，完成设计表明完成30％的工作量，完成开发表明完成70％工作量，使得进度可以自动进行计算，获得的进度数据更加准确，而不是靠开发人员主观评估。

同时，在完成系统的功能分解矩阵后，神州电信利用面向构件中间件EOS产品的进度管理控制工具，可以比较直观地了解到项目中各个构件的进展状况。通过工具，可以自动将功能矩阵导入到EOS Studio的项目中，这样构件系统成为一个项目工程，构件子系统成为一个业务构件包，业务构件接口成为业务构件的Entry Point。设计开发人员在基于EOS进行设计开发时，在完成某个业务构件接口开发的阶段工作后，可以进行阶段设置。这样，工具就能自动显示各个业务构件实现的进度，即可以从业务构件包的视角看到各个业务构件的进度状况，如图4.14所示。

图5

图4.14  业务构件包“销售过程管理”的进度信息

还可以进一步了解某个业务构件各个提供接口的实现进度，如图4.15所示。

在通过工具查看这些进度信息的同时，EOS还提供了进度文档导出的功能，能够形成基于Excel或者HTML格式的进度统计表。神州电信采用这种面向构件的项目计划和度量方法，通过EOS提供的相关工具，在项目实施过程中，项目管理人员能够快速获得准确的项目进展信息。

另外，在开发过程中，项目组大量采用了迭代的开发方法。在设计阶段，完成了系统总体设计、数据库设计、界面框架设计。在确立了项目的设计开发规范后，项目组将开发团队分成了若干个小组，每个小组由一名主程序员和2～3名构件所有者构成，负责某部分业务构件的设计和实现工作。具体做法为：假定1个开发小组由主程序员李杨和2名构件所有者迟易、李小小组成，开发组分配了销售过程管理的子系统交由该小组进行设计实现。李杨带领迟易、李小小首先完成了“销售线索”、“销售机会”、“销售计划”三个业务构件的设计（分配原则为每人一个业

图1

图4.15  业务构件包接口实现进度

务构件），在设计通过评审后，仍然由这三人进行构件的实现。在设计和实现过程中，可以给一个人分配多个业务构件，但一个业务构件只分配给一个人。在设计实现过程中，由主程序员组织进行内部的构件设计、实现走查。在针对一批业务构件完成设计实现后，又开始另一批业务构件的设计实现。通过这种迭代方式，针对业务构件的优先级逐步进行实现，这样使得开发可以很快提交工作成果，测试人员也能够尽快进入到测试状态。实践表明，神州电信业务支撑项目组采用这种过程组织方法，提高了人员的工作效率，缩短了测试的周期。