[T.18] BattleByte: Beta 阶段项目总结

HelloWorld 2024-06-30 22:51:32

设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们网站希望解决的是中小学编程教育缺乏游戏性这一问题。我们的Beta阶段再次认真分析了用户需求，典型用户变为了中小学电脑课的同学，有之前的报告中清晰的描述。我们也根据典型用户和典型场景设计了我们的功能。

我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)

任务功能	已完成	未完成原因
设计游戏	√

单元测试	√

修改游戏主页	√

增加展开的好友列表	√

私聊功能	×	不是典型应用环境的杀手功能，下一次例会时后续修改典型用户场景后修改为其他
组队匹配功能	√

端口隐藏	√

密码取消明文保存	×	时间成本不够
增加rating功能	√

根据rating进行匹配	√

增加大逃杀模式	√

增加人机玩家	×	不是典型应用环境的杀手功能，下一次例会时修改典型用户场景后修改为其他
通知	√

题目更新	√

除此之外，我们进一步实现了

任务功能	添加原因
页面美化	中小学生典型用户的要求
游戏音效	中小学生典型用户的要求
Alpha阶段游戏页面完善和增加信息量	提升软件质量
房间相关功能（创建、开始游戏等）	中小学生电脑课典型用户场景的要求
好友实时通知功能	中小学生电脑课典型用户场景（房间邀请）的要求
实时添加好友功能	中小学生电脑课典型用户场景的要求
docker部署	提升软件可移植性

相比原计划略晚了一会，主要是软件开发工程量较大。
用户量基本达到目标，在Beta版本后累积152名用户。

和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

提升了，比如功能性更完善了；多线程和单元测试使得可靠性提升了，关键代码覆盖率都接近一百，具体可以查看之前的测试结果；软件的设计使得易用性进一步提升；docker实现可移植性。
大部分通过肉眼和实际体验衡量，测试可以通过测试结果衡量。

用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量没找到合适的中小学生进行普及，但大学生用户量150+还是让我感觉不错的。并且由于在线匹配的局限性，每一局比赛都来之不易，这个数量也是令我们满意的。且从Beta阶段反馈来看，我们的杀手级功能还是让大家感觉蛮有意思的，实现了我们最初顶下的游戏性的设计。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

需求分析非常重要！Alpha阶段稍微有点四不像的感觉，把用户群体放的太大了。后面开发过程发现存在一定的矛盾，经过团队分析缩小了我们的用户群体，我们的开发方向变得更准确。这个问题意识的稍微有点晚了，导致我们与Beta阶段最初的计划有点不同，但总体来说更具备针对性了。

计划

**是否有充足的时间来做计划? **

在Beta阶段在Alpha阶段上做迭代开发，但由于我们的目标用户群体变更导致一些需求发生变化，我们团队结合用户的反馈意见和Alpha阶段的总结，通过线下例会确定项目计划与任务分工，保证项目开发的正常进行。整体做计划的时间充足，开发阶段的计划是两天一次的组会形式开展的。

团队在计划阶段是如何解决同事们对于计划的不同意见的？

通过在每日例会上进行讨论，每个同学都可以表述自己的观点和看法，最终选择大多数人或者所有人可以接受的方案。我们讨论时会涉及到工作量和实现难度以及相应的技术栈上，也会考虑到计划对于核心功能实现的影响

你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

有一些计划的工作并没有完成，例如：增加人机玩家以及玩家之间的私聊功能，由于这些功能不是杀手级功能，而且考虑到技术难度以及时间问题，最终我们团队没有选择开发这些功能。

有没有发现你做了一些事后看来没必要或没多大价值的事?

无

是否每一项任务都有清楚定义和衡量的交付件?

是的，每一项任务都有清楚定义以及衡量的交付件。通过github的issue和语雀文档来实现。具体而言，前端主要交付具有相应功能的界面，后端是提供前端所需要的接口，以及题目上传到OJ，验证题目等。

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

在项目推进的过程中，我们讨论发现如果用户群体缩小到中小学电脑课的同学会更加契合我们的功能。所以在Beta阶段我们更改了目标用户群体，并针对新的目标用户群体的需求设计实现对应的功能。

在计划中有没有留下缓冲区，缓冲区有作用么?

在计划中有留下缓冲区，并且为了留有缓冲区，我们团队选择在开发周前提前进行开发。缓冲区为我们最后修复bug以及测试留有了时间，保证在发布ddl前完整实现我们的产品。

将来的计划会做什么修改？（例如：缓冲区的定义，加班）

对于将来的计划，任务一定要清晰具体并配有预计耗费的工作时间，一定要有截止时间。（加班是不可能加班的！）

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

把计划的时间提前，再多留出来一些时间用来增加缓冲区和开发时间。并且在最初设定计划的时候就让任务清晰具体，不要在开发过程中临时增减设计需求。

资源

我们有足够的资源来完成各项任务么?

