团队作业6——复审与事后分析
个人简历
| 姓名 | 学号 | 班级 |
|---|---|---|
| 赛普拉·伊敏江 | 3122004705 | 计科3班 |
Alpha阶段项目复审
团队表现汇总
| 组名 | 优点 | 缺点 | 名次 |
|---|---|---|---|
| 白蓝混子队 | 功能多样性： 团队提供了较为全面的聊天功能，包括文本消息、图片消息、表情、文件传输等，满足了不同用户的需求。测试覆盖全面： 提供了详细的测试矩阵，覆盖了登录与注册、聊天模块、群聊模块和好友模块等多个方面，确保了基础功能的稳定性。技术栈多样性： 团队使用了多种技术栈，包括java环境、mysql、mongoDB、redis和浏览器等，显示出了较强的技术整合能力。 | 部分功能延迟： 有3个bug被延迟到下一个版本修复，包括登录连接turms服务器使用的还是userId和password，未来会尽力修改为token校验，这可能会影响安全性和用户体验。性能测试不足： 团队提到正常使用并未进行压测性能，这可能意味着在高负载情况下软件的稳定性和性能尚未得到验证。用户体验细节： 存在一些设计上的考虑，如注册发送验证码之后60秒之后才能再按，这可能影响用户体验。 | 1 |
| 拖延是你不队 | Bug修复与分类： 团队在测试过程中发现并修复了4个Bug，并对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。用户需求明确： 团队明确了不同用户群体（学生、管理员）的需求和目标，并提供了相应的功能来满足这些需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了多个平台和浏览器，确保了软件在不同环境下的兼容性 | 性能问题： 存在响应缓慢的问题，这可能是性能问题，需要在后续版本中得到关注和改进。功能延迟： 有3个Bug被延迟到下一个版本修复，包括图片显示失败、二级评论失败、信息刷新时文本框未能及时清空，这可能会影响用户体验。环境限制： 网站的限制主要体现在不同浏览器的兼容性问题，以及由于缺乏经济来源导致的服务器性能不足。 | 2 |
| 雄狮般的男人 | 全面的测试过程： 团队遵循了详尽的测试计划，包括测试准备、功能测试和回归测试，确保了软件质量。详细的测试矩阵： 提供了详细的测试矩阵，覆盖了教师端和学生端的多个关键功能，如注册登录、班级管理、作业设置和成绩管理。用户需求明确： 团队明确了教师和学生的需求和目标，并提供了相应的功能来满足这些需求。 | 界面设计待美化： 项目存在的问题之一是界面设计需要进一步美化，这可能影响用户体验。推广途径有限： 项目缺乏有效的推广途径，这可能限制了软件的普及和用户反馈的收集。 | 3 |
| 代码敲不完队 | Bug修复与分类： 团队在测试过程中发现并修复了4个Bug，并对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。用户界面友好： 提供了登录注册、商品列表、我的订单等多个功能的用户界面截图，显示了界面的直观性和易用性。功能全面： 提供了包括登录注册、商品列表、我的订单、聊天消息、个人信息、我的收藏等在内的全面功能，满足了用户的基本需求。 | Bug延迟修复： 存在4个Bug被延迟到下一个版本修复，包括用户登出后仍可使用JWT令牌、图片上传问题、不能重复评价同一订单、不能重复收藏同一商品，这可能会影响用户体验和数据准确性。性能问题： 提到响应缓慢的问题，这可能是性能问题，需要在后续版本中得到关注和改进。环境限制： 网站的限制主要体现在不同浏览器的兼容性问题，因此在各个浏览器上的支持情况存在差异；同时，由于缺乏经济来源，所使用的服务器成本较低，内存性能相对不足。 | 4 |
| 不要指望我们队 | Bug修复效率： 团队在测试过程中发现并修复了6个Bug，显示出了较强的问题解决能力。功能全面性： 提供了包括登录、学生管理、课程管理、成绩查询等在内的全面功能，覆盖了学生和管理员的基本需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了多个功能模块，包括登录功能、学生端操作、管理员操作等，确保了核心功能的稳定性和可靠性。 | 用户体验问题： 界面逻辑上存在欠缺，进行了补充设计，这可能意味着初始版本的用户体验不够流畅。性能问题： 系统还未能承受大规模用户数量，这是后期需要关注和改进的主要方向。功能不完善： 提到功能不完善、界面逻辑不完善、界面不美观等问题，这些都是后续版本需要改进的地方。 | 5 |
| Elegance | Bug修复效率： 团队在测试过程中发现并修复了6个Bug，显示出了较强的问题解决能力。用户友好的交互设计： 提供了简洁、轻量的网页形式，满足不同用户的需求，如模拟面试、法律咨询等场景。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了登录、对话、充值等多个功能模块，确保了核心功能的稳定性和可靠性。 | 功能延迟： 有2个Bug被延迟到下一个版本修复，包括前台窗口卡顿问题和用户输入数据的错误鉴别问题，这可能会影响用户体验。功能限制： 目前功能较少，需要后期继续改进优化，特别是对于未部署至服务器的问题，限制了软件的可访问性和实用性。 | 6 |
| 虹猫蓝兔七侠队 | Bug修复效率： 团队在测试过程中发现并修复了1个Bug，显示出了较强的问题解决能力，且没有延迟修复的Bug。用户需求明确： 团队明确了不同用户群体（家长、学生、学长学姐、教师）的需求和目标，并提供了相应的功能来满足这些需求。功能全面性： 提供了展示学校分数线、环境、伙食、住宿、学生评价、课表等功能，覆盖了用户的主要需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了学号认证、学生评论、分数线展示等多个功能模块，确保了核心功能的稳定性和可靠性。 | 功能深度： 家长模块的信息获取有限，目前只有分数线，可能需要更多的信息和更好的排版。后端压力： 提到增加更多排版会对后端接口开发造成较大压力，这可能影响后续功能的扩展和维护。 | 7 |
| 小飞棍队 | Bug修复与分类： 团队在测试过程中发现并修复了1个Bug，并对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。功能全面性： 提供了登录与注册、商户模块、消费者模块等多个功能，覆盖了商户和消费者的基本需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了登录、注册、商品搜索、购物车等多个功能模块，确保了核心功能的稳定性和可靠性。 | 功能延迟： 有1个Bug被延迟到下一个版本修复，包括促销热榜和24小时热榜不显示榜单，这可能会影响用户体验。性能问题： 提到多台设备或多个浏览器允许同一用户同时登录的问题，这可能是性能或设计问题，需要在后续版本中得到关注和改进。功能限制： 商户功能比较单一，商品推荐功能未完善，只能根据总流水进行分析推送，无法根据用户个人喜好分析。 | 8 |
| 发际线和我作队 | 针对性的Bug修复：团队修复了一个具体的Bug，即图标显示错误，显示出对细节的关注。明确的设计决策：团队对于系统设计有明确的决策，例如不在登录页面设置注册功能，以保证系统的安全稳定。测试覆盖：团队提供了测试矩阵，覆盖了多个关键功能，如打开链接、界面展示、货物信息、货物编辑等，并在不同平台（Windows和安卓）上进行了测试。清晰的发布标准：团队明确了Alpha版本发布的出口条件，包括所有功能的完备性、关键Bug的修复以及测试人员的全面测试。 | 功能延迟：有一个Bug关于货物分类下面不显示当前分类下的货物信息被延迟到下一个版本修复，这可能会影响用户体验。功能限制：团队提到功能还未完善，目前的演示账号只能管理同一个仓库，这限制了软件的实用性。性能问题：没有提供关于性能测试的信息，这可能是一个需要关注的领域。 | 9 |
| lzw1322 | 用户需求明确： 团队明确了管理员和用户的需求和目标，提供了相应的功能来满足这些需求，如商品发布、购物车管理等。功能测试覆盖： 提供了详细的测试矩阵，覆盖了用户注册与登录、发布商品、查找商品信息等多个功能模块，确保了核心功能的稳定性。用户界面友好： 提供了登录、注册、商品发布和购物车的用户界面截图，显示了界面的直观性和易用性。 | Bug延迟修复： 存在一个Bug关于搜索功能无法正确处理某些商品名，这被延迟到下一个版本修复，可能会影响用户体验。性能问题： 提到商品数据有时候会加载不出来，这可能是性能问题，需要在后续版本中优化数据库，提高查询和访问效率。环境限制： 推荐使用edge浏览器，这可能限制了软件的兼容性和可访问性。 | 10 |
| 民族大团结 | Bug修复与分类： 团队在测试过程中发现并修复了3个Bug，并且对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。功能针对性： 团队针对学生、老师和管理员的不同需求提供了相应的功能，如成绩录入、成绩查询和权限管理，显示出对用户需求的深刻理解。测试覆盖： 提供了详细的测试矩阵，涵盖了登录功能、学生端、教师端和管理员端等多个方面，确保了关键功能的稳定性和可靠性。 | 性能问题： 存在一个Bug关于成绩排序错误，这可能影响用户体验和数据准确性，且被延迟到下一个版本修复。环境限制： 软件对运行环境有特定要求，如Windows10和MySQL 5.5，这可能限制了软件的兼容性和可访问性。数据同步问题： 在多用户同时操作时，可能会出现数据不同步的情况，这需要在后续版本中得到关注和改进。 | 11 |
| 物归原主队 | Bug修复数量：团队修复了6个Bug，显示出较强的问题解决能力。功能实现：团队提供了包括用户注册与登录、发布失物信息、查找失物信息、认领失物等功能，覆盖了失物招领平台的核心需求。测试覆盖：提供了详细的测试矩阵，覆盖了关键功能模块，如用户注册与登录、发布失物信息等，确保了核心功能的稳定性和可靠性。 | 性能问题：存在系统响应时间较长的问题，这可能严重影响用户体验。硬件资源限制：硬件资源有限，无法支撑大规模扩展，这可能限制了软件的可扩展性和稳定性。数据库查询效率：数据库查询效率低，复杂查询影响整体性能，这需要在后续版本中得到关注和改进。 | 12 |
| 做不队 | 问题解决能力： 团队在测试过程中积极发现并修复了3个Bug，显示出了较强的问题解决能力。例如，使用nextTick解决了栏目切换后请求错误的问题，以及通过设置type:"button"解决了表单提交导致的页面刷新问题。用户反馈考虑： 团队考虑到了用户在浏览文章时刷新页面会丢失内容的问题，并计划在下一个版本修复，显示出对用户体验的重视。代码质量： 提到了代码的可维护性，并且有每日构建的实践，这有助于保持代码的质量和项目的持续集成。 | Bug重现困难： 存在一些Bug在正常使用时不会触发，这可能会给未来的维护和测试带来挑战。用户体验问题： 团队提到了用户在修改个人信息后，上传头像无需点击确认修改即可完成更改，这可能会导致用户混淆，建议进一步优化用户交互流程。测试覆盖不足： 仅在Windows平台和两种浏览器上进行了测试，可能未能覆盖所有用户环境，建议增加更多浏览器和操作系统的测试。 | 13 |
| 永远写不队 | Bug修复效率： 团队成功修复了3个已识别的bug，显示出了较强的问题解决能力，特别是在身份验证、功能选择和查找用户方面。测试覆盖： 提供了详细的测试矩阵，包括登录功能和聊天功能，这有助于确保软件的基本功能按预期工作。用户需求明确： 团队明确了用户的需求和目标，即日常聊天和学习交流，并提供了相应的功能来满足这些需求。 | 功能延迟： 有3个bug被延迟到下一个版本修复，包括图片显示失效、查找历史消息和添加好友，这可能会影响用户体验。功能单一： 团队提到功能较为单一，功能尚未完善，这限制了软件的实用性和吸引力。环境适应性： 测试仅在Edge浏览器上进行，没有提及其他浏览器或操作系统的测试，可能存在兼容性问题。 | 14 |
| 赛普拉·伊敏江 | 规划完善，对于分工有着很好的规划；项目为喜欢玩集合游戏的用户提供了一个平台，平台上功能基本完善，可以分享，创建，加入；是现在市场上较少的方向，富有创新性 | 网站加载速度较慢，影响用户体验，在一些浏览器和设备上，网站不太友好或是不兼容，布局出现了一些问题 | 15 |
事后诸葛亮分析
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
本系统包括了社区内管理各项功能，并针对住户和物业人员两个角色给予不同的权限，从而解决社区管理混乱复杂的问题，达到减少人力资源的使用和降低管理费用、提高信息准确度和可靠性、改进社区管理和人员服务和建立高效的信息传输和服务平台、提高信息处理速度和利用率的效果。定义清楚并对典型用户和典型场景有清晰的描述。
是否有充足的时间来做计划？
有。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
针对提出的不同意见，全组组员通过线上会议和群聊进行讨论权衡或以投票形式来决定最终意见。
计划
你原计划的工作是否最后都做完了？如果有没做完的，为什么？
没有。大部分都完成了，小部分是能力不足或花费的时间较多。
基本完成。剩下的一些细节由于时间不够而放弃了。
由于没有涉足难度大的开发工作，所以我能完成我原计划的工作。
全部完成了，部分接口时间不足弃用功能。
有没有发现你做了一些事后看来没必要或没多大价值的事？
有一些，比如说过于纠结页面的某些样式结构，花费了大量的时间研究，最后还是舍弃了这部分内容，因为不合预想或不如之前的好。
以及例如在开发页面时会对一些细节过于钻牛角尖，事后发现并没有必要纠结。
是否每一项任务都有清楚定义和衡量的交付件？
是，每一项任务都通过github的issue分模块定义，清晰标明了组员的任务情况、进度进展和交付情况。
是否项目的整个过程都按照计划进行？
并没有严格按照计划进行。计划中某些比较困难的部分花费了较多的时间，也有些较简单的部分花费了较少的时间。虽然实际进度对后面的计划有一定的打乱，但是后期团队也加快了自己的脚步和对接进度，最后基本完成了我们定下的计划。
资源
我们有足够的资源来完成各项任务么？
资源足够，但开发经验不足，缺少UI设计师。
各项任务所需的时间和其他资源是如何估计的，精度如何？
任务分解，经验预估，精度较高。
测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
时间、人力、软硬件资源充足，低估了美工设计难度。
你有没有感到你做的事情可以让别人来做（更有效率）？
各司其职，效率高。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
明确需求分析，全面风险评估，加强协作和沟通。
变更管理
每个相关的员工都及时知道了变更的消息？
是的，群内通知，及时回复确认。
我们采用了什么办法决定“推迟”和“必须实现”的功能？
线上讨论，投票决定。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
有，功能模块完成，测试无bug，用户易上手。
对于可能的变更是否能制定应急计划？
能，基础功能完成后再扩展，及时变更。
员工是否能够有效地处理意料之外的工作请求？
能，积极配合，学习新知识并应用。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
及时沟通，做好保底工作，遇到瓶颈及时变更。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
项目确定时由团队共同决定，合理。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
团队商讨，共同决定解决方法。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
用单元测试，有效。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计/开发的时候没有想到这些情况？
前后端交互产生的Bug最多，发布后暂未发现bug。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
各自负责各自代码的审读。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
调整任务分配，分配人员进行代码审读及专门进行测试，提升效率。
测试/发布
团队是否有一个测试计划？为什么没有？
有。
是否进行了正式的验收测试？
有不完整的测试。
团队是否有测试工具来帮助测试？
没有。
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
尚未跟踪。
在发布的过程中发现了哪些意外问题？
我们学到了什么? 如果重来一遍, 我们会做什么改进?
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
根据大家的能力和个人意愿确定角色。
团队成员之间有互相帮助么？
有，我们讨论比较多，遇到问题能一起解决。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
讨论，统一观点。
结论
通过这次项目，我们不仅完成了预期的功能开发，也在过程中积累了丰富的经验。尽管存在一些不足，但这些都是宝贵的学习机会。未来我们将继续改进和完善系统，同时也会将这些经验应用到新的项目中，不断提升团队的能力和项目的质量。
