自救题库——beta阶段项目展示
项目与团队亮点
-
成员与分工简介
-
团队共有7名同学组成,1位同学担任PM,4名同学承担前端工作,3名同学承担后端工作
-
成员名称 大致分工 cy 后端 hhc 前端 ljj 前端 zwh 前端 gs 前端 lsc 后端 dxh pm+后端 -
项目管理:
- 项目初始阶段开会确定选题、技术栈以及人员分工等
- 正式开发时,每两天进行会议记录,讨论接下来两天的会议进度以及遇到的问题
- 会议结束后,每名成员领取自己的ISSUE(自己创建或将现有任务分配给自己)
- 在个人开发时,每名成员需要创建个人分支,每次提交都和对应的issue关联,在merge req界面开一个WIP(可选),开发完成并测试通过后,向master分支提出merge请求,如果没有冲突则进行merge并关闭或记录相关ISSUE完成情况;如果有冲突则由冲突代码的完成者进行协商后解决冲突并merge
- 文档规范:本项目前后端以及相应的接口设计都有将为详细的文档。前端代码主要通过esLint进行规范,使用的标准如链接所示。规范
- CICD:本项目部署了CICD,首先用MVN进行打包,随后调用单元测试,codeLint,然后自动编译打包部署。实现更新master分支的同时同步部署到服务器中。
我们的SCRUM燃尽图在beta阶段通过石墨文档,统计工作量之后生成,相较于alpha阶段显得更为合理
-
典型用户场景
-
场景一:同学甲在做题过程中发现有道题目很有迷惑性,于是决定把其放入错题中并收藏起来,同时在该题目下方添加一定评论方便后来的同学更快地获取解题思路。之后,同学甲突然想到另一道错题当时忘了收藏,但是他现在只记得一些关键词了,于是通过上方栏的题目搜索功能顺利搜索到该题:
对应功能:题目搜索,题目收藏
-
场景二:同学甲在做题过程中希望既有分章节的顺序做题,也有验证学习成果的随机做题(随机的章节可以设置),还有针对错题的特定练习。
对应功能:包括顺序做题、随机做题以及错题查看功能。
-
场景三:一天的复习结束后,同学甲打开消息中心,查看是否有回复自己评论的消息以及一些系统更新的消息等,看完消息后,同学甲打开了成就系统,发现自己又获得了一枚新的勋章,感到很开心。
对应功能:题目评论与回复,消息中心,成就系统。
-
场景四:同学乙在临近烤漆时希望能够在一段集中时间内刷一定量的题,通过定时练习模拟考试氛围,让考试时达到最好的发挥效果:
对应功能:定时练习。
-
场景五:同学乙是个拥有十足热情的同学,在临近烤漆时,他想要检验自己的学习成果,于是他打开题库的比赛区,进入正在进行的比赛,与大家共同做题。
对应功能:比赛。
-
-
-
杀手级功能
-
打卡功能:用户可以设置每日目标数,完成目标后,即可进入日历进行打卡
-
成就系统:用户做题打卡参加比赛等行为均可以获得一定的成就,从而激励用户不断学习。
-
比赛系统:每日自动生成一定数量的比赛,供用户练习比拼。
-
-
发布
- 在微信朋友圈以及通过海报进行宣传
- 在1906、20级两航三大书院和知行书院的灌水群进行宣传
- 实际活跃用户:累计注册用户达到691人,基本达到预期;日活量平均100人左右(至少完成一道题的提交)。累计做题量已经达到21430道。
-
软件工程质量
- 前后端在不同的文件夹下开发,实现开发过程完全分离
- 前端遵循基本的Vue和JS开发规范,后端代码在必要位置也进行了注释,前后端的接口以及各自都有相应的文档支持
- 前端在本地的项目文件夹下均有部署eslint,保证了代码的书写规范
- 所有接口调用使用https
- 具体测试报告
-
项目Demo展示
项目与团队总结
-
项目管理
-
成员简介及个人博客地址
成员简介看这里
成员 个人博客地址 cy 我是cy的博客 hhc 我是hhc的博客 ljj 我是ljj的博客 zwh 我是zwh的博客 gs 我是gs的博客 lsc 我是lsc的博客 dxh 我是dxh的博客 -
成员分工协作:
- dxh担任PM,负责部分博客文档内容以及每次会议的组织协调工作
- hhc和lsc由于之前有相关项目开发经验,故分别担任前端和后端的小组负责人,项目前期负责技术栈的确定,项目后期对组员的相关模块代码进行审核,调试接口以及ISSUE的开设
- ljj和zwh负责前端部分页面的具体工作,lsc、dxh和cy负责后端部分模块的编写以及服务器和CICD的相关配置
- 改进部分:总体分配方案已经得到事先商议,总体工作量平衡。 具体工作相比alpha阶段根据每个人的特点有所调整。
-
沟通对接记录
- 由于alpha阶段任务较为简单,所以沟通交流方式主要通过微信群、腾讯会议以及线下会议,具体项目对接会通过ISSUE的方式具体到每名同学。简单的记录留存如下:
- 由于alpha阶段任务较为简单,所以沟通交流方式主要通过微信群、腾讯会议以及线下会议,具体项目对接会通过ISSUE的方式具体到每名同学。简单的记录留存如下:
-
开发中如何合理平衡各条件因素的影响
- 设立可靠的贡献分评分机制,激励组员按时按量完成任务
- 以两天会议周期为单位划分子任务,合理评估任务难度,尽量保证组员在一个时间单位内能完成任务并使整体进度处于可控范围内
- 对于在某段时间内有其他紧急任务的同学适当放宽时间限度,但仍然需要按量完成任务,只要不大范围影响整体项目进度即可
- 由于beta阶段整体时间跨度中考试以及ddl相比alpha阶段较多,所以对软工工程质量保证方面有所牺牲,尽可能优先保证开发工作的完整进行。
-
项目实际进展
我们的SCRUM燃尽图在beta阶段通过石墨文档,统计工作量之后生成,相较于alpha阶段显得更为合理
-
团队贡献分配
-
概述:每名同学有15分的基础分,之后的260分(某位同学的基础分被扣除)放入分配池,根据个人贡献进行分配
- 首先将分配池中的分数根据:测试:文档:开发 = 1 : 3 : 7,测试:260 * 1 / 11 = 24分,文档:260 * 3 / 11 = 71分,开发:260 * 7 / 11 = 165分
- 测试的工作量根据个人修复的bug时间进行计算(最小单位为0.5小时)
- 文档的工作量暂定按字数分配,主要以博客和设计类文档为主(技术类文档不计入,会议记录原则上不超过文档总分的10%,其余以百字为单位计算)
- 开发工作量按 前端:后端 = 6:5 进行分配
- 前端:按个人编写的页面以及所花费时间进行计算,142 * 6 / 11 = 77分
- 后端:按个人实现的功能以及相关配置的设置等进行计算,142 * 5 / 11 = 65分
- 贡献的衡量以时间和字数为单位,最终的分数会折算成百分比进行计算
-
角色及具体贡献
成员名称 角色 具体贡献 cy 后端 文档:项目展示博客、alpha阶段事后分析
推广活动:在一些微信群及个人朋友圈做了项目推广,联系了一些人脉广的同学发了朋友圈宣传
测试:花费了7小时进行测试并debug
开发:为项目完善CICD功能,包括codeLint,项目主页服务器端架设,SSL证书https相关配置,实现了评论区、消息中心、用户信息收集等hhc 前端 测试:花费了4小时进行测试并debug
开发:前后端接口定义+完善、个人中心页面修改、每日打卡引导、统计用户学习进度、计时做题页面入口、首页增加做题页面入口、题库页面修改、游客模式实现、成就系统页面、消息中心静态实现、实现微信小程序初次提交审核版本、消息中心页面功能实现、成就系统页面功能实现(包括弹出成就框)、css修改(评论区、错题页面、收藏页面、比赛页面、比赛排行页面、用户比赛信息、消息中心)、eslint配置和修改ljj 前端 测试:花费了2小时进行测试并debug
开发:评论区组件 、显示评论功能+用户评论和回复功能 、做题页面图片支持 、做题页面收藏功能、易错做题模式、计时做题模式、做题页面模式切换、做题页面格式优化、比赛做题页面、游客做题页面实现、eslint格式调整zwh 前端 文档:会议记录
测试:花费了1小时进行测试并debug
开发:排行榜页面(后废弃)、收藏页面、比赛页面、比赛页面功能实现、用户做题细节页面、比赛排行榜页面、eslint格式调整lsc 前端 文档:技术规格说明书以及测试报告
测试:压力测试
开发:完成项目框架的配置,数据库的设计,成就系统,比赛系统,题目搜索dxh PM+后端 文档:beta阶段功能设计,项目发布博客
开发:智能荐题,题目收藏gs 前端 无 -
具体贡献分分配
-
-
计分项 | hcc | ljj | zwh | cy | lsc | dxh | gs | 总计 |
---|---|---|---|---|---|---|---|---|
基础分 | 15 | 15 | 15 | 15 | 15 | 15 | 0 | 90 |
测试比例 | 18.4% | 9% | 18.2% | 27.2% | 9% | 18.2% | 0 | 100% |
测试分 | 4.4 | 2.2 | 4.4 | 6.4 | 2.2 | 4.4 | 0 | 24 |
分档比例 | 14% | 0 | 5.6% | 33% | 14% | 33.4% | 0 | 100% |
文档分 | 9.9 | 0 | 4.0 | 23.4 | 9.9 | 23.8 | 0 | 71 |
开发比例 | 28.2% | 17.2% | 9% | 18.4% | 18.0% | 9.2% | 0 | 100% |
开发分 | 46.5 | 28.4 | 14.9 | 30.4 | 29.7 | 15.2 | 0 | 165 |
总计 | 76 | 46 | 38 | 75 | 57 | 58 | 0 | 350 |
-
用户场景
-
开发前目标
-
用户分类及相关特性:
用户 特性 用户甲 希望能够好好学习航概这门课程,希望但还未完全拥有良好的学习习惯以及强大的计划与自制力。期末期望成绩95~100。
希望每天在固定量的时间内做一定量的题,保持做题频率。用户乙 不希望在课程上花费太多时间,希望能够以尽量少的时间获取最大的成绩,期末考试期望成绩80~95。
习惯在临近期末时高频率复习,希望能及时复习巩固错题。
-
-
发布功能及场所
- 我是发布文档
- 本项目通过小程序的形式发布
-
场景是否满足
- 项目基本符合预期,场景均较完整地实现
-
目标用户使用产品的过程和评价
-
-
用户日活
-
在软件发布后,软件注册量达到了近408人左右。由于还未进入烤漆,大家下载完进行试用后可能并不会持续使用,故日活量暂时平均为50~100人左右。由于我们开始预计的是进入考期后用户日活量,所以该数目比我们一开始的估计要少。
-
功能改进以及“bug”反馈:
用户反馈 bug / 功能改进 已知 / 未知 微信名中有特殊编码的字符无法登录 bug 已解决 区分单选多选 功能 已知 问题反馈换行超出文本框 bug 未知(本地无法复现) 安卓手机存在计时模式显示不正确的bug bug 已知
-
-
-
特色功能
-
杀手级功能:每日设定目标及打卡、比赛系统、成就系统
-
和我们的竞品做对比分析:竞品相比我们多了一些例如知识卡片,考期提醒,资源社区等功能,可能该竞品觉得做题小程序的核心功能做完后,剩下的主要是整合功能,建立社区。本团队还是希望加强小程序在做题这方面的功能,所以做出了用于做题激励的打卡系统以及成就系统,以及比赛系统,"国人干啥都特别喜欢排名,所以游戏基本都会有排位模式",针对小程序的其他功能整合以及社区化并没有做相关工作。
-
就团队成员评价来说,这里列举团队中两名同学的回答:
- 同学甲:打卡和成就功能能一定程度上能起到激励的作用,但是比赛功能目前使用的人数较少,可能是主要用户目前还仍然处于做题背题的阶段
- 同学乙:食之无味,弃之可惜
总体来说,达到了对beta阶段的基本预期。
-
就用户对这些功能的评价来说:同用户场景,这里不再赘述。
-
-
软件工程质量
-
文档规范:本项目前后端以及相应的接口设计都有将为详细的文档。具体代码规范前文已有介绍。
-
项目指引:本项目代码较为清晰,前端使用vue框架,后端使用springboot框架,关键方法以及接口设计、状态码说明都有详细注释或文档说明
-
-
对于想要接手该项目并继续开发的同学:需要首先熟悉相关技术栈的基础知识并安装相关软件(该部分在技术规格说明书中有简介,但具体方法不包括在本项目文档中),其次通过阅读NABCD以及功能文档了解项目的基础功能,最后阅读技术文档和前后端接口文档进行实际开发
-
对于想要在新机器上编译并运行项目的同学:本次项目的前后端文件分别放在两个文件夹中,结构分离较为清晰。由于本项目使用的云数据库和服务器是有时间限制的,所以项目在每次更新后会将数据库相关内容均转储成SQL文件,之后的同学可以通过阅读 本地运行后端 文档并下载相关文件直接将后端运行起来,前端通过阅读 前端 文档直接运行相关文件即可
-
-
测试:本项目由于时间紧急以及功能逻辑简单所以单元测试并不十分完善,主要通过最后手动构造测试样例进行综合测试,以及开发过程中对单独模块手动进行测试,具体测试文档
-
CICD:本项目部署了CICD,首先用MVN进行打包,随后调用单元测试,codeLint,然后用ssh连接服务器,将jar文件传输到服务器上,再通过远程控制服务器执行相应指令运行jar包即可。实现更新master分支的同时同步部署到服务器中,更加方便快捷。
-
经验及教训⭐:
-
整个团队在Beta阶段有较强的凝聚力,培养了团队合作精神,技术能力的同学为稍弱的同学积极进行援助交流沟通帮助,大部分同学在本身课程压力较大的情况下也会积极参加会议讨论,互相学习。
-
在实际软件工程中因为是团队合作,所以要更加注重代码质量,这无论是为相互合作还是之后的长期发展都至关重要。
Alpha Beta 用户注册、登录及修改信息 ✔ 题库背题 ✔ 顺序和随机做题 ✔ 做题计划 ✔ 每日打卡 ✔ 题目默认评价与评分 ✔ 题目评论以及回复 ✔ 比赛系统 ✔ 错题复习 ✔ 智能荐题 ✔ 题目收藏 ✔ 消息中心 ✔ 成就系统 ✔ 小程序移植 ✔
-
-