原文:2003/2/13
修订:2004/3/17
原文排版格式:http://www.marshine.com
这并不是一次正式的评估，而是一种访谈性的非正式评估(当时称之为交流)。事情的来由是这样的，公司有一个项目组承接了国家的863项目开发一个工作流产品，部门的领导对这个东西有较高的期望，但并没有提供与这种期望相应的支持。项目的结果并不太理想，因此部门领导对这个项目组非常不满，另一方面开发小组经常加班，成员因为得不到认可，士气低落。我当时并不在这个项目组中，但我觉得这个项目的不成功（从领导的期望来说）是有很多不属于项目组的原因，作为公司的一名资深的技术人员，我希望能够做一次简单的评估，以帮助领导能够清楚地了解项目的现状、形成的原因，好的和不好的地方，能够公平的看待项目组的努力（希望如此）。但最后这份报告并没有提交，开发室的主管有一些担心，而我也尊重他的意见，只在小组成员中进行了交流。
本文的主题涉及到公司进行863项目的一些内容，希望不会成为人们抨击公司和863项目本身的工具，我的目的是提供一些关于失败的教训或值得借鉴的经验。
原文序：2月11号下午，工作流项目组成员、部门主管XXX和我进行了一次比较长的关于工作流项目情况的总结性交流，以下是我通过交流对项目的一些认识和看法，从项目的最终结果的状态、项目的目标、项目开发过程中的好的和需要改进的地方等多个方面进行了分析。
项目背景项目来源于公司申报的国家863项目。工作流项目于2002年4月启动，12月份基本结束，但还未通过国家验收。
项目成果状态项目并未进行同类商业化产品的比较，主要目的是通过国家的验收，因此产品仅停留于技术原型状态。项目组选取了一些典型的应用案例，并基于原来在群件系统上的工作经验和WfMC（工作流管理联盟）的标准制定了需求，开发了可运行的基于J2EE平台的模型，其中包括了工作流引擎、建模工具以及一些示例，具备了应用开发包(SDK)的基本内容。
产品化能力鉴于时间和本身的原因，我们并没有真正进行产品的技术性测试评估，而是根据项目的一些信息来了解它的成果。相对于市面上可使用的主流服务器(如BEA/IBM)厂商产品和第三方产品以及开放源码产品来说，在实用性、成熟度、同其它技术和环境的整合度（如安全）、开发支持产品（文档、指南等）等方面还有较大的差距，毕竟这些产品的开发时间较长，并具有良好的开发基础。总的说来，离产品化还有很大的差距，有些原因不可忽略：
项目组具有群件平台（办公）协作的工作流方面较深厚的背景，但对业务流程协作相关的工作流仍然缺乏对应用场景的了解，公司的项目也没有类似需求提炼出来，项目组缺乏使用场景的引导，难以产生有效、完善的产品需求。 原来的项目目标是通过国家的863验收，而863验收向来比较形式化，公司也没有明确的在产品的实用化价值上的诱导。 有效的开发时间和人力太少，不可能产生商业化或可实用化的产品。通用化产品必须具有相当的成熟度后才可使用，否则大量的问题会是使用者失去信心，并让项目组陷于铺天盖地的维护工作中。这个问题下面会有描述。 项目的主要问题经过交流发现项目存在以下现象：
高层目标模糊公司在处理863项目没有自己的立场，为863项目而作863项目，没有考虑自己的发展方向，带来的结果是公司的高层领导并不关心以863计划为基础的项目，只有项目部才关心，因为他们需要对验收负责。到公司和部门来说，这些项目大多与公司的业务方向和基础背景不同，这带来了两个不利的方面，一是项目的目标不具有实用性，二是缺乏开发的基础。
工作流项目原来的目标据项目组说上级领导的意见是：
完成863项目 培养J2EE人员因此项目并不来自于自身的需求，而这样模糊的高层目标难以指导项目组完成具有真正可用性和市场化的产品。当然这些并不是在《前景》文档中反映出来的，然而是事实上的指导目标。
缺乏需求和应用场景获取渠道.公司在过去企业应用的开发上虽然有一定的业务协作工作流的应用场景和办公协作应用的开发经验和理论基础，开发时对需求的处理也因无法找到好的需求获取渠道显得效果不是特别好，而且用例我觉得在描述这种需求上还很有局限性，无法体现应用价值和应用场景，应当增加其他的需求描述方式，当然需求渠道和应用场景是最主要的。
项目组制定了计划，但计划经常被打断，并造成计划失效被外界干扰来源于几个方面：
人员调整。项目从初期到后期，人员一半以上被调换，无法保持一个一致的设计思想，特别是9月前后，后来的人需要重复以前的工作，这种人员的变化，是项目有效工作时间减少的主要原因。9月是项目组的编码实现阶段，虽然计划仍然在执行，但事实上受到了人员变化的影响，理解/废除/改进原来设计，增加了工作量，在按时完成的要求下，项目组只有缩减需求。 被抽调从事项目外的工作。在9月以前，项目组成员经常被抽调去进行其他工作，例如编写标书，项目成员认为在4月-9月之间基本上没有进行太多的工作，这段时间内的有效工作是需求和高层的设计。 需求的问题也导致了在计划被打断时调整的随意性。在整个开发过程中项目人员变动较大，受外界影响也很大，出现冲突时项目选择了削减需求的策略。 计划存在阶段，但成员对阶段的结束点和完成标志感觉不清楚因为工作流项目不是一个面向直接用户的产品，而是一个面向应用开发的基础服务产品，因此没有很明确的像MIS项目的交互式功能类型的需求，项目组在需求完成后无法获得对用户价值或“可视化”结果的主观感觉。
在处理这种类型项目上，以后的项目应该注意这点。我建议采用“领航者”项目来解决这个问题，即项目需求确定一个应用项目，可以是外部的，也可以是自己根据应用场景建立起来的，关于这个问题，以后的项目可以参考《软件架构：组织原则与模式》一书。这主要是让应用来驱动项目，并让项目组感到每一个完成点带来的价值。
项目的有效开发时间短前面已经提到9月以前项目的工作基本上提留在需求和部分的前期设计上，9月是项目的主要开发期，10月份项目成员有部分被抽调出去，10-11月集中在引擎的完善和增加外围部件。12后项目为了准备结项验收基本上结束了开发。基本上看来，项目整个的有效开发工作量约为5月*5人=25人.月，这对于像J2EE工作流应用这类产品来说太少了。
值得保持的地方 每周的周例会，短小，但起到了了解计划、解决问题的作用。实际上周例会起到了项目周计划的作用。 单元测试成为有效的检测手段。项目组采用JUnit的测试技术，对错误的查找、提高开发质量起到了很大的重要，另外在没有其它检测手段的情况下，可以在一定程度上反映任务的完成。建议以后在项目中推广XUnit测试技术（Java的JUnit,C#的NUnit/csUnit等）。 需要改进的地方 RUP过程组织不成功虽然项目是按照RUP方式来组织项目，但并不成功。阶段的划分比较机械，迭代的概念并不完整，阶段的划分和迭代的周期显得不合理，这也跟项目组的计划受外界影响可能有直接关系。从目前看，RUP并没有在我们内部真正使用好，RUP过于庞大复杂，建议以后的项目要慎重，不要机械的使用RUP。
公司内的工程管理活动并没有给项目组带来实际的价值SQA活动被要求，但并没有太多实际价值(改进活动)。这些活动包括组织（SQA部门）对项目活动和文档的评审，缺少对项目组真正有帮助价值的管理，这些是与组织的过程管理成熟度是有关的，在不成熟的组织，容易成为形式，并带来负面影响。
建立架构组负责项目的关键决策项目组没有一个明确的架构人员或架构组，以至于在一些项目项目的整体的构架决定上无法及时决策。在关键需求的定义、应用的验证和目录数据库技术引入等决定上都有影响。但对于每一部分具体的逻辑设计，构架组的作用并不明显，因此这里的构架组主要担任一种决策的职责。
但项目组同时也建立了与系统结构一致的组织：引擎组、建模工具组、原型组，这种结构应当是合理的，符合系统的特征，只是在进行的过程中，3个小组的节奏不太一致，难以形成一个整体的感觉，如果存在构架师或构架组也可能使他们更容易形成一个整体。
项目需要就总体计划保持一致同时也发现项目组成员对整体的计划没有很好的理解。虽然项目经理公布了进度，但因为总体计划经常变化，以至于在成员心中没有了权威性，这一点也可以说与需求的变化和外部的干扰有很大的关系。当然项目组如果能够控制变更的节奏（如两周或一月才基线化变更，而不是一有变化就引入给其他成员）和更有效的方式来反映进度（如进度图表、测试通过率等形式化手段），也可能会有改进。
说明: 本文的主要目的仅为帮助项目成员和外部人员通过项目的总结获得有价值的经验，了解项目的情况，并不证明项目本身的成功或失败。内容来自于交流获得的信息，虽然力求真实，但仍然带有很多个人的判断，需要注意。
本文地址：http://com.8s8s.com/it/it37207.htm