Compilify Alpha阶段事后分析

设想和目标

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

    《编译技术》是计算机学院开设的一门核心专业课程。课程参与者为教师、助教和学生。我们的编译课程平台需要提供课程管理、用户管理、课程通知管理、课程资料管理、作业管理、评测作业等功能。除了这些基本功能之外，由于《编译技术》课程实验存在其特殊性，课程平台还需要更好的满足这些特殊需求，例如对同一作业，学生用户需要选择提交类型，再如竞速排序作业等。
   
    目前《编译技术》课程采用的平台是希冀 judge 平台，这是一个全课程通用平台，并不能很好的适配当前编译技术课程设计实验的需求，例如存在服务器资源紧张，llvm版本不对，评测文件设置受限，作业提交和竞速排序展示对用户不友好等问题。我们的平台旨在做好课程平台基本功能并解决旧平台的这些问题，提供一个更符合《编译技术》课程需求的专用平台。
   
    在 Alpha 阶段功能规格说明书中，我们对平台在 Alpha 功能需要实现的功能做出了定义并给出了原型设计。
   
    同时，在功能规格说明书中，我们对典型用户和典型场景进行了详细的说明。随后又在Alpha阶段软件发布声明中进行了进一步细化。
   

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

   我们基本达到目标

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

   • 课程公告功能（完成）
   • 作业管理配置功能（完成）
   • 作业评测功能（完成）
   • 小测功能（完成）
   • 竞速排序功能（时间原因放入 beta 阶段）
   • 课程资源功能（完成）
   • 管理课程、用户、评测功能（完成）

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

   截止5月4日14:32，已经有49人完成登录，API访问1852次，提交评测39次

   截止5月4日20:28，Compilify-alpha用户交流群已有88人（其中7人为团队成员）

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

   该阶段为 Alpha 阶段，无上一阶段，仅介绍本阶段质量管理

   • 代码风格约定：用了软工课程组之前给出的参考规范，后端使用golang常用的代码规范，前端使用eslint+prettier自动化检查代码风格。
   • 可传承性：可以通过Apifox查看文档、notion查看开发说明、文档等了解项目内容。
   • CI/CD：我们为前端、后端、评测环境都配置了CI/CD，采用了docker容器化技术，项目的打包部署不用手动配置环境，极大的减少了部署所需要的时间，并且能够通过CI/CD的执行发现项目的问题。
   • 单元测试：共完成了54个单元测试，涉及到的模块的覆盖率均在 60% 以上。部分覆盖率无法进一步提升是由于对数据库异常进行一定的检测， 这种异常难以在单元测试中完成触发。

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

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

   在发布期间，我们收到了一些对于安全问题的反馈，我们第一时间进行了解决。也有用户反馈部分交互逻辑欠打磨，我们会在 beta 版本中进行进一步改善。

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

   • 要重视鉴权和安全问题。由于团队中没有对网安相对较熟悉的同学，Alpha阶段出现的比较严重的问题均为安全问题
   • 线下对接能够增加效率，在开发的关键阶段应该增加线下对接的次数，通常能够较快的发现问题并且当场解决
   • 要多和用户交流，明确需求，避免在开发的过程当中重构
   • Beta阶段主要完成的任务有重构评测机架构，完成讨论区、教程、成绩统计等功能

计划

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

   有。在确定选题并进行需求分析后，我们便设计了需要实现的功能，确定了两次迭代的目标。随后分配并细化了alpha阶段每个人需要完成的任务并预估了所需时间。在每次例会上，我们也会根据当前的项目进度，以需求为导向，对计划进行动态调整。

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

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

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

   有部分评测相关的工作未完全实现。相关技术存在实现难点，在计划时未考虑到。

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

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

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

   有。

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

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

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

   基本按计划进行。开发时评测部分技术存在实现难点导致开发战线被拉长，原因在于对技术与流程不熟悉，所以在计划阶段未能合理安排时间；测试时及发布后出现一些较为严重的安全问题，原因在于团队中没有对网安相对较熟悉的同学，意识不到位。

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

   对于时间方面，项目测试、发布及稳定的一周为缓冲区。缓冲区很有效，在这段时间内我们对alpha阶段工作进行了收尾，集中进行了测试，修复了很多bug。

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

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

   首先，会根据alpha阶段遗留的问题调整原本的项目计划；其次，安排更合理的工作时间，保障团队成员的睡眠，维持正常作息；最后，对任务预留提前量，保证按时交付下一阶段的任务。

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

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

   在计划阶段，我们会做更加详尽的调研，对计划进行更合理的时间评估，对功能进行更清晰的设计，并预留出缓冲区以应对突发或未考虑到的情况。

