自救题库——项目展示

Posted 是兄弟就来摸鱼

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了自救题库——项目展示相关的知识，希望对你有一定的参考价值。

项目与团队亮点

  • 成员与分工简介

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

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

    • 项目管理：

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

    • 典型用户场景

      • 见下方详细描述

  • 杀手级功能

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

  • 发布

    • 在微信朋友圈进行宣传
      • 在1906、20级两航三大书院和知行书院的灌水群进行宣传
      • 实际活跃用户：在第一天注册用户量达到35人，基本达到预期；日活量平均10人左右

  • 软件工程质量

  • 项目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 15 105
        测试所用时间 7 4 0.5 2 1 1 15.5
        测试所占百分比 45.0% 25.5% 3.0% 13.0% 6.5% 6.5% 100%
        测试所得分数 11.0 6.0 1.5 3.0 1.5 1.5 24.5
        文档所占百分比 31.5% 21.0% 7.0% 1.5% 17.5% 21.5% 100%
        文档得分 23.0 15.5 5.5 1.5 12.5 15.5 73.5
        开发百分比 12.5% 30.0% 11.5% 13.5% 20.0% 12.5% 100%
        开发得分 18.0 44.0 17.5 20.0 29.0 18.5 147
        总计 67 80.5 39.5 39.5 58 50.5 15 350

  • 用户场景

    • 开发前目标

      • 用户分类及相关特性：

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

      • 期待在alpha阶段完成的场景

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

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

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

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

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

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

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

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

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

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

    • 发布功能及场所

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

    • 场景是否满足