03组团队项目-中期总结

[郑泽淞102101529]

一、团队名片

1.队长博客链接

https://bbs.csdn.net/topics/617601370

2.团队logo

3.团队ID与团队名称

ID：03

团队名称：八俊徒

4.团队现场答辩总结

在本次现场答辩中，我们对项目进程进行了全面分析，发现整体进度相对较慢。为了加快进度，在下一阶段，组长将更加积极地督促组员们，推动项目的进展。同时，组员之间也将相互督促，以确保任务按时完成。此外，本次答辩中最为重要的是指出了我们组在算法方面存在严重错误的问题。这意味着在后续的β冲刺阶段，我们需要持续探索新的算法，并对现有算法进行优化和改进。这将是一个挑战，但我们相信通过团队的努力和合作，我们能够找到更好的解决方案。

5.团队讨论的真实照片

6.以表格形式展示团队中每个人在本次作业中的具体分工和各自得分比例。（得分比例之和为*总人数100%**，例如3人团队得分比例可以为95%、100%、105%）

姓名	具体分工	得分比例
郑清桔	算法	114%
郑泽淞	算法	103%
杨宇晗	前端+UI设计	103%
陈佳俊	算法	115%
孙祥	爬虫	115%
庄晨	后端接口	75%
陈湛钦	数据库建立	75%
		700%

二、总结思考

2.1设想和目标（5分）

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

我们的软件是要解决水果新鲜度检测难题，帮助人们能较为轻松地挑选比较新鲜的水果而无需太过专业的知识。定义非常清楚，就是降低挑选新鲜水果的学习难度，典型的用户是缺乏挑选新鲜水果经验和想查询水果新鲜度的人群，应用在检测水果新鲜度的场景。

2.我们达到目标了么？（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么？)

由于新鲜度检测算法实现难度比较大，算法实现有些问题，但其他基础功能如搜索，查询水果相关信息这些还是有做到的，能够按照原计划交付。

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

用户量和用户对重要功能的接收程度和我们事先的预想一致，因为新鲜度检测的功能实现效果不是很好，我们也觉得无法接受，但好在我们又找到了另一种实现方案，虽然适用此方案的水果种类会少很多，但是预期实现的效果还行，算是找到另一种通往目标的路径吧。

4.有什么经验教训？如果历史重来一遍，我们会做什么改进？

经验教训是要做好调研，确定的功能要具有可实现性，最好要有多种备份方案，到时实现困难要具有灵活可调整性。如果历史重来一遍，我们会对方案进行改进，确定多个方案以确定开发过程种能灵活调整。

2.2计划（6分）

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

时间是比较紧的，因为这学期课程作业比较多，但是还是能够完成计划的。

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

遇到不同意见时，团队会一起讨论这些意见，并完善和改进计划

3.原计划的工作是否最后都做完了? 如果有没做完的，为什么？

大部分已经做完了，一些比较少的部分因为时间问题，以及技术难度的问题，会在接下来的β冲刺继续完善。

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

对于后端接口部分，一开始我们将其作为一个单独的模块来处理。然而，随后我们发现实际情况是后端接口可以与前端进行结合，而且所需的接口数量并不多，这导致后端接口部分的任务量相对较轻，从而反映出任务分配不均的情况。

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

是的，比如：

数据采集与准备：
定义：收集具有不同新鲜度等级的水果样本图像数据，对数据进行标注和预处理，建立用于训练和测试的数据集

交付件：包括收集的水果样本图像数据集、标注和预处理过的数据集

算法研究与选择：
定义：调研图像识别和深度学习算法，选择适合的模型架构，设计用于水果新鲜度检测的图像处理和特征提取方法

交付件：算法调研报告、选定的模型架构和特征提取方法

系统测试与优化
定义：对系统进行功能测试和性能评估，通过真实数据集进行系统验证和优化

交付件：系统功能测试报告、性能评估报告、系统优化方案

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

大部分过程都是按照计划进行，项目遇到了一个比较严重的问题，就是对于算法部分的选择，由于算法选择错误，导致在下一阶段我们需要重新选择算法。

