07组团队项目-中期总结

[迟梦莉102101506]

一. 团队名片（5分）：

• 队长博客链接（请在博客开头给出）

  ​

• 团队Logo

• 团队ID：07组

• 团队名称：我的未来我做组

• 团队现场答辩总结
  本次的现场答辩和上次的不太一样，所以没有收到大家的反馈，很可惜，不过总的来说，这次的汇报还算不错，ppt应该也比之前进步吧，希望我们继续努力，为下一次的回报奋斗！

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

  姓名	具体分工	得分比例
  迟梦莉	负责手语识别和翻译算法的研发和优化 2.实现算法模型的训练和部署	95
  田鸿越	负责手语识别和翻译算法的研发和优化 2.实现算法模型的训练和部署	95
  陈嘉辉	负责开发和维护Web端的用户界面	95
  曾则远	负责收集手语视频数据和语言数据集 2.对数据进行清洗、标注和整理	80
  魏燕清	负责开发和维护小程序端的用户界面	95
  杨云开	负责手语识别和翻译算法的研发和优化 2.实现算法模型的训练和部署	140

二.总结思考

2.2.1 设想和目标（5分）

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

​ 针对于软件要解决的问题我们有十分清晰的认知，我们的用户画像就是文化水平较低的聋哑人群体，也正是这种明确的认知，我们在产品设计中也不断贴合实际，提高用户满意度。针对于典型用户以及典型场景，我们希望在公共场所，也就是聋哑人群在需要快速沟通交流的场所有所突破，当然日常生活中的交流也不可或缺，例外在教学、医疗等领域，我们也在不断设想更多的可能性。

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

​ 我们目前算是完成了主要目标，也就是主干功能的搭建，算是完成了原计划功能的70%，并求按照原计划交付时间交付了，由于还没有投入使用，所以没有用户数量，目前仍然是内测阶段。

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

​ 在内测阶段，我们也尽量设想并且模拟用户在系统使用上可能存在的需求，并不断改进提升模拟用户的满意度，我想我们确实在不断向目标靠近

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

​ 得到的教训是，数据集的格式不要那么快就决定，如果再来一次，我一定不会先处理数据集，这种中文的视频数据集实在太难处理了，每一次改进算法都要改数据集的格式，真的头大！

2.2.2 计划（6分）

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

在项目正式启动前，我们留下了充足的时间来对项目进行了计划。

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

① 在项目计划阶段，选题很明确，我们一开始就决定好了这个题目，没有进行什么讨论。但是我们在如何完善功能上花费了许多时间（四个多小时）进行讨论，对于选题的意见和功能的意见，我们在那次讨论上对于项目有了整体的一个规划，每个人的意见也得到了理解与解释，最终实现了意见上的统一。
② 在对于计划分工的意见上，对于开发同学，我们在组队之初就有了比较明确的分工；而对于文档PPT视频制作方面的同学，也经过内部的协商和轮流的工作实现了统一。

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

原计划的工作基本都能顺利完成，对于没有完成的部分都是经过仔细考虑后发现可以暂时先不进行的部分。最初的工作计划是打算实现较多词汇频率的手语翻译和生成，但是经过仔细的考虑和现实的训练情况决定先训练较常用的手语词汇。

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

有一些事情是我们已经投入了一些时间之后发现没有必要的，于是都尽量的及时止损；没有是完全做完之后发现没必要或没多大价值的事。比如在对手语数据集进行处理的时候，考虑到了对话的逻辑问题，但是这种情况会造成训练的语句内容很少，所以这个工作是先投入了一些时间，但是发现可以不使用这种方法之后，我们就及时止损了。

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

对于比较主要的、比较大的每一项任务我们都有比较清楚的定义和衡量的交付件；对于一些比较小的任务我们采取较简单的方式

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

① 项目的整个过程都基本都是按照计划进行的，项目没有出特别严重的意外。
② 由于项目设计的时候考虑的比较完备，没有出现什么超出预期的风险。

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

