「MOSS - 19」MOSS队：Alpha阶段项目展示

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

Author: MOSS队

Date: 2023.05.03

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能够通过表格导入辅导师所负责的科目

1.3 项目的杀手级功能

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

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

1.4.1 Alpha内测

我们面向士谔书院和相关学院招募了数十名辅导师和学生参加内测，收集了大量真实数据、bug反馈与意见建议。并通过及时的开发者答复、状态更新和认领来给予用户快速反馈，并实时进行热更新修复bug与增加feature。

目前，已收集bug和意见反馈85条，其中有效bug15条，已修复7条，剩余不太紧急的bug也正在修复中；加入beta阶段的意见反馈三十余条，为我们下一阶段的开发奠定了基础。

接下来，我们还将进行更大范围的公测，预计覆盖上百人，进一步收集用户数据和反馈。

1.4.2 与士谔对接需求

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

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

文档

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

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

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

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

测试

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

测试用例数目当前总共有53个。其分布如下：

• issues：16个
• users：15个
• admins： 6个
• subjects：4个
• tags：4个
• chapters：4个
• years：4个

代码覆盖率如图所示。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i8gXKO8Y-1683112755978)(Alpha阶段软件发布声明/test.png)]

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

CI/CD

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

1.6 demo展示

Part 2 项目与团队总结

2.1 项目管理

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

以字典序

陈楚岩

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

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

姜雨竺

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

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

史泽宇

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

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

王小鸽

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

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

王雪竹

想用代码画画 QwQ

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

叶颜函

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

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

于敬凯

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

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

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

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

2.1.2 团队是如何进行项目管理的

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

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

现代工具链

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

分层

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

专人统筹

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

2.1.3 团队的成员如何分工协作的？有什么经验教训？

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

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

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

目前最大的痛点在于没有专业的美工设计（逃.jpg

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进行士谔书院方的对接，确保项目开发满足甲方需求，同时得到支持和资源。

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

2.1.6.1 实际进展与燃尽图

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

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

燃尽图并没有美化状态。

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

成员	本职工作完成度	收获感谢信	额外工作与其他奖励	折算分数
于敬凯	好👍	0	翻转课堂（为团队每人带来bonus）+内测/志愿项目.etc	51
王雪竹	好👍	0		49
史泽宇	好👍	1		50
姜雨竺	好👍	0		49
王小鸽	好👍	1	提出ShieAsk需求案	52
陈楚岩	好👍	0	提出ShieAsk需求案	50
叶颜函	好👍	0		49

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. 目前没有管理员前端添加CRUD功能，即具有root级的增删改查权限，如可以删除任何问题，可以搜索并批量导出数据库里的问题，计划于beta阶段上线
3. 目前没有密码找回功能，计划于beta阶段上线
4. 目前没有添加打卡功能，计划于beta阶段上线
5. 目前没有工作量统计与可视化功能，计划于beta阶段上线

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

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

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

评价：内测用户表达了高度认可，也提出了很多意见和建议，期待我们的公测和beta阶段开发

2.3 用户日活

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

2.3.1.1 内测

内测阶段招募了数十名真实学生和辅导师参加倒项目体验中，进行了一定范围的宣传。

2.3.1.2 公众号推送（进行中）

目前正在进行公众号推送的文案撰写和对接，拟在五月初发布。

2.3.1.3 大班微信群推送（进行中）

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

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

目前正在和甲方士谔书院进行公测对接和公众号宣发对接等，即将进行正式发布。内测阶段用户非常活跃，满足了我们的预期。

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约定记录。

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

项目文档清晰，鲁棒性强，易于上手继续开发。

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

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

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

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

测试用例数目当前总共有53个。其分布如下：

• issues：16个
• users：15个
• admins： 6个
• subjects：4个
• tags：4个
• chapters：4个
• years：4个

代码覆盖率如图所示。

我们针对较为核心功能进行了较多单元测试，并在较为核心的功能方面覆盖率较大，如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: 担任软工的PM比我曾做过的所有工作都要求更高、付出更多，维持一个类似真实场景的软件工程项目正常进行不仅有理论知识的要求，也有实践经验的要求，如何合理地分工、设置议程、维护文档、推进项目节点、和甲方对接沟通，都是需要大量精力和经验的，同时需要应对各种可能的突发情况。在beta阶段，我希望可以完善地整理在alpha阶段的得失，继续稳定推进项目进度。

jyz: “磨刀不误砍柴工。”使用更多的时间在前期做好设计和讨论，会减少之后遇到问题的可能性。但思考过多而迟迟不动手实现也不可行，很多脑内设想的问题在实践中会迎刃而解。

ccy：“设计完接口后，写后端代码时不必考虑太多需求细节，效率高了很多。”

wxz：前期的需求分析和任务划分会一直持续影响开发的每个环节，也是最值得重视的阶段。这方面可以秉持极简主义的设计思想，先设计主干功能，在添加细节，这样更方便任务的拆分。

yyh: 需要确定好分工，制订好代码规范。当前项目后端的代码质量有待提高，希望Beta阶段能够对此进行改进。

wxg：通过实践体会到了敏捷开发的优缺点。优点是可以通过CI/CD快速将想法付诸实践，从设计到出成品的周期很短，且在遇到bug时修完可以自动部署。但缺点是很难在开发前就预先考虑到所有情况，导致开发过程中经常出现需求、设计、分工等方面的变更。若无法通过有效手段维护管理并通知这些变更，可能会导致开发成员之间的脱节。

szy:需要制定代码规范和更加详细的项目规划，前端的设计需要进行进一步的优化和改进，Beta阶段除了要完成beta阶段的任务外也需要美化前端的视觉效果。