团队作业6——复审与事后分析

这个作业属于哪个课程 计科22级34班
这个作业要求在哪里 作业要求
这个作业的目标 完成点评与复盘

前言

本篇博客是团队作业6，目的是对他人项目做点评并复盘自己的项目。

团队简介

  • 队名

    拖延是你不队

  • 队员学号

姓名 班级 学号
艾彬（组长） 计科4班 3122004730
陆宇星 计科4班 3122004491
范圣林 计科4班 3122004735
王佳伟 计科3班 3122004880
郑玮源 计科4班 3122004760

复审

小组名字和链接 优点 缺点，bug报告 最终名次
Elegance 项目在多个主流浏览器上进行了测试，确保了良好的兼容性。通过微信公众号实现快速登录，简化了用户操作流程。提供了登录、切换大模型、场景选择、对话和充值等功能，满足基本的使用需求。 项目尚未部署至服务器，只能在本地环境中运行，限制了用户访问的便利性。提到功能较少，需要后期继续改进优化，说明当前版本可能无法完全满足用户需求。存在前台卡顿问题，影响用户体验。 用户输入数据的错误鉴别不足，可能导致程序运行时出错，这也是计划在后续版本中改进的问题。对运行环境有特定要求（Windows系统、JDK1.8、Mysql8数据库），可能限制了在其他环境下的部署。 3
小飞棍队 提供了登录与注册、商品查询、商品预览、购物车等核心功能，满足基本的电商需求。项目考虑了商户和消费者的需求，提供了相应的功能来满足这些需求。使用了WebSocket和ES（Elasticsearch）等技术来提高性能和用户体验。 商户功能比较单一，消费者未实现多端登录功能，限制了用户的使用体验。商品推荐功能只能根据总流水进行分析推送，无法根据用户个人喜好分析，这可能影响个性化购物体验。存在促销热榜和24小时热榜不显示榜单的问题，这可能影响用户对热门商品的了解和购买。项目对运行环境有特定要求，如Java环境、MySQL和浏览器，这可能限制了在其他环境下的部署。提到了多台设备或多个浏览器允许同一用户同时登录的问题，这可能涉及到安全性和用户体验的问题。 4
雄狮般的男人 提供了详尽的测试矩阵和场景测试，覆盖了教师端和学生端的多种功能，这有助于清晰地了解软件的功能实现情况。Alpha版本实现了创建班级、作业布置、批改作业、加入班级、完成作业和查看作业分数等关键功能，满足了基本的教学管理需求。清晰地描述了教师和学生的需求与目标，以及软件如何通过功能组合来满足这些需求。 提到界面设计需要美化，当前的用户界面不够直观或吸引人。项目没有明确的推广途径，仅依靠引荐好友和人传人的传播效应，这可能限制了软件的快速传播和用户增长。存在一些Bug正在修复中，如部分情况请求超时，这可能影响用户体验。提到了性能测试结果需要满足预期指标，但未具体说明当前性能表现，可能存在性能优化的空间。项目依赖于外部服务如阿里云OSS存储，这可能带来额外的成本和配置复杂性。 1
代码敲不完队 通过场景测试确保了系统满足家长、学生和教师等不同用户的需求。 测试矩阵明确，有助于验证功能的实现，确保软件按预期运行。 系统易于扩展，可以根据需求添加新功能，适配不同用户群体。 评论认证和学号验证增强了互动性，提高了系统的可靠性和用户参与感。 评论认证流程复杂，学生可能遇到输入错误或身份认证问题，影响流畅度。 功能较为单一，缺乏深度互动，不能满足家长和学生更丰富的需求。 未提及不同设备的适配，若在手机端体验差，可能影响用户满意度。 5
虹猫蓝兔七侠队 通过场景测试确保了系统满足家长、学生和教师等不同用户的需求。 测试矩阵明确，有助于验证功能的实现，确保软件按预期运行。 系统易于扩展，可以根据需求添加新功能，适配不同用户群体。 评论认证和学号验证增强了互动性，提高了系统的可靠性和用户参与感。 评论认证流程复杂，学生可能遇到输入错误或身份认证问题，影响流畅度。 功能较为单一，缺乏深度互动，不能满足家长和学生更丰富的需求。 未提及不同设备的适配，若在手机端体验差，可能影响用户满意度。 14
不要指望我们队 测试矩阵覆盖了多个功能，确保系统在不同浏览器和平台上的兼容性。 用户需求分析清晰，能够满足管理员和学生等不同用户的需求。 跨平台支持提高了软件的普及性，扩展了用户群体。 界面设计缺乏现代感，影响用户体验，可能导致吸引力不足。 部分功能尚未完善，管理员管理时的细节处理不足，可能导致错误。 安装和配置过程繁琐，普通用户可能难以完成，影响系统便捷性。 系统推广和使用过程中存在问题，影响用户体验和系统的普及度。 10
物归原主队 功能齐全：系统提供了用户注册与登录、发布失物信息、查询失物信息、认领失物等核心功能，基本满足了用户寻找失物和帮助他人认领失物的需求。场景测试细致：团队在测试过程中考虑了多种用户场景，如丢失物品的同学发布寻物启事、捡到失物的同学发布失物信息等，确保了软件在不同场景下的稳定性和可用性。用户体验关注：尽管存在一些不能重现的bug和延迟修复的bug，但团队在测试报告中详细记录了这些问题，并计划在未来的版本中进行修复，以提升用户体验。 性能问题：系统响应时间较长，用户体验不佳。这可能是由于数据库查询效率低或硬件资源有限导致的。团队需要优化数据库查询和升级硬件配置，以提高系统性能。安全漏洞：平台存在安全漏洞，可能导致用户信息泄露或被恶意攻击。团队需要加强对用户输入的有效验证和过滤，防止SQL注入等安全问题。 9
汪汪队 功能完善：系统提供了完整的社区管理功能，包括住户信息管理、车位管理、社区活动发布等，满足了管理员和住户的不同需求。兼容性好：团队在测试过程中考虑了多种浏览器类型，确保软件在主流浏览器上都能正常运行。发布计划明确：团队制定了明确的发布计划，计划先向周边的社区发布，再通过网络在其他的社区中扩散。这有助于逐步扩大软件的使用范围。 部分功能未实现：系统虽然功能丰富，但仍有部分功能尚未完全实现，如管理员修改公司简介后，管理员和住户在【物业信息】查看的公司简介未更新等问题。团队需要在未来的版本中完善这些功能。缺乏细节优化：如部分UI在不同的浏览器中出现错位现象等，这些问题虽然不影响软件的正常使用，但会影响用户体验。团队需要对这些细节进行优化。 8
发际线和我作队 目标明确：系统针对仓库管理者和商店老板的需求，提供了货物信息管理、分类管理、账号管理等功能，满足了他们的实际需求。易于安装：系统以网页形式发布，用户只需访问网址即可使用，无需进行复杂的安装步骤。 功能有限：目前演示账号只能管理同一个仓库，这限制了系统的使用范围。团队需要在未来的版本中增加多仓库管理功能。测试不足：从描述中看，团队可能未进行充分的测试，导致存在一些已知的bug，如货物分类下面不显示当前分类下的货物信息等。 6
edg.gdut 团队“gdut.edg”在开发“校园拼多多购物平台”过程中展现了深刻的需求理解和优秀的技术实现能力。从需求规格说明书到Alpha版本发布，团队不仅详细规划了系统的功能和架构，还成功实现了用户注册与登录、商品管理、搜索与筛选、购物车与结算等核心功能。团队针对普通用户、商家用户和管理员用户的不同需求进行了细致的功能设计，确保每个用户群体都能获得良好的使用体验。特别是对于拼团砍价等功能的设计，体现了对目标用户群体——学生购物习惯的精准把握。此外，团队选择了现代前端框架和后端技术栈，如React或Vue.js以及Spring Boot，确保了系统的高效性和可扩展性。团队成员分工明确，各司其职，保证了项目的高效推进，并且通过GitHub进行代码管理和协作。 首先，在Alpha版本测试中发现了一些未能修复或延迟修复的问题，如商品数据加载不出来及特定商品名搜索结果错误，这些问题可能影响用户体验。其次，团队博客中的内容更新频率较低，缺乏详细的每日Scrum Meeting记录，这可能会影响团队内部沟通效率和外部评审者的理解。另外，对于系统的性能优化和安全性保障方面的描述较为简略，特别是在数据库查询和访问效率的优化措施不够具体。最后，虽然提到了云服务和CDN加速，但在实际部署中并未完全实现这些特性，使得系统的真实性和可用性受到一定限制。此外，团队计划调整后的任务安排显得过于紧凑，可能导致某些任务的质量受到影响。 7
白蓝混子队 白蓝混子队在软件工程课程的项目中展示了良好的团队协作和规划能力。从团队展示到Alpha版本发布，他们始终保持着清晰的目标和有序的任务分配。团队选题聚焦于开发一个智能社交桌面客户端应用——ChatGenius，不仅符合当前技术趋势，还具有一定的创新性。成员们根据各自的技术专长进行了合理的分工，确保了项目的高效推进。特别是在需求规格说明书、原型设计以及系统架构设计方面，团队表现出了严谨的态度和技术深度。此外，团队采用敏捷开发方法，并通过每日Scrum Meeting记录来跟踪进度，体现了对现代软件工程实践的理解与应用。最终，他们在规定时间内完成了Alpha版本的主要功能，如用户登录、聊天模块等。 首先，在测试阶段发现了一些未修复或延迟至下一版本修复的bug，这表明团队可能在时间管理和优先级设定上存在不足。例如，登录连接turms服务器使用userId和password而非token校验的问题被推迟到了下一个版本，影响了系统的安全性。其次，团队对于用户体验的关注度还可以进一步提高，比如解决登录跳转动画不流畅等问题以提升用户的满意度。另外，虽然团队设定了明确的功能模块和任务分配，但在实际执行过程中可能存在沟通不够顺畅的情况，导致部分非关键问题未能及时得到处理。最后，团队博客中的内容更新频率可以更高一些，以便更好地记录和分享项目进展。 2
民族大团结 民族大团结团队在绩点管理系统的开发过程中展示了出色的软件工程实践。从需求规格说明书到Alpha版本发布，他们保持了清晰的项目规划和有效的团队协作。该团队成功地实现了原定计划中的核心功能，包括成绩录入与查询、绩点计算等，满足了学生、教师及管理人员的基本需求。特别是他们在测试阶段发现了3个关键bug并全部修复，显示了对产品质量的关注。此外，团队通过详细的WBS任务分解和迭代冲刺计划，确保了项目的有序进展。每日Scrum Meeting记录表明团队成员积极参与讨论和解决问题，燃尽图也准确反映了工作进度。代码托管于GitHub，具备良好的可维护性和可扩展性，并且能够顺利在新环境中构建运行。 首先，在用户界面设计上可以更加人性化，例如优化排序功能以避免成绩错位的问题，这将提升用户体验。其次，虽然团队完成了主要功能的实现，但对于次要需求如教学成果评估等功能的删减，可能影响系统对于教师群体的价值。另外，团队未能充分展示如何收集并响应早期用户的反馈，这对于后续版本的迭代至关重要。最后，团队博客中提到的API对接细节较少，使得外部开发者难以评估接口的完整性和稳定性。最大的问题是Github仓库项目是空的。 11
永远写不队 项目测试内容具体，面面俱到。 团队将Bug分为“已修复”、“延迟到下一个版本修复”等类别，但没有提供详细的描述或原因分析。测试矩阵仅涵盖了基本的登录功能和聊天功能，而其他重要功能（如消息发送、好友管理等）的测试似乎不够全面。团队提到软件尚未部署至服务器，这意味着用户还无法真正使用该产品。可见该团队项目较赶，完成度尚未达到发布水准。 13
赛普拉·伊敏江 博客无内容 博客无内容 15
做不队 项目完成度较高，界面明确简洁美观，点击和跳转流畅，部分功能完善。 团队提到一个无法重现的Bug（疯狂发送请求），这表明他们可能没有充分理解问题的根本原因。用户刷新页面后会丢失当前文章内容，这种设计显然不符合用户的预期，尤其是对于长篇文章或需要频繁返回查看的用户来说，体验非常不友好。测试时还发现网页的博客展示存在问题，发表的文章无法展示并被搜索到，这对博客网站来说是一个致命bug。 12

