01组团队项目-中期总结

郑心玥102101509 2023-11-19 22:57:06

一、团队名片

队长博客链接：
团队logo：
团队ID：01
团队名称：Employees of Boss ke

团队现场答辩总结

中期答辩前，我们已经成功完成了项目的大部分功能，包括各个识别算法的开发以及Web端与数字大屏的搭建。这为我们的答辩增添了信心。虽然在答辩汇报的过程中遇到了一些小插曲，但我们通过这次经历收获了柯老板和同学们的宝贵意见与建议。

在接下来的Beta冲刺阶段，我们将继续努力，着手完善和调整各个检测算法的权重，以确保它们在实际应用中的准确性和鲁棒性。同时，我们将专注于小程序功能的完善，以提供更加友好和高效的用户体验。此外，我们计划进一步优化各个展示端的交互设计，确保用户能够更直观地理解和使用我们的市政管理平台。

团队讨论的真实照片

团队中每个人在本次作业中的具体分工和各自得分比例

姓名	任务	得分比例
郑心玥	项目管理、算法实现、答辩宣讲	100%
郑龙辉	项目架构设计、任务分配、算法实现	100%
郭子浩	算法设计、模型训练、代码汇总	100%
刘炜祺	算法设计、模型训练、博客汇总	100%
方蔚航	算法设计、模型训练、博客汇总	100%
陈欣莹	算法设计、模型训练、原型图制作	100%
吴鑫雄	后端开发、web端制作、前后端沟通	100%
林俊杰	后端开发、小程序端制作、博客汇总	100%
张佳雯	前端设计、原型设计、PPT制作	100%
肖嘉鑫	前端设计、视频剪辑、项目测试	100%

二、总结思考

2.2.1 设想和目标（5分）

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

我们的软件目的是为了提高城市管理效率，解决诸如路面垃圾、坑洼、人流量、违停等问题。我们的定义相对清晰，典型用户应当是政府机构，政府的相关机构能够使用我们的这款软件实现实时监控一些市政问题，例如路面垃圾、坑洼、人流量、机动车和非机动车违停、路面积水等等...
我们达到目标了么？（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？)

可以说我们完成了计划中的大部分目标，原计划的功能做到了大概95%以上，按照原计划时间交付了，但是由于我们项目需要依托于政府的机构，所以现在无法预估用户的数量
用户量，用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？

用户量达到了预期，但对于一些功能的接受程度可能需要更深入的用户反馈。我们离目标更近了，但是我们的智慧城管系统仍然不是完美的，它仍然需要改进和优化。
有什么经验教训？如果历史重来一遍，我们会做什么改进？

我们在项目的初期遇到了一些选择算法上面的困难，因为我们的智慧城管项目是多元的，有多维的检测算法，这意味着我们每一个检测的模型都需要不同的算法来支撑，而我们正是在这个部分遇到了大量的困难，而我们在一开始的评测阶段，对于这个部分的完成时间的预估不够准确，给我们后面项目的交付带来了不少的麻烦。如果历史重来一边，我们应当在一开始就做更多的调查，去正确的评估这个部分的难度从而预估该模块需要的时间，最终减少我们不少的麻烦。

2.2.2 计划（6分）

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

我们是有着充足的时间来做计划的
团队在计划阶段是如何解决组员对于计划的不同意见的？

在计划阶段，我们会去评估每一个组员对于计划的不同意见，例如通过上网查询资料，开组会交流等等方法去认真地评价组员对于该计划的意见是否可行。在有分歧的情况下，我们采用民主式的决策方法，通过团队投票的方式最终确定方案。
原计划的工作是否最后都做完了? 如果有没做完的，为什么？

原计划的大部分工作我们都做完了，但是由于一些技术上的挑战，还有一些难以预测到的问题，我们仍然有一些工作没有完成，这也与我们一开始的技术评估没有充分考虑到一些技术难题有关。
有没有发现做了一些之后看来没必要或没多大价值的事？

