10组团队项目-中期总结

陈宇尘102101428 2023-11-19 23:29:43

一、团队名片

队长博客链接：https://bbs.csdn.net/topics/617601775
团队logo：
团队ID号与团队名称：10组-鸡丝队
团队现场答辩总结
- 得到BossKe提点可以爬取评论做词频分析，后续会进行相关尝试。
- 历史数据的存储方式还有优化空间。
团队讨论照片：
具体分工与得分比例：

姓名	具体分工	得分比例
王伯平	视频制作	98%
郑芳旭	前端设计	102%
韦星星	各平台热搜数据爬取	99%
张毅凡	爬虫端	99%
格桑旦杰	博客编写	96%
许泽林	爬虫端	100%
张梓源	ui及前端设计、PPT与汇报	99%
林文光	服务器端、视频文案	105%
林宏宇	服务器端	102%
陈宇尘	服务器端	101%

二、总结思考

2.2.1 设想和目标（5分）

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

昨日一览旨在进行信息聚集，具体为收集国内用户常用的 9 大典型信息平台的热点的信息，并将其集中展示给目标受众。让用户可以快速了解广受关注的热点信息。

在软件定义方面，我们有别于一些~~画大饼~~的项目。昨日一览从始至终要实现的功能模块数量不多，要收集的数据平台在开发之初已经由讨论确定。只需组内成员共同为目标努力就好了。

典型用户主要是想破除信息茧房、没时间细览对最近发生的热点事件、不愿看所有平台上繁杂的信息、消除年龄代沟或是对新事物接受程度慢的群体。最为典型的用户和场景就是上水课、食堂排队、睡前刷手机的大学生。

以上话语最终解释权归为鸡丝组组长，如有疑问请在看一遍*《10 组-选题与需求分析报告》。*

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

多说无益，看图说话：

↑ 总功能 ↓ 目前

按照原计划本轮冲刺应该要实现前后端对接的，但最终没能按时实现。其余功能均已按照原计划实现。

~~小程序尚未上线，何来用户一言？~~我觉得我们的 B 站演示视频做的很好，也收获了一些播放量，目前这就足够了。

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

因为目前还没有让用户体验我们的小程序，在这里我说一下作为开发人员自己的感受：

在一开始的设想中，我们想的是点击热门消息直接跳转到浏览器播放消息的。但受小程序安全性限制个人性质的小程序无法跳转。我觉得这是一个很重要的功能，但受不可抗力的影响无法实现。非常可惜。

天无绝人之路，在汇报中老师提出了可以爬取评论做热词分析。我觉得是一种非常好的替代方案。总体来说我们的项目虽然实现不了理想的状态但更加切合实际了。

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

在设计具体功能时还是要更详细地对每个模块做可行性验证。如果历史重来其实我们也没有什么能改变不可抗力的地方，最多就是寻找其他展示方案，因为我们组内对于做这个项目还是比较不可动摇的。

2.2.2 计划（6 分）

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

我们组的时间相对来说是比较充足的，除了视频剪辑以外并没有出现特别需要赶时间的情况，视频剪辑因为所用到的实机视频是在任务的最后才能够产出，所以所留的时间相对来说没有那么充足。

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

对于不同意见，我们组通常是在一起讨论的时候提出，然后一起选出更优解，这样既保证了最后成品是符合我们组所有人的预期，又保证了这个方案在我们力所能及的范围内是最佳的。

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

完成了。

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

在任务规划阶段我们的任务规划是比较明确的，并没有出现做“无用功”的现象。

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

我们目前为止对于任务提交都有明确的定义和衡量，比如爬虫组所要提交的即为每日的热门榜。

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

整个流程基本是按照原计划进行的，没什么意外。在技术上大家都在按照自己的进度进行学习和实践，逐步完成项目内容。风险是没有留时间，导致最后一轮alpha冲刺时要制作视频、PPT等，这方面经验不足，做得比较匆忙，PPT中规中矩。没有估计到的原因是开始时不太清楚中期汇报的流程。

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

没有留缓冲区，希望在下次能够留出缓冲区。如果留足缓冲区的话，就可以更好的改善项目，也不会在汇报前做的匆忙。

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

