「MOSS - 32」MOSS队：Beta阶段项目展示

「MOSS - 32」MOSS队：Beta阶段项目展示

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	团队项目-Beta阶段项目展示
我们在这个课程的目标是	熟悉敏捷开发的方法论，并通过实际开发产品进行实践。
这个作业在哪个具体方面帮助我实现目标	完成Beta阶段软件的展示。

Author: MOSS队

Date: 2023.06.10

Part 1 项目与团队亮点

1.1 团队成员与分工简介

团队分工

团队创建之处，我们按照大家的能力和兴趣初步进行了分工的划分：「MOSS - 00」MOSS队：团队介绍。

在项目进行的过程中，我们也根据实际情况进行了一定调整。

成员	分工
于敬凯	PM，项目管理，运维
姜雨竺	前端开发，架构设计，原型设计
史泽宇	前端开发，前端测试，原型设计
王小鸽	前端开发，API对接，原型设计
王雪竹	前端开发，原型设计
陈楚岩	后端开发，数据库
叶颜函	后端开发，后端测试

项目管理

项目开始之初，PM于敬凯同课程组进行沟通和讨论并得出初步解决方案：讨论：关于团队的技术栈和项目管理工具选择。

在项目的进行中，团队逐渐完善这一解决方案，最终采用了完善的现代工具链+分层+专人统筹的方式进行项目管理。

现代工具链

1. 微信+腾讯会议：进行碎片化的、快速的沟通
2. GitHub：代码托管+issue管理（任务管理）+CI/CD（依托GitHub Actions）
3. notion：文档、会议纪要、博客、开发信息管理

分层

1. 重大/繁多事项待讨论：线下会议（此处点名表扬百航这学期推出的研讨室预约服务，非常赞👍）
2. 少量/简单事项待共享/讨论：腾讯会议
3. 零碎开发对接：微信

专人统筹

由PM统筹协调开发进度、会议召开和议程协调等。

1.2 项目的典型用户场景

学生

用户信息	用户情况
姓名	学生A
身份	大一学生希望参加“士疑解惑”活动解决自己在课程中的问题，提高自己的学习成绩，更好的考出理想的成绩
用户痛点	1.没有渠道提出课业上的问题，并获得及时准确的回答，只能线下见面提问。 2.无法看到其它同学的答疑内容。 3.提问给自己带来心理负担，希望可以匿名提问。 4.参加活动加入了各种各样的微信群，没有办法有效组织信息，干扰了自己的生活
预期使用场景	参加“士疑解惑”活动，发布自己的问题，和辅导师进行交流互动，如果满意，同意辅导师的解答，如果不满意可以拒绝辅导师的回答，系统重新分配辅导师进行解答直到学生满意为止。学生可以填写自己的个人信息主页，包括头像等信息，进行个性化展示，也可以方便的查看自己提出的问题以及收藏的问题。此外，可以方便的进行问题的检索，查看对自己有用的问题，从中获取启发。
实现该用户需求的功能	设计个人信息页面，展示头像，提出的问题，收藏的问题等信息。设计问答交互页面，以时间线的方式与辅导师进行交互，可以选择关闭问题，同意辅导师解答，拒绝辅导师解答等按钮更改问题状态，也可以点赞和收藏自己喜欢的其他人提出的问题。设计检索页面，支持多关键字检索相关问题，从其他人的问题中获得启发。设计发布问题页面，该页面可以选择匿名提问，选择问题所属的章节和科目。

场景一（个人信息定制，问题列表查看）

• 学生A可以在个人信息页面定制自己的信息，设置头像修改密码等。

• 学生A可以在个人信息页面方便地查看自己的收藏的问题，提出的问题

场景二（检索）

检索页面支持多关键字检索，选择检索字段，排序方式，科目章节可以快速检索问题。从其他人的相关问题中获得启发。

场景三（提问与解答）

• 发布问题，选择问题的所属科目章节，填写题目信息，可以上传本地图片，同时可以选择匿名回答减轻自己的心理负担。

• 和辅导师进行交互

学生可以随时关闭问题以及编辑问题，修改问题信息，在页面内可以看到当前认领的辅导师与复审者。

辅导师认领后可以在对话框内和辅导师进行交流，对话流以时间线的形式整理

交流结束后，根据对辅导师回答满意与否选择拒绝辅导师回答或者同意辅导师回答，同意辅导师回答，问题将变为有效问题，拒绝回答，系统将自动重新分配辅导师进行回答。

同意后问题变为有效问题

辅导师

用户信息	用户情况
姓名	50W
身份	大二计算机学院学生。擅长编程，希望通过“士疑解惑”活动帮助学弟学妹，并获得志愿时长。
用户痛点	1. 答疑在微信群展开，模糊了工作与生活的边界 2. 信息组织低效，回答与问题间经常隔了很多其他提问的内容，回答过的问题未被收集整理，导致经常出现重复提问 3. 部分答疑通过微信私聊进行，无法被统计到工作量中
预期使用场景	在自己空闲的时间，登录“士问士答”平台，搜索还未被解决的问题，认领并回答。在个人主页可以看到所有自己认领的问题，便于即使给提问者反馈。若遇到较为常见的问题，可以搜索查看是否有辅导师已经回答过类似的问题，减少重复劳动。所有回答都会被后台自动统计，并计入工作量中。
实现该用户需求的功能	1. 搭建“士问士答”平台，将“士疑解惑”活动从微信中剥离出来，与生活解耦。解决用户痛点1 2. 以issue的形式组织问题，构建完备的issue转移机制管理问题，通过科目章节的形式整理问题，解决用户痛点2 3. 在数据库中有序存储所有回答，便于一键导出生成工作量。