在智慧城管系统项目中，我们确实经历了一些阶段性的经验，发现一些任务或决策后来看似没有必要或者并没有带来预期的价值。这是一个学习和持续改进的过程，我们从中获得了一些宝贵的教训。举例来说，可能在初期的系统设计中，我们投入了过多的时间和资源在某个功能上，但后来通过一些调查发现市场需求不高，用户对该功能的需求也较低。这可能是因为我们在需求分析阶段未能充分了解用户需求或者市场趋势。
是否每一项任务都有清楚定义和衡量的交付件？

在我们的智慧城管系统项目中，我们致力于确保每项任务都有清晰的定义和可衡量的交付标准。

例如，在垃圾检测模块中，任务定义可能包括使用深度学习模型训练来检测不同类型的垃圾。为了明确交付标准，我们可能会规定在测试数据集上达到特定的准确度、召回率和精确度。这有助于确保团队成员对于完成任务的期望是一致的。总体而言，我们会在任务的定义和交付标准方面进行更详细的规划，以确保每个团队成员对于任务的理解是一致的，并且可以通过量化的指标来评估任务完成的程度。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？

项目大部分时间按照计划进行，但在深度学习模型训练和系统集成阶段遇到了一些技术挑战。一些风险可能没有在初期估计到，可能是因为相关信息不足或者对某些技术难题的认识不够深入。
在计划中有没有留下缓冲区，缓冲区有作用么？

在智慧城管系统项目中，我们意识到在计划中为不确定性留下足够的缓冲区是至关重要的。尽管一些任务可能会按照预期进行，但城市管理领域的复杂性和变化性意味着我们需要更灵活地应对可能的挑战。例如，在开发不同的检测模块时，我们可能面临到城市垃圾种类多样，光照条件变化大等挑战。为了适应这些不确定性因素，我们在计划中留有一定的缓冲区，以确保在面对挑战时仍能够按时交付。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）

我们将更加仔细地定义项目计划中的缓冲区，以更好地适应城市管理领域的复杂性和变化性。这可能包括在任务时间估计上增加更灵活的余地，以及为解决技术问题和不确定性预留更多的时间。例如我们在未来的深度学习算法的选择上，会事先去做更多的调查，来确定该算法不存在技术壁垒，我们可以直接服用，而不是到项目的中期才发现该算法不可行从而推翻重做。
学到了什么? 如果历史重来一遍, 会做什么改进？

我们学到了在项目启动阶段更全面地了解用户需求和市场趋势的重要性。如果历史重来一遍，我们将投入更多时间和资源进行深入的需求分析，确保我们的解决方案真正满足用户的期望。第二在项目的时间估计阶段，我们应该去做更多的调查来正确评估时间，特别是在深度学习模型训练和复杂系统集成方面。如果历史重来一遍，我们将更加关注提高时间估计的准确性，可能通过更细致的任务拆分和更好的技术评估来实现。

2.2.3 资源（6分）

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

我们有着足够的资源来完成各项任务，例如csdn上的深度学习方面的博客，知网上的论文等等，这些都是我们的技术支撑。
各项任务所需的时间和其他资源是如何估计的，精度如何？

首先进行任务分解，将项目的划分为小而明确的子任务；其次通过翻看他人博客教程等方式粗略预估所需的各个子任务所需的时间与资源，同时由于粗略预估的不确定性，为每个任务加上了部分的缓冲时间；再者考虑了各个任务之间的联动与依赖的部分，确认各个子任务的优先顺序；最后在项目过程中定期更新估算。

估计的精度在一开始比较粗糙，但是随着项目的开始，估计的精度在迅速提高。

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

测试所需的相关资源都比较充足。我们收集了饱和的数据用来训练、测试算法；硬件方面我们通过租借服务器来训练和测试模型；时间和人员方面验证算法对人力要求不高，对时间要求比较高。但由于测试运行在服务器上，所以在服务器运行验证的时候成员可以进行其他的任务，是实现了任务的并行。所以总体而言测试时各个部分的资源都比较充足。

