01组团队项目-中期总结

队长博客链接： https://www.cnblogs.com/Cindy051010/p/19283120

一、团队名片

团队 Logo

团队 ID 与名称

• 团队 ID：01
• 团队名称：LLLLLLLLR

团队现场答辩总结

团队分工与得分比例

以表格形式展示团队中每个人在本次作业中的具体分工和各自得分比例：

团队成员	中期具体分工（聚焦开发 / 落地 / 推进类任务）	得分比例
龙玉凤	统筹中期进度同步，协调跨模块协作冲突；整理中期问题台账（含接口联调、权限管控类问题）；完成中期汇报核心内容撰写	1.0
李思凡	优化设备管理模块 UML 类图（补充权限关联、状态流转细节）；协助测试设备预约 - 占用流程，记录 2 项边界场景 Bug；整理前端组件复用文档	0.99
刘恩垯	完成设备使用模块基础 UI 开发（含预约表单、设备状态标签页）；适配不同分辨率下的界面布局；协助调试 “设备状态同步显示” 功能	0.99
林雨	开发设备管理模块核心接口（设备增删改查、权限校验接口）；实现 “任务 - 设备联动” 基础逻辑（任务状态触发设备占用）；解决 3 次前后端数据格式不一致问题	1.01
林炜	开发设备使用模块核心接口（预约创建 / 取消、占用 / 释放接口）；实现预约冲突检测算法（含跨天预约场景）；协助林雨完成接口联调与压力测试	1.01
林睿	整理中期功能验收清单（覆盖设备管理、设备使用两大模块）；模拟不同角色（项目组管理员、科研人员）进行功能测试；输出中期测试报告	1.01
廖鹤翔	细化设备共享权限逻辑（项目组 / 实验室级共享开关配置）；优化设备历史记录查询功能（支持按时间段 / 操作类型筛选）；记录并跟进 4 项功能优化建议	1.01
阮儒祥	搭建中期项目博客框架，整理各模块进度图文素材；协助李嘉欣完成中期汇报 PPT 的技术模块排版；同步更新团队代码仓库文档（含接口调用说明）	0.99
李嘉欣	设计中期汇报 PPT 视觉风格（统一配色、版式）；制作设备管理 / 使用模块功能演示流程图；优化 PPT 交互逻辑（关键功能跳转链接、动画标注）	0.99

---

二、总结思考

2.1 参考《构建之法》第 15 章“项目回顾（Postmortem）”模板的总结

2.1.1 设想和目标

1. 软件解决问题与定义清晰度

本软件聚焦科研场景下实验设备管理痛点，核心解决传统管理中效率低下、数据分散、过程评估缺失、权责不清、使用流程不规范等问题，同时实现“任务-设备”联动的自动化管理。问题定义清晰，明确针对项目组管理员、实验室管理员、科研人员、系统管理员四类典型用户，且对各用户的核心需求、使用场景有详细描述，典型用户与场景刻画精准。

2. 目标达成情况

• 功能层面：原计划的核心功能模块——设备管理模块已实现，涵盖设备增删改查、分级权限管控等核心功能，达成预设功能目标；
• 交付时间：按需求分析报告中的规划推进，无明确延期记录，符合原计划交付节奏；
• 用户数量：因系统面向科研团队/实验室内部使用，用户量符合预期场景定位，未涉及大规模公开用户推广，达成内部使用的用户规模目标。

3. 用户接受度与目标贴合度

用户对核心功能（如分级权限管理、设备预约冲突检测、任务联动占用）的接受度与预想一致，解决了科研人员设备使用预约繁琐、管理员管理效率低的核心痛点，有效缩短设备调度时间、减少冲突，使项目离“精细化设备管控、提升科研效率”的核心目标更近。

4. 经验教训与改进方向