• 这一版本的新功能和特性
  • 该版本中实现了哪些新的功能和特性？请图文并茂地进行描述。
  • 这些功能和特性分别能解决什么样的问题？请对问题所对应的各个需求进行描述。
  • 这些功能和特性分别对应怎样的应用场景？请以“讲故事”的方式对应用场景进行描述。

场景一

学生A：提问

辅导师A：回答

学生A：认可

辅导师B：复审通过

辅导师A在有空的时候登录平台，选择自己负责的科目，搜索有没有待回答的问题

在认领回答后，可以在问题内进行回答。支持上传图片回答。图片上传用户友好，直接粘贴图片即可自动上传图床。

提问者认可了辅导师的回答，该问题转为待复审状态。转为待复审状态后，辅导师将无法再在该问题下发表新的内容。

辅导师B认领了该问题的复审。

从回答者名单中，可以看见该问题的历任回答者

辅导师B认为该问题有效、回答正确，将该问题判为有效问题。

场景二

场景二

学生A：提问

辅导师A：回答

学生A：认可

辅导师B：复审不通过

辅导师B：更正回答

学生A：认可

辅导师A：复审通过

辅导师A搜索发现了一个有趣的问题，点进去看了后认为确实是自己可以回答的，于是在问题详细视图内，认领了该问题

给出了错误的回答，学生未发现该答案有误被误导，认可了该回答

辅导师B在问题详细视图内，认领复审了该问题

认为该回答有误，重新认领了该问题

重新以回答者的身份给出了正确的回答，得到了学生认可

当一个问题下的消息过多时，会自动进行分页处理，便于读者阅读

辅导师A认领复审了该问题，并判断为有效

辅导师A觉得这个问题和回答很有价值，点击了点赞收藏

管理员

用户信息	用户情况
姓名	辅导员小C
身份	作为士谔书院半脱产辅导员，小C在上学期担任士疑解惑活动的组织者。
用户痛点	1.需要管理多个微信答疑群聊，负担较重。
	2.无法方便管理学生和辅导师的信息。
预期使用场景	在我们的平台上，小C可以通过表格为学生和辅导师批量注册账号，无需建多个群聊，还可以通过表格管理辅导师负责的学科。此外，小C能够根据学号、姓名、身份（学生/辅导师）等信息筛选所有用户，查看信息。对于违反规则的用户，管理员有权冻结账号。
实现该用户需求的功能	设计创建用户功能，支持创建单个用户和用表格批量导入用户。显示所有用户列表和用户信息，支持按照学号/姓名/身份对用户进行筛选，支持冻结用户。能够创建章节科目，并且通过表格导入辅导师负责的学科。

场景一（创建新用户）

• 管理员小C可以创建单个用户，也能用表格批量导入用户。

• 管理员小C可以输入用户信息，然后创建单个用户。

• 管理员小C可以导入表格，解析表格信息，然后批量导入用户。

场景二（用户信息检索）

管理员小C可以通过用户列表看到所有注册的用户，还可以通过指定学号/姓名/身份来筛选用户。

点击冻结账号，即可冻结某个用户，同时也能够解冻用户。

场景三（章节科目管理）

管理员小C能够查看现有学年下的科目，并且能够新建科目

管理员小C能够查看每个科目所包含的章节，可以添加或者删除章节

此外，管理员小C能够通过表格导入辅导师所负责的科目

Beta阶段新功能

通知查询

为了让用户获得即时的反馈和更新、改善用户体验，我们设计并实现了通知查询功能。用户可以查询的通知分为两类：第一类是由管理员发布的全局通知。例如，当平台做出了功能或政策性调整时，管理员就会发布全局通知来将变化告知所有用户。第二类是由系统自动发布的点对点通知。当有辅导师在学生用户提出的问题下给出了新的回复时，系统会自动向提问者发出【issue回复通知】，以便用户及时获得解答和反馈，并和辅导师进行进一步的互动。

通知发布

只有管理员才有权限发布通知，管理员可以编辑通知标题和通知内容。

添加关联问题

为了避免对同质问题进行重复回答，辅导师可以给其负责的问题添加“关联问题”，这些问题可以是有着相似的解法和思想，也可以是有着类似的应用场景。这样可以方便同学们以这个问题为基点，快速了解这一问题的相关问题，从而对问题形成更深刻的理解。

修改问题标签

标签可以对问题在科目/章节二级结构之外，从另一个角度进行刻画和描述。例如作业题、考试题、debug、经验分享等。辅导师可以给问题添加标签，以便于同学们进行搜索。

这样做的好处是，可以对问题进行多维度的分类和描述，以便对已有的问题进行归纳和整理，方便学生根据自己需求进行搜索。

