Compilify Beta阶段事后分析

设想和目标

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

   《编译技术》是计算机学院开设的一门核心专业课程。课程参与者为教师、助教和学生。我们的编译课程平台需要提供课程管理、用户管理、课程通知管理、课程资料管理、作业管理、评测作业等功能。除了这些基本功能之外，由于《编译技术》课程实验存在其特殊性，课程平台还需要更好的满足这些特殊需求，例如对同一作业，学生用户需要选择提交类型，再如竞速排序作业等。

   目前《编译技术》课程采用的平台是希冀 judge 平台，这是一个全课程通用平台，并不能很好的适配当前编译技术课程设计实验的需求，例如存在服务器资源紧张，llvm版本不对，评测文件设置受限，作业提交和竞速排序展示对用户不友好等问题。我们的平台旨在做好课程平台基本功能并解决旧平台的这些问题，提供一个更符合《编译技术》课程需求的专用平台。

   在 Alpha 阶段，我们完成了公告、作业评测、资源、个人中心、课程及用户管理等核心功能。Beta 阶段则着眼于优化用户体验，完成讨论区、通知、教程、成绩分析功能，并重构了评测功能使其更加稳定，评测记录给出的信息更加详细，教程中添加了 AI 辅助问答功能。

   在 Alpha 和 Beta 阶段功能规格说明书中，我们对平台在 Alpha 和 Beta 功能需要实现的功能做出了定义并给出了原型设计。

   同时，在功能规格说明书中，我们对典型用户和典型场景进行了详细的说明。随后又在Alpha 和 Beta 阶段软件发布声明中进行了进一步细化。

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

   我们基本达到目标

   Beta 阶段原计划的功能基本完成，并按照计划时间进行发布。

   • 讨论区功能（完成）
   • 通知功能功能（完成）
   • 教程功能（完成）
   • AI对话功能（完成）
   • 竞速排序功能（完成）
   • 评测和评测管理重构（完成）
   • 成绩分析功能（完成）

   在日活用户量方面，达到 Beta 阶段预期数量。

   截至6月10日晚，用户交流群已累计达到126人。现平台共有5个管理员账号和79个学生账号，共84名用户。

   通过docker的log文件统计，截止6月10日21:28，用户已经完成121次登录，API访问4440次，提交评测331次

   截止6月10日21:28，Compilify-beta用户交流群已有126人（其中7人为团队成员）

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

   有提高。

   对于前端，我们规定了前端使用的色卡，统一了页面的风格，在按钮、弹窗使用等方面制定了详细的规则。

   对于后端，我们重构了评测机，相比 Alpha 阶段，评测机更稳定，支持更多的异常处理，可配置程度更高。

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

   在用户满意度调查中，大部分同学对于 Compilify 平台的页面风格，易用性，评测流程反馈，资源下载等方面给出了5分好评。调查结果如下。

   	平均分
   对于 Compilify 平台整体的评价	4.93
   对于整体页面风格的满意程度	4.79
   对于系统易用性的满意程度	4.86
   对于评测流程及反馈的满意程度	4.93
   对于查看公告、作业要求、资源下载的满意程度	4.79
   对于小测功能的满意程度	4.86
   对于讨论区的满意程度	4.93
   对于教程指导书的满意程度	4.86
   对于教程AI的满意程度	4.57
   对于即时通知的满意程度	4.79

   

   大部分用户认为我们的平台体验较好。有部分用户对于 AI 提问表示希望增加每日限额。还有部分用户认为 markdown 渲染器有时渲染不正常，推测可能和插件本身有关。

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

   • 要重视鉴权和安全问题。由于团队中没有对网安相对较熟悉的同学，Alpha阶段出现的比较严重的问题均为安全问题
   • 线下对接能够增加效率，在开发的关键阶段应该增加线下对接的次数，通常能够较快的发现问题并且当场解决
   • 要多和用户交流，明确需求，避免在开发的过程当中重构
   • 制定 API 时最好前后端一起商量，避免后续改动重构