在原来计划功能的基础上，预计加入爬取评论区的功能，让用户看到人们对这件事情的主流看法。工作量变大，并且计划留点缓冲时间，要做更加紧凑的时间规划，把加班的时间提前，尽量避免到ddl在加班。

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

组员们经常开会交流进度，互相帮助和配合，我们学到了团队的较高效的交流与协作。很多方面都是从零开始，从入门开始，涉及到的数据库、前端、爬虫等技术也有所精进。如果历史能够重来一遍，我们会把计划完成任务的时间提前，并且做出团队的详细进度规划。

2.2.3 资源（6 分）

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

总体来说我们的项目难度不是非常大，在选题阶段我们就对项目的可行性进行了探讨，也在网上看到了许多可以使用的资源，所以目前来说，我们所掌握的资源还是能够支撑我们完成各项任务的。比如，在前端设计上我们有上一次结对编程的经验，在B站上也可以看到相关的教。学视频；在数据爬取上，我们也找到了许多类似的爬取热榜的相关教程；在服务器端我们也在网上找到了相关博客，B站上也有相关的教程可以借鉴。

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

先根据每个任务的难度值，并结合不同队员的能力进行工作分配后，进一步估计任务所需时间并且考虑过程中各种不确定性，在原定工作时间上加上一些缓冲时间，资源方面则是根据不同任务所需进行简单估计并增加缓冲值，随着任务的进展，精度随之提高

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

额我们目前的进度还可，在时间上不是十分紧张，所以后面花在测试上的时间应该是足够的。人力方面的话我们组一共有有十个人——原本是十个人的，但是有一位热心、好学的评测组同学来帮助我们，在这里也是万分感激。所以人力资源肯定是充足的。由于我们的项目是做一个各大平台的热搜榜集合，我们在数据库里存放的是热搜的封面、标题、跳转连接、评论、热度值。总的来说存储量不是非常大，而爬取数据工程量也不是很大，所以目前的软硬件资源足够支撑我们的项目落地。在美工设计上我们有上一次结对编程的经验，所以在前端界面的设计上感觉还可以。虽然，我们前期的UI上确实有点别扭，但是后来经过我们前端组同学的不懈努力下，前端界面好了不少。

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

每个人能力不同，在一些方面其他人可能做的确实比自己好，完成工作的效率更高

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

工作过程中团队之间多进行沟通交流，可以提高工作效率，也可以增加项目的整体质量，改进：将工作速度进一步提升

2.2.4 变更管理（6 分）

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

我们的信息交流十分便捷，我们小组成员都来自同一个班级，也都是在临近的宿舍，我们大大小小的会议开了十几次了，几乎是每天都开，项目一有变更员工都可以及时知道，我们还建立了一个QQ群，在这个群组里，我们可以随时分享项目进展、讨论问题和解决方案，以及发布最新的通知和任务分配。我们的消息传递是十分有效和迅速的。每个相关的员工都可以及时知道变更的消息。

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

1.优先级评估：我们对项目的各个功能进行了优先级评估，根据其对项目整体目标的贡献和紧急程度来确定其实施顺序。优先级高的功能被确定为必须实现的功能，而优先级较低的功能则被推迟到后续阶段进行开发。

2.可行性分析：我们对每个功能进行了可行性分析，评估其在当前资源和时间限制下是否能够顺利实现。如果某个功能的实现存在较大的困难> 或风险，我们可能会选择推迟该功能的开发，以确保项目的顺利进行。

3.里程碑规划：

我们制定了详细的项目里程碑计划，将项目划分为多个阶段，并为每个阶段设定了具体的功能开发目标。在里程碑计划中，我们将必须实现的功能放在了关键阶段，以确保它们能够按时完成。

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

我们对项目的出口条件有着清晰的定义，首先我们要考虑的是功能实现，项目的各个功能是否都已经开发完成并经过测试，确保其能够满足用户的需求和预期,确保其不出现漏洞以及安全性的问题。项目的质量时候达标，成果是否达到了预定的质量标准，例如性能、稳定性、安全性等。项目过程中可能出现的风险和问题是否得到了有效的管理和控制，确保项目的顺利进行。

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