资源

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

   这个问题可以分成两部分来回答。

   首先是时间和人力资源。一方面我们全组的同学都在本项目上投入了不少时间，另一方面通过科学合理的分工和规划，我们组对完成工作耗时的分配还算合理，因此最后大部分计划中的任务都能按时完成。

   其次是软件和硬件资源。感谢编译平台负责老师为我们提供了服务器可以让我们在其上实地测试和部署，我们在项目初期就规划了使用的开发工具和组件，比如后端框架gin，评测容器docker和前端的框架和组件等，这些开源工具简化了我们的开发，为我们完成任务带来了极大的便利。

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

   我们将大的任务拆解成诸多小的任务，从而能更精确的估计所用时间，对于具体的任务，我们采用以小时为精度，从之前的开发经验和本次的任务分工出发进行时间估计。

   对于资源估计，我们在开发过程中考虑了实际使用的用户数量，针对可能存在的资源紧张情况采取了诸如使用redis消息队列、存取优化等方式保证资源合理利用。

   在实际开发中，我们也针对具体情况做出了一定的调整。

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

   我们的测试包括单元测试、压力测试、功能测试等，对于具体的测试任务交给了具体的人来负责，同时使用了一些现有的测试工具，故各种资源比较充足，设计的各种测试基本顺利完成。

   我们组的美工主要在前端设计和logo设计，这部分基本由前端完成，相对工作量不大，主要遇到了一些技术问题（如CSS或组件库的使用等），实际美工的工作量比较合理。

   最后的报告由大家一起完成，花费的时间符合计划。

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

   我们在前期针对每个人的开发经验进行了调查，并据此安排了任务，因此我们的分工总体来讲比较合理，主要是出现了一些工作量安排不合适的情况，未出现成员分配到不合适的工作的情况。

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

   对于一些比较复杂之前没有经验的工作，我们对时间的估计不够准确，从而导致了一定的进度落后。同时，在评测部分前后端没有在前期充分沟通，导致最后频繁修改API和功能，导致了一定的延误。

变更管理 [WPY]

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

是的。

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

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

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

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

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

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

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

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

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

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

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

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

设计/实现

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

   设计工作主要在前两周完成，UI的设计工作主要由前端开发人员完成，数据模型和api的设计工作主要由后端开发人员完成。

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

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

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

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

   现在的文档相较于项目开始时的文档进行了很大程度的更新，比如数据模型、api、服务器说明等，但对于功能规格说明和技术规格说明等没有怎么进行改动。改动的原因主要是在实现时发现已有的设计不合理或是无法满足需求，需要进行一定的调整。

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

   评测功能产生的bug最多，因为这部分逻辑最复杂，需要前后端通信、后端和评测机之间通信，涉及到的技术栈最多，相关的代码量。

   发布之后出现的重要bug主要是安全性相关的，例如利用redis漏洞提权，源码中存放密钥等，由于开发经验不足且对网络安全不够了解，所以设计/开发时未能考虑周全，导致出现部分安全隐患。

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

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

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

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

测试/发布 [SHJ]

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

   有。

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

   是

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

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

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

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

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

   redis未设置密码的问题，代码仓库泄露minio密码的问题

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

   应当更加注意后端以及数据库的安全问题。

团队的角色，管理，合作

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

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

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

   当然。

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

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

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

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

总结:

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

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

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

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

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

   对彼此都比较熟悉，沟通成本进一步降低，更加信赖和依赖彼此。

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

   团队项目管理对应到issue仍有改进空间。同时考核绩效指标仍有待细化。

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

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

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

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

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

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

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

      进一步细化代码审核过程，审核通过再merge进主分支。

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

      明确现在的问题，再思考架构上如何解决这些问题。评价指标：各部分之间的耦合度应当充分低。

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

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

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

      应当明确考核绩效指标，提供贡献分的可靠依据。可能可以通过细化issue的方式完成。

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

      没必要吧。

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

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

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

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

   8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

      理论应当服务于实践，我们应当在具体的软工实践中体会这些理论的优雅之处。

全组讨论截图