管理问题标签

辅导师只能从现有的标签中选择一些添加到问题上，而管理员可以建立新的标签或者删除已有的标签。

完善修改密码

考虑到用户输入新密码时可能会由于输入错误导致实际密码与想要输入的不符，我们添加了重复新密码的要求。此外，为了避免空密码和过长的密码，我们将密码长度限制在6~30位。

找回密码

若用户忘记了密码，可以通过找回密码功能，重新设置一个密码。输入学工号，点击发送验证码后，我们会向这个学工号对应的北航邮箱中发送一个验证码。用户在收到验证码后，可以使用该验证码重置其账户的密码。

该功能主要解决之前用户一旦忘记密码，就只能联系管理员手动重置密码的弊端。

热门问题和用户展示

在搜索页面，我们会展示当前的热门问题和活跃用户。这样做的目的是给激发大家提问和回答的热情，同时给反映当前普遍而热门的问题。

往届问题搜索

每学期都会有不一样的科目，都会新增一个学年来管理这些新的科目章节和问题。但以往的问题仍可能对现实有指导意义，因此有必要提供一个对往届问题的搜索功能。切换到“以往学期问题”后，可以选择历史学年，对之前学期的问题进行搜索。

搜索优化

alpha阶段时，用户必须选择科目和若干个章节后才能进行搜索。而在beta阶段，我们新增了默认全部搜索功能。具体地，若不选择学年，则默认对全部学年进行搜索；若选择学年而不选择科目，则默认对该学年下所有科目进行搜索；若选择学年和科目而不选择章节，则默认对该科目下所有章节进行搜索。这样的改进使得搜索更加用户友好，更符合一般人的使用习惯。

此外，我们也增加了模糊搜索功能。对于输入的关键字，我们会只能进行分词处理，大大增加了搜索的准确度。

更优越的md文本编辑器

beta阶段我们采用了更优越的文本编辑器，即mavon-editor，其具有

1. 丰富的工具栏：此编辑器具有一套支持各种Markdown语法的完整工具栏，例如粗体、斜体、引用、有序/无序列表、链接、图片等，方便用户直接点击按钮进行编辑而无需记住所有语法。
2. 代码高亮：mavon-editor支持代码高亮，包括多种编程语言和主题，改善代码的可读性。
3. 自定义样式和扩展：编辑器可以让开发者根据项目需求，轻松定制自己的样式和功能。
4. Markdown和HTML双重支持：允许用户在Markdown和HTML之间切换，便于在不熟悉Markdown语法的情况下进行编辑。
5. 更有对应的md语法提示，方便初学者使用

这是文本的对应展示效果

草稿的保存与复现功能

beta阶段我们加入了草稿的保存与复现功能。其使用场景为，学生在编写长段文本时，可能遇到临时情况而不得不转而做其他的事项，这时可以使用草稿的保存功能，下次发布问题时点击回复草稿便可以回复最新一次保存的草稿，十分方便实用。

统计图展示

我们需要掌握使用我们软件的用户的一些关键行为信息来分析软件的优势与不足，因此，一个直观反映用户关键行为信息的统计图系统就至关重要。

对于用户的一些关键行为信息，我们进行了数据统计，并且通过丰富的图表形式展示出来。不仅如此，我们还支持选择特定的时间区间。

我们支持的统计量包括：辅导师回答问题次数、辅导师复审问题次数、问题访问次数。目前支持的图表有两种：折线图和饼图。

对于折线图，横轴是选定的时间区间，纵轴是每日的统计量（例如：所有辅导师当日回答的问题数）。

对于饼图，我们将每种统计量分成五个区间：1~10次，11~ 20次，21~30次，31~40次，40次以上（例如：这段时间被访问1~10次的issue数量是18）。

志愿时长统计

为了便于“士疑解惑”活动组织者统计各位学生和辅导师的志愿时长，我们实现了志愿时长的自动统计。考虑到灵活指定志愿时长分配策略的需求，我们的前端支持管理员用户输入每个有效问题/回答问题/复审问题可以获得的志愿时长。同时，为了能够向学生和辅导师发布结果，我们也支持将结果导出为excel。

1.3 项目的杀手级功能

功能	ShieAsk(Alpha)	QQ频道/Discord平台	Gitee(issue)	微信群
支持以issue为单位，清晰化每个问题	✅	❌	✅	❌
支持士谔书院特定需求	✅	❌	❌	✅
易上手、门槛低	✅	✅	❌	✅
专人认领issue	✅	❌	❌	❌
issue全流程状态可视化	✅	❌	❌	❌
复审机制	✅	❌	❌	❌
支持匿名	✅	❌	❌	❌
支持追问	✅	✅	✅	❌
支持回复评论聚合在issue下	✅	✅	✅	❌
支持数据统计与志愿时长导出【NEW】	✅	❌	❌	❌
支持问题关联【NEW】	✅	❌	❌	❌

1.4 项目发布时团队做的努力

1.4.1 Beta公测

