09组团队项目-中期总结

一、Alpha冲刺链接

冲刺轮次我的博客链接
Alpha 1/609组团队项目-Alpha冲刺-1/6-CSDN社区
Alpha 2/609组团队项目-Alpha冲刺-2/6-CSDN社区
Alpha 3/609组团队项目-Alpha冲刺-3/6-CSDN社区
Alpha 4/609组团队项目-Alpha冲刺-4/6-CSDN社区
Alpha 5/609组团队项目-Alpha冲刺-5/6-CSDN社区
Alpha 6/609组团队项目-Alpha冲刺-6/6-CSDN社区

二、团队名片

队长博客链接:https://bbs.csdn.net/topics/609373872

团队logo:

在这里插入图片描述

团队ID号与团队名称:09 叔叔阿姨菜菜捞捞

团队现场答辩总结:

1.后期添加用户自主上传菜品(需审核)功能
2.小程序上线
3.需解决用户达到一定数量后访问数据库速度问题
4.前端页面功能不丰富

团队讨论的真实照片:

在这里插入图片描述

本次作业的具体分工和得分比例:

具体分工贡献指数
黄森后端整合+服务器部署+项目展示+博客编写109%
瞿林杰博客编写+数据库部分+后端框架111%
廖诚杰博客编写+推荐算法+后端框架80%
陈诗琪统筹前端制作+进度审查100%
杨智宏ppt制作+前端页面制作101%
赖怡澄ppt制作+前端页面制作100%
李雪英介绍视频制作+前端页面制作99%
梁佳莺介绍视频制作+原型设计个人部分100%

三、总结思考

3.1 设想和目标

3.1.1 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?

我们的软件需要解决的是用户在学校内的美食选择问题,对于我们软件的定义是做到最直接的美食推荐。我们的软件主要面向校内选择困难症患者、一时间不知道想要吃什么的用户、还有对于校内某一美食有吐槽/分享欲望的小伙伴。当有人站在食堂不知道想吃什么时,当有人纠结于食堂的某个美食是否能能迎合自己的口味时,这款软件就大有作为。

3.1.2 我们达到目标了么?

我们的软件目前完成了大致的架构,由于目前处在开发的中期阶段,在这个阶段的目标基本上按时达成了。这个阶段我们对于用户数量还没有要求。

3.1.3 用户量,用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

目前还在内部测试中,就组内测试来说基本上达到了这个阶段的目标(有些没有想到的功能会在后续加入)。

3.1.4 有什么经验教训?如果历史重来一遍,我们会做什么改进?

首先就是,我们没有加上用户自主添加美食信息的功能,这一重要功能没有实现确实让软件减分不少,如果重来的话我们一定会及时加上!!其次,就是据说关于用户达到一定量级后,数据库访问速度问题,由于我们目前还在内部测试,用户数量远远低于这个数目,没有考虑到这方面,考虑欠佳(重来的话会做一些修改)。

3.2 计划

3.2.1 是否有充足的时间来做计划?

时间还是比较充足的,可能由于拖沓问题后端到最后才勉强做出来。

3.2.2 团队在计划阶段是如何解决组员对于计划的不同意见的?

计划阶段的话基本上是组长统筹的,队内都很默契,基本上没有不同意见,出现分歧时都能通过私下沟通解决。

3.2.3 原计划的工作是否最后都做完了? 如果有没做完的,为什么?

这阶段的计划工作倒是基本上做完了,但是存在一些考虑欠佳的问题导致功能不太完善。

3.2.4 有没有发现做了一些之后看来没必要或没多大价值的事?

由于基础不足问题,这个阶段的学习时间成本比较高,就对于这个阶段来说,我们在某些方面的学习过于深入,浪费了一些时间,导致没有足够时间去完善重要功能。

3.2.5 是否每一项任务都有清楚定义和衡量的交付件?

对于后端和前端交互的要求、需要完成的任务都比较清楚地体现在文档中。

3.2.6 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

项目大体上按照计划进行,首先就是,我们没有加上用户自主添加美食信息的功能(可能大家都打算通过后端这边手动录入美食信息,没有考虑到工作量和后续工作的问题),其次就是用户多了以后数据库访问速度问题,由于我们目前还在内部测试,用户数量远远低于这个数目,没有考虑到这方面。

