事后诸葛亮分析报告

事后诸葛亮分析报告

这个项目属于哪个课程	课程链接
作业要求	作业链接
作业的目标	Alpha阶段项目复审以及事后诸葛亮分析报告
Github链接	仓库地址

在 Alpha 阶段结束后，团队召开了项目事后诸葛亮会议，对整个迭代周期中的任务分配、协作过程、问题暴露及改进方向进行了集中回顾。本次会议以《构建之法》第 15 章提出的“事后诸葛亮会议”为指导，重点分析 哪些地方做得好、哪些地方可以做得更好，以及为什么会这样。

---

一、项目整体回顾

本项目广工枢纽旨在为广东工业大学师生提供一个一站式校园信息整合与智能查询平台。针对校园内通知公告分散在多个官网、更新频率高、查找成本大的现实问题，我们尝试通过技术手段对校内公开信息进行统一整合，并以更加友好的方式呈现给用户。

在系统设计上，项目以“信息集中 + 智能问答 + 分类检索”为核心目标。后端通过爬虫程序自动采集校园通知、水电服务、教务信息等公开数据，并对原始文本进行清洗、结构化处理，构建本地知识库；在此基础上，引入大语言模型能力，实现对自然语言问题的理解与回答。前端则采用问答模式与栏目模式并行的交互设计，使不同需求层次的用户都能快速获取所需信息。

在 Alpha 阶段，团队围绕既定目标完成了系统核心功能的实现，包括：

• 校园多来源通知数据的爬取与更新；
• 本地知识库的构建与统一接口封装；
• 问答模式下基于大模型的意图识别与内容生成；
• 栏目模式下通知公告的分类展示、分页与过滤；
• 前后端接口联调与基础异常处理；
• 核心功能的测试用例设计与功能验证。

从整体完成情况来看，项目中规划的大部分核心功能已经实现并可稳定运行，系统能够支持典型用户（如本科生、研究生、教师、新生等）完成常见的校园信息查询任务。虽然在性能优化、统一部署和高级功能扩展方面仍有待完善，但作为 Alpha 版本，“广工枢纽”已经具备了较为完整的产品形态和明确的发展方向。

通过本次迭代，团队不仅完成了一个从需求分析、设计、实现到测试的完整软件工程实践，也在真实协作过程中体会到模块分工、接口约定与持续沟通对项目成功的重要性。

二、Alpha 阶段团队角色与贡献评估

姓名	角色	团队贡献分（共20N）	可验证的贡献
王韵清	后端 / 算法	20	设计并实现多网站适配爬虫；完成大模型 API 调用与问答主流程；主导数据库初始化流程，支撑系统核心能力
曾钰仪	后端 / 算法	20	设计关键词划分与时间信息提取函数；参与问答接口本地调试；参与知识库结构整理
徐伊彤	后端 / 算法	20	负责数据清洗规则设计与正则化增强；重构接口与知识库结构并完成前后端对接
吴佳童	前端	20	实现问答模式与栏目模式的前后端联调；参与接口格式讨论；完成核心交互逻辑对接
张洁	前端	20	负责栏目模式接口重新规定；完成数据过滤、分页逻辑与页面优化；根据测试结果进行代码调整
李恺凝	UI / 前端协作	20	设计并优化 UI 原型；配合前端完成问答与栏目页面的视觉与交互一致性调整
戴军霞	测试	20	主导测试计划制定；编写并执行多项测试用例；完成 Alpha 阶段测试文档并推动问题修复

在 Alpha 阶段项目开始时，团队在充分讨论后，有意将工作任务进行等量、等重要性的分配，希望在最后可以拥有相同的分数。不仅是希望可以让大家更有动力，更是对每位组员能力的认可。每位成员都在自己负责的方向（前端、后端、算法、UI、测试）中承担了不可替代的核心职责，并且在整个迭代周期内均按时完成了分配任务，没有出现明显的工作缺失或投入不足的情况。

从团队协作的角度来看，我们认为 Alpha 阶段的成果是高度协同的结果：

• 后端功能无法脱离前端展示而体现价值
• 前端交互依赖稳定接口才能完成
• 测试工作贯穿始终，对系统稳定性同样关键
• UI 与产品设计直接影响系统的可用性与完成度

因此，如果仅从“是否完成任务”“是否对项目成功产生关键影响”这两个核心标准出发，所有成员在 Alpha 阶段的贡献是同等重要的，团队最初一致认为给予相同评分是最公平、最符合真实贡献情况的做法，团队希望可以成员完全同分。

三、做得好的地方

• 前后端沟通及时，接口在 Alpha 阶段完成统一
• 问答模式与栏目模式均形成完整闭环
• 测试介入较早，避免问题集中爆发
• 本地部署方案保证了系统灵活性与安全性
• 整体流程规划正确，没有出现算法等数据或者前后端相互等待的空窗期

四、可以改进的地方

• 接口文档在早期仍可更规范
• 爬虫适配成本偏高，后期可考虑模板化
• 测试自动化程度有待提升
• UI 与功能设计的同步程度仍可加强，缺乏大量真实用户的实际体验

五、总体复盘