我们面向士谔书院和相关学院招募了数百名辅导师和学生参加Beta公测，收集了大量真实数据、bug反馈与意见建议。并通过及时的开发者答复、状态更新和认领来给予用户快速反馈，并实时进行热更新修复bug与增加feature。目前，本项目已发放逾600小时志愿时长，测试覆盖面广、效果好。

目前，Beta阶段已收集bug和意见反馈58条，其中有效bug12条，已修复7条，剩余不太紧急的bug也正在修复中；加入与士谔交接阶段的意见反馈20余条，为项目下一阶段的开发和可持续发展奠定了基础。

接下来，我们还将进行更长期的测试，提升项目的可持续性和鲁棒性。

1.4.2 与士谔对接需求

我们在交付Beta软件前和士谔重新对接需求，并对老师提出的新要求进行敏捷开发，并进行热更新快速部署到生产服务。

1.4.3 合规性

在beta阶段开发完毕后，我们的软件得到了士谔方面的 高度认可，并就合规性方面进一步讨论，包括服务器迁移回校内、接入统一认证登录、通过信息办网络安全审查等。

1.5 团队代码的软件工程质量如何

文档

我们综合使用notion、GitHub Issue、Eolink等工具进行分门别类的文档管理。

团队使用Notion管理开发文档、记录会议内容，得益于Notion支持多人在线编辑和丰富的组件与功能，我们的协作效率大大提高。

记录会议内容：

开发信息分享：

博客分工与投票：

GitHub Issue记录具体的待开发工作并进行分工。

Eolink进行前后端API约定记录。

API分类管理：

API的关键信息展示和详细说明：

API的参数名、类型和说明

测试

项目后端有进行单元测试。测试分布在django的各个apps中。

测试用例数目当前总共有64个。其分布与Alpha阶段区别如下：

• issues：16个
• users：20个
• admins：9个
• subjects：4个
• tags：4个
• chapters：4个
• years：5个
• mail：2个
• notifications：3个

代码覆盖率如图所示。

我们针对较为核心功能进行了较多单元测试，并在较为核心的功能方面覆盖率较大，如admins，issues。

CI/CD

我们主要依托GitHub Actions进行CI/CD，前端工具链为Vue + Nginx + Docker，后端工具链为Django + Nginx + uwsgi

1.6 demo展示

ShieAsk Beta阶段项目展示

Part 2 项目与团队总结

2.1 项目管理

2.1.1 团队成员的简介和个人博客地址

以字典序

陈楚岩

我喜欢睡觉。Sleeping is all you need.

在本次团队开发中主要担当后端开发的工作。

姜雨竺

第一次实习那个夏天我说再也不要沾前端了，从此写了一整年的前端。

在本次团队开发中主要担当 架构设计、前端开发 的工作。

史泽宇

哇哇哇，我对软工课程的热爱就像那些代码一样，永不止息！但是看到Bug就想创丝自己，这是一个问题（。

在本次团队开发中主要担当前端开发与前端测试的工作。

王小鸽

喜欢梦到很新很新的东西~~

在本次团队开发中主要担当前端开发和前端测试的工作

王雪竹

想用代码画画 QwQ

在本次团队开发中主要担当前端开发的工作

叶颜函

我：MOSS，我们团队有未来吗？ 
MOSS：团队的未来取决于团队所有成员的选择。
我：我选择希望。

在本次团队开发中主要担当后端开发及测试的工作

于敬凯

550w听起来不像是个名字，如果把它翻过来，叫moss，直译为小苔藓，是不是亲切多了

工具爱好者，最佳实践爱好者（所以会沉迷于“找到最大的麦穗”），团队协作爱好者

技术力亟待提升，bug制造力亟待下降，谢谢大佬们带我orz！

在本次团队开发中主要担当PM、运维的工作。

2.1.2 团队是如何进行项目管理的？相比于Alpha阶段有什么改进？

项目开始之初，PM于敬凯同课程组进行沟通和讨论并得出初步解决方案：讨论：关于团队的技术栈和项目管理工具选择。

在项目的进行中，团队逐渐完善这一解决方案，最终采用了完善的现代工具链+分层+专人统筹的方式进行项目管理。

现代工具链

1. 微信+腾讯会议：进行碎片化的、快速的沟通
2. GitHub：代码托管+issue管理（任务管理）+CI/CD（依托GitHub Actions）
3. notion：文档、会议纪要、博客、开发信息管理

分层

1. 重大/繁多事项待讨论：线下会议（此处点名表扬百航这学期推出的研讨室预约服务，非常赞👍）
2. 少量/简单事项待共享/讨论：腾讯会议
3. 零碎开发对接：微信

专人统筹

由PM统筹协调开发进度、会议召开和议程协调等。

和Alpha阶段相比的改进

Alpha阶段我们已经初步进行了比较科学合理的项目管理方法，在beta阶段，我们进一步扬长避短，更清晰地划定每位成员的职责范围，确定工作落实到人、落实到事，进一步提高了沟通效率和工作效率。

2.1.3 团队的成员如何分工协作的？有什么经验教训？相比于Alpha阶段有什么改进？

队创建之处，我们按照大家的能力和兴趣初步进行了分工的划分：「MOSS - 00」MOSS队：团队介绍。

在项目进行的过程中，我们也根据实际情况进行了一定调整。