在非编程资源的难度预估上，由于在前期未能考虑到因为算法更新而需要更新先前已经做好的部分结果展示图等情况，这增加了美工的工作量。但在项目前期预留的缓冲期抵消了这一影响。
你有没有感到你做的事情可以让别人来做（更有效率）？

我认为这个问题需要衡量队友工作量以及空闲时间来定。首先，不可否认的是我们团队每一位队员我认为都很优秀，也都具备快速上手一项新任务的能力，因此每一项任务的分配都应该是均等的，毕竟我们队每个人得分也都是一样滴！每位同学在负责自己算法或是前后端等长期工作的同时，也要负责每一个阶段的后勤任务，那么这个任务就应该是均等分配的。我也不好意思让一位已经负责写博客的同学再帮我写开题报告的策划书嘛对吧。
另一方面，大三大家的课业压力都比较大，每个人空余时间和ddl可能都有不同，如果临时出现个人ddl很紧张情况下，当然需要队友挺身而出，互相补台（及时不擅长或是没接触过），这也是考验一个团队凝聚力的最佳时刻，那么我也相信我和我的队友们都可以做到。
有什么经验教训? 如果历史重来一遍, 会做什么改进？

预留缓冲是很有必要的。

如果重来一次，会在正式开始项目之前先用2天左右时间预热一下，让所有成员熟悉相关任务，再进行预估。

2.2.4 变更管理（6分）

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

通过2天一次的团队会议以及群聊等方式让每个成员都能及时知道变更的信息。
我们采用了什么办法决定“推迟”和“必须实现”的功能？

通过在团队会议上讨论，划分好各个任务，确定每个任务的重要程度、紧急程度以及各个任务之间的依赖关系。并由此确定好”必须实现“的功能。目前暂未有“推迟”的功能。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

我们对项目的出口条件有以下的定义：

功能完整：项目的8个算法都得到实现，各个展示端都可正常工作

性能：对于单张目标图片，各个算法应该在0.1s内得出检测结果（不包含模型加载，后同）；对于实时的视频流，考虑网络因素在内，应该在终端实现每秒更新

质量：对于目标识别的准确率至少达到90%，对于少部分极端场景也能实现较好的检测效果
对于可能的变更是否能制定应急计划？

由于有为各个任务分配缓冲时间，所以当突发变更的时团队能够有比较充足的时间制定应急计划。
组员是否能够有效地处理意料之外的工作请求？

由于预留了缓冲时间，在一定范围之内能够有效的处理。
学到了什么? 如果历史重来一遍, 会做什么改进？

在项目中发生需求变更会导致。应该在项目初期更仔细的设计各个任务，尽量减少后期项目的项目变更。

2.2.5 设计/实现（6分）

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

由组长在团队确定项目、简要分析完需求后主导完成的。时间合适，给予团队成员较长的时间来理解项目设计相关的内容。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

尽量从项目利益相关者的角度考虑，明确其期望与需求，同时将这些模棱两可的问题带入团队讨论，并通过创建原型设计的方式逐步完善，减少模棱两可的程度。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

开发过程中我们使用了单元测试来对每个识别算法进行了测试，保证算法的正确性，确保了各个部分的可靠性；同时还使用了UML图对项目进行建模，帮助团队更好的理解项目的结构。总体而言，我们使用的这些工具对项目产生了积极的作用。
比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

我们项目开始时的UML文档虽然只是初始设计的抽象表示，但是和现在的状态相比区别不是很大。区别可能源自需求变更、技术选型调整、新功能添加等。

我们需要更新UML文档。我们会定期更新确保文档与实际代码保持一致，帮助我们团队成员理解系统结构。我们也会记录下变更的理由，以便整个团队理解演进的原因。、
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

我们发现在算法方面的BUG最多，是因为算法整体的设计和实现难度都较大，需要花费很多时间和精力去解决。在发布后，我们没有发现明显的BUG，都是一些细节和人性化的东西没有考虑清楚。

