标签：评测 代码 事后 开发 阶段 测试 Alpha 团队 我们

设想和目标

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

   当前计算机学院的核心专业课程《操作系统》的理论部分和实验部分建设都趋于成熟，实验平台也需要进一步开发完善。实验的参与者主要包含课程教师、助教和选课学生。这三类用户分别需要完成班级、权限管理，实验、教程管理，课下实验和课上考试等功能。

   现有的平台对上述功能的实现尚不完善，各方面实现割裂，分散在不同的站点；各方面信息展示功能不佳，自动化程度有待提高；用户体验不佳。与此同时，校内各类课程平台的建设日臻完善，为了适配核心专业的课程定位，我们计划实现一个供教师、助教、学生使用的统一的课程平台。该平台能够一站式满足三类用户的主要需求，提供完善的信息展示机制，自动化程度高，具有良好的用户体验。

   我们对平台中涉及到的相关概念（如 Lab、评测、教程等）、用户端、功能以及验收场景有着清晰的定义（见 OSome-平台概念介绍、功能规格说明书）。

   在 功能规格说明书 中，我们列出了以教师用户、助教用户和学生用户的典型代表，并给出了实验、考试、班级管理等典型场景。

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

   目标已经达到。

   原计划共 12 个功能，包括：

   • 学生端（6 项）：首页通知、评测、进度查看、用户登录、个人信息、建议与反馈
   • 教师端（5 项）：用户管理、教学信息、公告管理、用户登录、评测记录
   • 评测端（1 项）：代码评测

   以上 12 个功能均已实现。

   5 月 7 日，我们邀请操作系统课程的沃天宇老师，进行长达三小时的视频会议。我们向沃老师展示了 OSome 平台的学生平台、教师平台，并听取了沃老师的建议。我们立即对老师反馈的问题进行了修改。最终，于 5 月 9 日晚，向全体操作系统老师和正在上操作系统课程的全体学生发布。

   截止至 5 月 12 日 17 时（Alpha 阶段项目展示前夕），已有 241 人完成登录，共 141 名学生完成提交，提交题目 302 次，总共 API 访问次数 13024 次。考虑到发布仅 3 天，且本学期仅有 6 系和 21 系开课，该活跃量已经可以满足预期。

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

   本项目为 Alpha 阶段，没有上一个阶段。此处仅概述本阶段的质量管理。

   • 文档与代码规范：

     • 每个仓库具有 readme，作为完整的开发指南，包含以下几方面的信息：
       • 本地开发、构建说明
       • 部署说明
       • 配置说明
       • 依赖说明
     • 使用以下自动化工具检查代码质量，不通过时 CI/CD 失败：
       • ESLint
       • Prettier
     • API 文档由 swagger 自动生成，省去人工维护的成本。

   • 可传承性：

     • 代码质量
       • 项目代码结构性好
       • 层次清晰
       • 标识符表意清楚，无需注释
       • 重要概念有 OSome 平台概念介绍，避免混淆
     • 指导质量
       • 项目均有 readme.md，指导本地开发、测试流程
       • 服务均有 docker-compose.yml 留档，可以使用同样的命令启动所有服务：docker compose up -d
       • 重要机制已形成固化记录（子站反代、Docker Registry 等），帮助使用

   • 单元测试：

     完成 24 个重要 API 的单元测试，涉及 68 个测试用例，覆盖率达到 62.6%，共 1874 行代码。

   • DevOps：

     • CI/CD 是敏捷开发的关键：

       我们为学生前端、教师前端、后端、评测端、评测环境都配置了 Gitlab CI/CD，从而自动进行回归测试、构建、部署到服务器，极大提高了团队开发效率——除了运维同学外，自动构建、部署的过程对于开发者来说是近乎透明的，开发者只需要知道有一个机制使得开发者每一次 push/merge 都能在服务器上看到效果，而不关心这个机制的具体实现。

     • Docker 容器技术也是敏捷开发与系统运维的关键。容器技术在我们的开发过程中起到了关键作用：

       • 我们可以在一个机器上同时运行多个服务且互不冲突。
       • 我们利用 Docker 镜像来包装、发布分布式评测机，只需在 V-TEST 上运行 docker-compose 即可自动拉取评测机镜像，扩充评测结点。

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

   用户量与预想几乎一致。

   用户对重要功能的接收程度好。收到的 21 份使用反馈中，21 份均为有效反馈。所有的 21 份反馈均表示“非常满意”，满意率达到 100%。

   用户的满意度反馈表示 Alpha 阶段取得了练好的结果，实现了大部分功能的集成，为 Beta 阶段的进一步开发打下了良好的基础。这也离“我们计划实现一个供教师、助教、学生使用的统一的课程平台。该平台能够一站式满足三类用户的主要需求，提供完善的信息展示机制，自动化程度高，具有良好的用户体验”的目标更进一步。

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

   • 设计时要即时和老师沟通，了解用户需求，以免重构
   • 开发期间出现了服务器宕机情况，形成处置文档
   • 要保护好身体，不要再有人倒下了
   • 要即时跟进项目，参与会议，接触技术栈，避免和项目脱节

