创建新的门户，第 3 部分: 项目计划、评估和跟踪

引言

计划、评估和跟踪门户项目的进度并非一个新概念。在外部人员和管理人员询问开发团队时，常常会问“项目进展得如何？”。但在内部，大多数团队负责人都明白，如果项目要进展顺利，执行某种项目跟踪是切实地度量项目进度并向项目发起人阐明项目状态的唯一方法。即使最简单的项目都需要某种类型的计划或任务列表。检查项目进展是否与任务列表所列任务相吻合，可能是最令人心满意足的事情——当然，实际完成的项目和已投入运行的项目除外。

可以采用许多方法来对项目进行跟踪，而其中的很多方法都采用了可靠且有用的方法学。但是，从哪里开始跟踪？着手开展项目或要求帮助或从头开始开展项目，有时可能比项目本身压力更大。团队成员应了解，在评估或划分项目中的任务时，他们应采用哪种方法。但重要的是，良好的评估是在项目进行的过程中跟踪项目进度的。

尽管本系列文章涉及项目计划和跟踪的概念，但作者不是项目经理。相反，我们都是参与过实际项目的门户专业人员，而且不止一次参与到项目中。因此，本文主要介绍项目团队内的领导关系。项目经理可以阅读本文以了解门户项目的具体差别，并有望从中获得一些新方法来与自己的项目成员共享。架构师和开发负责人等其他专业人员都可以尝试其中讨论的一些方法来提高项目的成功率。

且慢！我不是项目经理

有时，我们会听到技术人员说，“我不是项目经理，我不应承担这项工作”或“我只应做技术工作”。我们的回答千篇一律：“克服这个困难”。如果您要想成为负责人，您不应只承担“技术工作”。您的职责是在整体上让项目成功，这包括能够定义、评估和跟踪项目期间组件的完成和团队成员的进度。您可能开始享受这一切了。

具备良好技术技能的任何人都可以创建体系结构图、编写和审核技术设计，甚至编写一些代码。作为项目负责人，意味着要了解项目何时脱离跟踪，或某些团队成员何时遇到难题了。他还要了解何时会估计不足以及某些任务在项目计划好的很短时间内没有完成。要使项目成功，意味着要了解团队的每日工作、所花的时间，而且在较大的项目中，要获得每个成员的每周状态，以便帮助项目经理进行整体跟踪。

作为架构师或技术负责人，我们要掌握项目团队的每日工作。一种方式是每天与每个团队成员进行交谈。有些人觉得，这种方法会帮助负责人掌握团队的日常情况和进度（大多数时间）。每天与每个团队成员进行 5 到 10 分钟交谈有助于确保：

• 团队成员正确定义和理解任务。
• 在细节展开或需求变更时细化或展开任务。
• 进度按计划推进，并且在出现意外问题时进行沟通。
• 每个团队成员的经验与分配的工作级别相适应。
• 快速解决技术或个人问题，或对团队进行调整。

 

首先，我们承认，全面的项目管理不应由技术人员来担任。如果团队非常大或任务非常繁重，以至于干扰了正确技术解决方案的构建，则应另外为团队提供资源来跟踪项目。我们将决定何时提供附加资源这一问题留给读者。这里的关键是与项目团队进行沟通、沟通、再沟通。了解项目中正在进行哪些工作、所有组件的当前状态以及目前正在解决哪些问题？

当然，这里采用了这样一种推论：非技术负责人不应管理项目的技术设计和开发；他们应延迟技术决策，由架构师和开发人员进行这项工作。对于技术负责人，除了具备很强的技术和技术领导技能外，还必须进行项目计划、评估和跟踪。

关于下载

下载部分包含本文的两个电子表格，可能在您的项目中非常有用：

• 评估电子表格，有助于评估创建项目中某些组件所需的工作量
• 跟踪电子表格，提供每日状态并跟踪项目的进度。

 

本文稍后将讨论这两个电子表格。

回页首

制订项目计划

制订完整的项目计划要求了解完成项目所需的全部工作和任务。安排一个良好的工作划分结构（Work Breakdown Structure，WBS）可能是这种方法的核心。确定核心任务的列表将有助于您列出计划阶段、项目计划、评估和跟踪中的所有其他细节。经过培训的项目经理通常按照一套完整的方法来构建项目结构，包括了解业务价值、里程碑和任务、资源分配等。