我们小组将密切合作，通过在群里进行协作沟通来应对可能出现的需要变更的情况。我们会及时分享信息、讨论问题，并迅速做出决策。如果遇到较大的变动，我们将召开会议进行深入的讨论和分析。由于我们小组成员都是同班同学，住在相近的宿舍楼里，我们可以方便地进行面对面的交流和沟通。这种便捷的沟通方式有助于加强团队合作，提高解决问题的效率。无论是通过线上群组还是线下会议，我们都将确保及时有效地进行沟通，以应对任何可能的变更需求。

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

对于一些简单的工作请求，比如撰写博客之类的组员容易有效处理，对于制作视频，制作、演讲ppt等内容组员也均能适应处理。我们的组员具备适应处理各种任务的能力，无论是简单的工作请求还是复杂的项目需求，他们都能够高效地完成工作并提供出色的成果。

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

作为组长，我深感自己用人不善。有很多组员有自己的特长或者是学习新技术的速度很快但我在分工时没有了解到，加上对任务工作量的错误预估，导致初期一些工作进度受阻。从现在这个角度会看，如果重来一遍。我会做出更合理的分工。避免组员之间工作量不均衡。

2.2.5 设计/实现（6 分）

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

设计工作主要由服务器组和前端组的同学共同设计，设计初稿在选题与需求分析报告时就以完成。后续在界面搭建的时候也是在不断改进的。

在项目开始时就开始设计工作，并在后续实现的过程中不断根据要求改进。我认为是非常合适的，至于设计人选，由于组内都是理工男，在审美方面还是有些欠缺的，总是感觉交互设计还差点意思，但似乎也找不到更好的人选。

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

比如在搜索栏和详细信息展示界面我们不知如何具体设计。最终团队参考了一些其他小程序的设计方案，敲定了最终的设计样式。

我们组团队开会还是比较频繁的，遇到模棱两可的问题我们往往通过提出多个方案随后组内投票来决定最终方案。

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

在选题与需求分析阶段，每个分组的成员都对各自分属的模块做了UML图。为了能明确任务规划，我们也绘制了一些流程图，思维导图来细化项目进度。
我们组内开发时流传着一句话：“ 面向GPT编程”，ChatGPT确实是非常便捷好用的工具。
总的来说组内使用的一些工具都是行之有效的，因而我们组目前的项目进度也比较明朗。

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

区别主要存在于接口部分和用户端部分。我们在项目实现过程中简化了一些没必要传递的信息。同时也优化了一些交互逻辑。如果从现在的角度重新做UML图应该会更为简洁。
接口部分的区别主要在于爬虫的过程中部分数据获取困难且不便于在小程序界面展示。因而商讨觉得删去。用户端部分的区别主要是功能实现有所差别，优化了跳转部分的逻辑。
我觉得总的来说UML的差别不算特别大，也没有说要新增什么模块或者流程。没有必要花时间更新UML。专心实现项目就好。

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

bug出现最多的模块在于服务器的运行，因为组内成员鲜有相关经验。所以经常遇到版本兼容性问题，而且一旦遇到往往要更改实现逻辑了。
目前项目没有发布，如果让我预测可能出现的问题可能就是服务器能否处理高频高带宽的请求。目前没有做过压力测试，不知道具体能处理的请求带宽。

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

~~ GPT会给出答案 ~~，都什么年代了还在做传统复审。你觉得大学生懂代码规范还是GPT懂。一开始向他说明规范内容，剩下的把代码给他让他帮你自动改，最后验证一下是否影响功能的正常运行即可。
以上内容切勿当真，实际情况是项目没有到达该做集中代码复审的阶段，每个成员的代码复审均由自己完成，团队在项目初期的代码规范主要在于接口的格式规范，目前项目能否正常运转就说明还在可控范围之内。

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