计划

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

   是，我们从1月份就开始对需求进行分析。

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

   大家首先阐述自己的意见，之后同学们互相讨论优势劣势，最后由叶焯仁同学统一决定。

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

   都做完了，因为我们前期规划的好。

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

   开非常长时间的会，效率太低。

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

   并不是所有任务都有清楚的定义。我们的任务是以 Issue 形式定义和衡量的，在介绍任务时一般比较概括，实现时有时还会对任务进行讨论。

   交付件来说我们是通过同行评审的方式，在明确实现某个功能之后才能交付。

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

   确实出现了意外，有一位同学因为身体原因一段时间无法工作，我们紧急开了会议，将他的任务分配到了所有其他人手里。确实没有预料到有同学会因为本学期的课程身体不适，课程的带来的压力还是太大了。

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

   没有留缓冲区。

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

   我们计划在之后设置缓冲区，比如在周日设置缓冲区，这样同学们可以调整自己的时间规划。

   对项目未来计划做好风险备案，如果出现问题及时处理。

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

   我们学习到如何进行团队开发。

   如果再来一遍，我们会做更加详细的规划，对于各种意外情况做好预案，提升开会效率。

资源

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

   是的。

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

   • 时间：在 Alpha 阶段的设计阶段，我们一起对每个任务进行评估，分析每个任务所需的相关技术、完成时间，以及任务之间彼此的依赖关系。对于需要的技术，我们会事先安排时间学习，并调通样例。这样，之后的开发过程就会比较顺利。在指定完成时间时，要注意被依赖的任务完成时间应当早于依赖的任务。

   • 硬件：由于课程网站的特殊性，我们必须使用北航校内的硬件资源，还需要北航校内的域名。因此，我们与操作系统课程老师对接，拿到了所需的资源。

     实践证明，我们在时间上的估计是比较准确的。绝大部分任务都是在 DDL 当天或之后一天以内完成的。

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

   我们的测试时间略有不足，单元测试覆盖率仅达到了 70%。人力资源和进件资源都是足够的。

   由于我们是面向学生的课程平台，重在实用，因此对美工的要求没有那么高，也没有在上面花什么精力。我们的文案同样是以准确无误为主。难度与平时助教出题、发公告相近，并没有低估。

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

   • gyp：无。我可以多帮 yzr 写一些 API，这样他就能有更多时间做测试。
   • cjy：有。ch 对于前端的技术熟悉程度比我高，我其实对评测机更加熟悉，适合去完成评测机的编码。
   • ptw：并不。我在负责范围内有较高的熟练度和一定的经验，交给其他成员来做会增加项目的技术积累成本。
   • wwq：没有。我有较多的时间用于软工。

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

   有一位同伴在中间生病隔离在了培训中心。在软工的同时要多睡大觉。