• 经验：明确的用户画像和场景化需求分析为功能设计提供了精准指导，“任务-设备”联动的核心思路贴合科研场景实际需求；
• 改进：若重新设计，可在初期增加用户访谈的深度，针对不同科研领域（如理化实验、计算机科研）的设备使用差异，设计更具针对性的功能模块（如特殊设备的预约时长限制、维护周期定制）。

---

2.1.2 计划

1. 计划时间充足性

项目前期预留了需求分析、架构设计的时间，整体计划时间较为充足，但在功能细化落地阶段，部分模块的时间分配未充分考虑前后端协作的衔接成本。

2. 计划分歧解决方式

团队通过集体讨论、组长统筹协调的方式解决计划分歧，以“核心需求优先、用户痛点优先”为原则，对争议任务的优先级和实现方式进行投票决策，确保计划达成共识。

3. 原计划任务完成情况

原计划的核心功能任务均已完成，未完成的为部分拓展性功能（如移动端适配、高级统计分析），因项目优先级规划，将其纳入后续迭代阶段，未影响核心功能交付。

4. 无价值/没必要的工作

初期设计了部分过于复杂的设备参数字段（如设备采购合同扫描件上传、多语言适配），后续发现科研团队实际使用中需求极低，属于“冗余功能”，未投入开发，避免了资源浪费；但在文档撰写中，部分重复的架构图示（如多版本类图）增加了工作量，价值有限。

5. 任务交付件定义

大部分核心任务（如设备管理模块开发、权限管控实现）有清晰的交付件定义（如可运行的组件、测试用例、接口文档），但部分辅助任务（如文档排版、图示优化）的交付标准不够明确，导致反复修改。

6. 计划执行与意外风险

项目整体按计划推进，但存在以下意外情况：

• 前后端接口联调时，因数据格式定义不统一导致进度延迟，属于前期接口设计未充分对齐的风险，当时未预估到“字段类型细节分歧”的影响；
• 部分 UI 组件（如部门选择器）的复用性测试不足，导致在不同模块中出现兼容性问题，未预估到组件复用的潜在风险。

7. 缓冲区作用

计划中预留了 10% 的时间缓冲区，主要用于解决接口联调问题、UI 兼容性修复，有效避免了核心交付时间延误，缓冲区发挥了关键作用。

8. 未来计划修改方向

• 缓冲区：将缓冲区比例提升至 15%，并按模块拆分缓冲区，避免集中占用；
• 前期对齐：增加“前后端接口设计评审会”“组件复用性测试计划”，明确细节标准；
• 加班管控：避免无意义加班，通过细化任务颗粒度减少临时赶工。

9. 经验教训与改进

• 经验：优先级规划和缓冲区设置是保障交付的关键，集体决策能有效解决计划分歧；
• 改进：若重来，会采用更精细的任务拆分工具（如 Jira）管理任务，明确每个任务的前置条件、交付标准，同时在计划初期组织跨角色评审（前端、后端、测试），提前规避协作风险。

---

2.1.3 资源

1. 资源充足性

核心开发资源（前端、后端人力）充足，能覆盖核心功能模块开发，但测试资源相对紧张，仅依赖开发人员自测和少量人工测试，缺乏专职测试人员。

2. 资源估计精度

开发任务的时间估计精度较高（误差在 10% 以内），但文档撰写、图示设计的时间估计偏乐观，实际耗时比计划多 20%；资源估计主要基于团队过往项目经验，缺乏量化评估工具。

3. 测试与非编程资源评估

• 测试资源：时间、人力不足，未配备自动化测试工具，导致部分隐性 Bug 未被发现；
• 非编程资源：美工设计（Logo、UI 原型）、文案撰写（用户指南）的难度未被低估，团队内部有成员承担相关工作，未出现资源缺口，但设计迭代次数较多，耗时超出预期。

4. 资源优化分配

部分文档整理工作（如测试报告汇总、用户手册排版）可由行政或辅助人员完成，无需开发人员投入；部分重复的代码编写（如表单验证逻辑）可通过封装通用工具函数实现，减少重复劳动，提升效率。

