02组团队项目-中期总结

[黄逸舟102101440]

一、团队名片

• 队长博客链接：https://bbs.csdn.net/topics/617601645

• 团队logo

  • 团队ID号：02

  • 团队名称：大咖

• 团队现场答辩总结

• 团队讨论的真实照片

• 以表格形式展示团队中每个人在本次作业中的具体分工和各自得分比例

成员姓名	具体分工	得分比例
蔡宇杭	爬取美团、饿了么等平台用户关于咖啡的数据以及信息处理	101
薛承瀚	爬取美团、饿了么等平台用户关于咖啡的数据以及信息处理	99
李佳航	根据数据库结构来组织、存储和管理收录各咖啡单品和品牌信息	100
林展平	根据数据库结构来组织、存储和管理收录各咖啡单品和品牌信息	100
徐宇锋	判断前端需要获取何种信息，从数据库取出信息并分析后输出到前端	100.5
曾嘉诚	判断前端需要获取何种信息，从数据库取出信息并分析后输出到前端	99.5
黄逸舟	设计页面、还原页面以及获取用户所需信息	100
吴星宇	设计页面、还原页面以及获取用户所需信息	100

二、总结思考

2.2.1 设想和目标（5分)

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

  我们的软件解决咖啡评价问题，定义相对清晰，典型用户是咖啡爱好者和咖啡投资者，典型场是客户选择咖啡商品时提供参考
  

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

  原计划功能正在实践中，按照原计划略有拖延（考试有点小多），目前暂未上线，没有用户
  

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

  暂无用户反馈，我们离目标一步步靠近
  

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

  需要吸取的教训就是爬虫难度需要客观评价，历史重来，可能会选择不同的数据获取方式
  

  2.2.2 计划（6分）

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

  有充足的时间来做计划。
  

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

  团队在计划阶段会征求每个组员的意见建议，然后加以改进，最后得到大家都认可的方案计划
  

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

  原计划的工作基本完成了，有部分没做完的是技术上遇到的问题
  

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

  没有，都挺有价值的。
  

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

  有，任务都有清楚定义和衡量的交付件
  

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

  整个过程都按照计划进行
  

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

  有留下缓冲区，作用是遇到困难疑惑，可以集思广益，求助一下其他组员
  

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

  加班吧，加速推进进度
  

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

  学到了做项目之前，最好制定完备的计划，如果再来一遍，会制定更详细更公平的计划。
  

2.2.3 资源（6分）

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

  我们的团队拥有充足的资源来完成各项任务。我们已经在项目计划中详细列出了所需的各项资源，包括人力、时间、硬件和软件资源等，并且我们已经为每个任务分配了适当的资源。
  

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

  我们在进行任务分配时，首先对每个任务进行了详细的分析，并根据团队成员的能力和经验，对完成任务所需的时间和其他资源进行了估计。我们的估计考虑了各种可能的风险和意外情况，以确保我们的计划具有可行性和准确性。
  

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

  在测试阶段，我们将分配足够的资源和时间以确保测试的完整性和准确性。我们将确保拥有足够的人力、软件和硬件资源来进行测试，并解决可能遇到的问题。
  对于非编程方面的资源需求，如美工设计和文案等，我们已经充分考虑了其难度和所需的资源，并制定了相应的计划。我们将确保拥有足够的人力、时间和软硬件资源来满足这些需求。
  

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

  作为团队项目编程的组长，我的职责是协调和管理团队成员的工作，确保项目的顺利进行。虽然我可以承担一些任务，但我相信团队的力量，并且我会将任务分配给最适合的团队成员。通过合理的任务分配和协作，我们的团队可以更高效地完成任务。
  

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

  在过去的项目中，我们学到了许多宝贵的经验教训。例如，我们在初期阶段曾经遇到了一些沟通问题，导致任务分配不够明确，影响了项目的进度。后来我们加强了团队之间的沟通，定期进行进度汇报和讨论，确保每个团队成员都明确自己的任务和责任。
  如果历史重来一遍，我们会在项目初期更加注重团队成员之间的沟通，确保每个人都明白项目的目标和计划，并及时解决沟通障碍和问题。此外，我们还会更加注重任务的划分和时间管理，确保每个任务都有明确的负责人和时间节点，以避免延误项目进度。
  

2.2.4 变更管理（6分）

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

  是的，我们的消息沟通比较及时，大多数情况会直接到宿舍通知
  

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

  在项目开始的会议时，我们先讨论了一下有什么功能需要实现，之后讨论了一下项目的基础功能有什么，哪些是其他功能实现的基础，之后就确定了“必须实现”的功能，其他功能就是“推迟”的功能
  

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

  本来我们的出口条件是能实现用户模块、首页模块、种草模块、每日推荐模块、数据大屏这几个基础模块以及子功能，但昨天的汇报我们的项目被老师批评，因此会再跟老师沟通修改项目功能。
  

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

  目前没有应急计划，但希望能早点做完，以应对紧急状况。
  

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

  可以，我们组员的沟通积极性比较高，也比较不计较工作量，因此对于突发情况我们都愿意处理
  

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

  学到了对于项目要预留冗余功能，不能只满足于基础功能，基础功能要尽早完成，多留时间给进阶功能，其次是项目要有创新点，要打破信息差。如果历史重来一遍，会给项目多设计一些功能。
  