不仅如此，可能计划的许多信息都要自下而上获得。您或项目经理无法了解每个子领域的所有细节。某些团队成员甚至不了解所有任务以及其依赖关系。与大多数门户项目一样，经验在决定项目成功与否方面起着至关重要的作用。

入门

制订一个真正的项目计划是一项非常困难的任务。创建需要完成的任务的简单列表是一回事，而制订包含资源分配、依赖关系和里程碑的详细项目计划又是另一回事。甚至在制订好计划之后，计划的任务管理所需的技能和经验都不是许多项目经理力所能及的。

对于技术人员而言，要求通过确定任务和工作以及与项目经理一起工作来帮助制订项目计划是合情合理的。但项目经理常常并不知道所需的详细级别。在详细定义需求和功能以及研究许多未知问题之前，甚至技术人员都不了解详细级别。

就制订项目计划而言，可以说是百家争鸣。有些专业人员认为，项目计划不应是执行所有工作的逐步过程；他们认为，如果达到这种详细级别，则已经走得太远了。相反，他们认为，所达到的详细级别应该是团队力所能及的责任和跟踪结果。当然，这随您要制订计划的详细程度的不同而不同。所需时间仅为几分钟或一小时的任务可能需要集中到更大的行式项目中。

对于任一任务的最大持续时间，许多项目经理都有不同的经验，但一般而言，大多数任务都不应超过两周。某些项目经理喜欢将任务划分为以一周为单位的任务块，这就使他们有更多的机会来发现问题并跟踪进度。最大持续时间并不是非常重要；相反，如果每个人都各尽其责，则每个人员的进度都是可以衡量的。否则，您可能会发现，一个团队用 80% 的时间完成了 80% 的任务，而另一个团队用 80% 的时间就完成了全部任务！

“构建 QA 环境”等高级别任务可以采用工作划分列表。在某些时候，此列表应发展成子任务，这有助于确定问题何时发生；例如，确定如下所示的任务列表应发展成子任务。1. 安装 WebSphere Portal 2. 配置数据库 3. 配置 LDAP 和安全性 4. 群集 WebSphere Portal

如果您的团队已进行到项目编号 3 后所指出的任务，则确定 LDAP 服务器是否尚未构建并衡量它会将项目进度推后多久是一项简单的工作。

制订项目计划所采用的一种技术（不需要特别的项目管理软件）是拟定项目大纲。使用任何字处理软件或电子表格都可以很好地创建各个任务级别。实际上，我们就是通过拟定大纲来撰写本系列文章的。请回想一下，您在高等学校撰写“研究论文”时，您的导师是否让您先拟定大纲？我们全都不愿意写此东西，而只想写论文，但必须克服这个困难。（但可能，仅仅是可能，Smith（不管您的老师是谁）已教给我们一些真正有用的东西。）

在上例中，您将以构建 QA 环境开始，然后将这 4 个任务错落有致地排列在其下。之后，您意识到，唉，要群集门户，需要在多台机器上安装 WebSphere Portal，而且还需要一个单独的 HTTP 服务器。只需添加这些任务即可。突然间，您意识到需要硬件，因此添加一项“确认已分配机器的操作”。提醒：如果您让项目经理将此项添加到特殊的项目管理软件中，则他（或她）会兴奋地拥抱您。

在您设计出任务列表后，请记住将必须执行的非编码工作列入其中，例如详细撰写设计文档、测试或只是确定一些新任务。

确定任务

项目计划的制订决不是一劳永逸的事情，因此，我们在此提供一个项目计划。但是，了解可以包含在自己计划中的一些主要任务可能大有裨益。

• 项目启动
  • 人员安排
  • 培训
  • 目标
• 解决方案定义
  • 门户研讨会
  • 产品选择
  • 软件组件
  • 硬件平台选择
• 制订项目标准
  • 开发
  • 变更管理
  • 测试
  • 部署
• 环境设置
  • 开发
  • 构建
  • 集成
  • QA
  • 分阶段提供
  • 生产
• 开发
  • 设计
  • 开发
  • 构建迭代
• 部署和测试
  • 系统测试
  • 性能测试
  • 部署
• 生产发布
  • 最终的内部版本
  • 部署
  • 分阶段投入使用

当然，具体项目要求和需求不同，这些细节实现也是不同的。

