第一次迭代开发心得

通过第一次迭代,我真正意义上地体会到了当程序媛的感觉。有面对bug时的抓狂,有解决bug时的喜悦,也知道了整整一天都在码代码是什么感觉。

接下来就说一说我们组项目(基于联邦型知识图谱上的搜索引擎)第一次迭代的心得。

一、起步

  因为之前大部分时间一直都在写各种各样的文档,所以我们的项目起步比较晚,真正意义上编写代码的时间只有不到两个礼拜。而且,我们当初把项目实现想得过于理想,导致后来时间有些不够用,所幸,在验收前一天,大家一起在图书馆泡一天,最终实现了第一次迭代的需求。这也是下次迭代需要注意的地方,要把进度尽量往前赶,给测试bug留下足够长的时间。这种整整一天都在面对代码的抓狂的感觉并不是很好。。。因为我们做的是关于联邦型知识图谱的项目,而之前对这些名词可以说几乎听都没听说过,而网上与联邦型rdf相关的知识也比较少,所以花了很长的时间去摸索、了解相关专业知识。对于前端方面,由于我们上的JAVAEE课上正好讲网页,所以能够较切合地应用到我们的项目中去。

二、过程

  在整个第一次迭代的过程中,我们小组采取的是按照核心算法实现:前端网页设计:与数据库交互:与服务器交互=3:2:1:2进行分工的,在人员分配上,感觉还是较为合理的,如果哪一模块遇到问题长时间没有解决的话,其它组员会对其帮忙。(但是感觉这样效率比较低。。。)在开发上,我们使用的是eclipse,这里不得不吐槽一下eclipse。。。经常出现更改之后不更新的情况,程序本身没有问题,但eclipse单方面出bug,导致我们在与eclipse斗智斗勇时浪费了很多时间。所以我们决定第二次迭代开发使用idea。在做项目的时候,大家难免会有意见不统一的情况,这必然导致激烈的“争吵”,但在争吵的过程中又能碰撞出思维的火花,会蹦出很多新的点子,有时吵着吵着大家自己都会笑出来。总的来说,组里开发的过程中,气氛还是相当融洽的~~~~

三、结果

  经过种种考验,我们终于将第一次迭代需求大致完成,就在我们长吁一口气时,边老师突然在群里发了一份儿验收要求,仔细一看,我们组当时做的没有几条是符合要求的。于是我们赶紧加班加点按照老师的要求各种改代码,找bug。这也给我们一个教训,不要正好卡在ddl完成项目,一定要留出充足的时间去应对各种突发情况。幸运的是,最终验收结果还算较为满意。

四、心得

  在经过了这段时间的实践之后,对项目有了大致的整体的把握,对各环节有了更清晰的认识与规划。我对联邦行rdf、知识图谱和搜索引擎也有了较为深刻的了解。这对我来说是一个全新的体验。于是从零开始一步步编码开发。在过程中,除了克服自己负责区域的困难之外,对于有需要和软件衔接的问题,还与小组成员一起在一次次的磨合中找出了解决方案,有妥协,有商量,分阶段对成果进行总结,分析,改进,及时调整研究方向的偏差,尽可能地保证了项目质量。

  经历了第一次迭代开发,收获颇丰。我开阔了眼界,勇敢的接受挑战,不畏惧去接触了解不懂得技术。我更清楚的体会到不断充实自己的知识是多么重要,我们不能局限于自己专业的知识,还应该广泛的涉猎。通过实践,我也锻炼了自己行动实施的能力。虽然项目进展过程中我们也遇到了很多困难,但我们小组成员都以积极向上的心态去应对,一次次通过努力越过难关给我们带来了一段段难忘的回忆。

  相信第二次迭代开发我们也会取得满意的成果的!

原文地址:https://www.cnblogs.com/ttyape/p/10085327.html

时间: 2024-08-27 12:13:58

第一次迭代开发心得的相关文章

创新课程管理系统-第一次迭代开发心得