5. 经验教训与改进

• 经验：核心开发资源的充足配置是项目推进的基础，通用组件封装能节省开发资源；
• 改进：若重来，会提前协调专职测试人员，引入简单的自动化测试工具（如 Jest）；同时明确非编程任务的负责人和交付标准，避免开发人员兼顾过多非核心工作，优化资源分配。

---

2.1.4 变更管理

1. 变更消息同步

项目变更（如功能优先级调整、接口字段修改）通过团队群聊、每日站会同步，核心变更会发送书面通知（如文档修订版），大部分相关成员能及时知晓，但偶尔存在“口头变更未记录”的情况，导致部分成员信息滞后。

2. 功能优先级决策

采用“用户需求紧急度 + 开发成本”二维评估模型，由组长组织投票决定“推迟”或“必须实现”的功能，例如“移动端适配”因开发成本高、用户需求紧急度低，被推迟至后续迭代；“预约冲突检测”因紧急度高、成本低，列为必须实现功能。

3. 出口条件定义

核心功能的出口条件定义清晰（如设备管理模块能正常完成增删改查、权限管控符合预期、无致命 Bug），但辅助功能（如文档完整性、图示美观度）的出口条件较模糊，导致多次返工。

4. 变更应急计划

针对“核心功能开发受阻”“关键人员临时缺席”等可能的变更，制定了应急计划（如核心功能备用实现方案、人员交叉培训），但未针对“需求变更”制定专门的应急计划，导致一次需求微调（增加设备维护记录导出功能）时，临时调整开发计划，影响了部分模块进度。

5. 意外工作请求处理

团队成员能通过“任务优先级插入”的方式处理意外工作请求（如临时增加的设备状态统计功能），但因缺乏统一的请求评估机制，偶尔出现“高优先级意外任务”挤压原有计划的情况。

6. 经验教训与改进

• 经验：二维评估模型能有效决策功能优先级，每日站会是同步变更的高效方式；
• 改进：若重来，会建立“变更申请单”制度，所有变更需提交申请、评估影响后再执行；明确所有功能的出口条件（包括辅助功能），并制定“需求变更应急流程”，预留 5% 的弹性资源应对意外工作请求。

---

2.1.5 设计 / 实现

1. 设计时间与人员

设计工作在项目初期（需求分析完成后 1 周内）启动，由前端负责人、后端负责人、架构师共同完成，时间节点合适，参与人员覆盖核心角色，能兼顾技术可行性和业务需求。

2. 设计模棱两可问题解决

设计中遇到“设备共享权限的层级划分”“任务-设备联动的触发条件”等模棱两可的问题，通过组织“业务专家访谈”（咨询实验室管理员）、“技术评审会”的方式，明确了“共享权限按项目组-实验室-部门分级”“任务启动状态由项目管理系统接口同步”的方案，有效解决分歧。

3. 设计 / 实现工具运用

• 采用 UML 绘制类图、时序图，为开发提供了清晰的结构指导，效果显著；
• 前端使用 Vue 3 组合式 API、Element Plus 组件库，后端采用 RESTful API 设计，提升了开发效率和组件复用性；
• 未采用单元测试和 TDD 开发模式，主要依赖人工自测，部分隐性 Bug 未被提前发现。

4. UML 文档变更与更新

项目开始的 UML 文档主要描述核心类结构和接口关系，后期因功能细化（如增加设备维护记录模块、优化权限管控逻辑），UML 文档与实际实现存在差异，差异主要源于“需求细化后的功能拓展”；已更新核心模块的 UML 文档，确保与当前系统状态一致。

5. Bug 高发功能与未预见问题