我们不能过分强调对团队中某些有经验人员的要求，特别是在某个项目很棘手而最后期限又非常短的情况下更是如此。可能必须要有产品和门户开发专业知识才能列出项目计划的细节。了解软件组件的安装顺序和配置非常重要，因为这样就可以准确估计出完成各个任务所需的时间。但没有适当的实际专业知识对您的项目而言并不是至关重要的。然而，如果您没有专业知识，则需要抽出更多的时间来进行培训、学习和解决问题。

定义角色

要定义角色，您需要了解团队中所需的角色、不同的角色何时发挥作用以及每个团队成员主要工作。从长远而言，提前制订良好的人员安排计划可以减轻承担过多任务的团队成员的痛苦。门户项目中必需的许多角色都与许多企业开发工作中所需的角色类似。这些角色需要项目生命周期的所有领域中的专业知识以及特定领域的深层技术技能。需要考虑安排的角色有：

• 项目发起人
• 项目经理
• 业务分析人员
• 信息架构师
• 图形设计人员
• 架构师
• 技术负责人
• 熟练门户开发的开发人员
• 构建和部署专家
• 基础设施和操作专家
• LDAP 和安全专家
• 数据库管理员
• QA 和性能测试团队成员
• 内容作者和编辑
• 基础设施和操作专家

 

好了，上面只是一个简短的列表！正确的计划包括确保在正确的时间为项目使用正确的资源。如果您的团队有构建企业 Java 应用程序的经验，则您就会了解到需要所有这些不同的技能。如果这是您的第一个项目，请阅读本系列文章的第 2 部分：门户研讨会来了解所需的技能。

应用 80/20 法则

细节太多会让最细心的计划人员不知所措。在第 2 部分，我们提到 80/20 法则。此法则的本质是，项目中只有 20% 的工作是真正重要的。项目经理们应明白，20% 的任务占用 80% 的工作。在被无关紧要的细节搞得筋疲力尽的项目中，在不堪重负的项目中，我们常常看到这种情况。试图在第一个版本中一劳永逸地解决所有问题是行不通的。有实际门户项目经验的团队从实践中了解这一点，通常他们经历过有问题的项目。解决方法是分阶段完成项目。

图 1 显示了执行门户项目可以采用的方式的示例。

图 1：门户项目的 80/20 方法

我们建议您不应完全忽略其他 80% 的需求；相反，我们建议您集中处理麻烦最多的事情。甚至在主要任务中，也要留意将需要大多数工作的子任务。这些类型的工作对在项目生命周期内进行跟踪非常重要。将其他功能分成组，并随着时间的流逝采用迭代方法向用户发布。

回页首

评估工作

在我们看来，对大多数门户项目的评估只能根据经验正确地完成。不过，您可以选择各种不同的评估技术。在许多情况下，这些技术要求进行高级方法培训和正确完成某些工作。此领域中的经验也很关键，它与您评估的能力密切相关。您评估这些类型任务的经验越多，您就评估得越准确。我们的目标通常是进行快速而粗略的评估，之后再对这些评估进行细化，然后跟踪我们的评估，了解项目是否按计划进行。

一般而言，我们为不同任务提供了一个大致正确的评估，然后根据将每个任务所指定的人员的技能和经验增加或减少一定的百分比。您还可以根据整个团队的动态变化，使用一些基本的启发式方法，即领导团队的人是谁，他（或她）的经验处于哪一级别？在评估设计的复杂性、即装即用的应用程序必须进行多少自定义以及需求的稳定程度方面，代码设计将发挥作用。所有这些问题以及其他更多的问题在确定此项目从设计到部署所用的时间方面都起着重要作用。

近来，围绕在初始评估中起更大作用的许多评估方式有一些讨论。这使得架构师或开发负责人可以为任务或组件进行高估、低估和（更重要的）最可能的评估。下面让我们来了解几种评估技术。

Putnam 分布评估方法

一种评估方法基于 Putnam 分布评估方法，它表示项目从最初到单元测试所用的全部开发时间。此方法依赖于以下公式：

EV = (O + 4L + P) / 6

其中，EV=推导出的估计，O=乐观估计，L=最可能的估计和 P=悲观估计。

图 2：Putnam 评估方法

我们发现，在一些情况下这种方法是一种非常准确的评估方法。这很容易被许多项目经理和高级管理人员接受，原因是您提供了一个估计范围，而不是一个硬邦邦的数字（单个数字可能会非常不准确）。