没有估计到的风险就是算法选择失败，因为当时对项目的分析还不够仔细，不够全面。

7.在计划中有没有留下缓冲区，缓冲区有作用么？

在计划中有留下缓冲区。缓冲区有作用，在其期间内可以调试程序，修改bug，讨论不足并制定下一个小阶段的目标。

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

由于在中期答辩中被要求理清楚我们的技术路线，所以我们初步打算先集思广益，让每个人都上网查阅相关资料，讨论出一个相对可行的技术实现。由于这两周其他课程作业也相对较多，每个成员时间都不多，下一个月课程陆续结课，会投入更多时间来进行研究开发。

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

学到了任务制定一定要合理，我们在某个小阶段的成果验收阶段，发现某些组员所完成的任务有高度相似部分，也就是说这些任务完全可以就分配个一个人来完成，人力资源得到浪费，如果历史重来一遍，一定会更谨慎认真的负责每个阶段的任务划分让每个人每个阶段都能发挥出作用。

2.3资源（6分）

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

就目前的现状来说，以我们所拥有的资源和能力，还有对于网络以及现实书籍的资料整合情况来看，在算法方面实现我们最初的目标是有一定的难度的，不过在该项目的其他方面，我们仍然拥有足够的资源去实现项目的各项任务。

2.各项任务所需的时间和其他资源是如何估计的，精度如何？

各项任务所需时间的估计，我们是根据最初各项工作的花费时间对后续工作花费时间进行预估的，而资源的预估，我们是根据能查阅到的相似项目的资源使用情况进行预估的，就目前来看，精度还在可接受范围内。

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

就目前完成的任务来看，测试的时间还足够，人力、软件资源还较为充裕，不过缺少一定量的硬件资源，因为我们的项目是基于计算机视觉的，所以需要大量的GPU资源进行运算。对于美工设计的难度我们是低估了，毕竟我们都是计算机系的学生，无论是审美基础还是美术功底，这些点肯定赶不上专业的美术系学生，所以我们可能需要更多的精力去研究美工设计。至于文案，这一点倒是还好。

4.你有没有感到你做的事情可以让别人来做（更有效率）？

目前的任务分配很合理，倒是没有这种感觉。

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

我们的初期目标有一点超出目前我们的能力范围，如果重来一遍，我们可能会更加谨慎的去进行技术路线的选择。

2.4变更管理（6分）

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

是的， 我们通过定期召开会议，向团队传达变更信息，并让成员提出问题和意见。在大伙时间不充裕的情况下也可以通过QQ群及时了解变更消息。

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

首先对功能进行评估和排序，根据需求和价值，确定哪些功能是必须实现的，哪一些是次要的，基础功能就是必须实现的，附加的功能都是其次的，当有充足的时间的情况下再考虑做“推迟”的功能。其次考虑团队的资源、时间和能力。如果团队资源有限，必须考虑哪些功能可以在当前条件下实现，哪些需要推迟。

3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

是的，项目的出口条件是指确定项目何时被认为已完成或达到某个阶段的标准或条件。我们虽然算法上有所欠缺但都有一个规划，确保了最后项目成果的质量最低要达到什么要求。

4.对于可能的变更是否能制定应急计划？

是的，制定应急计划是项目管理中至关重要的一步，尤其是针对可能的变更或意外情况。这些计划可以帮助我们在变更或突发情况发生时迅速做出反应，以最小化对项目进度和成果的负面影响，比如重新选定负责人，在某方面加大人手，定期测试等。

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

不一定，每个人擅长的领域不同，在某些“技术活”上，还有所欠缺，作业意料之外的工作请求不一定能有效的处理，通常可以让其他成员协助以更好的处理意料之外的工作请求，或者网上查询学习。

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

合理分配工作，合理利用网上的知识，利用好各个成员的擅长。如果历史重来一遍，我会更加合理的分配组员的工作，督查组员完成自己的工作，以达到目标时间所要达到的项目要求。

2.5设计/实现（6分）

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

