共享之舟——α冲刺总结

[共享之舟]

这个作业属于哪个课程	软件工程实践-2023学年-W班
这个作业要求在哪里	团队作业—beta冲刺+事后诸葛亮
这个作业的目标	回答课堂上的问题，同时进行α冲刺阶段的反思
其他参考文献	-

目录

• 回答问题
• Q1：为什么货比三家功能的开发放在β冲刺而不是α冲刺？
• Q2：如何划分a和β冲刺的内容
• Q3:燃尽图的前几天进度很慢，原因是什么，如何改进？
• Q4:团队的成员贡献度差异比较大，原因是什么？
• 反思与改进
• 项目进度较慢
• 前端技术瓶颈
• 对接的协作低效

回答问题

Q1：为什么货比三家功能的开发放在β冲刺而不是α冲刺？

A1：货比三家是我们福鱼的最特色最重要功能，完成的难度也最大，考虑到a冲刺处于起步阶段时间很紧，要完成货比三家起码要先完成购物车界面，完成商品信息的设计和前后端相关的对接，我们考虑到在a冲刺可能难以将货比三家功能做的比较完善，所以放在β冲刺

Q2：如何划分a和β冲刺的内容

A2：大部分内容我们并没有定死了哪些部分一定在a冲刺哪些一定在β冲刺。我们是力求在a冲刺尽可能多完成内容，把我们福鱼项目的前后台的基本给功能做出来，做出一个比较完整自洽的产品。在β冲刺中则继续完善，做好特色功能货比三家，对其他页面也边测试边改善

Q3:燃尽图的前几天进度很慢，原因是什么，如何改进？

A3:主要原因有两点。①各成员配置环境的时间比预期的要长，在环境配置完成之前很多任务无法进展，导致进度慢。②在最开始几天安排的任务量不合理，比较多，低估了一些任务的工作量（如配置环境）。
如何改进:经过a冲刺的团队磨合和各成员自身磨炼，我们对自己和对团队日常可以完成的工作量有了了解，下阶段安排任务会更合理

Q4:团队的成员贡献度差异比较大，原因是什么？

有一位同学由于在外实习事务繁忙导致腾不出许多时间做任务，日常完成的是做日报博客，ppt等工作量较少的任务。还有一位同学做的是测试工作，工作量也比较少。所以这两位同学的贡献度偏低。实际上我们团队采用了比较合理的oKr制度。做多做少都会体现在贡献度上，不会刻意去拔高或降低人格成员的贡献度，a阶段的贡献度就是我们如实展示的结果

反思与改进

项目进度较慢

因为成员的学习成本较高，一开始制定比较强硬的OKR目标会失效。出现滞后现象，因此我们采用细化模块方式，让成员自主选择，出了学习的时间之外，只要满足每天1.5个小时开发即可。

前端技术瓶颈

在项目早期，团队面临着一些技术挑战，包括分页器的风格不一致和大量重复、手动编写CSS动态较为困难等，这些挑战主要源于我们没有采用elementUI这一强大的前端UI框架。
为了解决上述问题，并提高开发效率和产品质量，β冲刺决定采用elementUI：
可编辑表格，用于货比三家的数据填写：elementUI提供了功能强大的表格组件，支持数据的增删改查等操作。通过使用elementUI的表格组件，我们可以快速实现一个响应式、可编辑的表格，提高数据管理的效率。
图片上传+回显，用于商品的图片添加：elementUI的文件上传组件支持图片上传，并且可以轻松实现图片的即时预览（回显）。这使得用户在上传图片后能够立即看到上传的图片，增强了交互体验。

对接的协作低效

在α冲刺的过程中，难以平衡前端和后端的代码优先级，有时前端先完成，有时后端先完成，但是对于后端而言，修改的成本较高，包括Controller、Service、Mapper、数据库四个大层，所以在β冲刺阶段，我们团队决定以下的协作方式：
如果是Get接口，先让前端完成，然后前端写好交接的数据文档交给后端，后端根据文档，生成对应的视图和映射。这样能很大程度上避免数据遗漏的问题。
如果是其他的接口，例如Put、Post、Delete接口，先让后端完成，然后将交接文档发送给前端，这样后端能够拿到想要的数据，而减少前端的修改量。