3.2.7 在计划中有没有留下缓冲区,缓冲区有作用么?

留下的缓冲区太短了,有作用但是又没有作用(只完善了部分功能)

3.2.8 将来的计划会做什么修改?

多开会多沟通,不拖沓不懒散。设置足够长的缓冲区,加班方面看项目具体完成度

3.2.9 学到了什么? 如果历史重来一遍, 会做什么改进?

计划很重要,尤其是对于时间的分配(一些拖沓导致项目做得比较急,然后就是没有留够缓冲区),重来一遍的话组内会提前安排好各个时间段的任务,根据计划的完成度相应地分配下一阶段的任务,多沟通了解各个部分完成的情况。

3.3 资源

3.3.1 我们有足够的资源来完成各项任务么?

资源是足够的(但是要学的东西有点多,时间不够,而且人数也比较少,相对于其他组来说人力资源比较欠缺)

3.3.2 各项任务所需的时间和其他资源是如何估计的,精度如何?

估计基本上就是凭个人感觉,精度波动较大(有时准有时不准)

3.3.3 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试的时间较短 ,人力的话我们的人数比较少,任务量就会比较大,这方面相较于其他组还是不够的,除此之外,就其他资源来说倒是足够了。我们组内对于美工设计、文案、视频制作都很满意,没有低估难度。

3.3.4 你有没有感到你做的事情可以让别人来做(更有效率)?

组内的任务分配还是很合理的,每个人的任务量都挺大的,即使存在让其他组员来做自己的任务更有效率的问题,也不可能再给其他人增加任务量。

3.3.5 有什么经验教训? 如果历史重来一遍, 会做什么改进?

对于我们的能力有一定程度的高估,在人力资源上估计不太准确,导致项目做得比较急、比较赶。重来的话,我们会对于人力资源有更加清晰的认识,不会出现想这样人少还拖沓的问题,对于测试的时间也会安排得更加合理。

3.4 变更管理

3.4.1 每个相关的员工都及时知道了变更的消息?

是的。当后端的接口需要添加其他的返回值,后端成员会告诉后端的组长,组长与前端组长通过qq群沟通,前端组长会收集整理告知给前端的组员。当前端发生了变更时,同理。

3.4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?

主要还是通过团队讨论。在Alpha会议之初,我们通过站立会议讨论了我们必须实现的六个接口与功能,例如点赞、推荐、收藏、分享、查看美食等等。有几个比较难的功能,例如登录,还有几个没有那么重要的功能,例如分享、加好友,我们在Alpha阶段暂时还没有实现,打算放在Beta阶段来实现。

3.4.3 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

有。我们的平台是微信小程序,我们目前对于做好了定义就是完成我们在设计之初所需要的所有的功能。站在使用者的角度来说,能够流畅、舒适地使用我们这个软件来推荐美食。

3.4.4 对于可能的变更是否能制定应急计划?

制定了应急计划。在制定项目时,我们对于一些功能分歧比较大的地方制定了第一方案与应急方案来处理那些我们可能遇见的变更。但是在目前看来,我们所做的变更还没有达到我们需要启动应急方案的地步。简单来说就是:制定了但还没使用过。

3.4.5 组员是否能够有效地处理意料之外的工作请求?

能。在项目的实现的过程中,我们还是遇到了许多意料之外的事情,一般我们在遇到这样工作请求时,询问他/她的意见,评估他/她的剩余时间,给一个较为宽松的时间限制。基于这种条件下,组员一般能很好的地处理意料之外的请求。

3.4.6 学到了什么? 如果历史重来一遍, 会做什么改进?

在这变更管理模块,我们学到了人与人沟通之间的重要性,变更的反馈决定了我们的更新速度。如果历史重来一遍,我们会加快我们的变更反馈的过程。

3.5 设计/实现

3.5.1 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

产品思路的设计是在初期答辩之前做好的设计,是在柯老板上课提出的创意。至于代码方面的设计是在前两次阿尔法冲刺阶段逐步确认下来,先确定使用前后端分离设计,然后确定前后端框架,是大家共同完成的。时间相较比较晚,因为前期花费了很大的学习成本,大家共同参与确定我觉得是很合适的。