成员	分工
于敬凯	PM，项目管理，运维
姜雨竺	前端开发，架构设计，原型设计
史泽宇	前端开发，前端测试，原型设计
王小鸽	前端开发，API对接，原型设计
王雪竹	前端开发，原型设计
陈楚岩	后端开发，数据库
叶颜函	后端开发，后端测试

相比于Alpha阶段，我们在Beta阶段更加重视UI和界面体验，广泛学习了优秀先进经验，答复提升了界面设计感和用户使用体验。

2.1.4 团队成员如何沟通和对接的？有什么记录留存？

1. 微信+腾讯会议：进行碎片化的、快速的沟通
2. GitHub：代码托管+issue管理（任务管理）+CI/CD（依托GitHub Actions）
3. notion：文档、会议纪要、博客、开发信息管理

2.1.5 团队如何平衡 时间/质量/资源 争取如期完成任务的？

时间方面，我们遵循敏捷开发原则，在项目初期花费较多时间和精力进行API对接、ER图设计、原型设计、数据库设计等，为后续开发奠定了坚实的基础，在前后端对接、环境部署等方面没有遇到需要大规模重构的情况，比较顺利，保证了项目如期进行。同时，我们提前进行分工和节点规划，进行合理的工作安排，使得每位成员都能够完成分内工作。

质量方面，我们通过单元测试、内测等多种途径确保了代码的鲁棒性，引入CI/CD保证了环境部署的纯净和正确性，使用nginx和uwsgi等现代高性能服务器支持生产环境应用，使用SSL和HTTPS等手段保证了网站的安全性等。

资源方面，由PM进行士谔书院方的对接，确保项目开发满足甲方需求，同时得到支持和资源。在Beta阶段，士谔依旧给予了大力支持，为我们获取大量真实用户和数据做出了突出贡献。

2.1.6 团队项目的实际进展如何？在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？

2.1.6.1 实际进展与燃尽图

2.1.6.2 燃尽图是如何真实反映项目的状态

燃尽图基本反映了项目的真实状态，其中前端的曲线较为平整且符合预期，后端有一些接近直线的突变，主要体现在当时是在进行集中开发，因此需求完成地快。

燃尽图并没有美化状态。

2.1.7 成员在Alpha阶段的角色和具体贡献

成员	本职工作完成度	收获感谢信	额外工作与其他奖励	折算分数
于敬凯	好👍	0		50
王雪竹	好👍	0		50
史泽宇	好👍	0		50
姜雨竺	好👍	0		50
王小鸽	好👍	0		50
陈楚岩	好👍	0		50
叶颜函	好👍	0		50

2.2用户场景

2.2.1 项目开发前的目标，预期的典型用户场景，预期的功能描述

学生

用户信息	用户情况
姓名	学生A
身份	大一学生希望参加“士疑解惑”活动解决自己在课程中的问题，提高自己的学习成绩，更好的考出理想的成绩
用户痛点	1.没有渠道提出课业上的问题，并获得及时准确的回答，只能线下见面提问。 2.无法看到其它同学的答疑内容。 3.提问给自己带来心理负担，希望可以匿名提问。 4.参加活动加入了各种各样的微信群，没有办法有效组织信息，干扰了自己的生活
预期使用场景	参加“士疑解惑”活动，发布自己的问题，和辅导师进行交流互动，如果满意，同意辅导师的解答，如果不满意可以拒绝辅导师的回答，系统重新分配辅导师进行解答直到学生满意为止。学生可以填写自己的个人信息主页，包括头像等信息，进行个性化展示，也可以方便的查看自己提出的问题以及收藏的问题。此外，可以方便的进行问题的检索，查看对自己有用的问题，从中获取启发。
实现该用户需求的功能	设计个人信息页面，展示头像，提出的问题，收藏的问题等信息。设计问答交互页面，以时间线的方式与辅导师进行交互，可以选择关闭问题，同意辅导师解答，拒绝辅导师解答等按钮更改问题状态，也可以点赞和收藏自己喜欢的其他人提出的问题。设计检索页面，支持多关键字检索相关问题，从其他人的问题中获得启发。设计发布问题页面，该页面可以选择匿名提问，选择问题所属的章节和科目。

场景一（个人信息定制，问题列表查看）

• 学生A可以在个人信息页面定制自己的信息，设置头像修改密码等。

• 学生A可以在个人信息页面方便地查看自己的收藏的问题，提出的问题

场景二（检索）

检索页面支持多关键字检索，选择检索字段，排序方式，科目章节可以快速检索问题。从其他人的相关问题中获得启发。

场景三（提问与解答）

• 发布问题，选择问题的所属科目章节，填写题目信息，可以上传本地图片，同时可以选择匿名回答减轻自己的心理负担。

• 和辅导师进行交互

学生可以随时关闭问题以及编辑问题，修改问题信息，在页面内可以看到当前认领的辅导师与复审者。

辅导师认领后可以在对话框内和辅导师进行交流，对话流以时间线的形式整理

交流结束后，根据对辅导师回答满意与否选择拒绝辅导师回答或者同意辅导师回答，同意辅导师回答，问题将变为有效问题，拒绝回答，系统将自动重新分配辅导师进行回答。