当然，在看到这种分布时，大多数人都会乐观地集中于低估之上。尽管我们都是乐观主义者，但事实表明，真正更有用的估计是“最可能的估计”。

您可以在跟踪电子表格中建立这样一种评估方法，也可以采用单独的表格使用该方法。可以在整个项目中将其用作正式评估方法，也可以在您自己的项目中作为参考。

图 3 显示了评估电子表格的示例。

图 3：评估工作表

要指出的是，在此情况下，对时间的估计悲观一些可能实际上非常重要。但在最后时限到达之前，许多团队成员都会非常乐观。在实际项目中，这可能非常不现实，并且将偏离您的评估和计划，从而导致团队工作失败。

在下面几部分中，我们将讨论如何将组件和需求划分成评估任务。我们主要关注的是能否回答一些问题，例如：

• 任务是什么？
• 谁正在执行任务？
• 他们面对哪些问题？
• 进展如何？

 

基于功能的评估

从门户的角度看，基于功能的评估可能最易于理解。基于功能的评估首先了解应用程序内的主要组件，然后将这些组件划分为子组件和任务。通常，可以按 Portlet 的不同类型、Portlet 的数量或必需的所有后端服务来确定任务列表中的大部分组件。许多门户项目都需要许多服务（如 Portal Service、Singleton 或 EJB），通过这些服务可访问门户框架外的资源。

根据划分任务的方式，此方法可能考虑也可能不考虑项目所依赖的许多基础设施任务。在许多项目中，特别是在新门户环境中，Portlet 开发只是提交生产环境所需工作量的四分之一。但是，如果基础设施已经建立起来并已投入使用，而且项目只提供某些新功能，则此方法可能会适合您的项目。

一种常见的方法是确定范围和来源，您可以在其中列出对于每个 Portlet 都非常必要的需求和工作。您还可以分析依赖关系，然后估计整个工作量。

确定来源和范围

确定 Portlet 的来源是确定 Portlet 与哪些资源进行交互的活动。例如，Portlet 是显示某个数据库的数据还是显示 Web 服务调用的数据？确定范围也是与之相关的活动，但需要附加信息。在用户与 Portlet 交互时，是否需要有多个事务？在这两个实践中，您可能要回答的其他一些问题是：

• Portlet 将显示哪些内容类型，是单个项目还是多个项目？
• Portlet 需要访问哪些内容或数据来源，例如后端应用程序、数据或服务？
• 是否需要个性化、多台设备或多语言支持？
• 该 Portlet 是否与其他 Portlet 进行交互？如果要与其他 Portlet 进行交互，消息传递和设计约束涉及哪些内容？
• 所需状态、视图和 JSP 的数量是多少？是否需要编辑或配置模式？
• 开发时使用哪个 API、框架或工具？
• 访问控制要求有哪些（如果有）？
• 高速缓存是否必需或必要？

 

您看看，这些都是要考虑的问题，如果将项目中 Portlet 的数量与此工作量相乘，考虑的问题会更多。您可以将 Portlet 看作单独的应用程序，然后将某些确定范围的工作分给不同的团队成员，以使处理更加有效。开发负责人或架构师应关注任何跨应用程序依赖关系或可以合并资源的领域。这是可以应用 80/20 规则的另一个领域；最开始实现最重要的 Portlet，其他 Portlet 留待后续版本实现。

好了，我知道，大多数人都会想“我的企业或主管经理发起人需要所有功能，而不是仅仅 20% 的功能！”我同意这一点非常重要；否则他们不会再对项目提供支持。这就要看您的谈判技巧如何了。缩小了范围就极大地增加了项目成功的可能性，但并不意味着最初版本就是最终的版本。分阶段构建项目，以增量的形式进行发布。功能少而精要比功能包罗万象但浅尝辄止或根本不能发挥作用要好得多。请记住，您是这些功能出现问题时所要找的人。采用分阶段方法会保证优先顺序，您可以在合理的时间内及时完成工作，这不会对您的职业生涯带来任何风险。

根据集成评估

