7组-Alpha冲刺-总结
一、基本情况
1.1 组长博客链接：
1.2 现场答辩总结：
- PPT行间距存在问题
- 利用规则、规律提高“自习室场景”的识别准确性；
- 考虑座位识别区域的位置偏移，尝试使用IOU进行自适应；
- 前端不够优美，继续优化美化；
- 后端由于服务器选择，存在稳定性问题，后续解决；
- 长期完善的角度看，需要提高小人头的识别率，考虑小人头算法，使用小人头数据集；
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 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 项目整个过程基本按照计划进行
- 后端和算法方面在α5就提前完成了
- 前端在α6也完成了相应任务
2.2.7 在计划中有没有留下缓冲区，缓冲区有作用么?
- 留下了两天的缓冲区
- 算法和后端方面的工作在缓冲区之前就基本完成了
- 前端在缓冲区中继续完成了前后端交互的工作。
2.2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 本次冲刺中项目整体上在缓冲区前基本完成
- 因此将来的计划中缓冲区大致仍然设置为两天
- 并且尽量在项目中期完成大部分内容，避免赶DDL和加班
- 此外考虑额外设置一段时间用于测试项目
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，学习更多高效有用的算法。
林经纬：
我感谢 卢婧、俞志敏、许嘉滨 对我的帮助。因为前端小组群里我们互相分享进度和前端经验，互相监督进度，才让我们前端从无到有、一点一点搭建起来。嘉滨教我使用Bootstrap工具，还在前后端对接时，教我这方面应该怎么做，如何避坑。
学到了css html js前端编程。如果历史重来一遍，应该会直接开始编程，不用去学任何前端知识，因为在使用过程中，基本上就掌握了很多操作。
在此次团队作业中，我学到了一些新的前端框架和方法，能更有效率地写代码，并且熟悉了前后端交互的相关知识并学会应用。如果历史重来一遍，我会更早地学习相关框架和方法，更早地投入应用，并更早地尝试向后端发送请求，还是希望自己接下来能有更高的效率完成相关任务。
俞志敏：
感谢林经纬对我的帮助，因为在前端任务上帮我分担了很多，也在前端学习方面给到了一些建议，让我对前端的路线方向有大致了解。
学习到了bootstrap和各种前端页面的编写方法，如果重来一遍，学习效率会更高。
卢婧：
我感谢许嘉滨对我的帮助，因为当前后端交互出现问题时，他能耐心有效地进行讨论并调试，能积极地解决相关问题。
在此次团队作业中，我学到了一些新的前端框架和方法，能更有效率地写代码，并且熟悉了前后端交互的相关知识并学会应用。如果历史重来一遍，我会更早地学习相关框架和方法，更早地投入应用，并更早地尝试向后端发送请求，还是希望自己接下来能有更高的效率完成相关任务。
黄荣涛：
我感谢刘昌隆对我的帮助，在学习yolov5时请教了刘昌隆许多问题
我感谢余育洲对我的帮助，在进行标注区域人头检测时，学习了检测的相关思路
我感谢许嘉滨对我的帮助，在与他交接工作时，帮助我解决了很多问题。
我感谢组长潘伟君，是个很负责任的人！
（排名不分先后）学习了yolov5算法和检测人头的相关算法。重来：我会加强学习yolo的源码，做进一步的改进。
刘昌隆：
我感谢余育洲对我的帮助：给我在可视化热力图实现方法上提供的帮助。
我感谢组长潘伟君对我的帮助，组长是个负责人的人，给我规划好alpha冲刺个个时间段需要完成的任务，对于我这样没有push推动进度缓慢的人是非常大的帮助。
我感谢黄荣涛对我的帮助，我们是一起在团队中负责功能算法的实现，在alpha冲刺阶段我们保持沟通，一起完成了基本功能。学习到了图像增强的各种方法和数据可视化绘制热力图的方法，如果再来一次我想尝试用深度学习处理增强图像方法，以及学习更多的知识
余育洲：
我感谢刘昌隆对我的帮助，因为某个具体的事情:在标注数据集的时候帮我承担了一部分工作量，在编写权重文件和yaml文件时指出了一些错误。
学会了训练一个目标检测模型的全过程，以及对模型效果的后期优化。还把暑假时想学的openpose学了。如果历史重来一遍，我一定会在编写权重文件的时候多看看网络上的经验，对权重参数的不同组合的作用先有个大概了解，自己一点点debug和修参实在太痛苦了。
许嘉滨：
我感谢卢婧对我的帮助，在我后端服务器一直炸掉的情况下能等待那么久才进行测试。
学到了什么：对一个软件来说，测试环境和生产环境的冲突永远是存在的。这次作业更换了两台服务器，不适网络太差，内存过小，就是硬件不支持高版本cuda。如果一开始直接租一台高性能服务器可能事情会少一些，但没钱租啊。如果历史重来一遍我会多花些钱租个更好的服务器，这样就不会遇到例如内存溢出，cuda版本过低这样的问题了。
黄泽华：
我感谢许嘉滨对我的帮助，因为某个具体的事情：承担了一部分原先应该由我完成的工作，工作效率也很高
学到了后端通过flask搭建服务器，如果重来，会加快工作速度，学习更多技能
2.8 总结（4分）
潘伟君：
本次α冲刺，团队按照计划相对平稳地完成了大部分工作。还有少部分工作由于交接、考试之类的原因有所推迟，计划在β冲刺进一步完成。这次α冲刺非常感谢队友们的配合以及积极的态度，大家都尽自己的能力、精力来完成手头的项目，也有同学甚至额外花时间完成了分外的内容，一方面非常敬佩同学这样的精神，另一方面也反思自己对工作项目的考虑是否充分。这次冲刺我学习了算法方面的内容，主要是对YOLOV5的应用，各种API的使用，了解到了热力图，IOU等更好的技术。经过答辩也了解到了之后学习、改进的方向，感觉收获颇丰。
林经纬：
一开始节奏没跟上，到后期发现需要很多时间调整细节样式，还有一些bug的修改。跟着小组的进度走，学到了很多，也不是说很难，只是有了畏难心理就很难实现。这次软工实践，忙的时候连夜赶过进度，也跑到自习室花了一个晚上画座位图，alpha冲刺的时候刚上手前端那段时间大伙也都很体谅我，很不好意思。最后做出成果的时候，能说我有做出过贡献，感谢我们的团队！
俞志敏：
一个是需求一定要一开始就和负责任沟通清楚，像我一开始设置界面的座位布局是按ppt的设计的，与原型还有一定差距，做了一些无用功；
二是界面做完之后要在不同平台进行测试，避免电脑端显示正常而手机端排版混乱的情况；
三是遇到问题要及时和负责人沟通反馈；
卢婧：
在本次团队项目中，我又巩固了自己的掌握的前端知识，并学习了新的更高效的框架和方法，感觉真是收获满满呢。此外，在本次作业中，我熟悉了一直想熟悉的前后端交互部分，能够将学到的相关知识进行实践，并且有人能一起进行调试。当然，还得感谢一下周同学的热心解惑。通过本次作业，我感受到了理论联系实际的重要性，光是掌握相关知识是不够的，在写代码的过程中还是有不少疑惑。在此次团队任务中，我充分感受到了jquery的方便(不过似乎很少人用了）。我觉得自己还是得继续学习，前端需要学习的知识还有很多，接下来，在继续完成团队任务的过程中，将继续将所学进行实践，并且在后续过程中还打算学好三大框架中的一种，并且让自己能写出更好用且更好看的页面。
黄荣涛：
本次为期两周的α冲刺与我三门考试、大作业撞上了，给我的任务带来了很多困难，每天都很焦虑，担心考试挂科、任务做不完，而且两天都要进行一次提交，十分的痛苦！但也实实在在的促进了项目的进行与知识的学习，熬过来之后感觉收获颇多，学习了很多新知识，增进了与队友的感情。我也十分感谢其他成员对我的帮助，没有他们的帮助我的任务不能顺利完成。在接下里我也会进一步的优化，并增加新功能。
刘昌隆：
这次alpha冲刺的阶段作为一个学习者看到了我们队长对于任务进度的把控的能力，组员对于个人任务完成的信心以及能力，收获颇丰。作为一个组员，按照计划一步步的完成既定任务的时候还是有很高的满足感。学习到了对于图像的增强方法，现在对于图像处理的方法真的非常多，现在的能力还只是采用了经典的Retinex方法，希望继续学习一些深度学习处理图像的算法；学习了数据可视化绘制热力图的方法。但是像柯老师说的我在alpha冲刺阶段对低光，模糊图像选取增强只是做到“人工”智能的阶段。在不影响团队整体的项目结构，不做太多调整而只是更改权重文件的情况下，在beta冲刺的时候考虑用图片清晰度评价的方法，自动批量的对低质量的图片进行增强替换原始图片。
余育洲：
这次团队作业让我学会了很多新知识，也把之前学过的一些知识进行了巩固。最重要的是提升了我的debug能力，无他，唯手熟尔(实际就是菜，bug一堆)。另一方面就是让我看到了团队协作的力量，本以为很难的一个项目，在大家的不懈努力下一步步完善，使它从想象走向现实。最后，感谢队友的付出，很高兴能和你们一起组成一个团队。
许嘉滨：
这次作业可以用一个词形容：紧迫。如果没有其它课程的作业，考试，比赛，那还是比较从容的吗。但这些事情冲突的时候，为了最大化，考试是最重要的。
后端总体写起来还是比较快的，没有界面，专注于业务逻辑。但小问题比较多，比如数据库读写一开始没有选到最合适的框架，不会刷新文件读写缓存，json数据过大。总结就是经验不足，没有了解工业上常用的解决方案。
对一个软件来说，测试环境和生产环境的冲突永远是存在的。这次作业更换了两台服务器，不适网络太差，内存过小，就是硬件不支持高版本cuda。如果一开始直接租一台高性能服务器可能事情会少一些，但没钱租啊。
黄泽华：
通过这次作业，学习到了很多知识，flask框架如何搭建服务器、posthandler来获取ip地址做到限定ip访问等等，网上查阅资料的同时能学到很多知识，觉得自己也很多需要学习，自身能力也得到了提升，很感谢团队成员的工作付出以及帮助，以后会更加努力学习更多技能
