发际线总和我作队——alpha阶段问题总结

发际线总和我作队 2025-11-09 15:45:30

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	团队作业——事后诸葛亮
这个作业的目标	alpha阶段问题总结随笔
其他参考文献	无

1 关于设计/实现；测试/发布相关的问题

1.数据库设计上的的不足：
在最开始的数据库设计上有许多考虑不周到的地方，比如有的表缺少一些关键属性，有的属性类型不合适，这些问题在实际开发过程中逐渐显露出来，比较麻烦的是有的表已经在别的功能开发中使用过了，但在开发该表的核心功能时发现该表有需要更改的地方，就要花一些时间更改已经写好的代码。比如在最开始，我们使用number作为学生/教师的学号/工号，也是作为登录的账号，而管理员则使用username，后续发现，所有角色均使用username作为账号比较统一、便于理解和操作。
2.实现中的“一致性”难题：
前后端对“空值”的理解不一致。后端在返回空列表时，有时返回null，有时返回[]，导致前端频繁报错。解决之道：建立团队级的《API设计规范》，强制规定集合类型永远不返回null。
3.测试用例设计的问题：
在进行API测试时，由于测试用例设计的不恰当，导致返回的code与预期值不符，比如在进行用户管理的增删改查时，我添加了用户3，但却删除了用户2，第一次测试返回的结果是成功的，但第二次点击测试就会出现用户3已存在，添加失败的错误。所以在测试用例的设计上我们还需要多加改进。
Alpha阶段是需求变更最频繁的时期，如何管理这些变更，并保持团队稳定，是我们面临的最大挑战

2 关于变更管理；团队的角色，管理，合作相关的问题。

1.变更管理的“无政府状态”：
初期，产品需求变更仅通过口头或微信群消息传递，经常导致有人遗漏，开发与测试依据的版本不一致。我们如何建立秩序：我们引入了“变更请求”机制，任何需求变更必须统一记录在一个在线文档，并@相关开发与测试人员，待确认后方可实施。
2.团队角色的“模糊地带”：
虽然分工明确，但在遇到棘手Bug时，容易出现“这是前端问题还是后端问题”的扯皮，消耗了大量团队精力。我们的解决方式：确立了“Bug第一责任人”制度，谁最先发现Bug，谁就负责跟踪直至关闭，并协调前后端人员共同排查，打破了技术壁垒。

3 关于设想和目标；计划相关的问题

1.设想的“丰满”与“骨感”：
alpha阶段开始前的设想和目标是完成登录、管理员、学生模块，开始前我们都没觉得有什么困难的，但开发过程中问题频发，再加上每位成员还需要完成其他课程的上课任务和作业，导致开发时间的有限，我们最终并没能完成目标，而仅完成了登录、管理员模块以及学生模块的一部分。当然，这也和初期目标计划设计不合理有关，开始我们并没有考虑到其他课程的上课时间，从而导致计划过于繁重。所以，我们要吸取此次教训，在下一个冲刺阶段中，充分考虑到大家的时间安排。

4 关于对AI技术员工作的实例分析

在本项目中，AI技术员扮演了“技术探路者”和“效率催化剂”的角色。
1.实例：
测试同学不熟悉JavaScript，难以快速编写Postman的测试脚本。但是可以借助于DeepSeek，将问题描述给AI后，AI给出了好几种方案，首先它自己提供了可以参考的测试脚本代码，然后它推荐使用Postman内建的AI功能并提供使用教学，内建AI可直接生成测试脚本，而测试同学仅需进行适当修改，比如对预测的返回值的修改，而有不会改或报错等问题时，也可继续求助AI技术员。而测试同学也在此过程中熟悉并学习了编写基础断言脚本，并独立完成了剩余大部分接口的测试脚本编写。AI在此过程中起到了 “降低技术门槛，赋能团队成员”的作用。
2.分析：
在此次alpha冲刺阶段中，AI帮助我们解决了许多问题，而AI技术员的价值就体现在它的知识广度：AI能够快速提供多个技术领域的解决方案，弥补了团队成员的知识盲区；响应速度：传统需要数小时甚至数天调研的问题，AI能在几分钟内给出可行方案；一致性：AI提供的解决方案具有很好的一致性，不会出现人类工程师的风格差异；文档能力：AI生成的代码通常伴有清晰的注释和说明，提高了代码的可维护性并方便我们理解。当然，AI也会存在一些问题，比如对业务上下文的理解深度不够，在复杂系统集成方面缺乏实践经验等等，但这些缺点远比不上它对我们的巨大帮助。

...全文