变更管理

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

   是的。

   变更消息如果是针对全体的，我们会在群聊或会议中提出；如果是针对部分的，则在对接中即时提出。

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

   在制定需求时确定哪些是必须实现的功能，其他不必须实现的功能根据当前任务完成情况灵活调整。

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

   有，定义如下：

   • 功能条件
     • 在完成原定的 Alpha 阶段基本课程管理、学生使用、代码评测功能的基础上，按照操作系统课程老师的要求，新增基本的统计任务信息的功能。
   • 测试条件
     • 编写并通过全部单元测试，尽可能提高测试覆盖率。
     • 进行简单的后端压力测试、评测机压力测试。压测情况下系统稳定不崩溃。
   • 数据条件
     • 创建 2022 春季学期计算机学院操作系统课程，并将该课程全部学生、助教、老师信息导入系统。
     • 创建课程所需的题目、评测用例、评测脚本。

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

   能。

   我们组保证至少两天开一次会，且成员之间随时保持联系，因此可以即时制定应急计划。

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

   可以。

   在 Alpha 阶段实现过程中，OS 老师提出了一些新的工作请求，我们评估工作量，结合需求的紧迫性，将新的工作请求分为：Alpha 完成、Beta 完成、暂不实现三类。

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

   我们学到了要即时沟通，如果重来一遍，我们可能会更积极地和 OS 老师沟通。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
   • 设计工作按照涉及面大小、项目进度中所处位置安排其完成时间与人员。
   • 对于全局性设计，在例会上或者即时聊天群组中提出，绝大多数情况都能得到较好的解决。
   • 对于特定服务（前端/后端/评测端）的设计，由负责同学进行，在他们方便的时间进行单独或者结对设计。
   • 对于架构性设计，由负责架构的同学设计，并与相关服务负责同学与合适的时间进行核验。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   • 有。
   • 对于设计中的重大疑难，我们一般将其讨论范围扩大一级。即：
     • 对于特定服务的设计，由所有负责该服务的同学决定，或由全体成员决定；
     • 对于架构性设计，在例会上或者即时聊天群组中讨论决定；
     • 对于全局性设计，在例会上讨论决定，或与相关需求方讨论决定。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
   • 团队积极部署现代化设计与验证流程，具体形成措施如下：
     • 前端使用 Prettier / ESLint 自动验证代码质量，进行一定的代码测试，其通过作为顺利编译的前置条件。
     • 后端对关键 API 进行了单元测试，测试通过作为 CI 通过的必要条件，形成了 TDD 机制。
     • 数据模型构建采用由需求到 ER 图再到 SQL 结构的三级设计机制，其中 ER 图帮助我们对于概念进行抽象，并指导我们构建 SQL 层的实际数据模型。
   • 现代化设计与验证流程帮助我们快速形成共识，提高开发效率。
   • 项目开始时的 ER 图与现在的 ER 图由于一些细节设计的改动存在一定区别，已更新。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
   • 评测端出现的 bug 最多。这是由于其涉及的环境与服务众多，交互逻辑与内部逻辑繁杂，测试成本和难度较高。
   • 发布后目前没有发现新的 bug，只有发布前遗留的一个占用文件系统的 bug。
   • 由于对于 GitLab API 与 golang 第三方软件包的了解不足。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   • 修改由成员开启 Merge Request 请求合并开始，需要经过至少一位其他成员的审核后，方可合并进服务分支。这期间代码规范主要由自动化工具维护。人工审核主要聚焦逻辑部分。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   • 学到了如何进行高效的设计/验证迭代。
   • 如果重来一遍，我们会选择更早地形成单元测试机制，更早地进行 GitLab 使用培训，利用好计划阶段的时间，而非等到冲刺阶段还在进行计划的收尾工作。