3.5.2 设计工作有没有碰到模棱两可的情况,团队是如何解决的?

遇到模棱两可的情况时,我们会更加全面的考虑两者的差别,可能在某些方面a方案和b方案差不多,但是或许从长期维护难度,可拓展性等方面b的表现会更好。

3.5.3 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?

我们主要通过单元测试来帮助设计和实现,通过人工静态监察法进行检查算法逻辑正确性,接口正确性,输入参数正确性,其他方法接口正确性的检查。还有利用postman惊醒

3.5.4 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

用例图变得更加的详细,由于在初期报告之前,没有很明确各种方法以及接口,用例图比较简单,在各种接口确定之后,用例图变得更加详尽,会对uml文档进行更新。

3.5.5 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

后端接口部分部署到服务器上bug最多,原因我认为有以下几点,首先是数据库结构设计的有些复杂,增加了出现bug的可能性,然后还有就是本地测试框架时,框架设置与部署到服务器上时有一些设置没有事先进行调整,以及没有链接服务器数据库的经验。

我认为没有想到的原因主要处在设计时间太短,没有事先想好更为简洁的数据库的结构,然后是缺少服务器上开发的经验,导致了这个环节的bug很多。

3.5.6 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

由于是前后端分离式开发,后端的代码复审其实是通过postman进行接口测试,测试各类数据,查看各类返回值是否正常,各类接口是否能够正常访问。

前端则是在微信小程序开发程序上进行,先使用模拟数据进行测试,以确保不出现错误。

按照先前确定的接口文档执行代码规范。

3.5.7 学到了什么? 如果历史重来一遍, 我们会做什么改进?

其实要尽早进行设计的确定以及完善,不然会压缩很大一部分后面实现的时间。

如果历史重来,会先大致确定设计后,开始设计接口,尽早将工作进行到实现阶段。

3.6 测试/发布

3.6.1 团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?

暂时还没有,我们Alpha阶段主要是进行一个代码的完善工作,许多功能还没有实现,所以我们暂未指定测试计划与正式的验收测试。

3.6.2 团队是否有测试工具来帮助测试?

有的。举个例子,我们后端在编写接口时,使用了postman来测试接口能否工作。在前后端连接时帮了大忙。

3.6.3 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?

各个模块的测试分配给各个测试组员,这些组员进行用例测试。从软件实际运行的结果来看,这些测试工作还是挺有用的,比如可以测试出一段JavaScript代码或PHP代码对于边界数据的处理是否合乎期望,测试能否成功连接数据库以及相应的SQL语句的是否正常执行等等。改进的方面就是大家应该在如何运用测试软件上多做些学习,这样可以保证正确的执行测试任务同时节约时间提高效率。

3.6.4 在发布的过程中发现了哪些意外问题?

在前后端连接的过程中,我们遇见了许多的问题,连接失败、服务器无法响应、相关接口、服务器配置不当出现错误等等的情况。

3.6.5 学到了什么? 如果历史重来一遍, 会做什么改进?

我们应该尽早指定测试计划,尽早的进行发布工作,不然会导致我们在冲刺的后期阶段赶进度,影响发布的质量。

3.7 团队的角色,管理,合作

3.7.1 团队的每个角色是如何确定的,是不是人尽其才?

在我们第一次开会时,我们确定了我们团队项目的各个角色分配,我们的团队人数较少,只有八个人(其中包括5个女生与3个男生),我们认为我们团队的女生的审美在一定程度优于我们团队的男生,所以我们决定让女生来实现前端开发的工作,并指定了前端的小组长,让前端小组长来决定前端工作的具体分配。后端同理,我们也确定了后端的组长来负责后端任务的具体分配。目前看来,我们的团队确实是人尽其才。

3.7.2 团队成员之间有互相帮助么?

肯定是存在的。我们认为相互帮助才能让我们的团队进步的更加快速。当我们在编写代码时遇见了不会且没有办法解决的问题时,就会寻求其他队员的帮助。人多力量大,在这种情况下,我们遇见的大部分问题都能迎刃而解。

3.7.3 当出现项目管理、合作方面的问题时,团队成员如何解决问题?