事后诸葛亮

讨论照片

设想和目标

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

  • 软件旨在为校内学生提供一个关于流浪动物信息分享和交流的平台。问题定义较为清晰，目标用户群体为校内学生，典型场景包括学生注册账号、创建帖子、与其他帖子互动、实地喂养流浪动物等。对典型用户和场景有较为清晰的描述。

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

  • 项目完成了Alpha版本的基本功能，如用户模块、帖子模块、评论区模块等。所有原计划的功能都已实现，已经按原计划的交付时间和用户数量达成目标。

3.和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

  • 提高了。主要在沟通和执行的效率上，我们开会的时间更短，但是没有因此造成信息传达的失误。

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

  • 项目尚未部署到服务器上，因此用户量和对功能的接受程度尚未得到实际验证。

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

  • 我们可以对项目进度和资源进行更好的管理，并事先对用户需求进行更深入的理解。如果历史重来一遍，我们会更早地开始用户测试，以便更好地理解用户需求和反馈，从而改进产品设计。

计划

  1. 是否有充足的时间来做计划？
  • 有。
  1. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
  • 组长安排很合理，大家都没有特别的意见。
  1. 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
  • 有3个Bug延迟到下一个版本修复，原因包括时间限制、资源不足或技术挑战。
  1. 有没有发现你做了一些事后看来没必要或没多大价值的事？
  • 无
  1. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
  • 项目中存在响应缓慢和图片显示失败等问题，这些可能是未预料到的风险。原因包括技术挑战或资源限制。
  1. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  • 将来的计划可能会包括更详细的风险评估和资源规划，以及更灵活的时间管理策略。
  1. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
  • 通过这次经历，团队可能学到了更好的项目管理、沟通和用户需求分析的重要性。如果历史重来一遍，可能会更早地进行用户测试，更精确地规划项目时间线，并预留更多的缓冲时间来应对不可预见的技术挑战。