同意后问题变为有效问题

辅导师

用户信息	用户情况
姓名	50W
身份	大二计算机学院学生。擅长编程，希望通过“士疑解惑”活动帮助学弟学妹，并获得志愿时长。
用户痛点	1. 答疑在微信群展开，模糊了工作与生活的边界 2. 信息组织低效，回答与问题间经常隔了很多其他提问的内容，回答过的问题未被收集整理，导致经常出现重复提问 3. 部分答疑通过微信私聊进行，无法被统计到工作量中
预期使用场景	在自己空闲的时间，登录“士问士答”平台，搜索还未被解决的问题，认领并回答。在个人主页可以看到所有自己认领的问题，便于即使给提问者反馈。若遇到较为常见的问题，可以搜索查看是否有辅导师已经回答过类似的问题，减少重复劳动。所有回答都会被后台自动统计，并计入工作量中。
实现该用户需求的功能	1. 搭建“士问士答”平台，将“士疑解惑”活动从微信中剥离出来，与生活解耦。解决用户痛点1 2. 以issue的形式组织问题，构建完备的issue转移机制管理问题，通过科目章节的形式整理问题，解决用户痛点2 3. 在数据库中有序存储所有回答，便于一键导出生成工作量。

• 这一版本的新功能和特性
  • 该版本中实现了哪些新的功能和特性？请图文并茂地进行描述。
  • 这些功能和特性分别能解决什么样的问题？请对问题所对应的各个需求进行描述。
  • 这些功能和特性分别对应怎样的应用场景？请以“讲故事”的方式对应用场景进行描述。

场景一

学生A：提问

辅导师A：回答

学生A：认可

辅导师B：复审通过

辅导师A在有空的时候登录平台，选择自己负责的科目，搜索有没有待回答的问题

在认领回答后，可以在问题内进行回答。支持上传图片回答。图片上传用户友好，直接粘贴图片即可自动上传图床。

提问者认可了辅导师的回答，该问题转为待复审状态。转为待复审状态后，辅导师将无法再在该问题下发表新的内容。

辅导师B认领了该问题的复审。

从回答者名单中，可以看见该问题的历任回答者

辅导师B认为该问题有效、回答正确，将该问题判为有效问题。

场景二

场景二

学生A：提问

辅导师A：回答

学生A：认可

辅导师B：复审不通过

辅导师B：更正回答

学生A：认可

辅导师A：复审通过

辅导师A搜索发现了一个有趣的问题，点进去看了后认为确实是自己可以回答的，于是在问题详细视图内，认领了该问题

给出了错误的回答，学生未发现该答案有误被误导，认可了该回答

辅导师B在问题详细视图内，认领复审了该问题

认为该回答有误，重新认领了该问题

重新以回答者的身份给出了正确的回答，得到了学生认可

当一个问题下的消息过多时，会自动进行分页处理，便于读者阅读

辅导师A认领复审了该问题，并判断为有效

辅导师A觉得这个问题和回答很有价值，点击了点赞收藏

管理员

用户信息	用户情况
姓名	辅导员小C
身份	作为士谔书院半脱产辅导员，小C在上学期担任士疑解惑活动的组织者。
用户痛点	1.需要管理多个微信答疑群聊，负担较重。
2.无法方便管理学生和辅导师的信息。
预期使用场景	在我们的平台上，小C可以通过表格为学生和辅导师批量注册账号，无需建多个群聊，还可以通过表格管理辅导师负责的学科。此外，小C能够根据学号、姓名、身份（学生/辅导师）等信息筛选所有用户，查看信息。对于违反规则的用户，管理员有权冻结账号。
实现该用户需求的功能	设计创建用户功能，支持创建单个用户和用表格批量导入用户。显示所有用户列表和用户信息，支持按照学号/姓名/身份对用户进行筛选，支持冻结用户。能够创建章节科目，并且通过表格导入辅导师负责的学科。

场景一（创建新用户）

• 管理员小C可以创建单个用户，也能用表格批量导入用户。

• 管理员小C可以输入用户信息，然后创建单个用户。

• 管理员小C可以导入表格，解析表格信息，然后批量导入用户。

场景二（用户信息检索）

管理员小C可以通过用户列表看到所有注册的用户，还可以通过指定学号/姓名/身份来筛选用户。

点击冻结账号，即可冻结某个用户，同时也能够解冻用户。

场景三（章节科目管理）

管理员小C能够查看现有学年下的科目，并且能够新建科目

管理员小C能够查看每个科目所包含的章节，可以添加或者删除章节

此外，管理员小C能够通过表格导入辅导师所负责的科目

2.2.2 项目发布的功能，在哪里发布了软件

访问ShieAsk

本软件为网页平台，无需安装，直接访问士问士答即可。

注册方式：由辅导员批量导入账户，初始账号和密码均为学号。

使用说明

注册方式：由辅导员批量导入账户，初始账号和密码均为学号

辅导师使用流程：

按以下流程回答问题

按以下流程复审问题

学生使用流程：

2.2.3 项目发布后是否满足了全部典型场景？剩下的为何没有满足？