许多门户项目都是复杂的项目，客户希望在这些项目中将许多不同的应用程序和资源集成到单个界面中，以供用户使用。根据集成的评估方法可以帮助您集中处理项目中最耗时的任务，集成任务通常会耗费大多数项目时间。建立环境中的门户基础设施可能是复杂的集成工作。我听过客户说“我只想将其建立起来，即装即用”。但实际上，在开始为特定组织环境配置门户后，没有东西是即装即用的。自定义 LDAP 和数据库需求、单点登录和在最短时间内的内容馈送，所有这些都是最初建立门户时所面临的挑战。

在您第一次构建门户时，使用基于集成的方法可能很有用。在制订列出门户项目所需的全部任务的项目计划时，常常需要专业知识，因此，您肯定需要考虑如何安排项目的资源。任务划分与您在基于功能的评估中所完成的工作非常类似；不同之处在于，您投入更大精力处理门户所需的集成组件或服务，以及门户环境的安装。

此方法适用于集中处理需要由基础设施团队为门户和门户与之交互的任何组件完成的任务。DBA 是否需要为门户搭建一个数据库？您是否可以使用现有的 LDAP 硬件，或是否需要购买和安装其他的硬件？是否需要为安全性或用户资料库 (LDAP) 集成进行自定义开发？

所有这些项目都与集成有关，并与传统的开发行项目具有不同的依赖关系。另外，在成功集成的工作中，还可能涉及其他团队或人员。例如，需要创建更详细的设计文档，以确保所有团队都朝着同一目标努力。

基于敏捷的计划

