7组-Beta冲刺-总结
7组-Beta冲刺-总结
一、基本情况
1.1 组长博客链接:
1.2 现场答辩总结:
- 考虑后端向前端传输图片的安全性问题
- 前端搜索框输入提示
- 算法对模糊图像二分识别
- 前后端交互的资源传输优化
- 根据座位框进行图片分类识别
- 前端展示效果优化
1.3 全组讨论的照片:
1.4 贡献比例
前端工作流程:
后端工作流程:
分工比例
二、总结思考
2.1 设想和目标(4分)
2.1.1 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述 ?
- 解决什么问题:
- 解决高校图书馆学生占座现象频繁出现而管理员管理繁琐、不规范、不及时、少证据、多劳动、难服众的问题
2.1.2 我们达到目标了么?(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)
原计划:
- 实现五个页面,分别是:
- 账号密码登陆页面;
- 首页违规行为展示页面;
- 违规行为查询页面;
- 人流量统计页面;
- 设置页面;
- 基本功能:
- 对于长时间(2h以上)在预约系统中处于“使用中”状态但是空置的座位进行证据(图片)记录、向管理员提示、统计记录(以日、周为单位)
实际完成:
- 算法、页面基本完成,但仍有优化空间。
2.1.3 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户对项目的成果基本接受,并表示“人流量统计功能”,“空置座位设置功能”是他意料之外的功能,原来他以为只有“违规行为提示功能”。
- 我们离“一个完整完善的自习室智能管理系统”这一目标更进一步了。
2.1.4 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 功能虽然出乎用户意料,但是从开发者的角度看感觉功能有点少。
- 如果历史重来一遍:
- 考虑在完成首要功能后,再增加一些围绕自习室这一场景的管理功能。
- 考虑进一步从对小人头的检测、对人是否在座位框里的检测、对座位自适应功能三个角度进行算法优化
- 考虑优化图可视化方法,使用更高级的展示方式
2.2 计划(5分)
2.2.1 是否有充足的时间来做计划?
- 计划时间充足,并且尽量做到充分民主讨论、考虑周全、集体决定。
2.2.2 团队在计划阶段是如何解决组员对于计划的不同意见的?
- 公开讨论->头脑风暴->各提意见->投票表决
- 投票中,将要负责相应部分的同学有更高的投票权重
- 技术力比较强/贡献度比较高的同学有更高的投票权重
2.2.3 原计划的工作是否最后都做完了? 如果有没做完的,为什么?
- 算法和后端基本完成,前端由于人手不够和技术原因,稍有延后。
2.2.4 有没有发现做了一些之后看来没必要或没多大价值的事?
- 每个人都要写的博客内容其实不用都单独发给负责博客的人,直接使用腾讯文档多人在线编辑就行
- 站立式会议一天一次可能有些太频繁,平时队员有课有作业,一天内能做的事情其实不多
2.2.5 是否每一项任务都有清楚定义和衡量的交付件?
2.2.6 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
- 后端和算法方面在β4就提前完成了
- 前端的工作量估计出现了“低估”的情况,导致前端后期赶进度压力大
- 团队在前端方面的整体能力相对弱,前端出现意外是因为当时没有估计到是因为少考虑了队员的技术掌握程度
2.2.7 在计划中有没有留下缓冲区,缓冲区有作用么?
- 留下了一天的缓冲区
- 算法和后端方面的工作在缓冲区之前就基本完成了
- 前端在缓冲区中继续完成前后端交互的工作
2.2.8 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
- 本次冲刺中项目整体上在缓冲区前基本完成
- 因此将来的计划中缓冲区大致仍然设置为一天
- 尽量在项目中期完成大部分内容
- 原则上不加班,尽量在最初规划的时候就要留出足够的时间,并且进行合理的规划
- 此外考虑额外设置一段时间用于测试项目
2.2.9 学到了什么? 如果历史重来一遍, 会做什么改进?
- 技术上,每个队友都一定程度上学到了所负责方面所需的知识内容;
- 经验上,磨合了团队,使得队友在团队合作上有了进一步的经验,并且对计划、交接、维护流程有了更深刻的印象与体会;
- 会做什么改进:增设测试、完善、拓展功能的计划
- 会更加关注队员的心态,为队员排解畏难情绪、逃避情绪
2.3 资源(3分)
2.3.1 我们有足够的资源来完成各项任务么?
- 除了目标检测模型的训练需要的资源比较多(在云服务器上训练非常花钱,后来选择了使用本地GPU训练)
- 项目其它部分所需资源相较而言都不算多,能够满足。
- 在前端方面,人力资源相对不足
2.3.2 各项任务所需的时间和其他资源是如何估计的,精度如何?
- 任务所需的时间和资源是交给每个方面(两个人)中较有经验的一个人通过列出:
- 任务具体内容
- 单个任务占方面总任务的百分比
- 任务所需关键资源
- 任务难度/耗时估计
等信息来估计的。- 后面每次开会确定接下来一轮的冲刺时,这一系列信息起到关键作用。
- 精度方面,存在两项任务(总共有十九项)没有太大意义,其他任务的难度估计没有太大偏差,基本在原估计难度的约0.7~1.3倍之间。
- 前端方面的精度偏差相对算法、后端而言要大一些,主要原因是没有正确认识团队的前端技术能力
2.3.3 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 项目在计划的时候有准备测试时间,但是实际执行中测试做得比较简单仓促。
- 人力资源基本足够,大部分人能在缓冲区前完成任务。
- 此外由于存在训练模型的需求,所以硬件资源(说算力资源可能更准确一点)比较吃紧。
- PPT、企划书、介绍视频的难度存在一定的低估,但在加班后基本都较好地完成了。
- 前端的人力资源(三人)相对不足,如果能再从算法、后端分配一人到前端会更平衡一些
2.3.4 你有没有感到你做的事情可以让别人来做(更有效率)?
- 没有明显感觉
- 重要的不是“让别人来做更高效”,而是搞清楚“为什么别人能那么高效”,并虚心学习。
- 这个问题的进一步讨论可以在2.7.1看到
2.3.5 有什么经验教训? 如果历史重来一遍, 会做什么改进?
- 算力资源准备不充足,历史重来考虑提前收集(白嫖)一些云服务器的代金券,用于后续训练模型。
- 人力资源分配不恰当,历史重来考虑从算法、后端分配一人到前端会更平衡一些。
2.4 变更管理(4分)
2.4.1 每个相关的员工都及时知道了变更的消息?
- 起初部分队友消息的接收存在一定的落后
- 后来经过提醒“多关注变更消息”后,变更基本能及时让相关队友知道。
2.4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 根据用户的需求紧急度、功能必要性来决定功能实现的先后;
- 当前占座矛盾较为突出,因此优先实现“占座检测”;
- 当前疫情防控状态较好,因此可以稍微推迟“违规使用座位”的检测。
- 前端方面的“展示效果优化”属于项目阶段中相对靠后的工作,因此稍微推迟,优先优化更加重要的交互功能。
2.4.3 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
- 出口条件:可以稳定运行(检测),误报率在10%以下,能够抗基本干扰(戴帽子、趴在桌子上等)。
2.4.4 对于可能的变更是否能制定应急计划?
- 首先尽量避免突然的大规模的变更。
- 如果出现了就只能加班加点完成了。
2.4.5 组员是否能够有效地处理意料之外的工作请求?
- 由于一开始的计划和工作分配相对完备,没有太多意料之外的工作请求。
- 有一两次突发的工作请求也都被有效处理了。
2.4.6 学到了什么? 如果历史重来一遍, 会做什么改进?
- 在本次冲刺中,对突发变更的预案准备较少。
- 重来一遍的话:
- 会计划留出更多的应急空间、应急工作分配方案,避免因为突然分配意料之外的工作而过度加班的情况。
- 会更加注重项目要求的传达,避免表述不清或工作/目标不清晰
2.5 设计/实现(4分)
2.5.1 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
- 设计工作在学期第八周、第九周由潘伟君、林经纬完成。
- 时间和选人相对合适。
2.5.2 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
- 首先队长在选题分析、需求分析时就应当构建比较完整的项目流程和需求预期。
- 对于存在一部分模棱两可的情况,首先由队长和利益相关人员确认没有利益冲突/损失;
- 然后由队长和相应工作负责人共同决定具体方案:
- 队长主要负责确定设计不会偏离用户预期并且在项目整体开展上具有可行性
- 相应工作负责人主要负责确定在技术上设计的可行性
2.5.3 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
- 团队主要使用UML来协助设计和实现
- 这些工具在一定程度上理清了项目的流程、队友的实现思路,指导了项目的完成。
2.5.4 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
- 项目开始的UML和现在的状态存在一定的偏差
- 偏差来源主要是使用的技术方法不同:
- 因为一开始制作UML时还没有具体深入实现过程,但在实际实现过程中往往发现了更加便捷、合适的技术方法,随之实现方法或逻辑结构也产生变化。
- UML文档计划更新。
2.5.5 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 产生BUG最多的地方是在算法方面的人头检测部分
- 这也是项目的重难点,即回答“这个东西是不是人头”这个问题时,存在许多干扰因素
- 项目发布之后,发现对“头戴连帽衫帽子”这一情况的识别准确率比较低
- 主要原因是连帽衫的帽子被戴上时,从侧面看会遮住脖子面部、头发等“人头”的特征部位
- 设计/开发的时候考虑到了这种状况,由于这种情况的发生概率相对较小,因此目前解决方案是:
- 系统在向用户提醒违规行为时,会提供图片给用户进行辅助判断。
2.5.6 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
- 代码复审交给队友进行“分布式复审”;
- 代码规范执行得不够严格,没有使用统一的代码规范,仅要求详细注释接口和功能。
2.5.7 学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了什么:设计、实现、后续复审的方法很重要,很大程度上影响项目的完成和维护;
- 会做什么改进:使用单元测试、测试驱动的开发辅助项目的设计和实现,制定严格代码规范,并且设置代码复审计划,为代码复审留出时间;
2.6 测试/发布(3分)
2.6.1 团队是否有一个测试计划?为什么没有? 是否进行了正式的验收测试?
- 团队有测试计划;
- 但是在项目交付前没有充足时间进行完整地执行测试计划,仅进行了基本的测试;
- 对于算法,缺少更全面的性能测试,主要原因是视频资源有限
2.6.2 团队是否有测试工具来帮助测试?
- 暂时没有使用测试工具
2.6.3 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
- 如何测量并跟踪软件的效能:通过给出不同的输入,测试多种识别目标的识别效果与判别效度,使用适量的监控画面进行检测;
- 这些测试工作为优化和维护提供了方向,间接提高了软件对多种情况的适应性与长期运行的稳定性;
- 应有哪些改进:提高识别效率、效度,进行图像优化
- 应有哪些改进:改进前端的展示效果、交互功能
2.6.4 在发布的过程中发现了哪些意外问题?
- 在前后端交互过程中出现了跨域问题
- 有时候向后端请求数据时没有接收到数据,但是也没有报错
- 使用国内域名时由于没有报备,域名被封禁
2.6.5 学到了什么? 如果历史重来一遍, 会做什么改进?
- 学到了什么:软件测试是发布前重要的一环,应当被重视;
- 会做什么改进:
- 将测试写入日程
- 使用测试工具来帮助测试、分析效能
- 进一步收集视频数据,测试算法的性能
2.7 团队的角色,管理,合作(3分)
2.7.1 团队的每个角色是如何确定的,是不是人尽其才?
- 首先在团队成员的自我介绍环节,成员需要介绍自己所擅长的技术、期望承担的角色;
- 每个人期望承担的角色基本符合原计划的三个人负责前端,三个人负责算法,三个人负责后端;
- 是否人尽其才:
- 我认为软件工程主要是一个学习的过程,因此分角色的评判标准应该首要是成员的主观意向,然后是成员的客观能力;
- 因此分角色时本团队将成员意愿和能力综合考虑,进行角色分配;
- 这其中或许存在一定的“最擅长某方面的人不在该方面”的现象,但这也是依据相应成员的意愿做出的分配
- (比如:有的成员之前在其他项目负责过相关内容,有相关经验,但是在这个项目中他希望能在其他方面锻炼一下自己,那么在并不是非他不可时,我们团队选择尊重该成员的主观意愿)
2.7.2 团队成员之间有互相帮助么?
- 团队成员的互相帮助既存在于每个方面内(相似内容的讨论、互相学习帮助)
- 也存在于方面间(接口、交互部分的共同制定,使用方法的交流学习)
2.7.3 当出现项目管理、合作方面的问题时,团队成员如何解决问题? 每个成员明确公开地表示对成员帮助的感谢 (汇总至组长博客):
潘伟君:
α冲刺部分:
我感谢林经纬,因为他对任务态度端正且精益求精,没有强制要求的情况下仍然通宵完成了任务,此外还参与评估、评分,为贡献度的评分提供了重要依据。
我感谢余育洲,因为他帮我分担了α冲刺的PPT,并且认真地评估、评分,为贡献度的评分提供了重要依据。学到了企划书的编写流程,团队管理流程,PPT、博客、答辩的技巧。此外还对YOLOV5有了更深刻的了解以及应用。如果历史重来一遍,我希望更多地参加算法工作,收集更多趁手的API,学习更多高效有用的算法。
β冲刺部分:
我感谢黄荣涛,耐心地和我讨论座位框的自适应方法,确定具体实现方式
我感谢林经纬、卢婧、俞志敏、许嘉滨,在β最终阶段组建了讨论组进行冲刺,在答辩前加班加点最后成功完成前后端内容
我感谢余育洲,帮我收集了组内的技术图片和文档,为PPT的制作助力学到了座位框的自适应方法。如果重来一遍,会给前端多分配一点人,缓解前端工作压力。会多鼓励队友,发挥队长的鼓舞作用。
林经纬:
α冲刺部分:
我感谢 卢婧、俞志敏、许嘉滨 对我的帮助。因为前端小组群里我们互相分享进度和前端经验,互相监督进度,才让我们前端从无到有、一点一点搭建起来。嘉滨教我使用Bootstrap工具,还在前后端对接时,教我这方面应该怎么做,如何避坑。学到了css html js前端编程。如果历史重来一遍,应该会直接开始编程,不用去学任何前端知识,因为在使用过程中,基本上就掌握了很多操作。
在此次团队作业中,我学到了一些新的前端框架和方法,能更有效率地写代码,并且熟悉了前后端交互的相关知识并学会应用。如果历史重来一遍,我会更早地学习相关框架和方法,更早地投入应用,并更早地尝试向后端发送请求,还是希望自己接下来能有更高的效率完成相关任务。
β冲刺部分:
我感谢卢婧、许嘉滨对我的帮助,因为在修改前端bug、赶ddl的过程中他们给予了我非常大的帮助和支持。学到了前后端接口和jquery交互。会更早和组内成员进行讨论,商量需求,这样任务进度会快很多,同时很多不符合需求的组件也不需要浪费时间写。
俞志敏:
α冲刺部分:
感谢林经纬对我的帮助,因为在前端任务上帮我分担了很多,也在前端学习方面给到了一些建议,让我对前端的路线方向有大致了解。学习到了bootstrap和各种前端页面的编写方法,如果重来一遍,学习效率会更高。
β冲刺部分:
我感谢林经纬对我的帮助,因为他对我的设置界面的样式一体化做了最后的优化,当项目遇到困难时,我们的前端负责人组织了组员去空教室一起讨论解决通过本次冲刺使我对bootstrap框架更加熟练,审美也有了一定提高并能用ps对ui进行一些优化;如果重来一遍,会把界面一体化做的更好
卢婧:
α冲刺部分:
我感谢许嘉滨对我的帮助,因为当前后端交互出现问题时,他能耐心有效地进行讨论并调试,能积极地解决相关问题。在此次团队作业中,我学到了一些新的前端框架和方法,能更有效率地写代码,并且熟悉了前后端交互的相关知识并学会应用。如果历史重来一遍,我会更早地学习相关框架和方法,更早地投入应用,并更早地尝试向后端发送请求,还是希望自己接下来能有更高的效率完成相关任务。
β冲刺部分:
我感谢许嘉滨、黄荣涛和林经纬对我的帮助,因为在我写的代码遇到bug一时无法解决时,大家都很热心地帮助我一起查找问题所在通过这次冲刺,我对于前后端的交互有了更深的了解,对于前端的各种报错有了一定的解决能力。如果历史重来一遍,我会督促自己更早更快更高效地完成相关任务,并学习更多的相关技术,希望自己更好地完成前端和后端的交互。
黄荣涛:
α冲刺部分:
我感谢刘昌隆对我的帮助,在学习yolov5时请教了刘昌隆许多问题
我感谢余育洲对我的帮助,在进行标注区域人头检测时,学习了检测的相关思路
我感谢许嘉滨对我的帮助,在与他交接工作时,帮助我解决了很多问题。
我感谢组长潘伟君,是个很负责任的人!
(排名不分先后)学习了yolov5算法和检测人头的相关算法。重来:我会加强学习yolo的源码,做进一步的改进。
β冲刺部分:
我感谢刘昌隆、余育洲对我的帮助,在交流优化算法的思路时,给了我很多有价值的建议。
我感谢许嘉滨对我的帮助,与后端交接时,给我提供了很多帮助。
我感谢潘伟君对我的帮助,在讨论座位框自适应的算法时,耐心为我讲解。优化了座位检测算法,实现了座位框的自适应。重来:重视座位框自适应算法。
刘昌隆:
α冲刺部分:
我感谢余育洲对我的帮助:给我在可视化热力图实现方法上提供的帮助。
我感谢组长潘伟君对我的帮助,组长是个负责人的人,给我规划好alpha冲刺个个时间段需要完成的任务,对于我这样没有push推动进度缓慢的人是非常大的帮助。
我感谢黄荣涛对我的帮助,我们是一起在团队中负责功能算法的实现,在alpha冲刺阶段我们保持沟通,一起完成了基本功能。学习到了图像增强的各种方法和数据可视化绘制热力图的方法,如果再来一次我想尝试用深度学习处理增强图像方法,以及学习更多的知识
β冲刺部分:
我感谢黄荣涛对我的帮助,因为对于优化标框自适应的功能我在alpha的负责不在这一块,所以黄荣涛主动帮助我完成,我来提供一些测试数据,来检测命中率效果我学到更多的计算机图形操作的技术,如图像评价,和SVM的一些原来实现。
如果重来一遍,因为这段时间中间我还有一门考试,如果再来一遍没有考试,我希望可以做一些更多的任务,为队友分担压力。
余育洲:
α冲刺部分:
我感谢刘昌隆对我的帮助,因为某个具体的事情:在标注数据集的时候帮我承担了一部分工作量,在编写权重文件和yaml文件时指出了一些错误。学会了训练一个目标检测模型的全过程,以及对模型效果的后期优化。还把暑假时想学的openpose学了。如果历史重来一遍,我一定会在编写权重文件的时候多看看网络上的经验,对权重参数的不同组合的作用先有个大概了解,自己一点点debug和修参实在太痛苦了。
β冲刺部分:
我感谢刘昌隆对我的帮助,因为某个具体的事情:由于个人的电脑出现了一点bug,重装了系统,于是很多配置的文件都没了。所以在优化模型,增强远处的人头的检测效果的时候,yaml文件的编写以及最后的训练步骤都是由刘昌隆帮忙完成的。学会了很多能够增强检测准确率的规则,这些规则很多都是我在之前的工作中没有想到的。如果历史重来一遍,我一定要在标注数据的时候先使用图像增强工具增强图像效果,否则标注较远处数据的时候分辨率会变得很低,给标注工作带来很多困难
许嘉滨:
α冲刺部分:
我感谢卢婧对我的帮助,在我后端服务器一直炸掉的情况下能等待那么久才进行测试。学到了什么:对一个软件来说,测试环境和生产环境的冲突永远是存在的。这次作业更换了两台服务器,不适网络太差,内存过小,就是硬件不支持高版本cuda。如果一开始直接租一台高性能服务器可能事情会少一些,但没钱租啊。如果历史重来一遍我会多花些钱租个更好的服务器,这样就不会遇到例如内存溢出,cuda版本过低这样的问题了。
β冲刺部分:
感谢林经纬,卢婧等前端组成员的积极沟通,反馈。因此才能前后端交接顺利以及快速改进多考虑一些使用的情景,因为程序不是自己一个人在用的,写后端也要考虑前端使用是否容易。历史重来一遍可能会考虑加进更多人性化的功能
黄泽华:
α冲刺部分:
我感谢许嘉滨对我的帮助,承担了一部分原先应该由我完成的工作,工作效率也很高学到了后端通过flask搭建服务器,如何限定ip地址进行访问,如果重来,会加快工作速度,学习更多技能
β冲刺部分:
我感写潘伟君对我的帮助,很认真负责的帮助大家进行沟通,使作业能够顺利的完成学到了数据库的应用,posthandler的应用,收集数据进行测试,如果重来,希望自己能够多学会一些技能,多承担一些工作
2.8 总结(4分)
潘伟君:
α冲刺部分:
本次α冲刺,团队按照计划相对平稳地完成了大部分工作。还有少部分工作由于交接、考试之类的原因有所推迟,计划在β冲刺进一步完成。这次α冲刺非常感谢队友们的配合以及积极的态度,大家都尽自己的能力、精力来完成手头的项目,也有同学甚至额外花时间完成了分外的内容,一方面非常敬佩同学这样的精神,另一方面也反思自己对工作项目的考虑是否充分。这次冲刺我学习了算法方面的内容,主要是对YOLOV5的应用,各种API的使用,了解到了热力图,IOU等更好的技术。经过答辩也了解到了之后学习、改进的方向,感觉收获颇丰。
β冲刺部分:
本次β冲刺,非常感谢黄荣涛和我一起讨论了座位框的自适应功能,也非常感谢前后端的成员加班加点完成了交互,还有余育洲帮我在忙不过来的时候收集技术图片和文档,助力PPT制作。这次β冲刺的主要问题是前端的工作量比较大,给前后端的成员带来很大的压力,如果历史重来一遍,我应该会把算法或后端抽一个人去前端帮忙。也很抱歉给前端成员带来这么大的压力。队长的工作方面,感觉如果我多说一些鼓舞的话,鼓励大家、排解压力会更好。
林经纬:
α冲刺部分:
一开始节奏没跟上,到后期发现需要很多时间调整细节样式,还有一些bug的修改。跟着小组的进度走,学到了很多,也不是说很难,只是有了畏难心理就很难实现。这次软工实践,忙的时候连夜赶过进度,也跑到自习室花了一个晚上画座位图,alpha冲刺的时候刚上手前端那段时间大伙也都很体谅我,很不好意思。最后做出成果的时候,能说我有做出过贡献,感谢我们的团队!
β冲刺部分:
beta阶段任务一天结一次,时间太赶,然后又没有实现前端的好方法,感觉心里是很难受的,带着很大的压力,但是压力会带来压力下的突破和知识吸收,这次收获是蛮大的。
俞志敏:
α冲刺部分:
一个是需求一定要一开始就和负责任沟通清楚,像我一开始设置界面的座位布局是按ppt的设计的,与原型还有一定差距,做了一些无用功;
二是界面做完之后要在不同平台进行测试,避免电脑端显示正常而手机端排版混乱的情况;
三是遇到问题要及时和负责人沟通反馈;
β冲刺部分:
首先,页面样式的优化是必要的,对用户的体验有直观的提升;其次,页面的布局不仅要考虑自己负责的部分,也要和其他组员的样式有一体化的管理;最后,遇到问题的时候可以找个地方一起讨论解决,效率会高很多
卢婧:
α冲刺部分:
在本次团队项目中,我又巩固了自己的掌握的前端知识,并学习了新的更高效的框架和方法,感觉真是收获满满呢。此外,在本次作业中,我熟悉了一直想熟悉的前后端交互部分,能够将学到的相关知识进行实践,并且有人能一起进行调试。当然,还得感谢一下周同学的热心解惑。通过本次作业,我感受到了理论联系实际的重要性,光是掌握相关知识是不够的,在写代码的过程中还是有不少疑惑。在此次团队任务中,我充分感受到了jquery的方便(不过似乎很少人用了)。我觉得自己还是得继续学习,前端需要学习的知识还有很多,接下来,在继续完成团队任务的过程中,将继续将所学进行实践,并且在后续过程中还打算学好三大框架中的一种,并且让自己能写出更好用且更好看的页面。
β冲刺部分:
虽然在冲刺过程中有过焦虑和迷茫,但是好在有队员和朋友们的帮忙,能够及时地完成所有任务。通过这次冲刺,我感觉自己又掌握了更多的知识,我的精神世界也得到了升华,能够扛住更多的压力与焦躁。很高兴能加入比奇堡养老队,感觉很棒。
黄荣涛:
α冲刺部分:
本次为期两周的α冲刺与我三门考试、大作业撞上了,给我的任务带来了很多困难,每天都很焦虑,担心考试挂科、任务做不完,而且两天都要进行一次提交,十分的痛苦!但也实实在在的促进了项目的进行与知识的学习,熬过来之后感觉收获颇多,学习了很多新知识,增进了与队友的感情。我也十分感谢其他成员对我的帮助,没有他们的帮助我的任务不能顺利完成。在接下里我也会进一步的优化,并增加新功能。
β冲刺部分:
因为本周没有考试、其他科目的大作业,再加上α冲刺完成度较高,有足够的时间去优化算法、增加座位覆盖率,但每天一提交属实阴间,当项目没有进展时也要被迫抽出一点时间编写博客提交,但这个推力也促进了项目的完成,对于我这种赶ddl的人还是很有帮助的。本轮冲刺,对算法更熟悉了,简单实现了座位框的自适应,效果还是显而易见,答辩时柯老师的建议也很好,后续可以继续跟进实现。终于熬过来了!感觉收获颇多,学习了很多新知识,增进了与队友的感情。我也十分感谢其他成员对我的帮助,没有他们的帮助我的任务不能顺利完成。
刘昌隆:
α冲刺部分:
这次alpha冲刺的阶段作为一个学习者看到了我们队长对于任务进度的把控的能力,组员对于个人任务完成的信心以及能力,收获颇丰。作为一个组员,按照计划一步步的完成既定任务的时候还是有很高的满足感。学习到了对于图像的增强方法,现在对于图像处理的方法真的非常多,现在的能力还只是采用了经典的Retinex方法,希望继续学习一些深度学习处理图像的算法;学习了数据可视化绘制热力图的方法。但是像柯老师说的我在alpha冲刺阶段对低光,模糊图像选取增强只是做到“人工”智能的阶段。在不影响团队整体的项目结构,不做太多调整而只是更改权重文件的情况下,在beta冲刺的时候考虑用图片清晰度评价的方法,自动批量的对低质量的图片进行增强替换原始图片。
β冲刺部分:
在这次的Beta冲刺在一开始的时候因为在alpha冲刺的答辩现场效果不错,加上自己考试加身,对Beta冲刺有些松懈,在考完后继续投入Beta冲刺中的时候发现还有许多的细节需要优化,而且这些优化还是有一定的难度,最后在队友的帮助下还是基本完成的Beta的任务。在这再次感谢我的团队。我体会到了,对于一个项目来说,详细的计划,团队之间相互的推动,有助于团队进度推进,已经团队氛围的融洽
余育洲:
α冲刺部分:
这次团队作业让我学会了很多新知识,也把之前学过的一些知识进行了巩固。最重要的是提升了我的debug能力,无他,唯手熟尔(实际就是菜,bug一堆)。另一方面就是让我看到了团队协作的力量,本以为很难的一个项目,在大家的不懈努力下一步步完善,使它从想象走向现实。最后,感谢队友的付出,很高兴能和你们一起组成一个团队。
β冲刺部分:
这次β冲刺时间虽短,却也学到了许多东西,各种增强准确率的规则,以及自适应算法。我觉得这些知识将会在将来给我带来极大的帮助。同时也让我对解决方法的思路更加广阔,在遇到困难时不一定要死磕,转换思路往往能取得很好的效果。
许嘉滨:
α冲刺部分:
这次作业可以用一个词形容:紧迫。如果没有其它课程的作业,考试,比赛,那还是比较从容的吗。但这些事情冲突的时候,为了最大化,考试是最重要的。
后端总体写起来还是比较快的,没有界面,专注于业务逻辑。但小问题比较多,比如数据库读写一开始没有选到最合适的框架,不会刷新文件读写缓存,json数据过大。总结就是经验不足,没有了解工业上常用的解决方案。
对一个软件来说,测试环境和生产环境的冲突永远是存在的。这次作业更换了两台服务器,不适网络太差,内存过小,就是硬件不支持高版本cuda。如果一开始直接租一台高性能服务器可能事情会少一些,但没钱租啊。
β冲刺部分:
β冲刺是真的冲刺,又苦又累,但进展也很快。没想到到最后真能做出一个能用的软件,完成度也很高。因为平时都是面向命令行编程,界面没有写太多,看到自己参与的软件有界面又能用对我来说是很震撼的一件事。还有就是得注意休息了,熬夜写代码不推荐。
黄泽华:
α冲刺部分:
通过这次作业,学习到了很多知识,flask框架如何搭建服务器、posthandler来获取ip地址做到限定ip访问等等,网上查阅资料的同时能学到很多知识,觉得自己也很多需要学习,自身能力也得到了提升,很感谢团队成员的工作付出以及帮助,以后会更加努力学习更多技能
β冲刺部分:
β冲刺真的紧迫,通过这次作业,学习到了团队协作的重要性,感谢团队成员的辛勤付出,大家也是积极沟通,有困难没有放弃,想办法努力解决,还更加熟悉了数据库的应用,这次作业自己也学会了一些技能。