计划赶不上变化是常有的事，重要的是在理想与实际产生偏差时如果做出处理应对。这也是我们组内不断学习进步的地方。
要说改进的话就是多积累一些服务器知识吧，书到用时方恨少。在实现的时候碰上自己看不懂的bug、焦头烂额时才发现事前了解有关用法的重要性。
人的一生也不总是一帆风顺的，我觉得从设计/实现方面来看鲜有优化的进步的空间。时间和进度是需要各个环节协调才能进行的。在这个时间段内，如果可以重来也不见得就能比现在做的更好。别老是在这里自怨自艾，总得向前看吧，一个博客想了4-5次重开会怎样，你不怕我真重开吗？

2.2.6 测试/发布（5分）

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

有，在项目实现后会对小程序的功能进行测试，主要测试小程序UI是否存在bug,例如适配各种机型，是否能展现应有的全部信息，图片链接能否正确显示出图片等等；小程序显示的热搜和昨天对应app的热搜是否一致；小程序的搜索功能搜索出的结果是否符合用户的需求，是否具有人性化；点击组件能否正确跳转等等。

2.是否进行了正式的验收测试？团队是否有测试工具来帮助测试？

目前还没有进行整体的正规测试，但是对已经实现的功能进行过实机测试，没什么问题；
现在还没有使用专门的测试工具进行测试，等功能基本实现后会用专门的测试工具，例如JUnit，PyTest，LoadRunner，Apache JMeter等对小程序进行单元测试和性能测试。测试下图片加载速度是否足够快，页面切换十分卡顿，是否有占用内存或时间太大的函数可以改进之类的

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

目前小程序只简单地进行了实机测试，通过发布小程序体验版测试当前实现的功能，根据测试者自身的感觉来反应小程序的性能，总体感觉小程序加载很流程，没有明显的卡顿，图片切换很自然，爬取的结果也十分正确。
从软件是实际运行效果来看，这些测试还是很有必要的，是对当前工作的一段总结，验证了软件的可行性和可靠性，为后续的开发打下基础，减少了前期的bug。并且在实机测试的过程中也发现了实际的UI界面在手机上看着和预期有些差距，才能及时改正，这些测试总体是非常的意义的。

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

小程序目前还没有正式发布，只是发布了体验版，遇到的问题就是UI和预期的有略微差距，于是在团队共同协作下及时改正了这个问题。总的来说没太大的问题；
但是在开发过程中也遇到了些问题，例如有些软件只有app端无法爬取热搜，这对我们的项目实现和发布有很大的困扰。于是我们换了个思路选择了一些别的有这些app热搜信息的网站，转去爬这些网站的内容也能实现功能；
具体发布的时候可能需要备案和代码检测之类比较繁琐的步骤，可能有些资料填的不对审核就不给过，要得等一段时间重新审核。由于我们是爬取其他软件热搜的信息整合型软件，所以不知道这种类型的软件审核会不会比较麻烦点，但是由于是个人性质而且非盈利的应该还是不会太为难我们。我们也预先去试了下我们小程序的名字发现是可以审核通过了，没有重名和敏感词，只能说微信小程序发布实在太麻烦了。

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

本次的发布和测试基本只测试了前端的功能，测试的结果还是比较令人满意。也学到了团队配合的重要性，在大家对前端UI的各种讨论下才制作出了这么好看的前端界面。有了好看的前端，后端开发也更有动力和信心；也认识到了要发挥每个人各自的优点，各司其职，同时也相互配合，才能对项目做出最大的贡献；最后开发小程序本身也是学无止境的过程，过程中总能遇到各种问题以及遇到各种新的知识需要学习，在这个过程中也提高了知识的储备和编程技能。
如果重新开始做这些任务的话，基本也差不多吧，项目目前还没遇到太大的问题是需要重开才能解决的，最多就是大家能加快点进度，能早点把小程序做出来，就能多些时间优化了；然后前后端的对接要做好，一开始就要定义好接口，才能明确好要爬取的内容和后端需要存储的数据。

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

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

首先根据成员的能力、技能和经验，其次就是个人的意愿来确定的。虽然有的成员没有分配到自己最擅长的位置，但是通过小组成员之间的讨论和交流，提出自己的意见和建议，也算是人尽其才了。

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

有，团队成员之间经常沟通交流，共同寻找问题的解决方案。我们这一轮在完成任务时，也经常讨论问题，虽然分为不同的小组，但是成员之间还是经常互相沟通交流，很多问题也在沟通的过程中集思广益，最终顺利解决。

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