Alpha阶段覆盖了全部典型场景的核心需求，一些稍边缘的功能计划已经于beta阶段实现：

1. beta阶段添加邮箱验证与修改、邮件通知功能
2. beta阶段上线管理员前端添加CRUD功能，即具有root级的增删改查权限，如可以删除任何问题，可以搜索并批量导出数据库里的问题
3. beta阶段上线密码找回功能
4. beta阶段上线工作量统计与可视化功能

已经没有核心或边缘功能未完成了。

2.2.4 项目发布后真正符合用户需求了吗？列出目标用户使用产品的过程和评价

项目目前已经得到了上百名公测用户（真实的辅导师、学生、管理员）的认可，并且得到了甲方士谔书院老师们的认可，符合用户需求。

使用过程：根据我们提供的内测指南进行产品试用。

评价：公测用户表达了高度认可，也提出了很多意见和建议，期待未来正式移交士谔书院。

2.3 用户日活

2.3.1 项目发布时团队做了哪些努力来推广项目？

2.3.1.1 内测

公测阶段招募了上百名真实学生和辅导师参加到项目体验中，

2.3.1.2 公众号推送

通过士谔书院官方微信公众号、开发人员与同学的微信朋友圈进行推广，阅读量逾千人次，效果优秀。

2.3.1.3 大班微信群推送

在士谔书院大班微信群中进行广播推送。

2.3.2 软件的日活跃用户量是否达到了预先定义的数量？

公测有上百真实用户，产生了近200条有效的问题与答案，超过600小时志愿时长，达到了预先定义的数量。

2.3.3 是否有用户在功能改进上有所反馈？可以提供用户反馈的截屏。

2.3.4 是否有用户在Bug上有所反馈？有什么样的bug？这是预料之中的还是没想到的？

在公测阶段用户提出了一些意见、建议和少量bug，我们一一对其进行回复和修复。部分bug确实是意料之外的，但是由于框架的鲁棒性，我们得以很快地修复。bug的主要类型集中在前端，这是由于前端代码的复杂性导致的。

2.4 特色功能

2.4.1 项目的杀手级功能，与竞品相比最特色的功能展现

功能	ShieAsk(Alpha)	QQ频道/Discord平台	Gitee(issue)	微信群
支持以issue为单位，清晰化每个问题	✅	❌	✅	❌
支持士谔书院特定需求	✅	❌	❌	✅
易上手、门槛低	✅	✅	❌	✅
专人认领issue	✅	❌	❌	❌
issue全流程状态可视化	✅	❌	❌	❌
复审机制	✅	❌	❌	❌
支持匿名	✅	❌	❌	❌
支持追问	✅	✅	✅	❌
支持回复评论聚合在issue下	✅	✅	✅	❌

2.4.2 思考一下竞品出于什么原因并没有囊括该特色功能，团队凭借什么样的优势实现了它？

1. 独占信息优势。我们有士谔书院的官方支持，且项目成员都毕业自士谔书院，了解需求，因此得以开发出这一项目
2. 用户画像清晰。士谔书院学生不算是市场级别的大客户，但是群体依旧不小，团队成员非常了解士谔书院的学生平均状况和画像，得以根据具体情况设计这一项目
3. 相关工具使用经验。团队成员均担任过代码类课程的助教（包括面向对象、操作系统、数据结构、程序设计等课程），非常熟悉git和GitHub以及相关的issue机制，可以将其迁移至此并进行本土化修改和优化来满足用户需求。

2.4.3 团队成员对这些功能的自我评价如何，是否达到了预期目标，为什么？

1. 团队成员对这些功能的自我评价较高，我们一起实现了一个在最开始看来较为艰巨的任务。
2. 我们基本达到了预期目标，项目设计之初的核心功能均已完成并得到甲方的认可。

2.5 软件工程质量

2.5.1 项目有完善的文档吗，是否有约定代码规范？

我们综合使用notion、GitHub Issue、Eolink等工具进行分门别类的文档管理。

具体地，notion记录会议纪要、博客、开发信息集散等文档。

GitHub Issue记录具体的待开发工作并进行分工。

Eolink进行前后端API约定记录。

beta阶段新增的功能通过notion来管理

2.5.2 项目是否有出现代码混乱，没有注释，没有详细文档的问题？明年的同学继续开发这个项目，会不会出现以上抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？

前端暂时没有出现代码混乱，但详细文档还需要完善。如果一个学生在新机器上编译并运行这个项目，可以参考指导文档，以下是指导文档的部分内容

为了方便其他同学接手这个项目，我们列出了简要的项目结构介绍和迭代方法

• public 静态资源目录
• src
  • api api接口，在这里添加api与后端进行对接
  • assets 全局资源目录
  • components 组件库
  • icons 图标库，一般直接引入mdi图标即可
  • layout 布局，侧边栏和导航栏组件
  • router 路由（主要工作目录）利用permission对权限和路由做了映射。在这里添加路由可以直接显示到侧边栏，不同的权限看到的侧边栏路由不一样。在这里可以动态配置路由实现多种形式的路由功能
  • store vuex状态管理
  • styles 样式
  • utills js工具函数
  • views 编写vue组件，实现众多页面
• test 单元测试文件目录