基本在计划的每一个阶段都有留下一定的缓冲区，缓冲区能够在一定程度上使得项目进度持于一个平稳的位置，同时保证了我们项目的进度可以顺利进行。

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

对于将来的计划，会继续保留缓冲区，同时对于分工和工作计划进行更加明确的规划设计。

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

① 通过这次项目，学习到了项目的第一步是计划，只有一个好的计划，才可以保证项目好的进展，保证项目的完成。还学到了团队合作，需要和队友进行沟通，在思路不太通顺的时候，这个时候可以和队友进行一些思想交流的碰撞，这会有助于我们能够对项目进展提供一个更好的方向。
② 如果历史重来一遍，会将任务更加细化，同时合理规划好每个任务的时间，保证每个时间点都能完成相应的任务，这样可以保证项目的进度，同时保证开发人员之间的对接。

2.2.3 资源（6分）

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

​ 资源确实是我们一直以来都很头疼的问题，目前正在使用的数据集是中科院建立的中文手语数据集，来源可靠，数据的真实性得到了保证，但是他的缺点也很明显，覆盖的词汇不够全面（对于中文词汇来说，两千个词汇还远远不够），画质较差（但是将他生成骨骼图也较好的解决了这个问题），目前我们找不到更好的数据集来取代它。另外是计算资源，这个项目要用到的计算资源实在巨大，这不是服务器的问题，所以我们也在努力做简化了。

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

​ 我们在算法方面的时间花费很多，其他方面的时间比较均匀，我们前端等方面的要求不高，所以投入的时间也不算特别大，主要的精力在于不断优化模型，使之提高精确度，但是我们的精确度确实不高，仍然有一定的提升空间。

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

​ 虽然我们组的人数不多，但大家都有不错的能力，所以我们的人力资源还算充足，软件/硬件的资源也比较足够，对于不需要变成的资源，我们组负责的同学非常给力，非常优秀，所以尽管这方面有难度，但是我们没有消耗太多的时间，所以也并不算是低估了难度。

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

​ 我们组的人员分配还是十分合理的，我们相信由擅长的同学来完成相应的工作是节省我们项目时间的，但是对于交换任务来说，我们也相信组内的任何人都可以很好的完成，针对于自己没办法完成的任务，组员们也会及时提出，清晰地衡量出自己能胜任的工作，毕竟对于团队来说，最重要的是对团体内部的每一个人负责。

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

​ 沟通交流真的很重要，如果再来一次的话，我们希望组内每个人都能更好的了解队友的擅长部分，各尽所长。当然，我们认为这一次的组内配合也十分不错，感谢大家的付出。

2.2.4 变更管理（6分）

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

基本可以，我们小组每两天都会开一次小组会议，每个人汇报各自的任务完成情况

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

我们一般采用协商的方式，如果负责该任务下游任务的组员一定需要这部分的内容，则为必须实现的任务，否则就可推迟

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

任务本身向外提供完整的API函数，内部有处理异常的机制可供调用者调试测用API

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

能，小组任务中就有许多任务是紧急情况，如另时更改数据集的形式等

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

当然没有问题，项目的进行过程中难免有紧急问题的出现，一般该问题归属于上游任务的负责同学完成，而往往应急问题大家都能妥善解决

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

学到了多人开发协作沟通是非常必须的，本小组任务进行的过程中，不免出现一些因为沟通不善而重复造轮子的行为，或是不了解上游任务的完成情况，导致下游任务迟迟无法开展等问题，如果再来一次，一定要打卡每天自己完成的任务

2.2.5 设计/实现（6分）

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

设计工作在这个项目一提出来的时候，就由田鸿越和迟梦莉同学完成，是合适的时间合适的人。

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

在设计工作中，在关于页面功能分布已经具体实现细节又出现过分歧，但是我们小组通过开会大家一起商议，投票解决。

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

我们组采用了单元测试和UML来帮助我们实现,单元测试能够帮助我们在设计的过程中及时发现错误并改正,UML能够帮助我们更好的理解系统需求以及统一我们小组的建模语言等.

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

