ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

1组-Beta冲刺-总结

2021-11-28 22:03:37  阅读:168  来源: 互联网

标签:总结 什么 算法 冲刺 Beta 组员 团队 进行


https://www.cnblogs.com/Klein-Wang/p/15616513.html

一、基本情况

1.1组长博客链接

https://www.cnblogs.com/Klein-Wang/p/15616513.html

1.2现场答辩总结

  • 现场答辩总结
    • 现场答辩就Beta一周冲刺成果进行了展示,完成了算法的拼接,较理想的完成了前端界面的搭建,完成了后端接口的撰写与后端数据库的搭建;
    • 现场答辩分为两个部分进行,一是工作总结,二是成果展示。成果演示部分还包括现场展示环节,答辩现场反馈较好,没有异常情况的出现;
    • 答辩中有一名同学提问,该同学对组员的回答没有提出异议。

1.3全组讨论的照片

1.4评估团队中每个人对本次作业的贡献比例,描述为本次作业的工作流程、组员分工、组员工作量比例

姓名 团队分工 贡献比例
陈志良 产品前端实现 15%
施可婳 素材整理,界面设计与美化 10%
王业震 Insightface人脸识别算法,ppt制作,答辩 15%
郑浩彬 Yolov5目标检测算法,博客编写 15%
张静 openpose动作识别算法,ppt制作,博客编写 15%
毛长江 Yolov5&&Deepsort多目标跟踪算法,博客编写 15%
黄志翔 后端api设计与实现 15%