设计和实现

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

    • 设计工作在项目初期由开发团队共同讨论完成，时间上合适，但设计细节在开发过程中暴露了冲突，需要调整。

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

    • 有些设计存在分歧，通过讨论和原型验证达成一致，确保最终决策。

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

    • 是的。我们在后端代码中使用单元测试，前端使用浏览器反复测试模块来确保服务可以正常运行。

  4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug?

    • 登录和权限管理功能产生最多Bug，原因是逻辑复杂且与多个系统组件耦合，发布后发现会话过期和权限验证问题。设计时未充分考虑边界情况。

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

    • 代码复审定期进行，检查规范和潜在问题，但由于时间紧迫，某些细节未完全审查到位。

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

  • 学到了设计细节的重要性。重来一遍会更注重早期设计、原型验证和严格的代码复审，减少后期修改。

变更管理

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

  • 是的，会在群里同步消息

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

  • 通过评判是否刚需，是否核心，是否阻塞后续进度

3.项目的出口条件(Exit Criteria-什么叫“做好了”)有清晰的定义么?

  • 有：

    • 涵盖基础功能
    • 核心功能稳定可靠
    • 内部测试达标
    • 避免明显性能问题
    • 选定适配用户群体
    • 构建问题跟踪体系
    • 做好版本控制与备份
    • 提供文档与支持服务

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

  • 暂不清楚具体的变更，无法针对性制定有效应急计划

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

  • 可以，在面对挑战时变得更加自信成熟