设想和目标

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

   软件旨在为校园用户提供信息整合和智能问答服务，解决信息分散、查询成本高的问题。针对大学生、教师及校外人员等典型用户，系统提供问答模式和栏目模式，清晰描述了各类使用场景。

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

   核心功能大部分按计划完成，包括问答模式、栏目模式、爬虫和知识库构建，功能按预期时间交付。Alpha 阶段用户主要为团队内部，验证了功能可用性和稳定性。

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

   相比前一阶段，项目结构更清晰，前后端接口设计规范，代码可读性和模块化水平提高，Bug 数量减少，功能稳定性增强。通过代码检查和测试覆盖率可量化改进。

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

   用户量有限，但核心功能使用体验符合预期，问答和栏目功能可顺利访问，用户反馈显示对信息获取方式满意，功能实现已接近最终目标。

计划

1. 是否有充足的时间来做计划？团队如何解决不同意见？

   时间有限但合理分配，计划阶段通过讨论和协商解决团队对任务优先级和分工的不同意见。

2. 是否原计划的工作都完成了？如果没完成，原因是什么？

   大部分任务按计划完成，少量非核心功能未实现，主要因时间和资源有限。

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

   绝大多数任务有明确的功能交付标准，部分任务在细节上仍需明确。

4. 项目整个过程是否按照计划进行，有什么意外？

   大体按计划推进，但部分接口联调和环境配置出现意外，需要临时调试。

资源

1. 资源是否充足？估计精度如何？

   人力和技术资源基本足够，但测试和部分开发模块经验不足导致估计偏乐观。

2. 测试资源是否充足？

   功能性测试足够，但性能和自动化测试不足，部分测试依赖人工完成，效率偏低。

变更管理

1. 员工是否及时知晓变更？

   通过即时沟通和会议同步大部分变更。

2. 如何决定“推迟”和“必须实现”的功能？

   根据功能优先级和实现难度，由 PM 统一决策。

3. 出口条件（Exit Criteria）是否清晰？

   核心功能完成、接口可用、基础测试通过即可认定 Alpha 版本完成。

设计/实现

1. 设计由谁完成？是否合适？

   设计由核心成员在开发前期完成，时间和人员安排基本合适。

2. 设计中是否遇到模糊情况，如何解决？

   碰到接口和数据结构模糊时通过讨论和小范围试验解决。

3. 是否使用单元测试、TDD 或 UML 等工具？

   使用了 UML 设计文档和基础单元测试，但未系统应用 TDD，设计与实际实现略有差异。

4. 哪些功能产生的 Bug 多？为什么？

   数据处理和接口交互模块产生的 Bug 较多，主要因数据格式和接口约束复杂。

5. 代码复审是否严格执行？

   复审为非正式执行，整体遵循编码规范，但深度不足。

测试/发布

1. 是否有测试计划？进行验收测试了吗？

   有基础测试计划，进行了功能验收，但自动化测试和性能压力测试不足。

2. 测试工具和方法是否有效？

   手动测试为主，发现问题及时修复，但效率不高，计划后续增加自动化测试。

3. 发布过程中发现的问题？

   主要为环境配置和依赖版本差异，需用户本地调整。

4. 如果重来一遍，会做哪些改进？

   增加自动化测试覆盖，提前明确接口规范和交付件，优化计划缓冲区和资源分配，提高文档和沟通效率

六、收获与反思

1. 项目收获

通过本次“广工枢纽”项目的 Alpha 阶段开发，团队在技术能力与工程认知两方面都获得了显著提升。

在技术层面，团队成员首次较为完整地实践了一个前后端分离、数据驱动、结合大语言模型能力的校园信息系统。从爬虫数据采集、文本清洗与知识库构建，到接口设计、前端展示以及测试验证，各模块之间形成了清晰的依赖关系，使成员更加直观地理解了真实软件系统的整体运作方式。尤其是在前后端联调和接口规范制定过程中，团队深刻体会到接口设计对系统稳定性和开发效率的关键作用。

在工程与协作层面，本项目让团队成员切实感受到敏捷开发与持续沟通的重要性。在 Alpha 阶段的多次迭代中，需求并非一开始就完全明确，而是随着实现过程不断调整与细化。通过站会讨论、任务拆分与及时反馈，团队能够快速发现问题并进行修正，避免了单点失误对整体进度造成较大影响。同时，测试工作与开发同步进行，也帮助团队提前暴露潜在问题，提高了最终交付质量。

2. 问题反思

在总结收获的同时，团队也清醒地认识到项目中仍然存在一些不足。

首先，在需求规格说明书的早期版本中，对部分边界场景和异常情况考虑不够充分，导致后期需要对接口和功能进行一定程度的调整，增加了返工成本。这提醒我们在后续阶段应更加重视需求阶段的完整性和可验证性。

其次，当前系统在部署方式和性能优化方面仍较为基础，例如后端需用户自行部署、并发处理能力有限等。这些问题在 Alpha 阶段是可以接受的，但在未来版本中需要通过统一部署、缓存机制和更完善的异常处理来进一步改进。

最后，团队在时间管理上仍有提升空间。部分功能在临近迭代尾声时集中完成，增加了测试与修复的压力。未来应更均衡地安排开发与测试节奏，减少集中交付带来的风险。部分功能在临近迭代尾声时集中完成，增加了测试与修复的压力。未来应更均衡地安排开发与测试节奏，减少集中交付带来的风险。