• Bug 高发功能：设备预约冲突检测（因时间区间判断逻辑复杂，出现“跨天预约冲突漏判”）、任务-设备联动（因项目状态同步延迟，导致设备占用/释放不及时），主要原因是“边界场景考虑不足”；
• 发布后未发现致命 Bug，但存在“设备历史记录导出格式错乱”的小 Bug，开发时未考虑“大数据量导出”的场景，导致 Excel 格式兼容问题。

6. 代码复审与规范执行

代码复审通过“小组交叉评审”的方式进行，每周开展 1 次，主要检查代码逻辑、命名规范、注释完整性；团队制定了统一的代码规范（如 Vue 组件命名规则、接口返回格式标准），整体执行严格，但部分边缘代码（如工具函数）存在注释缺失的情况。

7. 经验教训与改进

• 经验：UML 设计、组件化开发能提升开发效率和系统可维护性，交叉代码复审能减少明显 Bug；
• 改进：若重来，会引入单元测试（针对核心逻辑如冲突检测、联动触发），采用 TDD 模式开发高复杂度功能；在设计阶段增加“边界场景用例设计”，提前覆盖跨天预约、大数据量导出等场景；加强代码复审的频次（每 3 天 1 次），细化评审 checklist（如注释完整性、异常处理逻辑）。

---

2.1.6 测试 / 发布

1. 测试计划与验收测试

团队有简单的测试计划，明确了核心功能的测试要点（如权限管控测试、预约流程测试），但缺乏详细的测试用例和测试流程文档；未进行正式的第三方验收测试，验收工作由团队内部管理员角色模拟用户完成。

2. 测试工具运用

未使用专业的自动化测试工具，主要依赖人工测试（点击操作、数据录入）和简单的接口测试工具（Postman），测试效率较低，无法覆盖所有场景。

3. 效能测量与测试改进

通过“人工记录 Bug 数量、功能通过率”测量软件效能，测试工作能发现大部分核心功能 Bug（如预约冲突、权限越界），但对隐性 Bug（如数据同步延迟、兼容性问题）覆盖不足。

改进方向：引入自动化测试工具（如前端 Cypress、后端 Jest），编写核心流程的自动化测试用例；增加“压力测试”（如多用户同时预约设备），验证系统稳定性。

4. 发布过程中的意外问题

发布过程整体顺利，未出现严重故障，但存在以下小问题：

• 部分用户浏览器（如旧版 Edge）对部分 UI 组件支持不佳，导致显示异常；
• 首次发布后，设备历史记录导出功能因服务器配置问题，响应时间过长（超过 10 秒）。

5. 经验教训与改进

• 经验：内部验收测试能保障核心功能可用性，接口测试工具能快速验证数据交互正确性；
• 改进：若重来，会制定详细的测试用例文档，覆盖功能测试、兼容性测试、压力测试；引入自动化测试工具提升测试效率；发布前进行多浏览器、多设备兼容性测试，同时优化服务器配置（如数据库索引、接口缓存），避免性能问题。

---

2.1.7 团队的角色及其分工

1. 角色确定与人员适配

团队角色按“需求分析、设计、开发、文档、宣传”划分，结合成员特长分配任务（如擅长设计的成员负责 Logo 和 UI 原型，擅长编程的成员负责前后端开发，擅长文字的成员负责文档撰写），基本实现人尽其才；但部分成员兼顾多项任务（如开发人员同时负责测试），导致精力分散。

2. 团队成员互助情况

团队成员之间互助氛围良好，例如：

• 前端开发遇到组件复用问题时，后端开发分享过往项目的组件设计经验；
• 文档撰写成员对技术术语不熟悉时，开发成员提供专业解释和内容审核；
• 测试过程中，所有成员参与“Bug 查找”，共同解决核心问题。

3. 项目管理与合作问题解决

当出现合作问题（如前后端接口分歧、任务进度不一致）时，团队通过“即时沟通 + 每日站会复盘”解决：

• 接口分歧：组织临时评审会，明确数据格式和接口规则，更新接口文档；
• 进度不一致：由组长协调资源，优先支持滞后模块，或调整任务分配，确保整体进度同步；
• 意见冲突：以“数据和用户需求”为依据，避免主观争执，通过投票或咨询导师决策。