二、总结思考

  • 2.2.1 设想和目标

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

      • 随着经济社会发展和物质消费水平大幅提高,生活垃圾产生量迅速增长,已经成为新型城镇化发展的制约因素。城市中生活垃圾的产生量急剧增高,小区或宿舍垃圾存放点的负载逐渐增大。在垃圾桶数量多、分散广的实际情况下,垃圾监管难、及时清倒难等一系列问题不断涌现。针对上述痛点,我们提出了一种基于深度学习的垃圾投放状态智能检测与识别方法。该方法以实时监控视频作为基础,使用目标检测技术,对垃圾桶进行实时监测,查看其空满状态以及是否存在异样,并对投放垃圾的居民进行动作识别判断其对垃圾是否按规定定点投放,采用人脸识别技术对投放垃圾行人进行记录可追溯垃圾投放来源,并对不合规投放垃圾的人群加以标记,有效缓解了人手紧缺和监管不力等一系列问题。
      • 定义清楚。
      • 本产品的可能应用场景还包括学生生活区、工厂园区、人流密集的公园垃圾点监测等。本产品面向社区管理者,于非正常状态,系统对社区管理者发出提示,社区管理者只需对异常垃圾点进行清理即可,大大提升了监管效率。
    • 2.我们达到目标了么?

      • 项目的核心功能大体上是完成了,诸如实时监测,录像上传到云端,录像回看等功能。
      • 暂未投放到真实的生产环境中,但是对于用户数量方面我们保持乐观的心态。
    • 3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

      • 暂未投放到真实的生产环境中,暂时没有用户,但我们组核心人员对重要功能可以接受。
      • 经过beta冲刺,我们离目标必然是更近一步了。
    • 4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

      • 在beta冲刺中,我们依然是处于半学习半写代码的状态,效率其实并不会很高。
      • 一切的一切,归结于自身太菜,水平不够。如果历史能重来,建议梦回大一,争取到大三软工实践时,大家都已经是半吊子全栈工程师了。
  • 2.2.2 计划

    • 1.是否有充足的时间来做计划?

      • 是。计划是冲刺的既定目标,有目标才会有动力。
    • 2.团队在计划阶段是如何解决组员对于计划的不同意见的?

      • 我们有一个QQ群,可以进行交流。并且每次beta的小冲刺,都会开一次简短的会议,交流一些每天冲刺的疑惑与困难。
    • 3.原计划的工作是否最后都做完了? 如果有没做完的,为什么?

      • 缺少了前端界面的美化工作与一些测试。
      • 原因:
        - 在一些功能的实现上,我们一开始预期太过于乐观,在接触后发现实现比预期要复杂以及困难,需要更多的时间来实现预期的功能。
        - 前端实现的大体上以使用为主,因此没有过多的美化。
    • 4.有没有发现做了一些之后看来没必要或没多大价值的事?

      • 暂时没有,在分工上每一个人都实现自己的功能,每一个功能都是这个项目所需要的。
    • 5.是否每一项任务都有清楚定义和衡量的交付件?

      • 在每一次任务发布时,我们都会对任务划分成几个模块进行分配,在最大程度上对每一项任务都进行了清楚的定义和衡量的交付件。
    • 6.是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

      • 大体上beta冲刺都是按照计划进行的。但还是一些小插曲。
      • 比如这一周有某些课的期末考试。
      • 前端的学习成本过高。
      • 整合算法的过程错综复杂,并且组装算法的机器的GPU并不是特别理想。
      • 对于我们组来说,beta的工作量并不比alpha少很多。
    • 7.在计划中有没有留下缓冲区,缓冲区有作用么?

      • 在计划中几乎没有留下缓冲区,每个人都在尽全力地冲刺。
      • 但如果有缓冲区,可以在一定程度上调整工作进度和工作节奏。
    • 8.将来的计划会做什么修改?

      • 之后就是对一些bug的修复,增加一些小功能,然后进行最终的测试。
    • 9.学到了什么? 如果历史重来一遍, 会做什么改进?

      • 学到了前后端如何更有效的交流,项目所使用到的计算机视觉算法的共性与差异
      • 如果历史重来一遍,希望大家都是猛男猛女全栈,在其他组员有考试的时候,可以进行项目接力,不让每个人都那么仓促。
  • 2.2.3 资源

    • 1.我们有足够的资源来完成各项任务么?
      • 没有
      • 我们缺少时间资源
    • 2.各项任务所需的时间和其他资源是如何估计的,精度如何?
      • 首先由组长进行大致分配,再由组员进行细分
    • 3.测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
      • 缺少网络摄像头,在测试阶段只能使用笔记本本地摄像头
      • UI原型设计的难度确实是十分巨大的,设计人员不懂技术,其实并不能很好的还原我们想要做什么或者能做什么,只能慢慢修改。
    • 4.你有没有感到你做的事情可以让别人来做(更有效率)?
      • 没有。在分配项目的时候,大家都会争取到最适合自己以及自己最愿意去做的模块,在达成共识后每个人所做的部分都是自己最擅长的。
    • 5.有什么经验教训? 如果历史重来一遍, 会做什么改进?
      • 希望大家以后都能往全栈发展,各个领域都懂一点,再专精某个领域,才能更好地交流,更好地编程。
  • 2.2.4 变更管理

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

      • 知道,会通过qq群发送变更消息。
    • 2.我们采用了什么办法决定“推迟”和“必须实现”的功能?

      • 看功能核心与否。
    • 3.项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

      • 基本条件就是预期功能全部实现,目标客户可以正常使用,前端页面可以正常跳转,可以给后端发送正确的消息,后端处理请求不报异常,返回正确的信息。
    • 4.对于可能的变更是否能制定应急计划?

      • 可以。
    • 5.组员是否能够有效地处理意料之外的工作请求?

      • 可以。
    • 6.学到了什么? 如果历史重来一遍, 会做什么改进?

      • 在冲刺初期就应该做好详细的计划,使得时间安排尽量合理。
      • 交流大于一切,组员之间一定要进行充分的交流。
  • 2.2.5 设计/实现

    • 1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
      • 设计工作是在Alpha冲刺结束的当天完成的,由小组7人共同商讨完成,时间和人员合适。
    • 2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?
      • 在前端界面设计时,实现方式摸棱两可,通过征求别组同学意见最终确定了最终方案。
    • 3.团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
      • 暂时还没有使用单元测试,在后面测试阶段会考虑。但是,用到了UML,感觉唯一的效果就是增加了工作量。
    • 4.比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
      • UML文档在设计中不断更新,增加若干功能,且部分功能进行了改进;在推进中发现不合理的地方,并对设计进行了修改,故产生区别;UML文档应在推进中实时更新以确保设计合理性。
    • 5.什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
      • 在进行算法拼接时,人脸识别功能产生Bug最多,因为人脸识别算法使用了Python2,而其他算法使用的是Python3,在算法拼接时出现兼容性问题多;
      • 发布后发现算法需要的GPU算力是很高的,运行的流畅度和之前的预期相比大打折扣;
      • 设计与开发只是纸上谈兵,是骡子是马,代码跑起来才知道,代码的错误很多都是不可预知的。
    • 6.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
      • 代码复审由人工检测核验,确保运行无误,严格执行了代码规范。
    • 7.学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • 学习了软件设计具体过程及算法实现,增长了开发设计经验。如果历史重来一遍,我们希望带着改Bug的记忆穿越回去,不要在Bug中绕圈圈。
  • 2.2.6 测试/发布

    • 1.团队是否有一个测试计划?为什么没有? 是否进行了正式的验收测试?
      • 已经形成了完整的测试计划,准备对各部分算法性能及可行性进行了测试,预计在项目测试阶段进行验收。
    • 2.团队是否有测试工具来帮助测试?
      • 后端有idea自带的测试工具。
    • 3.团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
      • 根据数据流传输的速率及处理时间来评价软件效能;有用,从测试中发现存在优化的空间;后续将对前端与后端接口调用速度为优化切入点进行重点优化。
    • 4.在发布的过程中发现了哪些意外问题?
      • 在进行算法拼接时,出现了算法环境不兼容的问题,导致了算法拼接时出现了许多意想不到的Bug,占总错误数的80%;
      • 在进行前后端对接时,由于接口文档出现错误,导致对接出现问题。
    • 5.学到了什么? 如果历史重来一遍, 会做什么改进?
      • 关于测试的知识确实浅薄,项目没有编写完,也无心学习这个,如果能退回几个月前,可能会让大家先把这个学习一下吧。
  • 2.2.7 团队的角色,管理,合作

    • 1.团队的每个角色是如何确定的,是不是人尽其才?
      • 根据大家学习的内容不同,以及擅长领域不同,进行前后端分工,以达到人尽其才。
    • 2.团队成员之间有互相帮助么?
      • 有。在进行算法拼接处理时,成员互相协助,分享经验;在遇到错误时,组员们共同分析,顺利解决了错误。
    • 3.当出现项目管理、合作方面的问题时,团队成员如何解决问题? 每个成员明确公开地表示对成员帮助的感谢。
      • 当项目管理、合作方面出现问题时组员将先争取组长的意见,若无法确定则采取投票的方式。
      • 王业震:我感谢张静对我的帮助。因为某个具体的事情:在进行Beta总结与汇报时,张静同学帮助我梳理了整个汇报的部分与流程,让Beta冲刺答辩变得有条理、有逻辑。
      • 郑浩彬:我感谢组里所有人对我的帮助, 因为某个具体的事情:王业震同学可以在我迷茫的时候给予我前进的方向;毛长江同学可以协助我完成一些算法上的问题;张静同学为了配合我的工作,可以配置算法GPU环境配置到凌晨;黄志翔同学可以在我对后端接口不甚了解的情况下,告诉我应该做什么;陈志良同学很奋进地在学习pyqt,让我很感动。
      • 毛长江:我感谢郑浩彬对我的帮助,因为某个具体的事情:合并算法时,由于先前在各自电脑上跑,安装的库文件存在重合,若直接合并导致冗余过多。在交流经验后进行了算法简化,仅保留了必要功能的追踪算法和相应适配文件,节约了空间且提高了效率。
      • 张静:我感谢施可婳对我的帮助, 因为某个具体的事情: 因为在代码测试时给我巨大帮助。
      • 陈志良: 我感谢郑浩彬对我的帮助,因为他教了我对combox控件如何进行处理。
      • 施可婳:我感谢张静对我的帮助,因为某个具体的事情:帮我解答了算法方面的问题。对页面的构建更加得心应手。
      • 黄志翔:我感谢郑浩彬对我的帮助, 因为在后端接口的编写我也是边学边写的, 因此需要一些后端帮助的时候就是舍友给了我提议, 虽然语言不同但是逻辑是互通的, 这为我节省了非常多debug的时间。
    • 4.学到了什么? 如果历史重来一遍, 会做什么改进?
      • 人和大于一切,每个人都把团队至上,就能有更美好的明天。
  • 2.2.8 总结

    • 王业震:通过Beta冲刺,我想说我又做到了。解决了前端页面的设计布局,解决了后端接口的牵线搭桥,解决了算法拼接令人头昏脑胀的各种错误,当程序成功运行的那一刻,忍不住说“哇塞,好起来了“。
    • 毛长江:本次beta冲刺,学习了不少算法合并与打包的相关知识,同时也在团队合作中了解并解决了不少bug,今后开发时或许会更为熟练,同时也认识到自己存在的一些不足,希望今后还能会继续提升,不断改变。
    • 郑浩彬:经过这次Alpha冲刺,我学习到了许多人工智能方面的相关知识,比如如何标注数据集,如何使用Yolov5算法训练数据集等,也感受到了时间真的很少,每天都被很多事所困扰。真的希望时光能多倒回一点,让我学习完软工要用到的方方面面的知识,再来更好地软工实践。
    • 张静 :在beta冲刺阶段,我体会到了团队合作的重要性,大家聚在一起想要共同干好一件事情的力量是无穷的。最后我觉得自己收获最最最大的是软件制作的流程以及文档的编写。从刚开始选题,需求分析,到开发阶段编写代码,最后的软件测试,bug修复,每一个步骤下来都让我收获颇多。
    • 陈志良:经过这次冲刺,我已熟练掌握qt设计师这个页面设计工具,学到了前端窗口控件等复杂操作的知识,码力也↑↑。后面我也会和队友继续对这个软工项目继续优化。学到了如何自定义标题栏以及都其他控件的用法。以及槽函数自定义和界面设计规范话,方便后期维护。但是界面还是有点丑,如果历史重来一遍,我会对界面的美观进行深加工,处理好细节。
    • 黄志翔:本次的软工冲刺从零到有开始学习了spring全家桶中部分框架的使用, 在极短的时间内运用了诸多的后端框架, 加强了我的后端能力,并且显著提高了赶DDL的能力。
    • 施可婳:这次Beta冲刺使我对页面的构建更加熟练了。但遗憾的是这次冲刺没有什么很大的进步,希望能在今后的学习里克服不足之处,掌握更多的知识和技巧,取得更大的进步。

标签:总结,什么,算法,冲刺,Beta,组员,团队,进行
来源: https://www.cnblogs.com/czl411/p/15616791.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有