计划

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

   有。在alpha阶段结束后一周内，我们根据最初设计的两次迭代目标，再次细化了beta阶段要实现的功能，分配到了个人并预估了所需时间。在每次例会上，我们也会根据当前的项目进度，以需求为导向，对计划进行动态调整。

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

   在计划阶段，我们依旧采取腾讯会议的形式共同讨论，出现意见冲突则阐明各自的观点，其余人发表自己的见解，最后由PM整理并做出决定。

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

   Mission success！

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

   前端开发前没有对一些组件定义统一的格式，导致开发过程不同组员撰写的代码在后续发现格式不统一问题后产生大量修改/删除，花费不少时间。

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

   有。

   对于任务的定义，前端按照页面列出所需功能，并分为页面UI和对接API两阶段任务；后端按功能划分模块，每个模块中细分接口并使用apifox对类型、参数、返回值等进行定义。

   对于交付件的衡量，前端包括页面UI美观，展现全部功能和完成api对接并通过测试两个条件；后端为对实现接口功能并通过测试。

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

   beta阶段与烤漆部分重叠，导致小组成员的时间被打散，部分线下对接时间被推迟。原因是在计划阶段考表未出，未将烤漆纳入考虑。

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

   对于时间方面，项目测试、发布及稳定的一周为缓冲区。由于Beta阶段冲入烤漆，组员们都有各自繁重的任务以及考试要应对，缓冲区为更灵活的时间调整提供了可能。

   对于人员方面，我们会根据实际进度和工作量动态调整每个人的任务。

8. 将来的计划会做什么修改？

   我们已经完成了项目伊始时设计的全部功能，接下来的主要工作是运维。由于我们开发的compilify平台为编译课程平台，在下个学期的编译课程中投入使用后需要讨论、解决同学们提出的新需求和遇到的问题。因此，将来的计划较为灵活，会持续以需求为导向，更准确的评估工作量与时间，预留缓冲区与提前量。

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

   学到了项目与成员的管理、任务分配、合作分工与沟通对接、资源平衡、突发事件处理等团队合作经验。

   相较于alpha阶段，在beta阶段我们的工作时间更加合理了，计划的实际实现进度上也有了提升。在未来的计划阶段中，我们会做更加详尽的调研，进行更合理的时间评估，预留出缓冲区以应对突发或未考虑到的情况。

资源

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

   在beta阶段，基础的软件和硬件资源基本与alpha阶段相同，除此之外，我们还是用了一些其他的工具来丰富我们平台的功能，比如使用我们自己的电脑作为一台评测机来测试本平台调度多台评测机进行评测时的加锁和通信等功能，比如使用ChatGPT的API来实现智能教程的功能，我们在ChatGPT的API上设置了一些限制，但是总体来讲我们的软硬件资源足已完成各项任务。

   对于时间和人力资源，我们在beta阶段也做了很多的时间规划，通过定期开会协调各个组员的进度；同时在设计需求的时候就考虑要花费的时间，通过过程管理控制进度，最终在有限的时间内完成了beta阶段开始时的需求。

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

   在beta阶段，我们的任务主要是添加新的功能，以及对之前功能的一些改进。

   对于这两种任务，我们从之前的开发经验出发，对于新的功能可能会需要一些调研的时间，对于之前功能的改进可以结合alpha阶段的开发进行估计，从而更加精确地估计所需时间，有了alpha阶段的经验估计用时相对来说较为容易。

   对于资源估计，我们估计了发布后的使用规模，从而对beta阶段新引入的功能设计合适的限额，当然发布后也受到了一些反馈表示ChatGPT限额不够。总体来讲我们对资源的使用较为合理。

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

   除去alpha阶段已经完成了的测试，我们在beta阶段对新开发的功能以及评测机进行了新的测试，我们使用了现有的单元测试框架，基本完成了预先设计的各种测试。对于评测机，我们在进行压力测试时打开了多个评测机，用以测试评测机评测任务调度的效果，各种资源比较充足。

   在beta阶段，前端的风格已经基本确定，主要美工任务在新开发的功能上，相对来讲难度不算大，总体来讲有了alpha阶段的经验难度估计还算合理。

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

   我们在beta阶段基本沿用了alpha阶段的分工，大家对自己负责的部分比较熟悉，因此基本没有出现分工不合适的情况。

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

   对于新功能，要注重开工前的调研，最好准备提前量尽早完成。