敏捷联盟网站 (http://www.agilealliance.com/home) 的横幅上有个口号：“通过提早交付和持续交付有价值的软件来满足客户的需要”。这些精挑细选的词汇道出了敏捷开发的核心。尽管可以采用多种形式，但大多数敏捷开发变体都有一个前提，即在项目整个生命周期中都要进行持续开发和集成。

下面是敏捷联盟的定义。“敏捷联盟是一个非盈利组织，致力于促进敏捷开发。本联盟的指导原则包含在敏捷软件开发宣言"中。下面是该宣言前面的部分：

图 4：敏捷软件开发宣言的部分内容

乍一看，这些话足以让项目经理感到畏缩。服务支持通常是通过右侧的列表实现的。敏捷开发似乎与传统的方法截然相反。但是，让我们看看最后的声明“即，如果右侧的各项有价值，则左侧的各项更有价值”。

在理想的情况下，左侧项目列表将（可能应）作为任何开发过程的控制标准。因为我们知道，在预算使用范围内，这一状况很难得到遵守，所以我们可能修改我们的方法，以将敏捷方法视为一种既兼顾左侧项目又兼顾右侧项目的一种方法，从而不会由于忽视右侧项目而使项目无法开展或预算超标。例如，我们研究一下表中左侧最后两个项目：

“我们重视按照计划对变化做出响应。”

假定我们全都同意或了解项目的变化。需求可能收集不正确；依赖关系可能会理解错误；技术或集成点可能会变化；或客户可能会改变其想法。了解此变化并将某种程度的灵活性融入项目中，有助于您以某种方式缓和变化，从而在项目中实际包含变化而不是手足无措地等待可怕的事情发生。

当您在不确定的情况下进行计划时，利用敏捷评估可以适应现实世界的各种情况。如果需求每日都在更改，而项目最后期限又迫在眉睫，则会强制采用这种灵活性。敏捷开发还允许您首先集中于最困难或最重要的功能，然后在项目资源允许的情况下，随着时间的推移轻松添加新的 Portlet 或应用程序。

此方法要求很好地区分项目中功能的优先顺序。如果更改很重要，则其中一个关键是采用短迭代周期，则可以将更改合并到下一个周期。可以通过多次迭代添加其他功能，这就允许在下个周期开始前，在任何时候进行更改。

在对项目实施敏捷方法时，您可能会遇到组织障碍。许多高级管理人员和项目经理都无法肯定敏捷流程的有效性，并怀疑这些流程提供的输出是否与传统项目提供的输出相同。使用敏捷方法的目的是在灵活性要求和更改要求之间进行调节；例如，客户在不了解他们需要什么时所发生的更改。其他方法（依赖于协定中更多的提前时间）可能会明确对过程其余部分的要求，但您最终会发现，这些要求可能不是客户端所希望的。

改造方法

上面列出的方法只是根据经验就团队进行项目规划提供的一些建议。对于所采用的方法和何时采用这些方法没有严格的规定；在门户生命周期中，每种方法在不同时间都有优点。

• 如果您的基础设施已经建立好，而且正在考虑将新的 Portlet 或组件添加到门户中，则基于功能的评估可能是一种很好的方法。根据您第一个门户项目的难度，您可能希望不将此方法用于第一个项目，或仅对部分项目使用此方法。
• 基于集成的评估主要关注的是使门户在您的环境中正常运行。该方法最适合主要集成组织内门户的第一个门户项目，或最适合门户项目内的集成工作。
• 在门户环境已经建立好并提供测试版本后，可以考虑使用基于敏捷的计划。这最适合区分功能计划表的优先顺序的项目发起人或管理团队，但再问一下，在您印象中，有多少项目在最后一天还没有开始？尽管设计敏捷方法的真正目的是应对项目变化，但在大多数时间内，完成功能的最后日期和百分比都是硬性的，并且当时间允许时，可以调整其他功能，这可能是敏捷计划最适合的地方。

 

回页首

跟踪项目进度

在不使用全面的项目计划或软件时，技术人员如何帮助跟踪项目的进度？过去这几年，我们已完全掌握了使用工作划分或基于任务的电子表格的技术。该高度可自定义的文档会帮助您很早就列出和评估项目中的部分工作。然后，使用此数据将工作分配给团队中的不同开发人员，并在项目期间跟踪进度。此方法具有以下优点：

• 与很快会变得过时且难以进行更新的比较正式的项目计划不同，电子表格非常易于使用和维护。稍后您可以看到一个示例。
• 如果您完成了这些初始任务并对项目进行早期评估，以便项目经理将这些评估纳入其项目计划中，则项目经理会感到很欣慰（真的！）。
• 此表格可用于进行设计以及跟踪团队的进度。通常由团队负责人或架构师创建和维护该电子表格。他或她可以使用此电子表格来帮助准备好设计中所需的不同组件（Portlet、服务和其他组件）。
• 这种表格短小精悍（通常一、两页），可以随时带上，在跟团队成员交谈时，可以用当前的状态进行更新。一周一次或两次将更改合并到文档中和新的印刷文档中。在项目的早期阶段（即设计阶段），可能要每天进行此操作。

 

我们相信，这种类型的电子表格可以有效地应用于采用任何一种方法学的项目中。

定义任务列表

下面的内容是了解要实际在电子表格中记录哪些任务。实际上，这一部分非常有趣。我们将表格分为几部分，然后在每个部分中列出各个组件或任务。这些部分可以是宽泛的对象种类（例如 Portlet 和非 Portlet），也可以是更精细的种类（例如功能种类）。例如，您可能具有这样一种功能：该功能包含所需的大量组件，并将这些组件作为一个组进行跟踪。您可能包含的某些部分有：

• 安全性（例如登录和注册）
• 服务（通用 Portlet 服务）
• Portlet
• 内容管理
• 基础设施
• 设计
• 文档

 

使用该表格可以跟踪开发组件之外的其他组件。我们常将该表格用于跟踪所有与项目有关的任务，因此，我们包含需要生成或编写的文档、环境的设置（例如分阶段提供、Q/A 和生产）、培训或项目团队需要完成的任何类型的任务。

 

每日跟踪

对于每日跟踪，您可以打印完整的表格，并在工作日与团队成员交谈时，随时带着它。您可以添加新的工作项目和新的问题，并随着项目的进展而加以调整。在特别复杂的项目中，在开会时间或项目发起人突然拦住您时，随身带着这些表格很有用。您不用声嘶力竭地解释哪些人在做哪些工作，或介绍工作的进展情况。每日与开发人员进行快速讨论可以向您提供不同组件的最新状态。

您可以有选择地用彩色代码对图表进行标记，并标记已完成的项目，以便可以快速浏览各个状态。

图 5：跟踪工作表

在时间表上标记的问题留待解决的时间不应太长。通常需要发出警报（真实或假想的）。向经理、客户或同事提醒可能发生的问题越早越好。在此情况下，使用彩色编码行可能会非常有效。在讨论项目期间，绿色（正常）、黄色（可能会与时间表不符）和红色（已停止，可能需要立即采取措施）都是醒目的颜色。可以在讨论有关项目时立即看到这些颜色。（示例中的颜色没有任何作用，只是区分不同的区域。）但请记住，尽量简明扼要。您也不要持续不断地对工作表进行更新。

有时，我们的开发团队很有趣，因为负责人手头总是不拿跟踪电子表格，总是问这问那，记个不停。只要不会变得过于随意，我们的建议就是让他们笑起来。这通常有助于减轻开发人员的压力。

获得更多帮助

Software Services 和 IBM Global Services 可以在许多功能方面为您提供帮助；他们共同完成了数百个项目，了解制订计划和构建门户需要考虑哪些方面的问题。这种帮助可以采用多种形式，例如帮助定义和划分任务与工作，或者提供适合您的项目的示例项目计划。从模板项目计划开始效果会很好；但是，每个项目和环境都是不同的。

他们还可以对大多数门户项目中常见的许多组件和配置要求进行分类。每组项目需求都是不同的，因而需要自定义集成计划。这就是门户项目包含的所有内容（集成人员、内容和应用程序），以前可能从来没有在一个地方使用这些内容。门户软件本身相当简单；只是由于集成的复杂性而使得各个系统在项目计划中花费了大多数时间。

我们的目的不是向您推销 IBM 服务，也不是增加您的项目成本。实际上，在项目周期的早期获得有经验的帮助可以确保项目成功，从而减少了项目的总体成本。由于大多数门户项目实际上是企业项目，因此只要做过了即可，这是一件好事情。开始门户项目时，如果有经验丰富的人员参与其中，可以节省几个月的总体工作量。对于任何项目（可能非常小的项目除外），建议团队中至少有一个经验丰富的人员参与到成本效益分析中。

回页首

结束语

本文的主题是讨论可以向项目负责人和发起人提供一些补充性建议。

1. 保持简单。确保用户、项目团队和高级管理人员可以快速得到结果。
2. 选择评估方法。根据构建门户的经验选择最佳的评估方法。
3. 使用迭代方法。在添加每个集成点后，应测试功能和性能以确保符合期望值。
4. 将其看作与任何其他复杂的应用程序或基础设施项目一样。采用这种方法，可以更容易地将项目分解成可管理的部分。

 

启动最初的门户项目很容易会搞得精疲力尽——这么多工作要做，而提交最终产品的时间又如此之短。制订计划是非常关键的，不仅对跟踪进度是如此，而且对首先确保您能够按时完成项目也是如此。

回页首

下载

描述	名字	大小	下载方法
Sample spreadsheets	planning-samples.zip	10 KB	FTP|HTTP

	关于下载方法的信息			Get Adobe® Reader®

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• developerWorks WebSphere Portal 区域：提供更多资源帮助您开发 portal 和 Portlet。
  
  
• 敏捷联盟网站：介绍相关组织并包含敏捷软件开发宣言。
  
  
• Agile Software Development: Principles, Patterns, and Practices. Robert Martin，Prentice Hall，2003 年。
  
  
• Extreme Programming Examined. Giancarlo Succi 和 Michele Marchesi。
  
  
• Extreme Programming Installed. Ron Jeffries、Ann Anderson 和 Chet Hendrickson。
  
  
• Web services programming tips and tricks: Project planning tips
  
  
• Program management: Different from project management
  
  
• The Comparison of the Software Cost Estimating Methods
  
  
• IT Project Estimation References and Resources
  
  
• WebSphere Portal in Action：developerWorks 上的 Read Joey Bernal 的日志。

作者简介

		Anthony (Joey) Bernal 是 IBM Software Services for Lotus (ISSL) 的高级 IT 咨询专家。自最初的 WebSphere Portal 1.1 版开始，他就从事这方面的工作，在设计和开发门户应用程序方面有着丰富的经验。他已经使用 IBM WebSphere Portal 实施了许多项目。Joey 还是一位杰出的作家、演说家以及关于 WebSphere Portal 及相关技术方面的讲师。他是 Programming Portlets 一书的合著者。

		Ken Polleck 是基于 IBM 的 Software Services for Lotus 的实践经理。在 IBM，他担任软件开发和服务方面的技术和管理职务已有 20 多年。作为获得 PMI 认证的项目经理，他花了 6 年时间使用 WebSphere 客户端评估、计划、开发和部署 500 多个 WebSphere 项目，其团队向这些客户提供了实用方法和专业知识。他和妻子现生活在美国北卡罗来纳州的 Raleigh，其妻子是 WebSphere 软件开发版本管理员。膝下现有三个孩子。