设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
当前计算机学院的核心专业课程《操作系统》的理论部分和实验部分建设都趋于成熟，实验平台也需要进一步开发完善。实验的参与者主要包含课程教师、助教和选课学生。这三类用户分别需要完成班级、权限管理，实验、教程管理，课下实验和课上考试等功能。
现有的平台对上述功能的实现尚不完善，各方面实现割裂，分散在不同的站点；各方面信息展示功能不佳，自动化程度有待提高；用户体验不佳。与此同时，校内各类课程平台的建设日臻完善，为了适配核心专业的课程定位，我们计划实现一个供教师、助教、学生使用的统一的课程平台。该平台能够一站式满足三类用户的主要需求，提供完善的信息展示机制，自动化程度高，具有良好的用户体验。
在之前的 Alpha 阶段，我们只完成了最基本的用户登录、评测、进度查看、班级管理等功能，这些功能都过于分散，未有效组织成课下作业、课上考试、权限管理等课程的必须环节，这是 Beta 阶段的重点。另外，适配教学环节的讨论区、通知管理、教程等功能也都在本阶段上线。
我们对平台中涉及到的相关概念（如 Lab、评测、教程等）、用户端、功能以及验收场景有着清晰的定义（见 OSome-平台概念介绍、功能规格说明书）。
在 功能规格说明书 中，我们列出了以教师用户、助教用户和学生用户的典型代表，并给出了实验、考试、班级管理等典型场景。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
目标已经达到。
原计划共 14 个功能，包括：
- 学生端（5 项）：讨论区、教程、通知提醒、极大地优化了评测界面和任务列表、丰富了个人信息
- 教师端（9 项）：评测节点管理、评测权限管理、通知管理、统计分析、考试配置、重评功能、记录导出、用户权限模板、优化了功能编排逻辑
以上 14 个功能均已实现。
系统于 6 月 17 日上线生产服务器供师生使用，活跃用户量已经达标。
- 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
提高了。
在后端增强了对并发的控制。将所有需要先后运行两条及以上 SQL 语句的 API 改为用事务操作。在 Alpha 阶段有部分遗漏了。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
在 Beta 阶段虽然由于疫情和课程政策等原因没有能够在平台上实现考试功能，但仍有超过 300 名用户使用了 OSOME 系统。
我们通过问卷的形式调查用户对重要功能的接受程度，截至 6 月 18 日，已收到 30 份问卷，其中 1 人评价为一般，2 人评价为满意，27 人评价为很满意。
- 学生
- “平台比较精美”
- “界面清爽”
- “太厉害了啊”
- “这个 OSOME 确实棒”
- “前端非常美观”
- 助教
- 希望开发评测时，有“上传标程”、“上传数据”等功能，将标程与数据解耦
- 教师
总的来说，用户量和接受程度都比较理想，我们通过 Beta 阶段的迭代开放也离目标更近了。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
讨论阶段一定需要前后端一起讨论，对于 API 中的每一个参数，都需要双方确定才可定下来。
对于 API 的语义，一定要商定清楚，存在争论的，要记录下双方的观点以及采纳的内容，防止后期开发过程中因为开发人员忘记而造成语义理解不一致的情况。
计划
- 是否有充足的时间来做计划?
有
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
有不同意见的各位同学首先表达自己的观点，大家各自阐述好处和坏处，最后由 PM 做最终决定。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
并没有所有都做完。原因有以下两方面：
- Beta 阶段时间不富裕，因此砍掉了一些没有意义的功能
- 有些功能在 Beta 阶段并不需要，可以在后续课程上线的阶段再继续进行（不然小助教就没活儿了）
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
确实没有，因为功能都是经过精细讨论的。
- 是否每一项任务都有清楚定义和衡量的交付件?
有的，所有的 Issue 都有清晰的界定。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
确实出现了一些意外，主要是本来预计 Lab5-2 使用我们的平台。但因为疫情原因课上再加上老师们反对使用新平台，导致我们的用户量无法获得，因此最终选择了发布学生成绩。没有预估到的原因主要是疫情和没有提前和老师沟通。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
有留缓存区，主要是工作安排时有些 GAP。因为 Beta 阶段实际上和期末考试是有些重合的。
- 将来的计划会做什么修改？
主要是能提前和老师商量吧（和需求方交流）。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学习到了如何进行软件的开发、团队协作，同时遇到特殊情况如何处理。如果历史重来一遍，我们肯定会在课程刚开始时设计做出更多的备案，定出两阶段出口条件和用户使用情况。
资源
- 我们有足够的资源来完成各项任务么?
有。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 时间：在 Alpha 阶段的设计阶段，我们一起对每个任务进行评估，分析每个任务所需的相关技术、完成时间，以及任务之间彼此的依赖关系。对于需要的技术，我们会事先安排时间学习，并调通样例。这样，之后的开发过程就会比较顺利。在指定完成时间时，要注意被依赖的任务完成时间应当早于依赖的任务。
- 硬件：由于课程网站的特殊性，我们必须使用北航校内的硬件资源，还需要北航校内的域名。因此，我们与操作系统课程老师对接，拿到了所需的资源。
实践证明，我们在时间上的估计是比较准确的。绝大部分任务都是在 DDL 当天或之后一天以内完成的。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们的测试时间略有不足，单元测试覆盖率仅达到了 50%。人力资源和硬件资源都是足够的。
由于我们是面向学生的课程平台，重在实用，因此对美工的要求没有那么高，也没有在上面花什么精力。我们的文案同样是以准确无误为主。难度与平时助教出题、发公告相近，并没有低估。
- 你有没有感到你做的事情可以让别人来做（更有效率）?
- gyp：无
- cjy: 无
- ch: 无
- wwq：无
- yzr：ptw 的运维技能比我高很多，但为了未来的 os 课程组对接，我还是需要学习与实践运维
- fxj: 无
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
开发过程中数据库的改表操作没有留档。在最后从测试服迁移至生产服时，对数据库变更进行了反复的校验。凡涉及数据库改表的操作，都应该留下记录。即，记录使得生产服与测试服数据库保持一致锁需的语句。
变更管理
- 每个相关的员工都及时知道了变更的消息?
是
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据任务的必要程度进行划分，再根据剩余时间和任务难度动态调整。具体实现方法是，在每阶段开始前先根据用户需求列出清单，再逐一讨论需求的紧急程度。如果在实现过程中需要动态调整，则在组会或小组群中讨论。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 功能条件
- 完成原定的 Beta 阶段预计的讨论区、教程、考试管理等功能。
- 测试条件
- 编写并通过全部单元测试，尽可能提高测试覆盖率。
- 进行简单的后端压力测试、评测机压力测试。压测情况下系统稳定不崩溃。
- 数据条件
- 导入 2022 春季学期计算机学院操作系统课程学生历次上机的成绩。
- 对于可能的变更是否能制定应急计划?
是的，在项目中我们即时开会，遇到需要变更的事项也会通过在会议上宣布、更新 Readme 等形式告知每一个相关成员
- 员工是否能够有效地处理意料之外的工作请求？
可以，我们根据每个人的可分配时间动态调整任务量，互相帮忙，即时解决工作请求。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在重要的、涉及较多参与人员的更改，有必要采取 at、pin 等方式确保更改被知悉。
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作按照涉及面大小、项目进度中所处位置安排其完成时间与人员。
- 对于全局性设计，在例会上或者即时聊天群组中提出，绝大多数情况都能得到较好的解决。
- 对于特定服务（前端 / 后端 / 评测端）的设计，由负责同学进行，在他们方便的时间进行单独或者结对设计。
- 对于架构性设计，由负责架构的同学设计，并与相关服务负责同学与合适的时间进行核验。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有。
- 对于设计中的重大疑难，我们一般将其讨论范围扩大一级。即：
- 对于具体逻辑的设计，由所有负责该服务的同学决定，或由全体成员决定；
- 对于架构性设计，在例会上或者即时聊天群组中讨论决定；
- 对于全局性、功能性设计，在例会上讨论决定，或与相关需求方讨论决定。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 团队积极部署现代化设计与验证流程，具体形成措施如下：
- 前端使用 Prettier / ESLint 自动验证代码质量，进行一定的代码测试，其通过作为顺利编译的前置条件。
- 后端对关键 API 进行了单元测试，测试通过作为 CI 通过的必要条件，形成了 TDD 机制。
- 数据模型构建采用由需求到 ER 图再到 SQL 结构的三级设计机制，其中 ER 图帮助我们对于概念进行抽象，并指导我们构建 SQL 层的实际数据模型。
- 现代化设计与验证流程帮助我们快速形成共识，提高开发效率。
- 项目开始时的 ER 图与现在的 ER 图由于 beta 阶段设计的加入存在大量区别。这些更改已更新至数据库，并已形成文档（Alpha > Beta 迁移语句）。
- 什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的 bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 评测端出现的 bug 最多。这是由于其涉及的环境与服务众多，交互逻辑与内部逻辑繁杂，测试成本和难度较高。
- 发布后目前没有发现新的 bug。
- 由于对于容器技术、GNU/Linux 底层原理了解不足。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 修改由成员开启 Merge Request 请求合并开始，需要经过至少一位其他成员的审核后，方可合并进服务分支。这期间代码规范主要由自动化工具维护。人工审核主要聚焦逻辑部分。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了如何进行高效的设计 / 验证迭代。
- 如果重来一遍，我们会选择更早地推广单元测试机制。
测试/发布
- 团队是否有一个测试计划？为什么没有？
有。
- 是否进行了正式的验收测试？
是。
- 团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
有。测试分为白盒测试与黑盒测试：
- 在开发过程中，每一次合并到主分支时，需要其他成员复审代码，尽早发现代码缺陷。
- 在黑盒测试时，编写单元测试，并使用 CI 机制对每一次 push/merge 进行回归测试。
同时评测端在每一次大改动后，都会进行压力测试，避免评测端出问题。
- 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 效能预估：SQL 连表操作原理探究与开销估计、数据库服务预部署测试等
- 效能跟踪：日志机制、前端资源压测、后端 API 压测
- 压力测试：
- 批量发送资源请求、批量发送 API 请求、批量发送评测请求等
- 详见 [Beta 阶段测试报告](Beta 阶段测试报告)
- 这些测试帮助我们很好地预估了项目对负载的耐受能力。后续需要重点提升评测性能。
- 在发布的过程中发现了哪些意外问题？
服务器上的 docker 服务出现死锁 bug，前后端开发因为 docker 服务出错而无法使用 CI 服务，开发一度中止。
- 我们学到了什么？如果重来一遍, 我们会做什么改进？
在对待影响全局开发的运维问题时，不要只关注“为什么出问题”，还要关注“这个问题能否有立即解决或缓解的方案”。如果重来一遍，应当考虑立即询问服务器提供端是否能够另开一个服务器用于 docker 调试，而不是始终使用开发服务器来调试。
团队协作
- 团队的每个角色是如何确定的，是不是人尽其才？
如展示文档所述，我们根据技术栈等因素综合考量，将开发人员分组分工，做到人尽其才，并根据个人规划等因素灵活动态调整协作模式与分组分工安排，增强团队组织的鲁棒性。
- 团队成员之间有互相帮助么？
有。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
项目管理、合作方面的问题主要在例会过程中沟通解决。
- 每个成员明确公开地表示对成员帮助的感谢：
- gyp: 我感谢 yzr 对我的帮助，因为某个具体的事情: 帮助我解决获取新题目的问题。
- cjy: 我感谢 ch 对于我的帮助，因为某个具体的事情：帮助我解决用户信息的前端相关问题。
- yzr: 我感谢 ptw 对我的帮助，因为某个具体的事情：与我不断探究 docker 死锁问题，教我服务器运维。
- fxj: 我感谢 gyp 对我的帮助，因为某个具体的事情：在我刚开始学习后端开发的时候在很多细节方面帮助我。
- ch: 我感谢 ptw 对我的帮助，因为某个具体的事情: 帮助我完成学生前端内嵌教程，并对教程内嵌小题提出若干建议。
- ptw: 我感谢 yzr 在评测器死锁问题的处理中做出的探索与后续备用方案的对接。
- wwq: 我感谢 ptw 对我的帮助，因为某个具体的事情：为前端设计提供有趣的思路。
总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
我们的团队处于CMMI 二级（管理级）阶段，团队目前有明确的计划和流程，会对每一个负责任务的同学进行培训，每一个 Issue 分配到人，权责到人。我们认为我们有能力完成所有同类项目的实施。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
创造阶段。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
在后端增强了对并发的控制。将所有需要先后运行两条及以上 SQL 语句的 API 改为用事务操作。在 Alpha 阶段有部分遗漏了。
- 你觉得目前最需要改进的一个方面是什么？
希望团队成员能更清楚的了解功能实现 ddl，尽量在时间内完成任务，减少 PM 的工作量。
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
以有进取心的人为项目核心，充分支持相信他们：Beta 开发中，我们坚持以潘天蔚为技术领导核心，充分支持相信潘天蔚的技术指导与系统设计，领导我们夺取 Beta 阶段的伟大胜利。
只有不断关注技术和设计，才能越来越敏捷：Beta 开发中，我们经常讨论某些代码实现的“优雅程度”，尽力保证项目可维护性。
- 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
- 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 代码管理质量：团队协商好代码规范和要求，对于不符合要求的代码及时指正
- 代码复审：多个人一块进行评审，在评审时给出自己的意见，不要直接合并
- 代码规范：更加细化规范要求，给出优秀范例供团队成员学习
- 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
- 其它软件工具的应用，应该如何提高？
- 由于 GitLab 通知缺少实时性，可以通过邮件对 GitLab 上的 issue 分配等即时告知（在项目后期已实现）
- 项目管理有哪些具体的提高？
- 今后开发成员开会讨论机会几乎不存在，需要围绕 issue 形成一套完善的讨论机制，以保证项目管理和质量管理措施落实。
- 需要提倡 API 与对应单元测试代码同时提交、同时复审、同时接受。
- 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
希望增加一些统计接口。目前是查 Log 获得。
- 项目文档的质量如何提高？
在文档分工协作方面，需要每个人撰写自己所从事的开发、管理方面工作的文档，其中大部分需要在工作开展的过程中自动形成。
汇总提交时，需要由专人将文档汇总整理，调整格式和部分内容，以更好地符合作业需求。
- 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
提高 PM 对项目整体的熟悉程度，成为类似“全栈领航员”的角色。
强化 PM 与项目成员的密切沟通，知悉项目难点，明晰时间节点，助推燃尽。
- 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。
适当记住用户的选择，以优化用户体验。
在 Alpha 的基础上我们在是否显示已读通知、使用题目视图还是任务视图上记住了用户的选择，并针对不同身份（学生、教员）的用户做了区分，取得了不错的反响。
进行探索式测试，发现问题。
在测试服务器的过程中，我们采用了探索测试的方式，测试包括但不限于如下情况：
- 使用 nmap 扫描服务器
- 使用 sqlmap 扫描服务器
- 使用 nessus 扫描服务器
- 排查 v-html 等可能的注入点
- 尝试利用 markdown 编辑器进行 XSS 注入
我们发现了 Redis 服务未鉴权的漏洞并进行了修复。
前后端分离的开发流程。
在前后端分离的架构下，我们采用初步确定 API，前后端分别实现并逐步对接的方式开发。
由于时间有限，前端没有采用 mockjs，而是先完成与 API 无关或关系较小的界面实现，待后端 API 完成后迅速对接，后端则通过 swagger 在没有前端的情况下开发与测试。
基于 Gitlab 的代码复审。
我们没有通过使用 todo/bug 等标记的方式完成代码复审，而是基于更加现代化的 Gitlab，我们使用 Issue 功能并把待办事项、软件缺陷等以 Issue 的形式管理起来。
践行敏捷开发流程。
现有的做法敏捷的做法流程和工具个人和交流完备的文档可用的软件为合同谈判与客户交流执行原定计划响应变化如上表所示，我们践行敏捷开发流程，尽早并持续地交付有价值的软件以满足需求。
（陈纪源与郭衍培共用麦克风）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