资源包括项目所需的人力、时间和技术资源是否足够支持项目的各个阶段和任务。在项目启动前，需要进行资源规划和评估，确保有足够的开发人员、测试人员、项目经理等角色参与，并且他们的时间可以充分分配到项目中。如果资源不足，可能需要重新评估时间表或增加资源投入。

各项任务所需的时间和其他资源是如何估计的，精度如何?

根据以往开发的经验进行的估计，精度以小时作为误差单位，事实证明精度不高。我们认为可以采用敏捷开发中的迭代和调整策略，根据实际进展进行资源分配的调整和优化。

**测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? **

足够。测试过程确保测试环境与生产环境尽可能接近，以便更真实地模拟用户使用场景。硬件资源如服务器、数据库等也需要充足以支持性能测试和负载测试等。对于那些不需要编程的资源有低估难度。美工和文案确实不是容易的事情。

你有没有感到你做的事情可以让别人来做（更有效率）?

我们认为这种情况可能出现在以下几个方面：

非核心技术任务：有些任务可能并非我的专长领域，例如某些特定的设计工作或文案撰写。如果有专门的团队或个人能够更快更好地完成这些任务，那么将这些任务分配给他们可以提高整体效率。
大规模的重复性任务：有时候可能会遇到需要大规模重复执行的任务，例如数据输入或简单的重复性测试。这种情况下，如果有自动化工具或者其他团队成员可以帮助处理这些任务，可以显著提高效率。比如增减题目。
紧急情况或高优先级任务：在项目进行过程中，有时会有突发情况或者需要立即处理的高优先级任务。如果有其他团队成员可以立即投入并解决问题，那么将任务交给他们可以更快速地应对紧急情况。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

我们会更加注重开发环境与步数环境的区别，多做测试，避免环境改变导致程序无法正常运行；在项目启动阶段确保需求尽可能清晰和稳定。采用敏捷开发方法时，建立良好的需求管理和变更控制机制，以便及时调整和反馈；加强测试，推广自动化测试以提升覆盖率和效率。

变更管理

每个相关的员工都及时知道了变更的消息?

是，我们利用微信群，Github邮件和线下集中开发的方式保证每个队员都及时了解各项变更要求。

我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们主要采用集体讨论，明确需求和面向人群的方式决定了“必须实现的功能”有大逃杀模式，可以“推迟”的功能包括排名，积分等机制。

项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有清晰的定义，我们在Beta阶段的出口条件是单人模式，大逃杀模式和个人中心功能的正常运行。

对于可能的变更是否能制定应急计划?

能，我们的人员分工比较灵活自由，有一位自由人，在特殊的情况下，可以另分人手去解决应急的情况，并且我们会在微信群即时沟通，如果线上效率较低，我们会直接线下开紧急会议讨论应急计划。

员工是否能够有效地处理意料之外的工作请求？

是，我们组的线下集中开发和线上及时沟通能够有效保证当一个人遇到问题时全组成员或者前端，后端人员分别讨论，这样能够较有效地解决意料之外的工作请求。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
大家一起当面开会的解决问题效率是最高的。如果重来一遍，在时间充裕的条件下还会尽量选择当面开会开发。

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

每轮迭代，整体功能由大家在项目开发第一天的会议上讨论确定；细节接口设计部分由前后端相应模块负责人商量共同设计；界面设计部分由前端各模块负责人自行设计并实现（有时重要内容也在会议上讨论）。在我们的实践中，给定功能需求，由各模块负责人自行设计，是一种比较高效的实行策略。前端由于界面由多人设计，一开始存在界面风格不统一的问题，后来经过讨论和重新编码解决。

设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有遇到过。例如房间的具体人数是多少，题目的tag如何分类等。由涉及到的相关模块的同学共同讨论确定。

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

团队一开始没有运用单元测试，仅仅部署了集成部署CD工具，方便代码新版本的快速上线。后来由于网络问题，后端的CD经常耗时过长，前端受影响较小。没有使用UML。

**什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况? **

ALPHA版本上线时，首页的实时在线人数模块由于负载过大，导致服务器宕机。设计开发时对当时该模块所采用的技术（轮询）缺乏了解，估计不当，结果占据了比想象中多得多的资源。

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

严格执行了提交规范，必须新建功能性分支pr合并到主分支。1人pr，2人同意才能通过。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们会更早地部署更有效的CI/CD，为开发加速护航，并采用HTTPS、MD5密码等方式，增强网络安全。此外，我们还会做更加充分的调研，了解需求，会在设计前提前规划好基本的功能和实现方式，尽量避免在开发时重构代码以增加需求。此外，我们会更精准地估计实现某功能需要花费的时间，做好充足准备，避免因为花费时间超出预期而熬夜赶工。

测试/发布

团队是否有一个测试计划？为什么没有？

有

** 是否进行了正式的验收测试？**

是的

** 团队是否有测试工具来帮助测试？**

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
后端使用junit对controller层http请求和websocket请求进行单元测试。

