[T.18] 团队项目：Beta 阶段项目展示

项目	内容
这个作业属于哪个课程	课程社区
这个作业的要求在哪里	作业要求
我在这个课程的目标是	凝聚整个团队通过一定的软件开发流程，在预计时间内发布"足够好"的符合用户需求的软件，并证明其是可维护和持续发展的，并在其中做出应有的贡献，提升进行软件工程开发的能力。
这个作业在哪个具体方面帮助我实现目标	完成最后的 Beta 阶段开发，构建出可正式公开发布的软件版本

项目与团队亮点

团队成员与分工简介

团队成立之初，我们按大家的能力和兴趣初步进行了分工的划分：团队介绍

为保证项目的按期发布，在项目进行过程中，我们根据实际情况做出了相应的调整。举例而言，先前专职测试的两位同学在本阶段亦参与了前后端的开发。

人员	任务	Beta 阶段负责的内容	个人博客地址	贡献分（按百分比记）	可衡量的贡献
彭子峻	PM,功能设计,接口设计	一半Paperwork，举报、审核、卡牌自定义等功能的功能设计，跟进、协调项目进度	https://www.cnblogs.com/lajipz	15	Scrum Meeting报告等各类项目有关的报告作业，项目展示，平台各项功能的设计文档
王梓恒	运维,前后端开发,API对接	另一半Paperwork，跟进、协调项目进度	https://www.cnblogs.com/yuuuumoo	15	Scrum Meeting报告等各类项目有关的报告作业，平台的部署，项目展示，
李奕宽	后端开发	优化对局后端执行引擎的性能	https://www.cnblogs.com/likend	15	对局时，自定义规则的后端执行引擎
邓智航	前端开发	完成卡牌自定义界面、对局回放界面的前端	https://www.cnblogs.com/cdostan	20	图形化规则构建系统（Alpha阶段）卡牌自定义界面、对局回放界面的前端（Beta阶段）
王靖茹	前端开发	完成举报、审核系统的前端	https://www.cnblogs.com/hillary	15	用户系统、对局房间的前端（Alpha阶段）举报、审核功能的前端界面（Beta阶段）
陈耕	测试,前后端开发	完成所有新增功能的单元测试编写及人工测试	https://www.cnblogs.com/er-huo	15	Github仓库上的单元测试，所有的测试文档
田锦煜	测试，前后端开发	完成规则市场的前端，完成举报、审核系统、规则市场的后端开发	https://www.cnblogs.com/tanhhhhtjy	20	所有的测试文档，规则市场前端，教程文档，以及 Beta 阶段以来新功能的后端

项目管理

我们沿用 Alpha 阶段的项目管理方式，参照先前于[T.3] 团队项目：团队基础设施及 DevOps 准备中确定的方式，进行项目管理。

交流沟通使用 飞书 + 微信。

• 由于有同学不习惯使用飞书，因此常常在飞书上失联，所以多了个微信群。
• 虽然能保证消息及时通知，但的确造成了信息的冗余。

代码托管在 Github 上，分前后端仓库并行开发。

对于团队例会：

• 重大事项（如决定分工与开发方向）由线下会议解决
• 出于日常进度核对的例会，通过线上的飞书会议解决
• 简单的消息对接，通过飞书+微信解决

实际进展

以下的燃尽图并未归零，其原因是我们的测试亦通过建立 Issue 完成；实际开发工作在发布时已经完成。

燃尽图通过 Issue 跟进项目与预期理想推进状态的差距，从而反映项目的开发进度。

于我们的项目而言，燃尽图对我们的项目进度反应略为悲观，原因在于：

• 燃尽图是基于 Closed Issue 追踪项目进度的。我们在开发过程中，常出现功能实现完成后，未完成基本测试，不足以 merge 进主分支的情况出现；对于这种情况，燃尽图并无法追踪进度。
• 我们的 Issue 中包含我们设计的测试。因此，测试进度的推进，亦会影响燃尽图上项目进度的展示。

经验教训

在 Alpha 阶段，我们在组内出现了项目进度跟进不积极、不及时，导致开发进度推进迟缓的情况。我们在 Beta 阶段，通过在各次 Scrum Meeting 间的时间，亦通过飞书或微信进行简短进度查询的方式，确保了各项功能的如期开发。

典型用户场景

本项目的开发初衷，是为了提供一套支持高度自定义规则的线上卡牌游戏平台，并允许用户使用 Web 端便捷访问。

我们通过将平台部署至云端服务器上，来完成本项目的发布，其可以通过本链接访问。

在发布时，本项目具备以下功能：

• 图形化自定义规则构建：允许用户拖拽组合规则组件，构建自定义规则。同时，自定义规则的牌面与背景，亦可由规则构建者进行自定义。
• 自定义规则的在线对局：通过选择规则创建对局房间的方式，用户可对于某个自定义规则进行游玩。
• 规则市场功能：用户可将自己创作的自定义规则发布于此，供平台上其他玩家游玩。玩家亦可在他人规则的基础上进行进一步的二次创作。规则市场支持评论功能。
• 规则审核功能：出于对用户创作内容的合规性控制要求，本项目对于要上架到规则市场的自定义规则需进行审核。
• 举报功能：对于规则市场评论，玩家不友好行为等情况，本平台亦提供了举报功能，以对行为恶劣的用户进行封禁处理。