第一次做项目,第一次用javaee开发web工程项目,很多东西不会,摸着石头过河,也学到了很多东西. 第一次迭代开发,小组总体做出来的东西不多,与计划相比少了不少.完成的大致有两个半模块,其一是登录注册,其二是报警信息展示,其三是工单处理,还在技术上研究了动态数据在图表上的动态展示的实现(基于单个数据项的展示).总体来说,很多后台工作没实现,前端做的页面倒是蛮多,交互功能也有,前端的工作进度是先于后台的:后台开发的滞后性,以致于功能模块的集成进度受到了阻碍. 接下来就说一说我们组项目(创新课程管

在线电力监测系统——第一次迭代开发心得

第一次做项目,第一次用javaee开发web工程项目,很多东西不会,摸着石头过河,也学到了很多东西. 第一次迭代开发,小组总体做出来的东西不多,与计划相比少了不少.完成的大致有两个半模块,其一是登录注册,其二是报警信息展示,其三是工单处理,还在技术上研究了动态数据在图表上的动态展示的实现(基于单个数据项的展示).总体来说,很多后台工作没实现,前端做的页面倒是蛮多,交互功能也有,前端的工作进度是先于后台的:后台开发的滞后性,以致于功能模块的集成进度受到了阻碍. 后台人员主要做了登录,注册,验证码验

第一次迭代开发心得——短视频APP项目

第一次迭代开发已经结束将近一个星期了,不管结果如何,完成与否,或多或少有些许收获. 首先知识上,对后台开发有了初步的认识,但是还说不上入门吧,毕竟没有系统的学习,都是做项目缺什么去学什么(很想系统的学一下,说实话的话),最开始的时候连用什么做都不知道,到处去查资料.问学长,学长最后给的建议是用Spring框架,但是去摸了一下,感觉很难理解,就像还不会走路就开始跑一样,然后就得到了一条建议,先从servlet开始(那时候javaee才刚开始servlet又是后面的内容,所以找到这个方式花了不少时间

第一次迭代开发总结

上周进行了Alpha版本项目的验收,为第一次迭代画上了句号.以下是我对本组项目第一次迭代的思考与总结: 设想和目标 1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 产品定义:我们软件定义明确,是为需要使用车辆的用户提供及时租车功能: 典型用户:出差在外上班族: 典型场景:机场. 2. 是否有充足的时间来做计划? 时间充足.每周每位成员都有本周必须完成的各自的任务,所以项目进度比较快. 3. 团队在计划阶段是如何解决同事们对于计划的不同意见的?  通过沟通

第一次迭代开发有感

前言:时光飞逝!第一次迭代开发已经过去大概一周的时间了,有必要来个小结了. 下面我就参考老师给出的模板,来对我们组第一次迭代开发做一个小结. 设想和目标 1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的项目是要做一个创新课程管理系统.根据指导老师的要求,就是做一个适用于本门(软件工程导论)课程的一个管理系统,web端应用程序.具体点来说,就是类似于我们大二上数据结构课使用的超星系统.(而在超星系统中,我们仅仅充当的是学生的角色,上传作业,接收老师发

快易需求文档编辑系统(二期)第一次迭代开发总结

设想和目标 1.目的: 项目为"快易需求文档智能生成系统".软件需求文档是软件开发与维护的重要基础,本项目希望通过建立一个专业的需求文档编辑系统,为软件开发人员提供一个便捷的协作文档编写工具,推动需求文档编写的规范与文档重用工作.同时,也为广大软件公司提供一个随时可以访问的平台,推广快易文档编写系统. 2. 成果:完成了原定计划中所有第一次迭代的功能和部分第二次迭代的功能. 3. 提高:所有成员各司其职,完成了自己的任务,比起最开始的一无所知有了很大的提升 经验教训:团队内需要多交流沟

第一次迭代开发——矢量图编辑系统

设想和目标 1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们设计的矢量图编辑系统主要解决变电站绘制电路图问题: 定义为以矢量图的方式绘制出电路图: 仅及于简单的用户与场景,尚未进行具体典型的用户与场景描述. 2. 我们达到目标了么(原计划的功能做到了几个?  按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?) 我们计划实现画元器件.添加任意元器件.对图形进行放缩.各元器件之间的规则连接.滚动条对画板进行拖动  更大的画图区域.图形元素的点

Team--时代团队第一次迭代总结

一.设想和目标 1.1 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件<flappy bird>是一款全新动作类的游戏,与市面上的存在的游戏不一样的是,我们增加了很多功能.从传统的单人作战,转变为更有趣的团队作战.从传统的单一模式转变为可以选择的游戏模式.游戏因此变得紧张成刺激.节奏感强,玩家在游戏中便能获得更多的乐趣与成就感.从而既解决了flappy游戏相对比较枯燥无聊被动的问题,使玩家能够乐在其中,又不会像大型游戏一样占用玩家过多的时间精力,

第一次迭代总结和思考

第一次迭代上周结束了,总的来说相比较有一开始收获是非常大的.重新开始学习一种语言,熟悉相应的开发环境,掌握编码规则,都是不可多得的体验和收获. 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们软件很明确的定义,就是一个统计实时噪声数据并绘制区域噪声地图,同时提供给用户需要的信息,之后政府也可以根据噪声数据采取针对性的措施 典型用户:学生(目前只能局限在湖大这个群体范围) 典型场景:交通,住房等人的活动区域 我们达到目标了么(原计划的功能做到了几