• 大致的设计工作（包括客户端、技术栈、软件风格、页面设计、功能等）是在确定选题前完成的，详细的设计工作（开发流程、交互设计）实在确认选题，α阶段冲刺之前完成的

• 设计工作完成时间较为符合团队心目中的预期，能有效的在软件开发前做出需求分析以及生成设计文档，在合适的时间内完成

• 在选题确认前后，小组多次进行例会讨论，从需求分析到开发流程再到具体的分工安排，团队每个人都积极参与其中，踊跃表达自己的观点和建议并及时汇报进度，郑清桔同学在例会中总结设计工作，设计工作中不存在不合适的人。

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？

在设计工作中吗，确实在功能选择上存在不确定性，比如跳转百度百科或是引用后台提前布置的数>据库的功能选择需要进一步的对需求进行评估，团队后续对技术方面的可行性进行了分析并且得知>了微信小程序不允许跳转含查询参数的链接，最终确定了后者方案。

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

团队有运用单元测试来对重要的模块进行输出测试，有使用UML类图描述软件架构、设计和过>程，这些工具十分有必要，UML类图在开发前帮助我们了解大致的模块结构，单元测试帮助我>们调试程序可能存在的漏洞。

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

肯定是有区别的，毕竟我们还不是资深的程序员，难以精确地保证设计与程序实际开发中的每>个类和方法都达到一致，但大致是吻合的，比如在搜索结果中我们还添加了推荐存储方式这一>个量，这些区别是在开发过程中对模块进行复审产生的，需要更新UML文档

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

产生最多Bug功能也是我们这次项目最关键最核心的图像处理算法模块，产生原因为数据集不够经典，存在差异。在前端真机演示过程中发现了夜间模式无法在其他页面维持，原因和wx.navigateTo()，wx.redirectTo()跳转方式有关。原因：设计和开发时对技术栈没有很深刻的了解，对其只是在理论上有着一定掌握并且知道其可行性和大致的实现方法。

6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

检查代码结构、逻辑、安全、性能，检查代码格式和命名规范，并及时修改，严格执行了代码规范。

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

学到了设计工作和分析对于软件开发具有重要意义，设计工作是软件开发的蓝图，如果没有进行设计工作只是盲目瞎干，则无论在团队协调还是功能、模块的构造、衔接上会出现很严重的问题。如果再做一遍，我们会在开发前更深入了解实现方式和各个模块需要用到的技术，并且认真考虑选题。

2.6测试、发布（5分）

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

团队有一个测试计划，以确保在软件开发周期的各个阶段都能进行充分的测试。同时，团队也有正式的验收标准，以确保软件符合我们团队的预期，避免发布时出现意外问题。

2.团队是否有测试工具来帮助测试？

团队有测试工具来帮助测试。使用pytest,JUnit等对独立单元进行测试。同时使用Selenium,Appium等软件进行测试用例的自动执行。也有SonarQube,Checkmarx等软件用于静态代码分析，以检测代码中的潜在问题。

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

团队通过性能测试，评估软件在不同负载下和条件下的性能。同时使用静态代码分析工具评估代码质量，包括代码复杂度，潜在的缺陷。

从结果来看，这些测试工具在软件开发中发挥着重要的作用。还应该确保测试用例覆盖到系统的各个方面，包括不同的功能、路径和边界条件。还考虑使用新的测试工具，特别是那些能够更好地适应项目需求的工具。

4.在发布的过程中发现了哪些意外问题？

在软件的发布过程中，我们遇到了较为严重的技术问题，即以最初设想的技术方法难以完整地实现我们团队所预期的功能。同时，也出现了在生产环境中，观察到软件的性能不如预期的问题。

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

在本次的开发过程中，我们学习到应该更早地对整个项目的技术需求有更为完整的认识，同时应持续进行项目的跟进，强调持续集成和持续交付。

如果历史重来一遍，我们会更早的对软件进行测试，思考更加可行的算法以完成我们的既定任务目标，实现我们最初设计的功能。同时，我们也会更强调持续集成和持续交付，减少潜在问题的集中爆发。

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

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

