[T.19] 团队项目：Beta 阶段项目总结

项目 内容
这个作业属于哪个课程 课程社区
这个作业的要求在哪里 作业要求
我在这个课程的目标是 凝聚整个团队通过一定的软件开发流程，在预计时间内发布"足够好"的符合用户需求的软件，并证明其是可维护和持续发展的，并在其中做出应有的贡献，提升进行软件工程开发的能力。
这个作业在哪个具体方面帮助我实现目标 事后分析总结，总结团队在开发过程中遇到困难时克服的经验以及收获的成长经历，为后续的实际软件开发工作总结经验。

设想和目标

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

我们的软件，旨在解决卡牌自定义规则无法线上游玩，以及开发门槛高的问题。

这是一个明确的问题定义。

我们在选题时，已经明确了三类用户，及其典型的场景：

  • 平台管理员：负责审核上架到平台上的规则，以及处理用户的举报。
  • 规则开发者：负责开发平台上可游玩的自定义卡牌规则。
  • 玩家：负责在平台上玩。
  1. 我们达到目标了么(原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

在功能实现方面，我们按时完成了开题时预期的所有功能：

  • 图形化规则构建
  • 对局系统
  • 规则市场
  • 对局回放
  • 管理功能：规则审核、举报系统

唯受可用的服务器资源所限，该平台于课程阶段无法支撑较大流量的访问，并没能达到预期的用户数量。

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

与上一个阶段相比，软件工程质量维持稳定。

如果说有改进的话：

  • 在本阶段内，我们在分工上配置更为合理，将上一阶段任务分配较少的两位负责测试的同学也加入了前后端开发中。
  • 我们在本阶段沟通项目进度更及时，确保了项目的如期交付。
  1. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

再次，受可用的服务器资源所限，该平台于课程阶段无法支撑较大流量的访问，并没能达到预期的用户数量。

对于图形化规则构建这一重点功能，用户反馈与我们的预期一致。该功能确降低了此类规则的开发门槛，但出于其组件原子化的特性，这套构建系统仍然具有学习成本，且使用较为不便。

自搭建出一个可以构建自定义卡牌规则，并联机游玩的这个目标而言，我们确实离其更近了。

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

选题的时候，还是要充分考虑选题难度的，对项目进展还是尽可能悲观的好。

历史重来一遍的话，我们可能会考虑换一个更容易实现的选题（笑）

计划

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

有。我们在选题时，就已经通过多次会议，确定好了我们的选题，要实现的功能，以及各个阶段需要实现的功能。

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

有两种方式：

  • 协商。通过协调组内各位同学的意见，得到大家都同意的方案。
  • 由一位有决定权的人拍板决定。在本门课程的场景下，这个人是PM。
  1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

是的，工作都做完了。

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

每两天把所有人拉起来开 Scrum Meeting。

且不论把所有人聚在一起，协调共同的时间、地点所需的精力，本项目的PM还发现：

  • 频繁的 Scrum Meeting，组员的情绪普遍是不乐意；此外，开会过程中，显著注意到组员处于汇报进度的高压状态，这并不利于组员之间的相互协作。
  • 每次开会，都会占据至少40min的时间。按每周至少3次而言，每周我们就需要浪费两小时以上，仅仅用于开会对进度；有这时间，项目的简单功能都已经实现了。沟通进度？发一条短信 / 在 Github repo 上看 Commit 就能问到，何苦把所有人都聚一块轮流汇报？
  1. 是否每一项任务都有清楚定义和衡量的交付件?

有。

对于前端开发，交付件就是前端网页；对于后端开发，交付件就是后端服务逻辑；对于测试开发，交付件就是单元测试；对于运维，就是服务端的稳定部署；对于PM，就是各项文档。

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

整体而言是按计划进行的，意外基本出现在 Alpha 阶段：

  • 规则执行引擎的开发进度滞后，这是包括规则执行引擎在内的后端开发，当时仅由一位开发同学负责，且其进度沟通不积极导致的；
  • 申请的域名无法备案，政策规定个人无法申请在线游戏平台有关的域名。

对于第一点，这是我们对于开发任务工作量估计过于乐观，且不强制要求沟通进度引起的。在 Beta 阶段，我们通过在后端加入更多人手，且要求组员及时沟通进度解决了这一问题。

对于第二点，这是我们对于有关政策文件考虑不周导致的。

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

有。Alpha 和 Beta 阶段我们都留了最后一周作为缓冲。

是有用的，我们事实上在两个阶段的最后一周，都在处理尚未完成的任务。

缓冲区可以理解成，用于防止计划不及预期的，而灵活分配的一段保险时间。

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

可能的修改是，缓冲区不再是用于保险，而是用于做更详尽的测试。

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

学到的是“计划不如变化快”。一开始充分的计划，在后面实施的时候难免会出变数，不留足用于灵活变通的时间，对于项目的实施是非常危险的事情。

历史重来一遍的话，开发进度里面留的缓存区应该留大一点。

资源

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

时间而言略为局促，我们在开题时事实上低估了实现一套图形化编程语言及其执行器的难度。

人力而言是足够的。

硬件资源方面，我们可用的服务器资源相当有限，以至于我们的发布范围只能限制于较小范围。

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

通过开题时，PM和组员集体讨论决定。

对于简单的功能，比如用户系统等，这部分的估计是精确的；而对于图形化规则构建这一部分的估计，我们均低估了其难度和开发所需时间。

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

测试时间因为开发时间占比高，事实上做得相当局促。

对于测试和开发而言，人力是足够的。

硬件资源，再次，我们可用的服务器资源相当有限。

不需编程部分的资源，我们在本项目中涉及较少，故没有低估其难度。

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

自团队整体而言，这个问题并没有出现。

硬要说的话，本项目的具体实现接口是由PM确定的，这一部分如果交给前后端的同学做决定可能会更高效。

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

经验教训是，给定有限的人力资源，做好分工是比较重要的。在 Alpha 阶段，我们将后端开发仅交予一人进行，这导致了我们于那一阶段的开发迟缓。

历史重来一遍的话，也就是把分工在一开始就设计成一个合理的状况。

变更管理

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

是。有 Merge 都会在项目群中转告其他组员。

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

按功能优先级排序。举例而言，我们的图形化规则构建作为核心功能，其优先级最高。其他诸如规则回放的附加功能，优先级较低，被放在了 Beta 阶段。

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

有。定义可以认为是：

  • 在前端，能够按预期设计展示交互逻辑
  • 在后端，能够执行预期的逻辑
  • 在测试，能够通过所有预期的单元测试
  1. 对于可能的变更是否能制定应急计划?

事实上，我们的项目在开题的时候就把各阶段的任务规划做好了，包括其分工和开始、截止时间，对于应急计划的应变能力相当有限。

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

再次，因为我们倾向于事前完全做规划，且我们的开发计划相当紧凑，员工处理意料之外的工作请求的能力有限。

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

再次，“计划不如变化快”。再来一次的话，我们一开始就不会把计划写得那么细，而是每隔几天开会的时候灵活调整。

设计/实现

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

功能设计由PM在开题时，结合会议上各组员意见完成。

前端、后端的具体设计交由前、后端的开发人员自行决定，PM只参与了部分API的确定。

设计的时间是合理的，负责设计的人也基本合理。

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

有。比如前后端如何交互。

团队通过由PM确定统一方案来解决此类问题。

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

团队运用了单元测试，来保证项目的实现符合预期。

单元测试确实帮助我们发现了一些 Bug，是有用的。

我们并没有使用UML。如果就其他设计文档而言，项目一开始的文档就现在的状态而言，少了一部分新增功能，以及部分边界条件的考虑。开发过程中，我们也确实对其进行了更新。

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

用于对局的规则执行引擎产生的 Bug 最多。

其原因大概有：

  • 逻辑自身相当复杂，其不仅需要负责规则本身的执行，还需要负责与客户端的网络通信
  • 这一部分的开发进度事实上较慢，留给测试的时间较少
  • 初期开发人手不足，后端仅一位同学负责

发布后未发现重大 Bug。

未想到这些情况的原因，是因为我们对于自定义规则执行引擎开发所需的工作量过于乐观。

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

代码复审通过在关闭 Issue，由审核者在 Merge 前统一检查来进行。

执行了简单的代码规范。

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

我们学到了，事先做好计划对开发工作是有好处的，至少我们在开发过程中没有出现任何将已有功能计划推倒重来的情况。

历史重来一遍的话，这一部分的执行我认为很好，没有进一步改进的空间。

测试/发布

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

有。具体而言，在每个功能实现完成后，负责测试的同学就对应编写单元测试。

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

有。在开发完成后，我们对所有功能都进行了简单的测试，确保其行为符合预期。

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

    很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

我们利用编写单元测试 + Github Actions的 CI/CD 方式来辅助测试。

对于低效率手动测试的改进计划：

  • 引入单元测试。
  • 部署基于单元测试的CI/CD流程。
  1. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

我们主要对我们项目进行功能测试，压力测试主要在于组内多个成员同时开房间游玩这一情况进行。

这一测试发现了我们的平台受服务器制约，无法支撑大规模玩家同时进行游玩的问题。

后续改进也只能是想办法更换更好的服务器资源。

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

邮件系统再次失效。后发现是SMTP配置有问题，后续已修正。

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

我们学到了，测试时间要留足，在开发完成后永远应该假设程序有 Bug。

历史重来一遍，会多留用来测试的时间。

团队的角色，管理，合作

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

团队角色通过在项目开题时，各位毛遂自荐，并结合自己学期内可用的时间来确定。

确实做到了人尽其才，各部分的负责的同学，均有各自负责部分的开发经验。

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

有。

举例而言，在 Alpha 阶段的最后两周，负责后端的同学汇报进度难以完成，我们组内有空的同学均参与了剩余未完成工作的开发。

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

在 Scrum Meeting 上面直接指出问题怎么解决，期间可能有PM的协调。

每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

  • 彭子峻：感谢田锦煜同学在 Beta 阶段，承担了大部分功能开发工作的努力！
  • 王梓恒：感谢彭子峻同学在代表团队进行汇报时所做出的努力以及精彩演讲！
  • 田锦煜：我感谢陈耕同学能够就在这里不躲、不藏 、不绕、不逃，稳稳地接住每一个开发工作的测试任务
  • 邓志航：感谢王梓恒同学对项目的整体部署与维护，让平台能够在网络中有一席之地
  • 陈耕：我感谢田锦煜同学能够始终在这里不推、不怨、不拖、不闪，稳稳地搞定每一个紧急需求的功能开发。
  • 王靖茹：我感谢王梓恒同学积极组织会议对齐大家的进度，让项目以可预知的速度推进。
  • 李奕宽：我感谢彭子峻对项目的设计。包括WebSocket 方案中的连接管理、心跳机制、异常重连等；以及规则构建方案中的规则链编排、优先级设计、业务与执行引擎解耦等。

总结

  • 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

可重复级。

  • 有代码规范、评审记录和构建脚本，建立了基本的管理流程。

  • 管理与工程过程在部分情况仍有脱离文档，直接口头/人为干预的情况，因而需要进一步完善。

  • 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

规范阶段。协作工具链、流程等都已确定，能够维持稳定产出。

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

在进度交流方面更流畅，从而允许更灵活的分工，保证任务及时完成。

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

团队追DDL的能力。事实上，我们在 Alpha 和 Beta 阶段都是卡点完成任务。

要解决这个问题的话，可能就需要把DDL划得更细一点，分功能设置最晚期限。

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

做得最好的两个原则：

  1. “可工作的软件是衡量进度的主要标准”
  • 事例：我们尽可能减少了不必要的文档说明，将大部分时间直接用于代码编写。
  1. “团队定期反思如何提高效率”

  • 事例：在 Scrum Meeting 和 Alpha 阶段结束时，我们会核对过去几天的进度如何，并对应反思原因，并对分工等进行了相应的调整。

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

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

对于上述两个问题，有以下几种办法：

  • 初始设计：使用UML等工具，在实际编码前辅助建模实现框架
  • 测试：单元测试覆盖率必须达到某个预设值（比如说，75%），才允许被合并入主分支
  • 交叉验证：负责开发的人员，相互检查编写的代码是否符合预期的代码规范。
  1. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

给出架构设计，及其背后思路的说明，这样后人才可以在此基础上继续迭代。这个说明的形式，可以是文档，也可以是UML图。

重构的思路，自然是需要现在已知的 Bug 有什么，现在的性能瓶颈在哪，这样才能对症下药。要衡量是否提高也很简单：

  • Bug 是否被解决？
  • 性能提升了多少百分比？
  • 单元测试覆盖率有多少？
  1. 其它软件工具的应用，应该如何提高？

我们现在使用了“微信”、“飞书”这两个”其他软件工具“，旨在服务我们的项目管理和进度追踪。

这引起的问题是，进度交流并不处在统一平台上。后续应考虑统一迁移到飞书这一平台上进行沟通。

  1. 项目管理有哪些具体的提高？

首先，通过部署CI/CD流程，我们整个开发、测试流程都趋于规范化。其次，我们逐渐注意到了进度追踪的重要性。

  1. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

我们目前基于云服务平台提供的访问数据，来跟踪用户使用情况。这存在一个问题，即流量统计与我们的用户系统分离。日后可考虑在我们的项目中整合流量统计模块，并将其与用户系统关联起来。

  1. 项目文档的质量如何提高？

首先是减少不必要的文档需求。 为了完成要求写出的文档，只可能为了应付要求而敷衍了事。

其次，对于API等影响具体开发行为的文档，应有统一的格式要求，并显式要求说明其功能与行为。

  1. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
  • 可以引入更多维的考核和奖励机制。例如，对于我们当前组员人数少的情况，可以鼓励项目组成员在闲暇时帮助其他组员完成开发工作。
  • 建立一个安全的氛围，减少组员压力，而不是以频繁开会/查询进度的方式推进项目进行。
  1. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

我们感受最深的是“没有银弹”。这反映在我们的整个选题上。

选题之初，我们希望是构建一套基于图形化语言的自定义规则构建系统。其客观上确实免去了规则开发者需要学习计算机编程语言的门槛，但他又引起了学习我们这一套图形化语言的学习门槛。此外，这套语言的组件原子化相当高，使用起来远提不上好用。

  • 发布博客时，要附上全组讨论的照片。
    讨论照片
posted @ 2026-06-20 10:32  ISET  阅读(1)  评论(0)    收藏  举报