2.2.5 设计/实现（6分）

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

  设计工作在前期主要是由黄逸舟、吴星宇完成，时间和人都比较合适。
  

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

  有，如部分功能的具体细节不清晰，原型设计中图标均为灰色，没有使用任何具体的图标。团队通过会议进行深入讨论，从而明确了各类细节。
  

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

  是，使用了原型设计工具，UML以及思维导图，这些工具在整个开发过程中起到了关键作用。
  

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

  比起开始，现在的UML文档更加复杂详细，同时对一些模块功能做了一些取舍。团队在一次次的讨论过程中，逐渐对UML文档进行扩展，同时对各个功能模块的开发周期进行评估，舍弃一些因为能力不足或时间有限，难以实现的功能模块。UML文档仍需要更新。
  

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

  小程序页面部分产生了最多的Bug，因为开发小程序时使用的功能框架本身并不完美，在开发过程中会遇到很多问题。发现的重要Bug是导航栏的图标无论如何都无法加载，一片空白。因为这类Bug潜藏在功能框架这类第三方库中，开发人员调试的只有自己的代码，难以消除他人代码的问题。
  

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

  由开发经验丰富的成员（这里是吴星宇成员）对其他人写的代码的格式、写法进行复审，同时给出修改意见。整个项目严格执行了代码规范。
  

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

  学到了团队在代码协作上的相关经验。我们会提早进行原型设计等工作，从而提高其余部分的开发效率。
  

2.2.6 测试/发布（5分）

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

  有测试计划，由于项目还在进展，还未进行正式的验收测试。
  

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

  有测试工具来帮助测试
  

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

   目前是根据测试效果和计划效果的比对来测量和跟踪软件的效能，有一定的用处，可以发现项目的测试过程中的问题以及提高改进的思路，改进的话，可以选择多种测试工具，从不同的角度测试与跟踪软件的效能。
  

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

   项目还在进展，暂未发布。
  

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

   学到了测试在项目的过程中还是比较重要的，不能到项目都完成了再进行测试，过程中的测试也是很重要的，测试的角度也很重要。改进方面：在项目开始时，先选择好测试工具，在项目进行的过程中，进行多重角度的测试且挑选出合适的测试工具。
  

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

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

  在最开始的会议，组长蔡宇杭同学将整体项目内容分为了爬虫、数据库、前端、推荐算法四个部分，大家通过自己的技能优势选择了想要完成的内容。团队角色确定是符合人尽其才的，吴星宇同学有过做前端的经历，因此选择做前端设计，蔡宇杭同学和薛承瀚同学对爬虫较为熟悉并且感兴趣，因此选择完成项目中需要爬虫获取数据的部分。
  

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

  是的，团队成员之间通常会互相帮助。在团队合作中，我们共同追求项目的成功，这也是我们的一致目标，在第一次现场编程时，大家出现问题及时讨论，如果有同学出现困难例如vscode配置环境出现问题以及脚本软件安装出现问题，也是一起想办法解决。在现场编程写脚本的过程中，大家有问题及时讨论。
  

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

  共同探讨和提出解决问题的方案。进行头脑风暴等，以找到最佳的解决方案。一旦确定了解决方案后制定一个详细的行动计划。这个计划包括具体的任务、责任人、时间表和预期结果，以确保问题得到有效解决。我们之后便按照制定的行动计划开始执行。密切合作以确保每个任务按时完成，并及时调整计划以适应变化的情况。
  

• 在解决问题的过程中，我们定期监督和评估进展情况。方式包括但不限于举行会议以及共享资源等

  当出现项目管理、合作方面的问题时，我们采取积极的态度，一起面对和解决问题。通过相互有效的沟通和协商，特别是站立会议时面对面沟通以及制定和实施相应的解决方案，可以确保项目顺利进行，实现团队合作的成功。
  

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

  非常感谢吴星宇大佬给予我对前端的帮助和原型设计的建议。
  

2.2.8 总结（6分）

蔡宇杭：经过这次爬虫尝试，运用了部分第一次个人作业所学会的知识，认为还需要彻底了解其构造原理，并且能够应对反爬虫举措

李佳航：α冲刺阶段我们的沟通做的还不错，但我们对于项目的要求不够高，且没有创新点，在β阶段会尽可能找到创新点。

曾嘉诚：通过这次α冲刺阶段的学习，我掌握了嵌入式SQL程序如何对应各种搜索情况，能够将数据库语言嵌入到高级语言中应对多种情况，接下来我会接着学习实现更多拓展功能。

黄逸舟：通过这次冲刺，我学习了微信小程序原型设计和前端的创建，要跟团队组团进行良好的沟通，不足是前端技术vue等还有欠缺

徐宇锋：在Alpha冲刺的过程中学到很多新的知识，如：前后端如何实现信息交互、推荐算法等，也体验到了团队是如何制作一个项目的。中途也遇到了很多的困难，感谢团队在这个过程中给予的帮助，成功解决了许多问题，在后续的Beta冲刺进行努力，按计划完成项目。

薛承瀚：发现爬虫没有我想象中那么简单，由于生活中经常使用美团，所以一开始想着从美团上爬取数据，结果发现美团的url太难寻找了，在alpha冲刺后期于是改成使用饿了么来爬取数据

吴星宇：在α阶段开发过程中，开发时间过于紧张，导致开发进度过于缓慢了。今后的开发一定得提高效率了。

林展平：参与这个软件工程实践项目，我深刻认识到团队合作、需求分析、规划、技术实践、代码质量和测试以及项目管理的重要性。通过紧密的团队合作和沟通，我们共同应对各种挑战，并取得了项目的成功。同时，我也学会了如何进行有效的项目管理，掌控项目的进度、资源和风险。这些经验和教训将对我的职业生涯产生积极的影响。