http请求使用MockMvc模拟请求并采用数据库回滚方式对好友请求相关，游戏相关，广播消息和私聊消息相关，oj评测相关，房间相关以及登录注册相关功能进行多次测试。
websocket请求本地建立客户端类，模拟多个客户端实现多线程模拟请求，测试单人模式匹配请求，局内聊天请求，番茄道具功能，大逃杀，房间内开启游戏以及提交答案等多人相关功能以及个人登录，光标移动等个人相关功能。

** 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？**

我们认为团队代码的软件工程质量较好。衡量代码质量的指标如下：

代码质量指标：包括代码复杂度、代码覆盖率、bug 数量等。
用户满意度：通过收集用户的反馈和评论，了解他们对程序的整体体验和满意度。
性能指标：包括响应时间、吞吐量、资源利用率等

使用 apache bench 模拟 3500 路并发，15000个请求获取较大资源

请求平均等待时间34秒
服务器平均处理时间0.009秒

** 在发布的过程中发现了哪些意外问题？**

由于不同电脑分辨率原因，部分用户由于电脑的不同导致进入房间无法看到退出房间，查看题目和开始游戏按钮。
注册时未检测密码是否进行输入，密码长度可能为0。
密码不正确也可以登录。
在进入房间时，未开始游戏但生涯数据添加，重新登录后生涯数据未显示。

我们学到了什么? 如果重来一遍, 我们会做什么改进?

在Beta阶段，整个团队通过项目的持续推进和迭代优化，积累了宝贵的经验和教训。继承了Alpha阶段的合作模式，后端每个人负责一项技术的专攻，前端每个人负责一个模块的前端，然后两两合作。这种模式在Beta阶段继续执行并取得了显著成效，确保了项目的高效推进和各模块的稳定发展。针对Alpha阶段发布时出现的资源不足问题，团队对多线程高并发进行了重点优化和改进。在Beta阶段分配专门的测试人员进行了更为全面的压力测试，确保了系统在高并发情况下的稳定性。同时，引入了更多题目和大逃杀模式，增加了游戏的多样性和可玩性。特别是新道具的引入，不仅丰富了游戏内容，还为玩家提供了更多的策略选择。在Beta阶段，团队高度重视用户反馈，及时根据玩家的建议进行调整和优化，确保游戏体验的持续提升。
经验教训：尽管在本地进行了十多个账号的测试，但未能完全模拟真实环境下的资源需求，导致首次发布时因资源不足出现bug。Beta阶段教训深刻，即在测试中需要尽可能模拟真实场景，特别是高并发和资源消耗的测试。软件开发是一个持续改进的过程，Alpha和Beta阶段的迭代优化证明了不断修正和完善的重要性。每次迭代都应基于前一阶段的经验教训，进行有针对性的改进。

团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？

团队角色基本上依据个人对技术栈的掌握程度、个人的对相关技术与模块的了解、个人的趋向与爱好等因素进行确定。

**团队成员之间有互相帮助么？ **

有互相帮助。在遇到各种问题时，向组内懂这个问题的同学请求帮助相对而言比较方便。

当出现项目管理、合作方面的问题时，团队成员如何解决问题？

主要是有关开发者对于这个问题进行团队讨论，协商出一个较好的结果。

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

CMMI 三级，我们现在有一套完整的管理措施和标准流程。每个功能开发后都有相应的措施去合并管理，但是还达不到四级的量化粒度，所以处于三级。

**你觉得团队在这个里程碑相比前一个里程碑有什么改进? **

HelloWorld团队目前属于规范阶段，我们有较流畅的合作模式，但是相比于创作阶段中的高度自治和根据项目要求自然转换可能还没到那个水平。

你觉得目前最需要改进的一个方面是什么?

细化任务分配的粒度，最好能有合理的量化标准。
软件的安全性需要提升

**对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。 **

原则一：我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
我们尽早地完成了Alpha阶段的最小可用产品，并在发布以后解决了若干用户提出的bug。
原则三：经常性地交付可工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好
我们将在三周后交付Beta阶段版本软件
原则四：在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
在团队的大部分开发时间里，我们都是面对面一起进行迭代，虽然没有全部，但已经尽我们所能
原则六：在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
我们所有例会都是面对面进行的

正如我们前面提到的，软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？

提高代码管理质量：
- 删除重复代码，提取可复用代码
- 进行单元测试和集成测试
提高复审和代码规范的质量：
- 多人审核PR
- 增加注释

整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？

团队讨论并搜索好的架构资料
文档化
对于特别复杂的架构进行重构（将大函数拆分为小函数，将大类拆分为小类，减少类和函数之间的耦合，移除重复的代码）
衡量质量提高：
- 代码质量指标：包括代码复杂度、代码覆盖率、bug 数量等。
- 用户满意度：通过收集用户的反馈和评论，了解他们对程序的整体体验和满意度。
- 性能指标：包括响应时间、吞吐量、资源利用率等