我们学到了什么?

  • 沟通的重要性：有效的内部沟通是保证项目顺利推进的关键。需要确保所有成员都能及时获得必要的信息，并参与到决策过程中。
  • 优先级管理：学会如何根据业务价值和技术可行性合理分配资源，确保最重要的功能得到优先实现。
  • 质量控制：认识到高质量的产品不仅依赖于良好的编码实践，还需要严格的测试流程和持续集成/持续部署(CI/CD)的支持。
  • 风险管理：理解提前识别潜在风险并制定相应预案的重要性，以便在出现问题时可以迅速采取行动减少影响。

如果历史重来一遍,我们会做什么改进?

  • 如果有机会重新开始，团队可以在以下几个方面做出改进：

    • 强化沟通渠道：从项目启动之初就建立起完善的沟通机制，确保信息流通顺畅，减少误解和延误。
    • 优化任务分配：基于成员技能和个人兴趣更科学地划分任务，避免因个人能力差异导致的任务积压或过度负担。
    • 细化变更流程：制定详细的变更管理流程，确保每次变更都有据可依，并能及时通知相关人员。
    • 增强风险管理意识：将风险管理纳入日常工作中，定期评估潜在威胁并更新应急预案。
    • 提高文档质量：注重文档编写，尤其是技术文档和技术债务记录，为后续维护和扩展打下坚实基础。
    • 促进团队成长：提供更多学习和发展机会，鼓励成员不断提升自身技能，培养多面手，增强团队整体实力。

测试与发布

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

  • 有，指定了较为详细的测试计划。

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

  • 是。但因为时间原因，部分内容匆忙测试。

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

  • 使用IDEA自带的测试工具JUnit。

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

  • 使用IDEA集成的性能分析工具JProfiler。并未进行压力测试。这些测试工作能够验证本项目的功能实现，为发布增加信心，也为后面项目的管理提供帮助。
  1. 在发布的过程中发现了哪些意外问题？
  • 无。