这些东西在设计/开发的时候没有想到是因为我们是想着先完成一份简易的、能够跑通的、实现部分功能的产品，后续再更改这些问题。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

我们执行严格的代码复审流程。开发者提交变更请求，团队仔细审查代码，提出问题和建议。复审会议强调最佳实践和代码规范，开发者根据反馈进行修改。自动化工具如Lint辅助确保规范。定期培训保持对最新规范的了解，这确保了高质量、可维护且符合规范的代码。
学到了什么? 如果历史重来一遍, 我们会做什么改进？

在设计和实现方面，我们学到了注重系统的可扩展性、灵活性和可维护性的重要性。

如果历史重来一遍，我们会强调更全面的需求分析，确保设计满足未来变化。提前考虑性能和安全性，引入更多自动化测试以确保代码质量。定期进行代码审查，促进知识分享。采用敏捷开发，更频繁地与利益相关者沟通，以便更及时地调整设计。这些改进将有助于更好地适应变化、提高系统质量和团队效率。

2.2.6 测试/发布（5分）

团队是否有一个测试计划？为什么没有？

团队是有一个测试计划的，在我们团队中，负责后端接口的同学也要参与测试的环节，他们既要对前端页面和算法呈现方面做出测试，也要忙于接口和前后端的对接。
是否进行了正式的验收测试？

是的，我们的团队进行了正式的验收测试。验收测试是我们软件开发生命周期中的一个关键步骤，确保我们交付的软件符合客户的期望和质量标准。我们制定了详细的测试计划，其中包括验收测试的范围、测试用例、测试数据以及执行和报告的计划。这确保了我们对系统进行了全面的测试，覆盖了所有功能和性能方面的要求。
团队是否有测试工具来帮助测试？

是的，我们团队使用了多种测试工具来支持我们的测试流程。这些测试工具的选择取决于项目的需求、技术栈和测试目标。以下是一些我们常用的测试工具：
1. 单元测试工具：对于单元测试，我们通常使用像JUnit（Java）、pytest（Python）、JUnit（JavaScript）等工具，这些工具有助于确保代码的各个单元按预期方式运行。
2. 性能测试工具：如果项目涉及到性能要求，我们可能使用工具如JMeter、LoadRunner等来评估系统在不同负载下的性能表现。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

我们团队使用性能测试、监控和用户反馈来衡量软件效能。自动化测试确保稳定性。改进方向包括更全面的测试覆盖，优化持续集成和部署，实时监控与用户体验分析。不断优化代码和定期审查有助于提高软件性能。
在发布的过程中发现了哪些意外问题？

发布中遇到数据库连接问题和用户界面兼容性。我们通过快速修复和追踪系统日志解决问题，确保用户体验和数据完整性。
学到了什么? 如果历史重来一遍, 会做什么改进？

在测试和发布中学到了及时沟通的重要性，提前发现和解决潜在问题的价值。如果历史重来一遍，我们将加强自动化测试，改进持续集成，确保更全面的测试覆盖。加强用户体验分析和实时监控，以更早识别和解决性能问题。加强团队培训，以确保每个成员都能理解并执行最佳实践。加强发布前的最终验收测试，以确保高质量的交付。

2.2.7 团队的角色，管理，合作（5分）

团队的每个角色是如何确定的，是不是人尽其才？

我们小组的每个角色是根据每个人的过去学习经历，所掌握的技术和自身的意愿所决定的，绝对称得上是“人尽其才”！！！
团队成员之间有互相帮助么？

有的，而且帮助特别多。举个例子，我们小组有6个人负责算法部分，但是yolov7目标检测算法的环境搭建就是一个很难的问题，但是如果我们6个人都去忙活这个，效率不高且问题不能很好解决，于是我们专门派两名同学负责研究算法环境的搭建，其他人忙数据集的收集，算法的核心代码等，等两名同学搞清楚了就可以帮助其他人搭建环境，实现了团队的相互帮助和效率提升。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