主要还是通过沟通来解决,如果在两个人之间的讨论无法达成一致,会引入第三个人,一次类推。如果问题看法还存在问题,我们会专门开会讨论。

3.7.4 每个成员明确公开地表示对别人帮助的感谢

感谢前端团队,感谢诗琪为我们制定好前端计划,带领毫无基础的我们一步一步完成前端页面。感谢佳莺,智宏,雪英,大家互帮互助,完成了一份份前端页面。
感谢后端的男生们,真的很厉害,是我们这次项目的核心!

3.8 总结

黄森

先讲讲不足,首先是时间分配上的问题,由于我经常性的拖拉,以及没有注意时间剩余,还有前期花在确定框架以及学习的成本过多了,导致了后期真正开发的时间不足,导致a冲刺末尾的产品功能还是很简陋。还有个人的事情太多所以没有很好的关注项目的各类进度,导致了进度过于缓慢。

其次是前后端的交流太少了,没有好好的确认接口需求,导致了后面,开发不断推翻,修改,浪费了很大一部分的时间。

收获很多,首先是学习到了后端框架的知识,以及数据库和服务器方面的知识。然后大家都很积极地完成任务,例如诗琪会很主动的push前端任务的实现进度,使得前端页面很快的完成了。也同时学习到了前后端分离开发的具体流程。

瞿林杰

  • 时间分配真的很重要,不合理的时间分配导致我在Alpha冲刺前期时间较为宽松,在冲刺后期赶工完成功能,导致我们很多预想的模块与功能没有完成,最后的结果也是差强人意,希望我们在Beta冲刺阶段能够在开会之初制定好更为具体的计划,来保证我们每天的工作量达到理想的状态。
  • 面对面的讨论,我们在Alpha冲刺采用的大部分是线上的站立会议的形式,有的时候出现的问题不能及时反馈。且线上会议的讨论氛围等等也不如线下的会议。
  • 在这过程中也学习了很多的技能,了解了数据库的建立,flask框架的使用,后端的开发工作,接口的撰写。总体来说还是收获满满。
  • 在这也要感谢一下我们组员的努力,我们无论是前端的页面还是ppt与视频的制作都非常精美。在这次的冲刺中。我个人的工作量不够,脱了团队的后腿,呜呜呜。

廖诚杰:

这次冲刺的话就个人来看还是挺成功的(学了很多东西:flask框架、一些推荐算法、提升了python的代码能力…),组内的成员们也都很给力,前端的页面做得很好看(基本上和漂亮的原型差不多,甚至有些地方有所超越),制作的视频也很精致(完全代表了我们组内制作视频的最高水平)。然后组长ss也很帮忙,直接就到我宿舍敲代码(代码能力超强的,还给我提供了数据录入的思路),林杰和我沟通得也很及时,因为做算法要访问数据库,他负责的数据库有什么改动通知得很及时,建立的数据库也很符合我的要求,很大程度上方便了代码的编写。接下来就是一些问题,用户自主录入美食数据的重要功能我们没有考虑到,然后自己干活有点拖沓了,多多少少导致了后来测试的时间不够(拖累了前端的同学,对不起!)。最后还是要赞美一下组员们(实在是太强了)。

梁佳莺:

本次冲刺确实学到了很多东西,刚开始配uni-app环境的时候就非常一波三折,装node和npm,以及idea连上微信小程序,由于我的电脑比较不争气,所以花费了大家比较多的时间来解决,中间git也出了点小问题但也迎刃而解。然后是一些前端界面的书写,刚开始自己什么都不会,后来查了一天关于vue3的语法,加上之前对html、css、js的理解,成功书写完了第一个界面,最初自己是根据绝对高度来定义界面的,因为不是很会水平垂直的布局,后来发现不同的机型就会出现相应的偏差,一定要通过相对高度%来书写才行,并且在前后端交接的时候,数据其实是传到组件上的某个元素中,所以写上去的时候一定要写成组件封装的新式。自己的其他界面在书写过程中并没有太大问题,主要是主界面改了很多遍,把零零散散的元件组成组件和相对化,中间还有一些莫名其妙的报错,最后几天就是接口方面,这一块自己确实不大会,是同学手把手教我的,并根据她们的格式来写相应的接口,但实际上我自己也没有很深入的了解,希望有机会能继续学习。后端的小伙伴也非常给力,做出了推荐算法,搭建出了框架,并且完成前后端的交接。中期答辩的前一天,被分配到了剪视频的小任务,很久没剪视频的我和小伙伴一起讨论,然后尝试各种素材,说着自己的创意点,中间的过程真的非常快乐,但感觉剪视频也没用想象中的那么简单。总之这次收获的还是非常多的!

