德国电信数据分析平台―BI项目总结.

1、德国电信数据分析平台 一项目总结经过大半年的艰苦努力，电信数据分析项目终于结束，回想我们团队当初从 不熟 悉技术、业务以及开发流程的新兵到现在久经磨练老战士，经过了无数个灯 火通明的夜晚，我们的付出已经获得了几个阶段性的成果，并得到了一线用户和 发包方客 户的高度认可。下面就项目中几个方面进行总结：1、项目进度从项目工作任务书中约定，项目原计划从 2010 年 12 月启动到 2011 年 6 月底结 束,而实际结束到 2011 年 8 月底,延期将近 2 个月，可以看出工期有 30%的增加。其 中分析原因有：（一设计规格（1 项目设计需要的设计人员经验没有根据项目的实际情况而投入，并且设计人

2、员太少;（2 设计人员对数据统计分析型报表系统设计经验不足；（3 对报表制作工具Cognos 的实现报表过程基本不了解，造成设计结果要求与开发工具实际可支持功能 脱离;（4 设计规格内容在起初设计时没有根据数据统计分析（报表系统定出合理描 述模板，也是设计成果不能很好适应开发需要的原因。（二规格变更需要、规格的变更是我们这个项目特别突出的现象，前期迭代开发人员拿着 规格文档只是完成功能，对一些公用组件由于没有详细规定只能实现基本的功能,对用户操作细节和界面风格等更是缺少详细的标准要求，而在后期迭代，设计人员对一些标准逐渐确定后才给开发人员提出实现要求，导致前期开发已经完成或正在开发 的功能投入

3、了大量的重复修改时间；项目中同时出现了一定的 特征蠕变”现象:即将额外增强功能逐渐纳入到 计划 之内的趋势，而之前由于设计没有预计到这种情况在一定程度上的发生，当它发生时给迭代内开发工作造成一定的压力，这样就会出现开发人员加班加点赶工期，经常 疲劳工作。（三新业务、新技术由于项目涉及新业务、新技术，特别是开发人员需要熟练使用技术高效率开 发 必须经过一定的业务熟悉和技术锻炼，所以前期需要投入学习的时间。针对以上的情况我们在前期对工作量的估算时没有充分考虑到，对工作量的 估 算偏小,导致为了追赶进度，开发人员几乎每天都在加班、 周末也被作为正常 的工 作时间，当然其中也有一定的商务原因，希望在以

4、后的项目中能客观的估算 项目周 期和工作量，让团队能保持长期正常的工作状态。综上所述:通过本项目的迭代开发模式，可得出这种模式是典型的时间周期 与完 成功能数量的“ S 型关系，我简单的画了个图示如下：迭代周期迭代开发周期与完成模块 S 型关系图2、项目质量作为一个项目组团队要完成一个新产品的研发，各个环节都涉及到我们在工 作 中需要不断学习和改进的地方。 在前期迭代中，测试组提出了一批批的问题单，其 中有开发人员不仔细导致，也有规格不清晰导致，但是归根结底需要我们项目组的 每位成员有很好的质量意识，分析每一个问题发生的原因，处处把工作做扎 实、做 到位，握好每一个环节，质量风险会降到最低；当

5、然我们也需要有一个健全的质量管 理体系，用制度来辅助管理好质量。3、项目风险下面列举一下主要的风险：(1 技术风险：项目使用了比较新的 Cog nos 报表工具，由于开发人员没 有使用过 此工具的经验，前期是一边学习一边开发，在开发过程中遇 到了很多技术难题，给开发 进度和质量造成了一定的风险。对于技术上的风险,我们在请教了 Cog nos 的技术 专家,并进行了多次的培训 指导，在日常的开发过程中也安排专人研究攻关技术难题,这一系列工作保证了开发工作的顺利进行，让我们的团队从中积累了不少宝贵 的技 术经验。(2规格风险：项目前期规格描述比较粗糙，在后期逐渐暴露出现了 特征蠕变”现 象:即将额

6、外增强功能逐渐纳入到计划之内的趋势，而之前由于设计没有预计到这种 情况在一定程度上的发生，当它发生时给 迭代内开发工作造成一定的压力。面对如 此的设计，开发人员只能不断的与设计人员沟通确认，加班加点工作，把由于设计不到 位造成的影响降到最低。(3 质量风险：在前期开发人员与设计人员由于理解不一致导致了一些开发结果偏离设计的现象；在后期由于变更大量发生，开发人员为了追赶工期长期加班加点，疲劳的工作状态也造成了一定的质量问题。项目组为了提高开发质量，除了要求开发人员做到单元测试，还专门增加了内部测试人员，在功能被开发完成后进行相应的 集成测试，避免了显而易见的问题暴露出去。(4 成本风险：对于我们

7、外包项目成本，投入的人力和得到的工作量是否 平衡决 定了我们的项目的成本是否被控制在合理范围中。从现在统计 看，我们的人力的投入已经超过了发包方给予我们的工作量，分析原因主要有以下几个方面造成:(1 项目 的初始工作量估算只是从发包 方提供当时看似比较粗糙、简单的规格文档为依据；(2 对实现过程 技术风险估计不足；(3 对业务规格文档自身不能很好指导开发存在 风险估计不足；(4 开发后期基本界面规范才确定风险没有预计；(5 开发中期大量的 变更发生导致开发重复工作风险估计不足；(6 在变更发生时，对变更工作量估算偏少，主要考虑了编写代码时间，忽略了测试、联 调、VT 等环节用时；(7 最后还有

8、项目的大的里程碑计划 进行了多次延后，导致人 员投入不能按任务书计划的时间释放也是造 成了人力大量超额投入。针对成本问题，我们在以后项目中要从项目起初的需求范围、规 格文档和技术 选型等几个方面考虑，并对工作量估算要多次评审决定;在后期需求变更发生时，要 考虑全面的工作范围，而不仅仅是编 写代码;也希望发包方能在项目计划延后时，提 早通知我外包项目负 责人，并说明延后原因和时间，我外包方针对延后情况商讨后给 出延期导致成本增加的回复。4、项目范围我们外包的项目分为三块，其中报表组完成了 21 个第一类业务统计分析应 用模 块,其中包括 18 张报表和 3 个非报表功能；还有 30 个第二类业务

9、统计分析 应用，其 中包括27个报表和3非报表功能；ELT-Hadoop MapReduce组完成41个数据加工 作业;J2EE-配置管理组完成 39 个应用。其中涉及第一类、第二类 业务应用的报 表、MR、配置功能都已经通过多次的验证，现已经上线试运行。5、项目评价项目从开始到现在虽然遇到了一定的困难，但是通过我们与发包方共同坚持 不 懈的努力，终于走到了现在，并且得到了几个阶段性的成果：(1 2011 年 6 月项目顺利进行入了用户测试阶段；(2 2011 年 7 月初，数据分析平台在维也纳成功进行了演示，演示的成功 是对项目 组在内的所有参与项目研发、 交付的兄弟姐妹们最大的肯定和鼓舞，是对兄弟们挑 灯夜战最好的褒奖；(3 在 2011 年 7 月底，项目顺利通过了 TR5 阶段性验收和 TR6 评审，发包方项目 终验 9 月中旬也已顺利通过。本数据分析平台后期在逐步推出新的版本。最后要特别提出的是：项目组从成立到现在人员最多达到 82 人，最多的时 候为 8 个小组，每组 9 10 人;其中组长都是带领大家日夜塵战的带头人，他们付出了常人 无法忍受的代价,他们是报表组的