首先是沟通和协商，成员之间应该开放地沟通，共同讨论问题，并寻找解决方案。我们这一轮在完成任务时，也经常讨论问题，虽然分为不同的小组，但是成员之间还是经常互相沟通交流，很多问题也在沟通的过程中集思广益，最终顺利解决。
其次就是团队会议，因为两台要交一次博客，我们也定期召开小会，讨论项目的进展、遇到的问题和解决方案，在开会的过程中共享信息、交流意见，并协商解决方案。接着是分工和协作，我们根据各自的专长和能力，分成了四个小组，分别是前端组、爬虫组、后端组、汇报组，分担各自的任务。通过有效的分工和协作，可以更好地应对问题并解决挑战。
然后是寻求专业支持，遇到困难或问题超出我们能力范围，我们会寻求专业支持，包括从chatGPT、博客或者其他途径寻求帮助。
最后是持续改进，我们会持续进行反思和评估，寻找改进的机会。通过回顾项目的经验教训，识别问题的根本原因，并提出改进方案，以避免类似问题的再次发生。

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

我感谢宏宇对我的帮助，因为他在我们对服务器怎么实现还没什么进展的时候，搭建的服务器，实现了数据的上传和获取，为我们后续的开发提供了方向。
还有文光也一直在统筹全局，把大家凝聚在一起，我们才能相互合作一起完成这次的作业。

2.2.8 总结（6分）

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

张毅凡：

总结：在这次软工实践中，我主要负责爬虫部分的内容。通过开发的过程，我学到了许多知识和工具。
我学会了如何描述用户画像。在项目中，我们需要了解我们的目标用户是谁，他们的需求是什么，以及他们的使用习惯是怎样的。通过分析用户数据，我能够准确地描述出我们的目标用户画像，从而更好地设计和开发我们的软件。我学会了制作用户端类图、ER图和燃尽图。这些图表对于项目的规划和管理非常重要。通过制作类图，我可以清晰地展示系统中各个类之间的关系和功能；通过制作ER图，我可以设计数据库的结构和关系；通过制作燃尽图，我可以跟踪项目进度和任务完成情况。我还学会了如何上传本地仓库到GitHub，并解决上传过程中出现的各种问题。GitHub是一个非常流行的代码托管平台，通过将代码上传到GitHb，我可以与其他开发者共享我的代码，并与他们合作开发。在上传过程中，我遇到了一些问题，比如权限设置、分支管理等，但通过查阅文档和寻求帮助，我成功地解决了这些问题。我学会了如何使用Python中的selenium和beautifulsoup库来爬取各大网站的数据。这两个库非常强大，可以帮助我从网页中提取所需的信息。通过学习它们的使用方法和相关技巧，我能够高效地爬取大量的数据，并将其用于分析和处理。我学会了如何定义接口。在软件开发中，接口是非常重要的一部分。通过定义接口，我可以规定系统各个模块之间的交互方式和数据传递格式。通过学习接口的定义和使用，我能够更好地组织和管理我的代码，提高系统的可维护性和扩展性。总的来说，每个冲刺阶段都有合适的内容学习和实践，虽然过程累而充实，但我收获了很多知识和技能。这次软工实践不仅让我更加熟悉了软件开发的流程和方法，还提高了我的团队合作能力和问题解决能力。我相信这些经验和技能将对我的未来发展产生积极的影响。

陈宇尘：

总结：本次Alpha冲刺虽然作为服务器组暂时没太大的展现机会，但是也学习到了很多关于后端和数据库的知识。这次的冲刺也让项目的进度实现了较大的跃进，团队的每个人都做好了各自的工作，相互协作，目前做出来的成功还是很不错的。通过这次的软工项目，不仅对个人的编程水平有了较大的提升，也提升的团队协作的能力。现在小程序已经有了大致的样子，接下来就需要和服务器配合实现最后的功能了，希望后面能顺利的完成任务，尽力把小程序做的更好。

郑芳旭：

