德国电信数据分析平台—项目总结
2014-03-28 16:08
274 查看
德国电信数据分析平台—项目总结
经过一年多的艰苦努力，电信数据分析项目终于结束，回想我们团队当初从 不熟悉技术、业务以及开发流程的新兵到现在久经磨练老战士，经过了无数个灯火通明的夜晚，我们的付出已经获得了几个阶段性的成果，并得到了一线用户和发包 方客户的高度认可。下面就项目中几个方面进行总结：
1、项目进度
从项目工作任务书中约定，项目原计划从2010年12月启动到2011年6月底结束，而实际结束到2011年8月底，延期将近2个月，可以看出工期有30%的增加。其中分析原因有：
（一）设计规格
（1）项目设计需要的设计人员经验没有根据项目的实际情况而投入，并且设计人员太少；（2）设计人员对数据统计分析型报表系统设计经验不足；（3）对报表制作工具Cognos的实现报表过程基本不了解，造成设计结果要求与开发工具实际可支持功能脱离；（4）设计规格内容在起初设计时没有根据数据统计分析（报表）系统定出合理描述模板，也是设计成果不能很好适应开发需要的原因。
（二）规格变更
需要、规格的变更是我们这个项目特别突出的现象，前期迭代开发人员拿着 规格文档只是完成功能，对一些公用组件由于没有详细规定只能实现基本的功能，对用户操作细节和界面风格等更是缺少详细的标准要求，而在后期迭代，设计人员 对一些标准逐渐确定后才给开发人员提出实现要求，导致前期开发已经完成或正在开发的功能投入了大量的重复修改时间；
项目中同时出现了一定的“特征蠕变”现象：即将额外增强功能逐渐纳入到计划之内的趋势，而之前由于设计没有预计到这种情况在一定程度上的发生，当它发生时给迭代内开发工作造成一定的压力，这样就会出现开发人员加班加点赶工期，经常疲劳工作。
（三）新业务、新技术
由于项目涉及新业务、新技术，特别是开发人员需要熟练使用技术高效率开发必须经过一定的业务熟悉和技术锻炼，所以前期需要投入学习的时间。
针对以上的情况我们在前期对工作量的估算时没有充分考虑到，对工作量的估算偏小，导致为了追赶进度，开发人员几乎每天都在加班、周末也被作为正常的工作时间，当然其中也有一定的商务原因，希望在以后的项目中能客观的估算项目周期和工作量，让团队能保持长期正常的工作状态。
综上所述：通过本项目的迭代开发模式，可得出这种模式是典型的时间周期与完成功能数量的“S”型关系，我简单的画了个图示如下：
迭代周期与完成功能数量S关系
2、项目质量
作为一个项目组团队要完成一个新产品的研发，各个环节都涉及到我们在工 作中需要不断学习和改进的地方。在前期迭代中，测试组提出了一批批的问题单，其中有开发人员不仔细导致，也有规格不清晰导致，但是归根结底需要我们项目组 的每位成员有很好的质量意识，分析每一个问题发生的原因，处处把工作做扎实、做到位，握好每一个环节，质量风险会降到最低；当然我们也需要有一个健全的质 量管理体系，用制度来辅助管理好质量。
3、项目风险
下面列举一下主要的风险：
（1） 技术风险：项目使用了比较新的Cognos报表工具，由于开发人员没有使用过此工具的经验，前期是一边学习一边开发，在开发过程中遇到了很多技术难题，给开发进度和质量造成了一定的风险。对于技术上的风险，我们在请教了Cognos的技术专家，并进行了多次的培训指导，在日常的开发过程中也安排专人研究攻关技术难题，这一系列工作保证了开发工作的顺利进行，让我们的团队从中积累了不少宝贵的技术经验。
（2） 规格风险：项目前期规格描述比较粗糙，在后期逐渐暴露出现了“特征蠕变”现象：即将额外增强功能 逐渐纳入到计划之内的趋势，而之前由于设计没有预计到这种情况在一定程度上的发生，当它发生时给迭代内开发工作造成一定的压力。面对如此的设计，开发人员 只能不断的与设计人员沟通确认，加班加点工作，把由于设计不到位造成的影响降到最低。
（3） 质量风险：在前期开发人员与设计人员由于理解不一致导致了一些开发结果偏离设计的现象；在后期由 于变更大量发生，开发人员为了追赶工期长期加班加点，疲劳的工作状态也造成了一定的质量问题。项目组为了提高开发质量，除了要求开发人员做到单元测试，还 专门增加了内部测试人员，在功能被开发完成后进行相应的集成测试，避免了显而易见的问题暴露出去。
（4） 成本风险：对于我们外包项目成本，投入的人力和得到的工作量是否平衡决定了我们的项目的成本是否被控制在合理范围中。从现在统计看，我们的人力的投入已经超过了发包方给予我们的工作量，分析原因主要有以下几个方面造成：（1）项目的初始工作量估算只是从发包方提供当时看似比较粗糙、简单的规格文档为依据；（2）对实现过程技术风险估计不足；（3）对业务规格文档自身不能很好指导开发存在风险估计不足；（4）开发后期基本界面规范才确定风险没有预计；（5）开发中期大量的变更发生导致开发重复工作风险估计不足；（6）在变更发生时，对变更工作量估算偏少，主要考虑了编写代码时间，忽略了测试、联调、VT等环节用时；（7）最后还有项目的大的里程碑计划进行了多次延后，导致人员投入不能按任务书计划的时间释放也是造成了人力大量超额投入。
针对成本问题，我们在以后项目中要从项目起初的需求范围、规格文档和技术选型等几个方面考虑，并对工作量估算要多次评审决定；在后期需 求变更发生时，要考虑全面的工作范围，而不仅仅是编写代码；也希望发包方能在项目计划延后时，提早通知我外包项目负责人，并说明延后原因和时间，我外包方 针对延后情况商讨后给出延期导致成本增加的回复。
4、项目范围
我们外包的项目分为三块，其中报表组完成了21个第一类业务统计分析应用模块，其中包括18张报表和3个非报表功能；还有30个第二类业务统计分析应用，其中包括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人；其中组长都是带领大家日夜鏖战的带头人，他们付出了常人无法忍受的代价，他们是报表组的XXX、XXX、XXX等、负责MR组的XXX、负责配置管理组的XX；还有我们派到发包方工作的XXX、XX、XXX都得到发包方负责人的高度赞扬，他们就是我们团队的“花木兰”；当然还有很多在默默奉献的好兄弟，如Cognos技术专家XXX、设计专家XXX、行政助理XXX等等。
总结人：mgjava@163.com
2012-03-1913:10
经过一年多的艰苦努力，电信数据分析项目终于结束，回想我们团队当初从 不熟悉技术、业务以及开发流程的新兵到现在久经磨练老战士，经过了无数个灯火通明的夜晚，我们的付出已经获得了几个阶段性的成果，并得到了一线用户和发包 方客户的高度认可。下面就项目中几个方面进行总结：
1、项目进度
从项目工作任务书中约定，项目原计划从2010年12月启动到2011年6月底结束，而实际结束到2011年8月底，延期将近2个月，可以看出工期有30%的增加。其中分析原因有：
（一）设计规格
（1）项目设计需要的设计人员经验没有根据项目的实际情况而投入，并且设计人员太少；（2）设计人员对数据统计分析型报表系统设计经验不足；（3）对报表制作工具Cognos的实现报表过程基本不了解，造成设计结果要求与开发工具实际可支持功能脱离；（4）设计规格内容在起初设计时没有根据数据统计分析（报表）系统定出合理描述模板，也是设计成果不能很好适应开发需要的原因。
（二）规格变更
需要、规格的变更是我们这个项目特别突出的现象，前期迭代开发人员拿着 规格文档只是完成功能，对一些公用组件由于没有详细规定只能实现基本的功能，对用户操作细节和界面风格等更是缺少详细的标准要求，而在后期迭代，设计人员 对一些标准逐渐确定后才给开发人员提出实现要求，导致前期开发已经完成或正在开发的功能投入了大量的重复修改时间；
项目中同时出现了一定的“特征蠕变”现象：即将额外增强功能逐渐纳入到计划之内的趋势，而之前由于设计没有预计到这种情况在一定程度上的发生，当它发生时给迭代内开发工作造成一定的压力，这样就会出现开发人员加班加点赶工期，经常疲劳工作。
（三）新业务、新技术
由于项目涉及新业务、新技术，特别是开发人员需要熟练使用技术高效率开发必须经过一定的业务熟悉和技术锻炼，所以前期需要投入学习的时间。
针对以上的情况我们在前期对工作量的估算时没有充分考虑到，对工作量的估算偏小，导致为了追赶进度，开发人员几乎每天都在加班、周末也被作为正常的工作时间，当然其中也有一定的商务原因，希望在以后的项目中能客观的估算项目周期和工作量，让团队能保持长期正常的工作状态。
综上所述：通过本项目的迭代开发模式，可得出这种模式是典型的时间周期与完成功能数量的“S”型关系，我简单的画了个图示如下：
迭代周期与完成功能数量S关系
2、项目质量
作为一个项目组团队要完成一个新产品的研发，各个环节都涉及到我们在工 作中需要不断学习和改进的地方。在前期迭代中，测试组提出了一批批的问题单，其中有开发人员不仔细导致，也有规格不清晰导致，但是归根结底需要我们项目组 的每位成员有很好的质量意识，分析每一个问题发生的原因，处处把工作做扎实、做到位，握好每一个环节，质量风险会降到最低；当然我们也需要有一个健全的质 量管理体系，用制度来辅助管理好质量。
3、项目风险
下面列举一下主要的风险：
（1） 技术风险：项目使用了比较新的Cognos报表工具，由于开发人员没有使用过此工具的经验，前期是一边学习一边开发，在开发过程中遇到了很多技术难题，给开发进度和质量造成了一定的风险。对于技术上的风险，我们在请教了Cognos的技术专家，并进行了多次的培训指导，在日常的开发过程中也安排专人研究攻关技术难题，这一系列工作保证了开发工作的顺利进行，让我们的团队从中积累了不少宝贵的技术经验。
（2） 规格风险：项目前期规格描述比较粗糙，在后期逐渐暴露出现了“特征蠕变”现象：即将额外增强功能 逐渐纳入到计划之内的趋势，而之前由于设计没有预计到这种情况在一定程度上的发生，当它发生时给迭代内开发工作造成一定的压力。面对如此的设计，开发人员 只能不断的与设计人员沟通确认，加班加点工作，把由于设计不到位造成的影响降到最低。
（3） 质量风险：在前期开发人员与设计人员由于理解不一致导致了一些开发结果偏离设计的现象；在后期由 于变更大量发生，开发人员为了追赶工期长期加班加点，疲劳的工作状态也造成了一定的质量问题。项目组为了提高开发质量，除了要求开发人员做到单元测试，还 专门增加了内部测试人员，在功能被开发完成后进行相应的集成测试，避免了显而易见的问题暴露出去。
（4） 成本风险：对于我们外包项目成本，投入的人力和得到的工作量是否平衡决定了我们的项目的成本是否被控制在合理范围中。从现在统计看，我们的人力的投入已经超过了发包方给予我们的工作量，分析原因主要有以下几个方面造成：（1）项目的初始工作量估算只是从发包方提供当时看似比较粗糙、简单的规格文档为依据；（2）对实现过程技术风险估计不足；（3）对业务规格文档自身不能很好指导开发存在风险估计不足；（4）开发后期基本界面规范才确定风险没有预计；（5）开发中期大量的变更发生导致开发重复工作风险估计不足；（6）在变更发生时，对变更工作量估算偏少，主要考虑了编写代码时间，忽略了测试、联调、VT等环节用时；（7）最后还有项目的大的里程碑计划进行了多次延后，导致人员投入不能按任务书计划的时间释放也是造成了人力大量超额投入。
针对成本问题，我们在以后项目中要从项目起初的需求范围、规格文档和技术选型等几个方面考虑，并对工作量估算要多次评审决定；在后期需 求变更发生时，要考虑全面的工作范围，而不仅仅是编写代码；也希望发包方能在项目计划延后时，提早通知我外包项目负责人，并说明延后原因和时间，我外包方 针对延后情况商讨后给出延期导致成本增加的回复。
4、项目范围
我们外包的项目分为三块，其中报表组完成了21个第一类业务统计分析应用模块，其中包括18张报表和3个非报表功能；还有30个第二类业务统计分析应用，其中包括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人；其中组长都是带领大家日夜鏖战的带头人，他们付出了常人无法忍受的代价，他们是报表组的XXX、XXX、XXX等、负责MR组的XXX、负责配置管理组的XX；还有我们派到发包方工作的XXX、XX、XXX都得到发包方负责人的高度赞扬，他们就是我们团队的“花木兰”；当然还有很多在默默奉献的好兄弟，如Cognos技术专家XXX、设计专家XXX、行政助理XXX等等。
总结人：mgjava@163.com
2012-03-1913:10
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 