具体地，我们还使用了notion、GitHub、eolink等现代工具综合记录了完善的项目全流程文档，适合明年的同学接手快速了解项目结构。

另外，我们使用了CI/CD和Docker容器化技术等，使得项目的打包、部署、运行等摆脱了对手动配置环境的依赖，不会存在无法编译或者安装环境时各种报错的情况。

2.5.3 项目是否有单元测试，测试用例数目，代码覆盖率等

项目后端有进行单元测试。测试分布在django的各个apps中。

测试用例数目当前总共有64个。其分布与Alpha阶段区别如下：

• issues：16个
• users：20个
• admins：9个
• subjects：4个
• tags：4个
• chapters：4个
• years：5个
• mail：2个
• notifications：3个

代码覆盖率如图所示。

我们针对较为核心功能进行了较多单元测试，并在较为核心的功能方面覆盖率较大，如admins，issues。

2.5.4 项目是否采用了CI/CD，并说明理由

项目采用了CI/CD。

理由：CI/CD通过在应用开发阶段引入自动化来频繁向客户交付应用的方法，以持续集成、持续交付和持续部署为核心，可让持续自动化和持续监控贯穿于应用的整个生命周期。在本项目中，我们成功地将前后端都完成了CI/CD部署，实现了以下工作流：

开发者工作流：

1. 开发者checkout新分支，本地编写代码并push
2. 开发者在GitHub发起Pull Request，经过Review后Merge入主开发分支dev
3. GitHub Actions脚本检测到指定分支（dev）的指定行为（Push）（Merge Pull Request会被检测为Push），执行GitHub Actions脚本，进行自动拉取、构建、打包、部署、发布。

注：通过GitHub仓库设置可以保护dev分支，要求使用pr，避免直接push

核心亮点 ： 解耦开发和运维，减轻开发者负担，使开发者专注于代码开发本身，无需关注环境等琐碎细节

2.5.5 学到的经验和教训：整个团队在Alpha阶段学到了什么，对软件工程有什么样的经验教训，Beta阶段有什么大体计划？

yjk: 在beta阶段，我完善地整理了在alpha阶段的得失，继续稳定推进项目进度。和Alpha阶段相比，我们的合作更加熟练，技术更加高超，达到了选课时的初心和预期，开发了一个页面美观大方、功能使用的复杂软件，并且具备了较高的实用价值，将在未来移交士谔书院做进一步开发，真正实现了一个可持续发展的软件。

szy：在软件工程课程中，我们的团队在Beta阶段学会了需求分析、设计模式、代码规范和团队协作。经验教训包括事先规划好流程、保持沟通、测试驱动开发以及持续集成。Beta阶段我们将优化代码、修复bug、增强功能以达到更高的质量标准。

jyz：在软工课程中我们学会了团队合作开发，团队共同体验了需求分析、原型设计、制定代码规范、分配任务、实现代码、测试、修复bug、每日例会、持续集成的流程。在ALPHA阶段我们总结应该在早期就制定更详细的分工，在BETA阶段我们更好地实现了这一点。

yyh：第一是用户需求的重要性。在 Beta 阶段，团队需要深入了解用户的需求和反馈，以便及时调整产品功能和设计。第二是测试的重要性。在 Beta 阶段，团队需要投入大量时间和精力来测试产品，以确保它的稳定性和可靠性。第三是管理风险的重要性。在 Beta 阶段，团队需要密切关注产品的风险，并采取措施来控制风险，以确保产品的安全和稳定性。

wxz：软件工程课程的Beta阶段对开发团队的要求有别于Alpha阶段。在Alpha阶段开发团队可以天马行空地构建系统、开发软件的新功能，虽然也有用户调查，但是毕竟停留在分析层次上。而Beta阶段开发团队要切实地面临用户反馈的bug和对新功能的诉求。因此，与用户的交流也变成了开发的一部分。

wxg：Beta阶段的新增功能不像Alpha阶段那样可以简单按照用户角色来分类，而是拆分成了很多个相对零散的功能。因此我在Beta阶段的其中一项任务就是明确新的需求，给需求定义较为清晰的描述，制定对应的接口，并将其派发给前端和后端对应的实现用户。这过程颇有种多线程并行管理的风格。同时，不同的功能之间可能还具有前置和后置关系（例如得先实现发通知的功能，才能测验收通知的功能），所以还得对不同的进程进行优先级管理。此外，我也感受到可扩展性的重要。在Alpha阶段，我们已经预先设想了Beta需要扩展的大致功能，留了足够的接口。但同时，我们并没有设想对提问的流程进行更改，这导致在Beta阶段用户对我们的提问流程提出建议时，我们无法即使做出更改。这可能需要在后续进行一定的重构。

ccy：与Alpha阶段不同，在Beta阶段，我们更关注用户的反馈和数据，通过共享文档及时地收集、发现和修复问题。通过Beta阶段的开发，我们学会了如何从大量用户反馈中高效地筛选信息，并以此为参考不断迭代开发Beta版本的功能。但在Beta阶段中，一个在Alpha阶段中没有找出的bug对开发造成了一定的影响，因此Alpha阶段的测试力度可能仍需提高。