当出现项目管理、合作方面的问题时，首先我们会召开集体会议，对这些问题进行初步的了解和分析，找到问题的根源，并进行集体投票等方式，对问题进行解决。如果有更艰难的问题，我们会根据组长的意愿来确定团队的方向（信任，信任还是信任）。
每个成员明确公开地表示对别人帮助的感谢（写在各自的博客里）：

我要感谢陈欣莹小美女对我的帮助，因为她精湛的ps水平以及画图技术，我们组的项目logo、目标市场图、包括功能展示图与总体架构图在内的各类图片绘制我都不需要操心，给作为队长的我省了非常多的事情。只要我能想到，她一定能画出很好很符合的图片，就是说非常nice，有这样一位集美貌与智慧于一身的队友我深感荣幸！

2.2.8 总结（6分）

郑心玥

Alpha阶段我主要做了算法设计相关内容，在成功跑通yolov7的算法后，进行了数据集的扩充与算法的优化。在这个过程中，先后遇到了诸如pytorch安装困难、代码各类新型bug等一系列问题，也是通过队友的帮助、查阅相关资料、询问gpt大师等方法，最终都得以解决。在这个阶段我也锻炼了阅读论文的能力，通过学习先进的各类算法，不断地对自己的模型进行优化，在保证正确率的同时也希望能提高训练效率；当然也发现了自己很多不足，深度学习相关的知识只是掌握了一些些些些些细微的皮毛而已，还是需要日后不断学习的。中期答辩方面，我作为队长负责项目汇报的工作，还是反思自己存在的问题，没有思考清楚到底应该汇报哪些内容，出现了本不该介绍的选题背景再次讲一遍的情况，也让自己体验了一把极限挑战，最后一秒讲完真的很惊险刺激。下一次汇报一定想清楚，凝练内容，争取做到汇报时不慌不忙！
郑龙辉

在Alpha阶段的工作中，我通过爬虫和实地拍摄等方式成功地收集了数据集。这一步骤为模型的训练提供了基础，确保了模型具有足够的多样性和丰富性，以应对不同场景和条件的挑战。数据集的质量和多样性对于模型的性能至关重要，这使得在实际应用中具有更好的泛化能力。在数据准备的基础上，我学习了数据增强的技术。通过对数据进行增强，我能够扩充训练集，增加模型对于各种变化的适应性。这一步骤对于提高模型的鲁棒性和性能至关重要，尤其是在面对有限的数据情况下。另外，我深入研究了YOLOv7框架，并成功地部署了它。YOLOv7是一种先进的目标检测框架，具有高效的实时检测能力。通过了解和应用这一框架，我提高了对目标检测领域的理解，同时也为项目的下一步工作奠定了基础。最后，我进行了模型的训练。这一过程涉及到调整模型参数、优化损失函数以及监控训练过程。通过反复的实验和调整，我逐渐优化了模型的性能，确保其在目标检测任务上达到了令人满意的水平。整个Alpha冲刺阶段的工作让我深刻体会到了深度学习项目的复杂性和挑战性。在不断学习和实践的过程中，我不仅提高了技术能力，还锻炼了解决问题的能力。同时，与团队成员的合作也为项目的成功提供了有力支持。在Beta阶段，我期待能够进一步优化模型、改进算法，并在实际场景中取得更好的效果。
郭子浩