变更管理

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

   是的。

   我们的交流主要在微信平台、Notion和组会。在微信上面我们会实现日常的任务交流和共同对接。对于较为重要的任务，我们会在Notion平台上面发布，并微信通知到各位。与此同时，对于个人方面的改动和疑惑，会发布在Notion上面。每次开组会前所有成员需要浏览并完成Notion上面的事宜，组会上面汇报自己的任务完成情况和对于重要改动的沟通。

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

   推迟任务主要由原来的功能负责人对任务向所有人汇报，介绍自己的评估和考量，再由所有组员共同决定。

   必须实现的任务在前期计划中就已经确定，而在后续的开发过程中则根据实际开发的需要由小组讨论进行实现。

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

   功能条件：在用户的产品体验上面，没有出现明显的bug，功能在Beta阶段制定任务上基本完全实现

   测试条件：编写并通过单元测试，并尽可能提高测试覆盖率。同时进行压力测试，主要保证测评机的稳定。

   用户条件：用户使用便捷，没有明显的bug同时保证使用体验良好。

4. 对于可能的变更是否能制定应急计划?员工是否能够有效地处理意料之外的工作请求？

   面对可能的变更我们会紧急召开会议，并且同学之间能随时保持联系。与此同时，我们对任务进行了充分解耦，因此对于任务变更能尽可能的落实到个人，同时也方便与其他人对接。

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

   我们在变更管理上做得还是很好的，能够合理运用GitLab、Notion等平台来管理团队项目。如果再次重来我们会进一步健全管理机制，保证各尽其能，宏观调控每个人的工作量和投入，帮助团队更好地面对挑战。

设计/实现

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

   在beta阶段，设计工作只有数据模型和api的设计，其中一部分在alpha阶段已完成，另一部分在beta第一周内完成。主要由后端开发人员完成，其他人也会帮忙复审。

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

   数据模型和api在设计时遇到过一些困难，比如实体间关系的设计、api功能的划分等，这些困难一般会放在例会上解决，经过大家一起讨论、设计，得到一个最优的解决方案。

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

   团队使用了notion来进行博客、文档的管理，使用了apifox来进行api的设计和管理，使用了go test对后端进行了单元测试，这些工具极大地提高了生产效率。

   现在的文档相较于alpha阶段时的文档进行了很大程度的更新，包括功能规格说明、技术规格说明、数据模型、api、服务器说明等。改动的原因主要是新需求的增加，以及在实现时过程中发现有的设计不合理或是无法满足需求，需要进行一定的调整。

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

   评测功能产生的bug最多，因为这部分逻辑最复杂，需要前后端通信、后端和评测机之间通信，涉及到的技术栈最多，相关的代码量较大。除此之外，刷新token机制在开发过程中也出现了不少bug，主要原因是js语言本身对多个线程的互斥访问和阻塞不能有着很好地支持。

   发布之后暂未出现重要bug，因为主要的安全漏洞已在alpha阶段修复，出现的bug主要是ui相关的一些小bug。

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

   由仓库的Maintainer或Owner在合并merge request时进行代码复审，如果有问题就给出反馈意见，修改后重新提交，再进行合并。代码编写和开发流程基本上严格执行了规范。

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

   在项目开发过程中，设计是很重要的一环，一个好的设计能够减少开发时的难度，提高开发效率。如果重来一遍，我们会在设计上花更多的时间，尽可能避免因为设计上不合理或无法满足需求而进行的修改或重构。

测试/发布

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

   有。团队进行了前端资源访问压力测试、后端API压力测试、评测机扩容测试、评测机压力测试

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

   是。团队将去年编译课程的所有作业部署到现有平台上，进行了验收测试。

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

   有。在开发的过程当中，每次合并分支的时候需要其他成员复审代码，在开发完成之后，编写了单元测试，利用CI的机制自动化进行回归测试。

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

   效能测量和效能跟踪主要是根据gin框架的运行日志、前端资源压测以及后端API压测。压力测试主要是通过apache bench并发测试工具，以及python并发测试脚本进行，具体可见Beta段测试报告

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

   Alpha阶段出现redis未设置密码的问题，代码仓库泄露minio密码的问

   Beta阶段并未发现问题

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

   应当更加注意后端以及数据库的安全问题，注意及时和甲方沟通需求，测试的密度应当增加，不能将所有问题堆积到最后进行

团队的角色，管理，合作

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

   尽量。团队成员分工都是根据自身擅长领域自行选择、动态调整的。

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

   当然。

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

   及时报告问题、沟通寻求解决方案、迅速行动验证解决方案可行性。

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