测试/发布

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

   有。

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

   是。

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

   有。测试分为白盒测试与黑盒测试：

   • 在开发过程中，每一次合并到主分支时，需要其他成员复审代码，尽早发现代码缺陷。
   • 在黑盒测试时，编写单元测试，并使用 CI 机制对每一次 push/merge 进行回归测试。

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

   • 效能预估：SQL 连表操作原理探究与开销估计、数据库服务预部署测试等
   • 效能跟踪：日志机制、前端资源压测、后端 API 压测
   • 压力测试：
     • 批量发送资源请求、批量发送 API 请求、批量发送评测请求等
     • 详见 Alpha 阶段测试报告
   • 这些测试帮助我们很好地预估了项目对负载的耐受能力。后续需要重点提升评测性能。

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

   服务器宕机，开发成员生病，开发初期非法数据引发系统出 bug。

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

   保重身体，保障开发服务器的数据库数据的正确性。

团队协作

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

   如展示文档所述，我们根据技术栈等因素综合考量，将开发人员分组分工，做到人尽其才，并根据健康情况等因素灵活动态调整协作模式与分组分工安排，增强团队组织的鲁棒性。

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

   有。

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

   项目管理、合作方面的问题主要在例会过程中沟通解决。

4. 每个成员明确公开地表示对成员帮助的感谢：

   • gyp: 我感谢 ptw 对我的帮助，因为某个具体的事情: 帮助我掌握规范的开发流程。
   • cjy: 我感谢 ptw 对我的帮助，因为某个具体的事情: 帮助我熟悉前端开发技术与规范。
   • yzr: 我感谢 ptw 对我的帮助。ptw 对 dind 机制的熟练帮助我完成了评测机；全栈能力覆盖，发掘后端多处实现问题；运维技术高超，多次拯救了濒临崩溃的服务器。
   • fxj: 我感谢 ptw 对我的帮助，因为某个具体的事情: 开发了燃尽图生成工具，方便例会文档编写；在我生病期间接手并分配我原先的工作。
   • ch: 我感谢 ptw 对我的帮助，因为某个具体的事情: 修被我搞的乱七八糟的分支图。
   • ptw: 我感谢全体成员对我的帮助。大家在团队面临严峻挑战时，对我的工作给予了充分的理解与全力的支持。这减轻了困难时期压在我身上的担子，也使得我们的项目仍旧能够达到 Alpha 阶段的出口条件，为 OS 课程布置理论作业提供了清晰准确的题目资源与稳定的评测平台。
   • wwq: 我感谢 ptw 对我的帮助，因为某个具体的事情: 对前端的布局和代码风格提出了很有建设性的建议（比如学生前端 commit 分支树）。