在Alpha冲刺阶段，我完成了基于深度学习的 YOLOv7 路面垃圾检测模型的开发工作，这个经历让我收获颇丰。首先，在整个项目中，我对深度学习模型的训练和部署流程有了更深入的理解。通过调研相关文献、学习现有的开源项目，以及实际动手搭建模型，我深刻体会到了模型设计、数据集准备、超参数调优等环节的重要性。在模型训练过程中，我不断尝试不同的技巧和策略，以获得更好的检测性能，这对我的技术水平提升有着显著的帮助。在路面垃圾检测这一具体应用场景下，我明白了深度学习在环境保护和城市管理方面的潜在价值。通过将先进的计算机视觉技术应用于垃圾检测，我们可以更加高效地监测和管理城市环境卫生，为城市的可持续发展做出贡献。这种结合科技和社会问题的实践也让我对自己的工作充满了使命感。另外，通过项目的实践，我对团队协作、沟通和解决问题的能力都得到了增强。在与团队成员讨论模型设计、遇到技术难题时，我学会了更加积极主动地寻求解决方案，并且善于倾听和接受他人的建议。这些都是我在日后职业发展中不可或缺的能力。总的来说，基于深度学习的 YOLOv7 路面垃圾检测模型的开发经历让我受益良多。我不仅在技术层面取得了实质性的进步，也更加深刻地认识到科技创新与社会问题之间的紧密联系。我期待着将这些收获运用到未来的工作中，并继续探索人工智能技术在解决实际问题中的应用潜力。
刘炜祺

共同奋斗，成就了我们在这次alpha冲刺中的一次难忘经历！

首先，在算法环境的配置方面，我深刻体会到了团队协作的重要性。通过与团队成员的交流和合作，我们共同解决了配置过程中的各种问题，提高了工作效率。在这个过程中，我学到了沟通的艺术，学会了倾听和表达自己的观点，形成了更加紧密的团队合作关系。

其次，在算法的编写和训练数据集的查找方面，我意识到了自我学习的重要性。通过阅读文档、学习在线教程以及与团队成员的讨论，我逐渐掌握了新的算法和数据集的使用方法。这让我对自己的学习能力有了更大的信心，并在解决问题时能够更加灵活地运用所学知识。

同时，通过参与训练数据集的整理和优化算法的调试，我更深刻地理解了团队协作的力量。大家相互帮助，分享经验，共同攻克难关，最终取得了令人满意的成果。这让我意识到，一个团结友爱、积极向上的团队是事业成功的关键。

在整个过程中，我也学到了如何高效地查找资源，包括学术论文、在线教程、以及社区讨论。这不仅提高了我的问题解决能力，也让我对行业前沿有了更深入的了解。

最后，感谢团队中每一位成员的付出和支持。有了大家的共同努力，我们成功地完成了这次alpha冲刺，不仅取得了优异的成绩，更锻炼了团队协作和解决问题的能力。我深信，在未来的学习和工作中，这次宝贵的经验将成为我不断前行的动力。期待未来与大家一同再创佳绩！
方蔚杭

这次alpha冲刺,我在学习的过程中遇到了很多困难,但是也收获到了很多东西,比如我学习了一些卷积神经网络的相关知识,学会了一些YOLOv7相关的网络架构,和一些先进的数据增强方法,同时在YOLOv7的网络架构中加入CBAM的注意力机制,使得训练模型更加注重于坑洼的形状特点从而获取更加优秀的权重文件等等…总得来说,在这次alpha冲刺中,我学会了关于深度学习的一些理论知识和提高了机器学习方面的代码能力。
陈欣莹

从一步一步构建人头数据集，以及一步步改进yolov7算法使我学习到了很多东西，在优化yolov7的时候，想了很多方法，但都有点土，于是查阅了很多资料，最终决定采用DAT方法、引入gnConv操作、NAM注意力机制和NWD损失函数，结果日夜不休的辛勤劳作，终于获得了不错的效果，让我感到非常满足，啊真的好累。在这个过程中，我不仅仅是优化了一个算法，更重要的是积累了宝贵的经验和技能，学会了如何处理和优化数据集，学会了如何查找和应用先进的算法技术，更重要的是，学会了坚持不懈地追求目标，哪怕过程中会感到累，但最终的收获是值得的。
吴鑫雄