总结：在这次软工实践中，我深刻体会到了团队合作的重要性。在项目开始阶段，我们进行了充分的讨论和规划，明确了每个人的职责和分工。在这个过程中，我学会了如何与团队成员有效沟通，提出自己的想法和建议，同时也倾听他人的意见，共同为项目的顺利进行做出贡献。在前端设计方面，我首先进行了需求分析，了解了用户的需求和期望。然后，我参考了市场上其他类似产品的设计，结合我们的项目特点，进行了界面布局和交互设计。在设计过程中，我注重用户体验，力求让界面简洁明了，操作便捷。同时，我还关注到了细节的处理，如按钮的样式、动画效果等，以提高用户的使用满意度。在设计完成后，我与团队成员进行了多次讨论和修改，以求达到最佳的效果。在这个过程中，我学会了如何在团队中发挥自己的专长，为项目的成功贡献自己的力量。同时，我也认识到了自己在前端设计方面的不足之处，需要在今后的学习和工作中不断提高和完善。

张梓源：

总结：这次软工实践，我主要负责前端，身为一个理科生，设计出的UI并不是特别好，还好通过团队大家的讨论，修改完善得到了更好的原型，前端界面设计过程中，一直扮演着协助者的身份，在这过程中还是学习到许多东西的，并且认识到团队协助的重要性，通过网课学习也了解并掌握的有关知识，我相信在我们的努力下，这个项目我们团队一定可以完成的又快又好

韦星星：

总结：在alpha冲刺阶段，我主要负责对抖音、百度贴吧和小红书的热搜榜进行爬取。过程中也遇到了一些困难，例如：抖音爬取的跳转链接有问题、小红书热榜难以爬取等等。但是在经过上网查询、同学帮助下成功解决。总的来说，在经过这个阶段后，我对于爬虫有了一定的基础，了解了一定的python知识。也明白了在遇到困难时，可以先问一下GPT、寻求队友帮助会是非常明智的选择。

王伯平：

总结：在这次alpha冲刺中，我主要是负责的视频的制作。由于之前制作视频的经验不是很充足，在制作的时候也遇到了一些问题，一些动画效果也并未实现，但是这次经历也是对我的一个很好的磨砺，相信在下个阶段会有更好的表现。

许泽林：

总结：在alpha冲刺阶段，我主要负责的是对快手、知乎、今日头条热榜的爬出。一路做下来，总体是比较顺利的，当然也有遇到一些问题，比如头条的视频链接是不能直接爬取的，需要通过一步一步对链接的部分进行提取，组合在一起，诸如此类，主要是细节上的问题。在本次课程中也学到了不少的开发知识，接触了需求文档的撰写、UML的知识和制作。这些东西虽然入门很难，但是没有接触过的话是很难把它做好的，早接触早学习积累经验是有帮助的。在搜索学习资料和进行debug时，用上了gpt,不得不说，AI的效率比自己一行一行细品代码高多了。遗憾的是在制作PPT和视频时参与的比较少，失去了这个边学习边实践的过程。

林宏宇：

总结：在本轮任务中，主要负责后端服务器的搭建和数据对象的定义，一开始是想通过js获取云服务器上的mysql数据库数据，但是微信开发者工具一直下载不了完整的mysql2包，所以放弃了这条路。后面通过python的flask库创建对应app的路由，然后通过小程序通过访问不同的路由获取所需的信息。后面也参与了前端页面的设计和汇报视频的制作，

林文光：

总结：每两天写一次博客确实是一件比较有意义的事，可以一直push成员在一定时间周期内拿出成果。但也对组织者对于成员每轮的规划提出了要求。清晰合理的规划能切实促进项目进度，分配不均的时间也会让同学深受各科作业量的共同折磨。在本轮中我自觉主要的工作就是协调各个环节的工作。每个模块遇到问题都会来找我，很多情况下我不了解具体的设计情况，只能给出一些方向性上的建议。也是希望后半部分的项目可以顺风顺水吧。本轮在成果展示阶段我参与了汇报视频的制作。选用麦克阿瑟的主意是由我敲定的，文案工作也是我写的（写的时候才发现自己溜得还不够多）。之前在看到别的组有做这个风格的时候很担心本组的视频能否带给大家眼前一亮的效果，好在最终结果还是很不错的。

格桑旦杰