总结

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

   我们认为我们的团队处于CMMI 二级（管理级）阶段，团队目前有明确的计划和流程，会对每一个负责任务的同学进行培训，每一个 Issue 分配到人，权责到人。我们认为我们有能力完成所有同类项目的实施。

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

   创造阶段。

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

   没有前一个里程碑。

   • 软件质量方面：

     在前文已经介绍，我们对本阶段的项目开发制定了 文档与代码规范 以保证代码和文档的可传承性，并实现以 Merge Request 功能为核心的 Code Review 机制 ，通过 Review 后方贡献方可生效。。对重要 API 进行 单元测试 ，达到了较高的代码覆盖率。采用 Gitlab CI/CD 和 Docker 进行 持续集成部署 ，简化开发流程。

   • 时间管理方面：

     以模块化的整体规划为顶层，根据功能模块的技术难度与依赖关系设计。将任务划分为子任务作为中层，见 Alpha 阶段任务划分文档。在各子项目中创建 Issue 作为底层，实现项目进度的动态化管理。使用自动化工具绘制燃尽图，聚合底层数据，作为项目进度管理抓手。

   • 分工协作方面：

     根据技术栈等因素综合考量，将开发人员分组分工，实现效益最大化，技术积累成本最小化；根据健康情况等因素灵活动态调整协作模式与分组分工安排，增强团队组织的鲁棒性。

   • 沟通对接模式：

     我们有三种基本的沟通对接模式，用以完成开发阶段的任务分配、灵活解决各种问题。

     • 基于功能对接的沟通：
       • 前后端同学直接对接
       • 应用开发同学与应用部署同学直接对接
     • 基于需求对接的沟通：
       • 安排郭衍培、叶焯仁负责与需求方对接
       • 冯旭杰负责汇总与分析需求
     • 基于设计迭代的沟通：
       • 微信群直接沟通
       • Scrum Meeting 直接沟通

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

   开会时间过长，且时间阴间，需要注意效率，减少无关讨论。

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

   以有进取心的人为项目核心，充分支持相信他们：Alpha 开发中，我们坚持以潘天蔚为技术领导核心，充分支持相信潘天蔚的技术指导与系统设计，领导我们夺取 Alpha 阶段的伟大胜利。

   只有不断关注技术和设计，才能越来越敏捷：Alpha 开发中，我们经常讨论某些代码实现的“优雅程度”，尽力保证项目可维护性。

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

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

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

      • 架构的提高：
        • 后端的某些 SQL 语句过长，不利于维护，可考虑使用数据库视图来简化操作语句
        • 评测端直接轮询数据库，考虑改为轮询后端
      • 衡量重构的提高：
        • 代码复用率提高
        • 架构统一度提高

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

      GitLab 协作时可以添加 Label（如 bug、feature 等），便于区分各种 Issue。

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

      更合理地分工、更早地做计划、更全面的测试、更及时的对接、更敏捷的流程、更多维的管理。

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

      希望增加一些统计接口。目前是查 Log 获得。

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

      在文档分工协作方面，需要每个人撰写自己所从事的开发、管理方面工作的文档，其中大部分需要在工作开展的过程中自动形成。

      汇总提交时，需要由专人将文档汇总整理，调整格式和部分内容，以更好地符合作业需求。

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

      提高 PM 对项目整体的熟悉程度，成为类似“全栈领航员”的角色。

      强化 PM 与项目成员的密切沟通，知悉项目难点，明晰时间节点，助推燃尽。

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

      适当记住用户的选择，以优化用户体验。

      我们在 浏览题面 / 提交评测 的切换上记住了用户的选择，若用户进入了浏览题面页面，则下一次仍然进入浏览题面页面；若用户进入了提交评测页面，则下一次仍然进入提交评测页面，取得了不错的反响。

      进行探索式测试，发现问题。

      在测试评测机的过程中，我们采用了探索测试的方式，测试包括但不限于如下情况：

      • 调用关机命令
      • 无限 fork
      • sleep 或死循环
      • 尝试通过 system 调用 python
      • 尝试在评测机中联网

      我们发现了评测机的若干问题，并通过限制 Docker 可用资源等的方式进行了修正。

      前后端分离的开发流程。

      在前后端分离的架构下，我们采用初步确定 API，前后端分别实现并逐步对接的方式开发。

      由于时间有限，前端没有采用 mockjs，而是先完成与 API 无关或关系较小的界面实现，待后端 API 完成后迅速对接，后端则通过 swagger 在没有前端的情况下开发与测试。

      基于 Gitlab 的代码复审。

      我们没有通过使用 todo/bug 等标记的方式完成代码复审，而是基于更加现代化的 Gitlab，我们使用 Issue 功能并把待办事项、软件缺陷等以 Issue 的形式管理起来。

      践行敏捷开发流程。

      现有的做法	敏捷的做法
      流程和工具	个人和交流
      完备的文档	可用的软件
      为合同谈判	与客户交流
      执行原定计划	响应变化

      如上表所示，我们践行敏捷开发流程，尽早并持续地交付有价值的软件以满足需求。

发布博客时，要附上全组讨论的照片。

标签：评测,代码,事后,开发,阶段,测试,Alpha,团队,我们
来源： https://www.cnblogs.com/it-was-you-and-me/p/16291145.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。