因为我们项目一开始就已经非常明确我们系统所要实现的功能以及客户人群,所以我们的UML图并没有发生变身,不需要更新UML文档.

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

在手语翻译和手语生成的功能实现过程中BUG 最多,因为这两个功能本来就不算是非常简单的项目,我们需要直接重新构造数据集,训练我们的项目,然后在手语翻译的过程中,任何杂乱的背景或者手势的不清晰都可能影响翻译的结果,所以导致BUG更多.在发布之后发现的BUG目前只有前端页面,在我们快要发布的时候,发现没有设置分辨率自适应,于是在每个人的电脑上所展现的效果不同,但是后来已经修复.

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

首先我们先选出团队成员来担任审阅者。审阅者会仔细阅读和分析代码，检查其是否符合代码规范、是否存在错误或潜在的问题，并提出改进建议。审阅者与代码编写者进行讨论，共同解决发现的问题，并对改进建议进行沟通和确认。目前我们严格执行了代码规范.

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

学到了多人开发协作沟通是非常必须的，在团队项目中一定要多与团队成员沟通,及时发现大家的问题.

2.2.6 测试/发布（5分）

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

是否进行了正式的验收测试？

有，项目进行过程中，每完成一个模块，我们都会进行相应的单元测试。在各个模块都完成并整合后，我们会进行验收测试。目前还没有进行正式的测试验收。

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

有，目前用了pytest,Selenium

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

目前主要是通过响应时间，和判断结果是否正确来测量的。确实测出了一些问题，也进行了相应的改进。之后会采用更加严谨更加专业的方法。

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

Web前端完成时，由于测试不够严谨，在几个组员的电脑上测试都没有出现问题，但是中期汇报前一天又在一台新的电脑上出现了问题。
因为某门课的考试，报告前期出现了很严重的时间不足。

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

要提前建立测试环境，与实际使用环境尽可能接近，来减少在发布过程中发现的意外问题。 并且要引入自动化测试工具和流程，以提高测试效率和覆盖率。 重来一遍我们会指定更加详细且严谨的测试计划

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

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

团队中的每个人负责各自擅长的领域，当然是人尽其才。

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

当然，遇到一些没有接触过的问题，有经验的成员会提供帮助协助开发。一些有联系的项目，例如数据集处理和模型训练，需要多加沟通，提供合适的数据。

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

我们会进行会议，讨论当前阶段遇到的问题，明确各个组员当前阶段的任务分工，避免造成进度迟缓，工作量分配不均等问题。

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

   我感谢 田鸿越同学 对我的帮助，因为在我赶ddl的时候帮我承担了许多的工作，同时感谢杨云开同学深厚的代码水平，拯救我们组于水火当中，感谢前端和视频制作的同学，弥补了我所没有的审美。

2.2.8 总结（6分）

列出组内所有人Alpha冲刺阶段后的心得。

• 迟梦莉

  • 首先十分感谢组内成员的协力配合，每次分配的任务，大家都没在赶ddl，在摸鱼的时候突然收到组员交上来的任务，让我十分羞愧，也让我更加努力的赶进度，这个阶段的完成度我认为还是不错的，当然，这个阶段也让我认识到了大家的特长和优点，为下一个阶段我们组内更好的合作，打下了基础。我们的组员每一个人都是宝藏，再次感谢大家的付出！

• 田鸿越

  • Alpha冲刺阶段，我做了算法相关的工作，首先是学会了去github查找相关的代码资料，其次是学会从网上查找相关的论文，能够从他人的代码或者论文里学到许多很有前瞻性的知识。然后还学会了和队友进行合作，手语的翻译和生成本身就是一个比较难实现的项目，这些都需要进行无数次的训练才能很好的学会人体的骨骼点等特征。最初的时候，我是希望能够对单个词语进行训练，但是在队友的帮助下，我才明白最初的思路是行不通的。单个词语的训练只能实现孤立词语的识别，我们的目标是识别句子，句子的识别属于连续手语的识别。那么应该怎么改进呢？当然是在句子中训练了，所以最初得到的数据集或许帮不上什么忙了，所以我们选择了重新自己构造数据集，构造一个map，映射句子里手语和标签的关系，把整个ai的训练放在一个句子的思维里，这样才能达到更好的效果。后续Beta阶段，将进一步完善页面设计，以及接口的编写。需要继续冲刺，不断改进之前的不足，学习其他队友的优点，也需要更进一步学习技术，提升自我。