我们初步是按照每个人的擅长方向来确定分工，对于接口、数据库等所有组员之前没接触的部分我们会分配学习能力比较强的人去学习运用。

2.团队成员之间有互相帮助么？

团队成员之间有互相帮助，某个部分遇到问题的时候，有余力的组员就会来帮助他解决这个问题，或者是在某个组员时间比较紧的时候，其他组员会帮助他一起完成某项任务。

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？

当出现项目管理、合作方面的问题时，团队成员如何解决问题？
出现这方面的问题的时候，我们都会到食堂聚集讨论一下， 灵活地分配每个人的任务，力求做到分工明确，人尽其用，尽量避免两人工作方向高度重叠的情况出现，

4.每个成员明确公开地表示对别人帮助的感谢 （写在各自的博客里）：

我感谢郑清桔对我的帮助，因为在某个阶段中我的代码调试一直通过不了，他帮我完美解决了问题

2.8总结

郑清桔

在α阶段中，我深刻认识到了技术选择的重要性。在项目初期，我们可能没有充分考虑到不同检测算法和技术对于水果新鲜度检测的适用性和性能差异。另外我也意识到项目进行过程中，团队成员之间的有效沟通和协作能力对于解决问题、调整方向至关重要，通过α阶段，我们组加深了团队合作的意识，并意识到团队间的良好沟通是项目顺利进行的基础。

陈佳俊

本次Alpha冲刺我学到了很多东西，接触到很多关于AI领域的东西，学习到了很多新知识。虽然相关算法实现起来很困难，但仍然有所收获。我深刻体到了团队间合作和沟通的重要性。我们作为一个团队，需要共同面对挑战、解决问题，充分发挥每个人的优势，推动项目向前发展。有些东西不是光靠一个人就能做出来的。

陈湛钦

我负责的部分是数据库,在学习数据库的过程中,我发现这之中存在很多的细节,稍有不慎自己做出的程序就会出错,调试时显示各类错误,比如：没有using命令、标点符号的错误。尤其是汉语下的标点符号和英文符号，有时看着很像，但在数据库应用程序中就是对与错的区别。通过这次项目的学习，让我对于数据库有了更深的理解。也让我加深了对于团队协作的理解，对我今后参与编程项目也打下了基础。

孙祥

这次alpha冲刺阶段，感觉每个人任务量分配的不是很好，有些人偏难有些人偏简单，感觉难的人做起来挺自闭的，就目前的成果来看还是没有达到预期的，希望在后面的阶段中能再接再厉，和伙伴们做出期望的项目。

杨宇晗

在UI设计的过程中，我对绘图工具和原型设计工具的使用相比于之前有了更进一步的掌握。在前端真机演示过程中发现了夜间模式无法在其他页面维持，经过逐步排查wx.navigateTo()，wx.redirectTo()跳转方式有关。在图片的布局中花费了不少时间弄明白容器和层级关系，mode使用widthFix，图片尺寸和位置使用自适应单位rpx会比较好处理，在不同手机尺寸的页面自适应。参数在不同页面的传递，淡入淡出动画，图标通过平移切换状态也花费不少时间，最后都顺利开发实现，然后就是接口部分，也顺利地测试了请求与接收、处理，并将结果呈现在前端页面上。这次团队编程我学到了设计工作和分析对于软件开发具有重要意义，对UI和前端有了更进一步的学习，并学习了前后端对接数据请求与处理。

庄晨

通过本次Alpha冲刺阶段，我意识到团队协作的重要性，同时也意识到沟通的重要性。也发现了自己较多的不足之处，包括对于本次项目的重视程度仍然不够高，这也导致了在本次Alpha冲刺阶段我认为我完成的工作不太够，这也为我在接下来的beta冲刺阶段指明了道路。

郑泽淞

在α冲刺阶段我负责的是算法部分，研究项目的技术路线，在这个阶段我接触学习到了YOLOV8目标检测算法，自己建立数据集并训练出能够从图片中识别到水果的模型，对深度学习也有了进一步的认识。在接下来的阶段，我也会进一步学习水果新鲜度检测算法，认真完成项目。