Loading

自救题库——项目展示

项目与团队亮点

  • 成员与分工简介

    • 团队共有7名同学组成,1位同学担任PM4名同学承担前端工作,3名同学承担后端工作

    • 成员名称 大致分工
      cy PM + 后端
      hhc 前端
      ljj 前端
      zwh 前端
      gs 前端
      lsc 后端
      dxh 后端
    • 项目管理:

      • 项目初始阶段开会确定选题、技术栈以及人员分工等
      • 正式开发时,每两天进行会议记录,讨论接下来两天的会议进度以及遇到的问题
      • 会议结束后,每名成员领取自己的ISSUE(自己创建或将现有任务分配给自己
      • 在个人开发时,每名成员需要创建个人分支,开发完成并测试通过后,向master分支提出merge请求,如果没有冲突则进行merge并关闭或记录相关ISSUE完成情况;如果有冲突则由冲突代码的完成者进行协商后解决冲突并merge
    • 典型用户场景

      • 场景一:同学在看到相关宣传后进行注册登录,准备使用。

        对应功能:用户的注册、登录以及修改个人信息。

      • 场景二:同学甲在做题过程中希望既有分章节的顺序做题,也有验证学习成果的随机做题(随机的章节可以设置),还有针对错题的特定练习。

        对应功能:包括顺序做题、随机做题以及错题查看功能。

      • 场景三:同学甲在做到一道较难的题时,希望给后来做的同学提供警示,于是他希望为该题做一个较难的标签。

        对应功能:题目的默认评价和评分。

      • 场景四:同学乙在临近烤漆时需要有一定的动力敦促他学习,于是他希望为自己设立每日目标并创建打卡功能。

        对应功能:设立做题计划及每日打卡。

      • 场景五:同学在试用完软件后有一些反馈意见希望能反馈到开发团队中。

        对应功能:设立用户反馈模块。

  • 杀手级功能

    • 由于暂时在alpha阶段,故致力于实现基本功能:顺序练习随机练习错题回顾
      • 打卡功能:用户可以设置每日目标数,完成目标后,即可进入日历进行打卡
  • 发布

    • 微信朋友圈以及通过海报进行宣传
    • 190620级两航三大书院知行书院的灌水群进行宣传
    • 实际活跃用户:在第一天注册用户量达到35人,基本达到预期;日活量平均10人左右
  • 软件工程质量

    • 前后端在不同的文件夹下开发,实现开发过程完全分离
    • 前端遵循基本的Vue和JS开发规范,后端代码在必要位置也进行了注释,前后端的接口以及各自都有相应的文档支持
    • 具体测试报告
  • 项目Demo展示

项目与团队总结

  • 项目管理

    • 成员简介及个人博客地址

      成员简介看这里

      成员 个人博客地址
      cy 我是cy的博客
      hhc 我是hhc的博客
      ljj 我是ljj的博客
      zwh 我是zwh的博客
      gs 我是gs的博客
      lsc 我是lsc的博客
      dxh 我是dxh的博客
    • 成员分工协作

      • 陈同学担任PM,负责大部分博客文档内容以及每次会议的组织协调工作
      • 黄同学和李同学由于之前有相关项目开发经验,故分别担任前端和后端的小组负责人,项目前期负责技术栈的确定,项目后期对组员的相关模块代码进行审核,调试接口以及ISSUE的开设
      • 林同学和张同学负责前端部分页面的具体工作,董同学和陈同学负责后端部分模块的编写以及服务器和CICD的相关配置
      • 经验教训:对于任务的分工在前期需要进一步细化,否则后期可能导致项目任务有些杂乱,各个同学之间任务量差距较大,合理性有待加强
    • 沟通对接记录

      • 由于alpha阶段任务较为简单,所以沟通交流方式主要通过微信群腾讯会议以及线下会议,具体项目对接会通过ISSUE的方式具体到每名同学。简单的记录留存如下:
    • 开发中如何合理平衡各条件因素的影响

      • 设立可靠的贡献分评分机制,激励组员按时按量完成任务
      • 两天会议周期为单位划分子任务,合理评估任务难度,尽量保证组员在一个时间单位内能完成任务并使整体进度处于可控范围内
      • 对于在某段时间内有其他紧急任务的同学适当放宽时间限度,但仍然需要按量完成任务,只要不大范围影响整体项目进度即可
    • 项目实际进展

      从整体来看,我们的SCRUM燃尽图似乎不太美观,这里做两点说明:

      • SCRUM燃尽图的确有缺陷。开始的ISSUE定得较为宽泛,在后期创建了较多ISSUE后,燃尽图的起点并没有发生变化,导致看起来整体项目比较拖延。但实际上项目进度是符合预期的,后期燃尽图的生成我们会做一定的修正。
      • 虽然我们在前期没有做很全面的规划,但后期在创建ISSUE的时候也在努力做长远计划,在一步步修正中让项目走上正轨,这也是开发过程中我们学习到的重要收获...
    • 团队贡献分配

      • 概述:每名同学有15分的基础分,之后的245分放入分配池,根据个人贡献进行分配

        • 首先将分配池中的分数根据:测试:文档:开发 = 1 : 3 : 6进行分配(由于在alpha阶段功能较为简单,而所要书写的文档较多,所以将测试与文档按1:3比例分配,在belta阶段可能会根据实际情况进行调整)
        • 测试的工作量根据个人修复的bug时间进行计算(最小单位为0.5小时)
        • 文档的工作量暂定按字数分配,主要以博客和设计类文档为主(技术类文档不计入,会议记录原则上不超过文档总分的10%,其余以百字为单位计算)
        • 开发工作量按 前端:后端 = 5:4 进行分配
          • 前端:按个人编写的页面以及所花费时间进行计算
          • 后端:按个人实现的功能以及相关配置的设置等进行计算
        • 贡献的衡量以时间和字数为单位,最终的分数会折算成百分比进行计算
        • 以上所有分数计算均以0.5为单位四舍五入,最后如有剩余将计入推广同学总分中
      • 角色及具体贡献

        成员名称 角色 具体贡献
        cy PM+后端 文档:(团队介绍)、初步设计、功能规格说明书、团队贡献分分配规则、NABCD博客、软件发布声明、一次会议记录
        推广活动:在一些微信群及个人朋友圈做了项目推广
        测试:花费了7小时进行测试并debug
        开发:为项目部署了CICD,实现了个人信息、设置每日计划、用户反馈以及部分错题信息功能,总计约12小时
        hhc 前端 文档:部分技术规格说明书、部分alpha工作量分配、CSS说明文档、Vuex说明文档、功能说明、接口使用说明
        测试:花费了4小时进行测试并debug
        开发:完成登录注册、首页修改、个人中心、个人详细信息、密码修改、打卡、问题反馈、题库和相关接口的调试,总计约27小时
        ljj 前端 文档:一次会议记录
        推广活动:在微信群进行推广
        测试:花费了2小时进行测试并debug
        开发:完成首页初稿、做题界面,总计约12小时
        zwh 前端 文档:五次会议记录
        测试:花费了0.5小时进行测试并debug
        开发:完成用户信息上传、排行和错题页面共,总计约10小时
        lsc 前端 文档:部分alpha工作量分配、部分技术规格说明书以及测试报告
        测试:进行1小时压力测试
        开发:完成项目框架的配置,数据库的设计,接口的调试,总计约20小时
        dxh 后端 文档:视频文稿以及项目展示博客
        测试:花费了1小时进行测试并debug
        开发:完成服务器的配置,部分用户做题记录、部分错题信息、顺序做题、随机做题和用户打卡等功能,总计约12小时
        gs 后端
      • 具体贡献分分配

        cy hhc zwh ljj lsc dxh gs 总计
        基础分 15 15 15 15 15 15 0 90
        测试所用时间 7 4 0.5 2 1 1 0 15.5
        测试所占百分比 45.0% 25.5% 3.0% 13.0% 6.5% 6.5% 0 100%
        测试所得分数 11.0 6.0 1.5 3.0 1.5 1.5 0 24.5
        文档所占百分比 31.5% 21.0% 7.0% 1.5% 17.5% 21.5% 0 100%
        文档得分 23.0 15.5 5.5 1.5 12.5 15.5 0 73.5
        开发百分比 12.5% 30.0% 11.5% 13.5% 20.0% 12.5% 0 100%
        开发得分 20.0 46.5 20 23.0 31.0 21 0 162
        总计 69 83 42 43 60 53 0 350
  • 用户场景

    • 开发前目标

      • 用户分类及相关特性:

        用户 特性
        用户甲 希望能够好好学习航概这门课程,希望但还未完全拥有良好的学习习惯以及强大的计划与自制力。期末期望成绩95~100。
        希望每天在固定量的时间内做一定量的题,保持做题频率。
        用户乙 不希望在课程上花费太多时间,希望能够以尽量少的时间获取最大的成绩,期末考试期望成绩80~95。
        习惯在临近期末时高频率复习,希望能及时复习巩固错题。
      • 期待在alpha阶段完成的场景

        • 见上述团队亮点
    • 发布功能及场所

      • 我是发布文档
      • 本项目暂时通过北航云盘以安卓APP的形式发布,后期可能考虑通过小程序的形式发布
    • 场景是否满足

      • 项目基本符合预期,场景一、二、四、五较完整地实现
      • 场景三在实现过程中由于交流原因出现了一些偏差,原本是期望实现多种默认标签,包括较难、难度适中、较易等,但后来在前端退化成👍和👎,后期会根据用户反馈和实现成本进行一定调整
    • 目标用户使用产品的过程和评价

    可以看出,大家对于一些在Beta阶段的杀手功能较为期待,对于Alpha阶段一些做题功能也提出了中肯的建议。但与此同时,团队所认为的打卡杀手功能由于显示原因甚至没有引起大家的注意,后期可能会调整相关界面显示引导新手进行操作。

  • 用户日活

    • 在软件发布后,软件注册量达到了近50人左右。由于还未进入烤漆,大家下载完进行试用后可能并不会持续使用,故日活量暂时平均为10人左右。

      • 注册量基本达到标准,说明我们的项目推广效果还是不错的,但日活量可能有待加强,主要是由于alpha阶段仅仅实现了做题的基本功能,对于一些杀手级功能主要放在了beta阶段,同时因为界面美观以及发布形式的原因,对于用户的吸引力仍然有待提高。用户对软件的反馈和建议也可以说明用户是基本认可该软件的,但希望在一些功能或是外表上有所改进。

      • 功能改进以及“bug”反馈

        用户反馈 bug / 功能改进 已知 / 未知
        每天都需要登录 功能改进 已知
        手机邮箱是否都需要 / 已知
        区分单选多选 / 已知
        赞和踩换成收藏 功能改进 已知
        文理题库分开 功能改进 已知
        部分题没有图 bug 已知
        题目选项放在一个滚动框内等美观问题 外观改进 未知
  • 特色功能

    • 杀手级功能:每日设定目标及打卡

    • 这里仅以之前存在的航概练习题库作为竞品进行分析:可能该竞品是希望做一个轻量级的做题小程序,因此有较多的做题模式(顺序、随机、错题练习等),但是少有其他功能。团队根据市场上现有答题软件的打卡功能决定将其加入alpha阶段版本中。

    • 就团队成员评价来说,这里列举团队中两名同学的回答:

      • 同学甲:项目目前的功能比较全面,涵盖了用于背题的题库功能、用于测试的顺序做题以及随机做题功能,且设置了将错题记录下来的错题本。有设定每日目标和打卡功能,能起到督促作用,属于项目的特色
      • 同学乙:食之无味,弃之可惜

      总体来说,达到了对alpha阶段的基本预期,但由于没有特色功能,可能缺少吸引力。

    • 就用户对这些功能的评价来说:同用户场景,这里不再赘述。

  • 软件工程质量

    • 文档规范:本项目前后端以及相应的接口设计都有将为详细的文档。具体代码规范由于alpha阶段功能较为简单,大家前期花费了一定时间熟悉项目所使用的技术栈,后期直接上手编码,对于关键部分会进行注释,没有约定代码规范。

    • 项目指引:本项目代码较为清晰,前端使用vue框架,后端使用springboot框架,关键方法以及接口设计、状态码说明都有详细注释或文档说明


      • 对于想要接手该项目并继续开发的同学:需要首先熟悉相关技术栈的基础知识并安装相关软件(该部分在技术规格说明书中有简介,但具体方法不包括在本项目文档中),其次通过阅读NABCD以及功能文档了解项目的基础功能,最后阅读技术文档前后端接口文档进行实际开发

      • 对于想要在新机器上编译并运行项目的同学:本次项目的前后端文件分别放在两个文件夹中,结构分离较为清晰。由于本项目使用的云数据库和服务器是有时间限制的,所以项目在每次更新后会将数据库相关内容均转储成SQL文件,之后的同学可以通过阅读 本地运行后端 文档并下载相关文件直接将后端运行起来,前端通过阅读 前端 文档直接运行相关文件即可

    • 测试:本项目暂时没有单元测试,主要通过手动构造测试样例通过postman模拟请求以及成员试用进行测试,具体测试文档

    • CICD:本项目部署了CICD,首先用MVN进行打包,然后用ssh连接服务器,将jar文件传输到服务器上,再通过远程控制服务器执行相应指令运行jar包即可。实现更新master分支的同时同步部署到服务器中,更加方便快捷,之后在构建单元测试后会实现运行-测试-上传同步

    • 经验及教训⭐:

      • 整个团队在Alpha阶段有较强的凝聚力,培养了团队合作精神,熟悉技术栈的同学为不熟悉的同学积极撰写相关文档或者实时演示,大部分同学在本身课程压力较大的情况下也会积极参加会议讨论,互相学习。

      • 在实际软件工程中因为是团队合作,所以要更加注重代码质量,这无论是为相互合作还是之后的长期发展都至关重要。

      • Beta阶段大体还是按照原有计划进行,因为现在的成员对于相关技术要比之前熟悉许多,所以可能会考虑加快进度的同时做一些美化工作。

        Alpha Beta
        用户注册、登录及修改信息
        题库背题
        顺序和随机做题
        做题计划
        每日打卡
        题目默认评价与评分
        题目评论以及回复
        排行榜以及选择是否开启
        你问我答
        用户自定题目上传
        错题复习
        "禅"模式
        智能荐题
        题目收藏
        消息中心
        首次使用导引

posted @ 2021-05-14 08:23  是兄弟就来摸鱼  阅读(170)  评论(3编辑  收藏  举报