4. 成员感谢留言

• 林炜： 我感谢林雨对我的帮助，因为在设备管理模块开发中，他协助我解决了 Vue 3 组合式 API 的响应式数据同步问题，节省了大量调试时间。
• 廖鹤翔： 我感谢林炜对我的帮助，因为在细化设备共享权限逻辑时，他分享了后端权限校验的实现思路，帮我解决了跨项目组共享开关的逻辑冲突问题，提升了功能落地效率。
• 阮儒祥： 我感谢李嘉欣对我的帮助，因为在搭建中期项目博客时，提供了图文排版的专业建议，帮我优化了架构图示的展示效果，让博客内容更直观易懂。
• 龙玉凤： 我感谢林睿对我的帮助，因为在整理中期问题台账时，他精准梳理了设备管理模块的测试痛点，为我协调跨模块协作冲突提供了数据支撑，让进度同步更高效。
• 李嘉欣： 我感谢阮儒祥对我的帮助，因为在设计汇报 PPT 时，他整理了各模块的进度图文素材，还标注了核心功能亮点，帮我节省了素材筛选和整理的时间，让 PPT 内容更充实。
• 林睿： 我感谢廖鹤翔对我的帮助，因为在竞品分析环节，他整理了详细的通用资产管理系统功能对比表，为我设计系统优势功能提供了关键参考。
• 李思凡： 我感谢刘恩垯对我的帮助，因为在宣传视频制作中，他提供了专业的剪辑技巧指导，让视频呈现效果远超预期。
• 林雨： 我感谢龙玉凤对我的帮助，因为在开题汇报前，她帮我梳理了需求分析报告的逻辑结构，指出了核心痛点描述不清晰的问题，提升了汇报质量。
• 刘恩垯： 我感谢李思凡对我的帮助，因为在绘制系统流程图时，他分享了思维导图优化技巧，让图示更清晰、易理解，减少了反复修改的工作量。

---

2.1.8 心得总结

龙玉凤（统筹协调）

作为项目统筹者，中期阶段让我深刻体会到“进度同步”与“跨模块协作”的重要性。前期因未充分预判前后端接口联调的细节分歧，导致部分任务推进延迟，后续通过建立“每日站会 + 问题台账”机制，才逐步理顺协作节奏。这让我明白，复杂项目中“沟通前置”比“事后补救”更高效，未来需在计划初期就组织跨角色评审，提前规避协作风险，同时要更关注成员的任务负荷，避免核心成员因兼顾过多工作导致精力分散。

李思凡（设计与测试辅助）

参与设备管理模块 UML 类图优化和测试辅助工作后，我意识到“边界场景”是功能落地的关键。之前优化类图时，因忽略权限关联的细节，导致后续测试中出现权限越界的小问题；协助测试预约流程时，也发现跨天预约冲突这类前期未考虑的场景。这让我学会，设计阶段需更细致地覆盖“异常情况”，测试时要跳出“常规流程”思维，多从用户实际使用的极端场景出发，才能让功能更完善。同时，刘恩垯分享的组件复用技巧也让我明白，代码复用不仅能提升效率，还能减少兼容性问题。

刘恩垯（前端 UI 开发）

负责设备使用模块 UI 开发的过程中，我最大的收获是“用户体验优先”的落地思路。最初设计预约表单时，只关注功能实现，忽略了科研人员操作的便捷性，后来根据测试反馈调整了表单字段顺序、增加了实时校验提示，才让界面更贴合用户习惯。此外，在适配多分辨率布局时，我学会了利用 Element Plus 的响应式工具，避免了不同设备上的界面错乱问题。这让我意识到，前端开发不仅是“实现界面”，更是“优化交互”，需多站在用户角度思考操作逻辑，才能做出真正好用的功能。