陈诗琪:

​ 这次冲刺我非常的充实且收获很多。首先,作为一个以前从来没有接触过Vue的人,我必须在这两个星期上手Vue3和uni-app,包括学习并实践响应式编程和前后端交互,并额外学习了js箭头函数、Promise等特性。还大大增强了自己的团队合作能力,包括git仓库管理、前端进度把控和任务分配等等。跟大家一起开发一个项目虽然辛苦,但是学到了很多东西,感觉很有成就感。团队的大家都非常不错,前端的UU们都很积极,任务完成的保质保量。当然我们也存在一些问题,包括开发过程耗费了太多时间,导致没有充足的时间进行联调和测试。接下来的β冲刺,在继续推进开发的同时,还要完善现有的页面,包括优化样式,增加代码注释,封装新的通用组件等等。

赖怡澄:

在本次阶段学习了许多东西。首先是配置uni-app环境与git仓库的连接与微信小程序与vscode连接,这里出现了许多问题,如:git连接不上,环境配置不成功等,但通过查询资料与询问队友都成功解决。其次是前端页面的编写,因为自身对于前端没有什么基础,因此只能从零开始学习,学习了vue3 的语法,js语言等,从图片插入的学习到button,swiper组件等学习运用,逐渐熟练编写前端页面。期间也出现了许多问题,如轮播图的插入,如何消除按钮的边框,如何设置动作点亮星星收藏等,通过不断地搜索与和同学讨论,也逐一地攻破各个问题。最后一块是前后端交互中端口编写的部分,这是我认为最难的一块,因为对于接口,我本身是非常陌生的,所以无从下手。通过B站的视频学习,勉强写出,但这个接口还是出现许多问题,在同学的帮助下,通过不断修改才得以运行。这次冲刺,提高了我的学习能力与解决问题能力。团队中的每个人都很认真负责,团结一致,在制作PPT展示团队的成果时,还是非常有成就感的,虽然还是有许多进步的空间,但仍感到收获满满,受益匪浅。

李雪英

冲刺阶段还是非常有意思的,虽然很多东西都是从小白开始做起,但是与队友们互相学习一起讨论进步,最后做出成果的时候是非常有成就感的。在这个过程当中也感受到了要分工明确与合理计划的重要性,有一个规划能力很强同时push能力一流的小组长让我们的工作有条不紊的进行,不会积在最后才去完成。中期汇报前一天剪辑视频的时候,与搭档商量了很久剪辑的想法,到晚上十一点拿到视频剪辑到凌晨两点但是成品很可爱的时候,感觉到了满满的成就感,那种一起奋斗然后得到结果的感觉真的超好。不过最后在答辩的时候还是发现了我们小组的不足之处,希望接下来我们小组继续努力,弥补不足,共同进步!

杨智宏:

​ 这次冲刺“冲刺”得名副其实,天天都在冲刺!最真实的感受就一个字:累die 高情商:太充实了!First,作为小白,学习成本好高,光是学前端三件套就花了好多时间,再加上配环境、vue3语法,一波三折中对前端编写有了更深的认识。同时,一些边角技能,比如文档撰写、ppt制作、视频剪辑也得到了提升。团队编程中,我十分感谢队友给予的帮助和鼓励,特别是前端小组组长诗琪同学,非常有担当和规划!也非常有耐心!在她的引导下,前端小组工作进度和工作质量超乎预期。当然我们也存在不少问题,比如测试时间预留得比较少、产品思维不够完善、对于数据隐私的处理有待完善、前端页面样式还需要做出细微调整等等……正如ke老板说的,我们α阶段的进度还不够,β冲刺需要更冲刺一些;希望下一阶段我们能够补缺补漏,站在用户角度对产品功能进行进一步的优化,一起加油叭!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值