扑克爱好者

用户信息	用户情况
姓名	扑克牌爱好者A
身份	不折不扣的扑克爱好者
用户痛点	1. 有好点子设计特殊的扑克牌规则，但无法实现2. 想要知道别的同好的规则
预期使用场景	有了好点子后在平台上通过相应的组件设计并且实现相应的规则供广大扑克牌爱好者进行游玩，同时也可以在规则市场中看到他人发布的有意思的规则并进行相应的游玩
实现该用户需求的功能	设计个人信息界面。设计规则构建界面。设计对局界面。设计房间交互界面。

场景一、用户系统

用户可以进行如下的基本用户系统操作：

• 注册
• 登录
• 修改用户基本信息：密码、用户名

场景二、房间交互系统

用户可与进行如下与房间有关的操作：

• 创建房间
• 根据房间号加入房间
• 进入房间后，设置/取消准备状态
• 对于房主，在所有玩家准备好后，开始游戏

场景三、对局界面

在房间中所有玩家准备好，且房主点击开始游戏后，所有玩家会正式进入对局界面。

• 对局界面中，可以进行出牌/不出牌操作。
• 可以查看其他玩家的名称、剩余牌数状态。
• 在对局结束后，会显示玩家的输赢结算结果。

场景四、自定义规则构建

用户可以在“创作中心”页面，访问规则构建系统，进行：

• 已有自定义规则的管理
• 新自定义规则的构建

场景五、举报

在发现规则存在违规内容，或玩家出现不友好行为时，用户可通过平台的举报窗口提交举报请求。

平台管理员

规则审核

对于申请上架规则市场的规则，平台管理员可对其进行规则审核。

规则审核包括:

• 在规则市场的规则介绍页
• 点击“可视化预览”，可查看待审核规则的内部逻辑实现，以及其自定义背景/牌面

用户举报审核

对于用户提交的举报请求，平台管理员可以在“举报审核”页面，对举报请求进行处理，并对涉及的违规规则进行下架，或对违规用户进行封禁。

杀手级功能

1. 有一套高自由度的组件仓库，可供用户基于图形化编程，自由进行自定义规则的构建。
   

2. 平台可以直接通过公网访问，在Web端进行联机游玩，无需App。

3. 为自定义规则提供规则市场。开发者可以向平台内所有用户分享自己构建的新规则，用户亦可依赖用户创建内容，进行自定义规则的游玩。
   

对功能的评价

通过收集用户评价，以及组内各位开发同学的意见，我们总结出了以下对功能的评价：

• 图形化自定义规则构建，确实能够完成自定义规则的构建；但规则组件过于原子化，具备上手难度，开发过程也显繁琐
• 对局历史回放这一点具有相当的新意，现有对局平台少有提供此功能
• 规则市场上对于常见规则的支持依靠第三方创作者，缺少具备吸引力规则的现状需要吸引开发者前来来进行改善。

软件工程质量

对于项目文档：

• 在选题完成后，编写了需求文档
• 对于自定义规则系统的图形化语言编写了设计文档
• 对于前后端通信使用的 JSON 格式亦编写了说明文档
• 对于图形化语言，编写了使用文档和简易的示例教程。

对于测试：

• 在前/后端开发进度跟进后，负责测试的同学同步跟进编写单元测试，单元测试覆盖率达60%。
• 除单元测试外，测试同学亦通过实际使用样例，对功能进行了验证。
• 测试对于平台各功能均有覆盖。

对于运维：

• 采用了CI/CD，实时将开发仓库主分支的代码部署至服务端
• 理由：自动化部署，减轻运维压力

宣发和用户统计

受限于本项目组在服务器上的有限预算，且本项目基于网络平台进行游玩的特性，我们仅在身边可触及的宿舍群内，进行了小规模的宣发与公共测试。

在我们的宣发范围内，我们预计的理想日活用户数量为25_{30人。在一段时间的运营后（自6月10日开始宣发记起），日活数量为3}4人，留存率较低。

综合下来，我们认为上述用户活动的成因如下：

• 本平台提供的图形化规则构建，即使在提供了充足的教程文档的前提下，其使用仍具有一定门槛
• 平台目前于规则市场上提供的可用游戏规则有限
• 受限于本平台当前部署的服务器资源，我们平台的宣发范围有限；在宣发范围扩大后，用户数量相信会有上升。

整个团队所得的经验

回顾整个开发流程，我们大致得出了以下三点经验：

• 项目开发进度应即时跟进，在出现某位同学难以完成所负责部分的开发的情况下，就应及时调整人手前去支援，这样才不至于项目进度受到影响
• 在实际开发前，如果各部分功能存在耦合，则必须在事前使用接口文档等方式，确定好各部分如何协同，以避免各部分开发进度相互制约
• 人手分工在一开始就严格确定并不是好事。由于职责不同，在项目进度推进过程中，负责各部分的同学必然存在工作量不同的问题，此时灵活调配人手，对于软工课程这一背景下的小型团队可能是更好的选择。我们在开发过程中确实这么做了，将负责测试的两位同学也加入了前后端的开发中。