在这次alpha冲刺阶段中，我不断push自己，学到了许多课程中没有的知识，在我们团队的共同努力下，我们的项目也是做得有声有色，实现了一开始既定的许多目标。在最开始，我深刻感受到了自己能力上的不足，知识上的缺漏，因为我之前没有过前端三件套的知识储备，所以我必须画大量的时间去学习三件套的基础知识，并且还得要去查找很多资料，了解一些美观的页面demo，从而让我有灵感去实现我们的页面制作，最后我也是成功的实现了我们的页面制作。今后的学习生活中，我会继续加强自主学习，同时也向团队里优秀的同学们学习，争取成为更好的前端设计师。在接下来的beta冲刺中，我会继续去查找更好看的页面demo以及一些动画效果，从而让我们的页面更加美观。
林俊杰

这次alpha冲刺我负责的部分是小程序的编写，虽然在之前的结对编程就已经接触过微信小游戏的开发了，但是这次的开发却比我预想的更加困难。上次小游戏不涉及客户端与小程序端之间的文件传输，相关的网络接口可以说是对我透明的，我并不需要关系具体是怎么实现的。但是这次不一样了，我需要调用微信的上传和下载接口来实现所需的功能，所以恶补了下http的相关知识。其次由于我上次所使用的是微信的小游戏框架，所以并不能无缝丝滑过渡到本次的小程序开发。

虽然这次alpha冲刺困难重重，但是我也是学到了不少东西，比如安装cuda，部署相关环境来使用算法组的模型进行推理、再次阅读微信的“写的不错的”文档（我接受事实了，其实阅读文档并不适合作为学习一个新东西的方式），提高了查文档的能力、http网络协议的相关内容等等。

总体而言，尽管alpha冲刺中面对了很多挑战，但这一阶段的学习和经历让我更加深入地理解了项目开发的复杂性，也为未来的工作奠定了更加坚实的基础。在接下来的Beta冲刺中，我将继续努力，不断完善小程序功能，为项目的成功发展贡献自己的力量。
张佳雯

Alpha冲刺两天一篇博客给人的感觉十分紧凑，但是还是感觉两天一篇博客实在是有一丝丝不合理。但是还好下一个阶段的博客的间隔时间就不用这么久了。在本次冲刺任务之中还是遇到了很多困难，最大的困难就在于数据传输的困难，在试过一万种方法后终于成功解决了，真是松了一口气，本来还以为会做不出来的。最后，在这次的实践中我学到了很多与以往在课堂中学习的知识完全不相同的东西。学会了制作页面、数据传输，虽然说起来只有一点点，但是过程中的艰辛只有自己知道。总而言之，这次的经历也算是刻骨铭心。
肖嘉鑫

在这次alpha冲刺实践过程中，我从零基础到逐步掌握JavaScript、HTML、vue3.js等开发语言，从一窍不通到能够独立设计开发符合团队项目需求的可视化数据大屏，从方向不明确到制作出精彩丰富的宣传视频，无不得益于队友对我的热情帮助和爱心包容，同时也深深地体会到了团队中融洽的合作氛围，正如第一次博客中的题目问道：你愿意为一只团队熬夜吗，我想，在这个实践阶段中，我愈加确信我遇到了一个愿意为之努力付出的团队，而对于这个问题的回答，也愈加坚定了。我想，团队中的每位成员都是如此，我并没有看到哪位成员在项目中作出偷懒的行为，他们都十分努力，都在为项目的推进努力，因此在这种互相鞭策和鼓励的氛围中，每位成员都能够得到发展，都能够收获团队合作的乐趣。
对于我来说，alpha冲刺需要不间断地推进项目进度，要求我们每天都要有所进展，我不仅要负责可视化数据大屏的设计开发，还要负责项目的视频宣传，不得不说，这是一个强度不小的任务，但两个礼拜也熬过来了，我很欣喜地看到项目正在朝着我们所预期的方向不断发展，每位成员负责的项目也在逐渐落地，整体呈现出良好的发展趋势，一切的努力都是十分值得的，期待在接下来的阶段中和队友们继续为同一个目标不断努力冲刺！