• 杨云开

  • 经过了α阶段的努力，终于完成了小组任务的核心模块，生成功能和翻译功能，这两个模块看似轻飘飘，实则背后的技术繁琐至极，为了搞好这两个模块，我们小组翻阅了近两三年来的顶刊顶会，寻遍GitHub上面的开源代码，自制手语部分数据集，为了模型的鲁棒性，小组成员们呕心沥血，爆肝三个夜晚，完成了2w条高质量数据集的制作，这对于我们寥寥数人的小团队来说，几乎是不可能的任务，但我们还是完成了，现在我们的系统仅差后端服务器的功能实现，和模型训练，可以说任务到后期就只剩下一些边边角角的修复任务，经过这次α冲刺，无疑对于我们小组每个人都是一次精气神的洗礼，从一个懵懵懂懂的大学生逐渐成为了可以独当一面的工程师，付出了辛勤的努力，得到了物超所值的汇报，感谢这次软工作业，让我们每个人都变成了一名经验丰富的工程师。

• 魏燕清

  • 在α阶段中，我深入了解了微信小程序的开发方式和规范。我学会了使用小程序提供的组件、API和工具，熟悉了小程序的生命周期以及数据绑定等核心概念。这让我对微信小程序的开发流程有了更全面的了解。在制作微信小程序的前端过程中，我需要与产品经理、设计师和后端开发人员密切合作。通过与团队成员的沟通和协作，我更加深入地理解了用户需求，并学会了将设计思维运用到实际的开发过程中。这让我明白了用户体验的重要性，培养了对产品设计和用户需求的敏感性。我遇到了各种各样的问题，如界面布局错乱、接口调用错误等。通过仔细分析和调试，我学会了快速定位问题所在，并提出解决方案。这锻炼了我的问题解决能力和调试技巧，让我能够更加高效地解决各种技术难题。制作微信小程序需要与团队成员紧密合作，共同完成项目。我学会了与他人沟通、协调任务和解决冲突，提高了团队合作和项目管理的能力。

• 陈嘉辉

  • 这一次的冲刺让我深深的感受到了“适当的压力也是动力”的道理，虽然每一天都笼罩在Alpha的阴霾之下，但这确实也促使我去学习、去与困难战斗，当Alpha冲刺结束之后回望自己在这过程中的努力与收获，感觉一切还是挺值得的。说实话，我人缘一直不太好，直到组队的最后一天我才找到小组。我进入小组的时候他们选题就已经定好了，我看到小组选题的时候就觉得“？这是大学生能搞出来的东西？”。我不是一个很有自信的人，所以我会害怕在这个小组里啥都做不了。不过好在，我还是在小组里找到了属于自己的位置。我主要负责的工作是一部分前端和PPT还有视频的制作。我自己一直都有在做视频，做视频也是我的个人爱好。我以前自己做视频都是比较喜欢慢工出细活的。一个视频基本都要做上三四十个小时。但是很显然，这次alpha冲刺没有那么多时间给我，最后还是苟且地去套了模板，很多想法没实现。也算是个遗憾吧，希望项目的最终视频能把自己的创意展现出来。

• 曾则远

  • alpha冲刺阶段我跟随团队学习了许多知识，了解了一个软件的主要组成和项目的分工合作。还学习了许多软件开发的方法论，以及开发相关的工具和知识。不过，我的基础还是很薄弱，需要打更多的代码。软工这门课让我学到了很多，还有我们的组员十分包容，业务能力非常强，让我打开了全新的世界。