团队的角色，管理，合作

  • 团队成员角色： 团队成员在明确的角色分工下，展现出了各自的专长，但仍需继续优化角色的配备。

  • 团队协作： 团队成员之间的合作良好。

  • 项目管理问题处理： 团队在面对项目管理和合作方面的问题时，表现出齐心协力的精神和较强的解决问题能力。

资源分析

资源充足性：

  • 在项目执行过程中，我们发现大部分任务的资源配置是合理的，但在某些关键阶段，尤其是测试阶段，资源显得有些紧张。这导致了一些任务的延误，影响了整体进度。

时间和资源估计的精度：

  • 各项任务所需的时间和资源是基于历史数据和团队经验进行估计的。然而，实际执行中发现，某些任务的复杂性被低估，导致时间预估不够准确。未来需要在估计时更加谨慎，考虑潜在的风险。

测试资源的充足性：

  • 在测试阶段，虽然基本的功能测试得到了覆盖，但由于时间限制，某些边界情况未能充分测试，可能影响后续的维护。未来需要在项目初期更全面地评估测试所需的资源。

任务分配的有效性：

  • 在项目执行过程中，有些任务可以更有效率地由其他团队成员来完成。通过回顾，我们发现某些任务可以由具备相关经验的团队成员承担，而不是由开发人员来处理。未来应更加注重团队成员的技能匹配，合理分配任务。

经验教训与改进建议

  • 改进资源估计：在项目初期，进行更全面的资源和时间估计，考虑潜在的风险。
  • 加强沟通与协作：定期进行团队沟通，确保每个成员对任务的理解一致，及时调整资源分配。
  • 优化任务分配：根据团队成员的技能和经验，合理分配任务，确保每个成员都能在最擅长的领域发挥作用。

总结

CMM/CMMI档次和团队阶段

  • 我们认为自己目前处于CMMI的已管理级别（Managed）。我们已经建立了基本的开发和测试流程，但还需要在性能优化和用户体验上做出改进。按照团队发展的阶段来看，我们正处于“规范”阶段，已经建立了一定的工作流程和标准，但仍有提升空间。

里程碑改进

  • 与前一个里程碑相比，我们取得了以下进步：

    • 成功修复了4个关键Bug，提高了系统的稳定性。
    • 实现了基本功能，如用户注册、帖子管理等，满足了用户的基本需求。
    • 通过全面的场景测试和测试矩阵，增强了软件的可靠性和用户的信心。
      最需改进的方面

  • 我们认为目前最需要改进的方面是性能优化，特别是响应缓慢的问题，这直接影响到用户体验。我们将优先解决这个问题，以提升用户满意度。

敏捷开发原则

  • 在我们团队中，我们认为做得最好的敏捷原则包括：

    • 客户合作：我们通过场景测试深入理解用户需求，并计划根据用户反馈进行功能优化。
    • 响应变化：我们通过QQ在校内发布软件，快速响应市场变化和用户需求。

提高软件工程质量

  • 为了提高软件工程的质量，我们计划采取以下措施：

    • 代码管理：引入代码审查工具，制定代码规范，并定期进行代码复审。
    • 程序架构：通过架构评审、使用设计模式和定期重构来提高架构质量。
    • 软件工具应用：引入自动化测试工具和CI/CD工具，提高开发效率和软件质量。
    • 项目管理：使用项目管理工具来更好地跟踪任务和进度，以及进行风险管理。
    • 项目跟踪用户数据：使用工具如Google Analytics来跟踪用户活跃度，并通过用户反馈了解用户行为。
    • 项目文档质量：制定文档编写规范，定期更新文档，并进行文档审查。
    • 领导和管理：改进绩效考核机制，提高团队沟通效率，增强团队凝聚力。
    • 软件工程理论：通过技术分享和学习会议提高对软件工程理论的理解和应用。

团队成员在Alpha阶段的角色和具体贡献（满分100分）：

姓名 角色 贡献分 可验证的贡献
艾彬（组长） 项目经理 90分 博客、计划编排、需求分析
陆宇星 前端开发 91分 前端设计、开发
范圣林 后台开发 89分 后台设计、开发
王佳伟 后台优化 88分 后台优化
郑玮源 测试 87分 测试
posted @ 2024-12-07 20:36  RMAB  阅读(29)  评论(0)  编辑  收藏  举报