我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。

总结:

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

   处于可管理级。组织已经实现了基本的项目管理，如需求管理、计划与跟踪、配置管理等。过程有了一定的规范，组织能够重复成功的项目经验。但是，过程的改进和优化仍然有限。

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

   处于创造阶段。成员们相互鼓励，积极提出自己的意见和建议，也对别人提出的意见和建议给出积极评价和迅速反馈。团队的效率达到了颠峰状态，这时最重要的已经不是解决团员之间的矛盾，也不是明确每个团员的职责和任务了，而是要建立团队业绩和个人绩效相结合的考评体系，最大限度地调动团队成员的积极性。

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

   • alpha阶段：对彼此都比较熟悉，沟通成本进一步降低，更加信赖和依赖彼此。
   • beta阶段：对从需求到API到实现的业务流程都更加熟悉、沟通效率更高，可以高效联调，发现和解决问题。

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

   • 团队项目管理对应到issue仍有改进空间。
   • 量化的考核绩效指标仍有待细化。
   • 团队开发文档通过apifox维护，其中异常处理的反馈顺序有待明确。
   • 单元测试有待完善。

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

   1. 个体和互动 高于 流程和工具

      我们没有很关注具体的流程，对于API和具体实现细节不同的部分，小组成员会及时沟通或者查看源代码，而非局限于工具进行信息传输。

      例如我们通常需要先确定开发的具体需求，在开发过程中如果发生了需求变动，按照需求变动时的流程，我们应当先在apifox中修改API，再修改代码，最终修改单元测试。
      实际开发过程中，为了前端能够尽快用上修改后的最新版本，需求改动较少时我们会优先修改代码，再维护相应的API和单元测试。

   2. 响应变化 高于 遵循计划

      我们整体把握计划，但具体执行的过程中精确到每一天、每段时间需要做的事。这样需求产生后可以及时作出调整，而非“计划”作出调整。

   3. 优先提供最小可用产品

      我们在alpha阶段优先完成了能支撑整个作品的最小集，将较复杂的功能更多放到beta阶段开发，因此能够在alpha阶段完成后就可以进行发布，让用户体验前一部分的功能。

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

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

      • 进一步细化代码审核过程，审核通过再merge进主分支。
      • 维护代码开发文档，包括环境配置、遇到的问题、代码规范等。
      • 代码规范的质量可以使用代码风格检查工具、互相审计代码来提高。

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

      明确现在的问题，再思考架构上如何解决这些问题。

      评价指标：各部分之间的耦合度应当充分低、代码复用尽量充分。

   3. 其它软件工具的应用，应该如何提高？

      工具服务于需求，不需要抛开具体应用场景谈工具。

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

      • 应当明确考核绩效指标，提供贡献分的可靠依据。
      • 通过细化issue的方式完成。
      • 可以设计绩效函数，从贡献代码行数、所用时间、提交git次数等多个角度衡量绩效。

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

      没必要吧。产品具有特殊性质，只需要在学期初根据选课名单知道用户总人数，学期中的用户人数不会再发生改变。

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

      • 完善审核机制，PM进一步审核文档。
      • 设置多个文档责任人，让多人多轮检查统一文档。

   7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

      • PM需要关注需求分析、设计、开发、测试、部署等各个阶段，并与相关团队进行有效的沟通和协调。
      • 绩效考核应该是公正、客观的，基于具体的目标和指标，避免主观评价和偏见的影响。同时应当考虑到成员的具体情况，避免过度注意考核指标而产生其他问题。

      改进地方：

      • PM应当更注重和团队成员的点到点对接，注重项目进度的整体把控。有些时候大家时间充裕，PM没有及时组织讨论，导致需求无法尽早明确，一定程度上拖慢了进度。

   8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 ([这个作业的期中阅读](http://www.cnblogs.com/xinz/archive/2012/10/14/2723635.html))

      体会到了敏捷开发的意义。敏捷开发的意义体现在强调灵活性和迅速反应变化的能力。它致力于提供更快、更有效的软件开发方式，更注重实用性，而非严格遵循预定的计划和文档。更重要的是，敏捷开发以人为本，鼓励团队合作和面对面沟通，以提高工作效率并促进问题的快速解决。这些都是我们在开发过程中遵循的一些准则，指导我们能够更好的完成开发工作。

全组讨论截图