林雨（核心开发）

开发“任务-设备联动”逻辑和设备管理接口时，我深刻体会到“技术选型适配业务需求”的重要性。初期用传统方法处理任务状态同步，导致设备占用/释放延迟，后来改用 Vue 3 的响应式 API 结合后端接口实时回调，才解决了数据同步问题。同时，与林炜协作联调时，我们发现前期接口文档未明确字段类型，导致数据格式冲突，这让我明白“接口规范先行”的必要性。未来开发中，我会更注重核心逻辑的技术方案验证，提前与协作方对齐接口细节，减少后期返工。

林炜（核心开发）

实现设备使用模块接口和预约冲突检测算法后，我对“复杂业务逻辑的拆解”有了更深理解。跨天预约冲突检测最初因时间区间判断逻辑混乱，多次出现漏判问题，后来通过拆解“日期边界”“时间重叠规则”两个子问题，逐步梳理出清晰的算法逻辑。此外，协助廖鹤翔解决共享权限逻辑时，我学会了从后端权限校验角度反推前端功能设计，让前后端逻辑更统一。这让我意识到，面对复杂功能时，“拆解问题 + 跨角色沟通”是高效落地的关键，不能局限于自身负责的模块，要多关注整体业务逻辑的连贯性。

林睿（测试与验收）

整理中期功能验收清单和执行测试后，我明白了“测试是功能质量的最后一道防线”。最初测试设备管理模块时，只覆盖了常规的增删改查操作，后来在龙玉凤的提醒下，补充了“权限越界”“数据异常输入”等场景，才发现了隐藏的权限校验漏洞。同时，统计测试结果时，我学会了用“Bug 优先级分类”帮助团队快速聚焦核心问题，提升修复效率。这让我意识到，测试不仅要“找问题”，还要“懂业务”，需深入理解每个功能的业务价值，才能更精准地判断测试重点，为项目质量保驾护航。

廖鹤翔（功能优化）

细化设备共享权限逻辑和跟进功能优化建议的过程中，我体会到“用户需求是功能优化的核心依据”。最初设计共享开关时，只考虑了“是否共享”的二元逻辑，后来咨询实验室管理员后，才意识到需要区分“项目组内共享”“全实验室共享”等不同层级，这让功能更贴合科研场景实际需求。此外，与林炜协作梳理后端权限逻辑时，我学会了从“技术可行性”和“用户易用性”双维度评估方案，避免功能设计脱离落地能力。未来我会更注重前期用户调研，让功能优化更有针对性，而非单纯追求技术复杂度。

阮儒祥（文档与博客）

搭建中期项目博客和整理进度素材时，我深刻认识到“文档是项目沉淀的重要载体”。最初整理架构图示时，因未标注核心功能亮点，导致博客读者难以快速理解模块价值，后来在李嘉欣的建议下补充了图文注释，才提升了内容的可读性。同时，同步代码仓库接口文档时，我发现“文档实时更新”的重要性——前期因接口调整后未及时更新文档，导致后续查阅时出现误解。这让我明白，文档工作不是“事后补充”，而是要与开发进度同步，既要保证内容准确，也要注重呈现形式，才能让文档真正发挥“传递信息、沉淀经验”的作用。

李嘉欣（PPT 设计与素材）

设计中期汇报 PPT 和整理功能演示素材的过程中，我学到“视觉呈现要为内容服务”。最初设计 PPT 时，过于追求动画效果，反而让核心功能亮点被掩盖，后来简化动画、用“图标 + 关键词”突出重点，才让观众更容易抓取信息。此外，与阮儒祥协作整理素材时，我学会了从“汇报逻辑”出发筛选内容，优先保留与“中期成果”“核心价值”相关的素材，避免信息冗余。这让我意识到，无论是 PPT 还是其他视觉载体，都要围绕“传递核心信息”的目标，平衡美观性与实用性，才能让成果展示更高效、更有说服力。