[T.13] 团队项目：Alpha 阶段项目总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.13] 团队项目：Alpha 阶段项目总结
我在这个课程的目标是	学习软件工程的基础知识，和团队成员们实践各种软件工程的方法与流程，开发一个让我们值得骄傲的项目
这个作业在哪个具体方面帮助我实现目标	对Alpha 阶段项目开发进行总结

一、设想与目标回顾

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

   企业或个人用户难以构建高质量问答系统，尤其是基于内部文档/知识的RAG（Retrieval-Augmented Generation）流程。企业缺乏高效的知识管理和问答服务集成手段，存在数据隔离、权限管理和系统对接困难。个人用户 在学术场景中文献整理与问答效率低，缺少可信引用的自动总结工具。

   定义的很清楚。

   描述非常清晰。对B端企业用户（如IT负责人老王）和C端个人用户（如研究生小李）都给出了完整的使用流程、动机与效果。应用场景覆盖了上传文档、配置Pipeline、接入业务系统、智能问答等关键步骤，强调了实际的使用痛点与解决成果。

2. 我们达到目标了么

   Alpha 阶段功能基本完成，核心模块均已实现，满足了最初的功能目标。

   按照原计划交付时间交付了。

   尚未进行大规模用户测试，邀请了B端用户进行了测试，C端用户较少。因此暂未达到原计划设定的用户数量目标。

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

   • 有提高：
     项目采用了更规范的模块化架构与统一接口（MCP 协议），提升了系统扩展性与可维护性。
     • 引入统一工作流框架，便于功能复用和迭代。
     • 代码结构更清晰，模块职责分明。
     • 开发流程更规范，PR 与 Code Review 严格执行。
   • 衡量方式：
     迭代效率提升，代码质量问题减少

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

   • 用户量：邀请了B端用户，C端用户较少，用户量有待提高。

   • 用户接受度：早期反馈显示用户对核心功能认可度较高，符合预期。

   • 目标进展：整体方向正确，技术架构和功能实现符合预期，距离大规模推广和用户增长目标还有一定距离。

5. 经验教训

   • 项目初期对需求变更控制不足，导致部分资源浪费。

   • 如果重来一遍，我们会：

     • 在设计初期引入更多用户反馈；
     • 引入更好的自动化测试框架进行充分的测试。

二、计划执行分析

1. 是否有充足的时间来做计划?
   初期有相对充足的计划时间，但中后期由于临时任务增多，导致时间不足。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   对于重要的时间节点会进行线下会议，团队主要通过线上会议和文档记录进行充分讨论，最终由pm做出最终决策。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   原计划中约90%的任务完成，部分任务因时间和资源限制被延期。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   发现部分页面样式的微调工作对用户体验影响较小，事后认为这些工作优先级可以降低。

5. 是否每一项任务都有清楚定义和衡量的交付件?
   除少数临时任务外，大多数任务都有明确的交付标准和验收定义。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   项目整体较为顺利，但出现了人员临时离岗和第三方接口调整的意外，未能提前预估，主要是因为对突发人员变动和外部依赖的风险准备不足。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?
   计划中预留了缓冲区，后期确实发挥了兜底作用，但缓冲时间总体偏少。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
   未来计划将增加合理的缓冲时间，针对关键任务设定备用方案，并优化风险预测机制，减少加班压力。

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

   • 经验教训：

     计划阶段需要更加充分，尤其是预留足够的缓冲时间，防止突发事件影响进度。

     对潜在风险（接口调整或临时添加功能）要提前进行更全面的评估和预案准备。

     任务优先级的设置应更加合理，避免资源浪费在影响较小的任务上。

   • 改进措施：

     加强计划的风险管理和应急方案设计。

     明确任务优先级和资源分配，减少无效或低价值的工作。

     增加缓冲时间，特别是在关键节点设定备用方案，确保项目进度的稳定性。

三、资源使用情况

1. 我们有足够的资源来完成各项任务么?
   开发和测试资源基本满足需求，但UI设计和评测人员相对不足。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   开发时间估算较为准确，但UI设计和测试环节的工作量被低估，导致资源分配不均。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   测试时间较为紧张，手动测试占比较高，文案和设计相关资源的难度和工作量明显低估。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?
   是的，一些技术含量较低的任务如资料整理和文案编写，可以交由PM完成，释放核心开发人员的时间。

5. 经验教训及改进：
   未来应更加精准估算各环节资源需求，合理分配任务，提高整体效率。

四、变更管理

1. 每个相关的员工都及时知道了变更的消息?
我们采用Git与飞书文档进行任务分布管理，确保每次变更都被系统记录并通知到相关成员，信息传达及时。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
通过影响评估和需求评审会议，对功能优先级进行讨论，决定是立即实现还是推迟。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
项目文档中明确规定了出口条件，包括功能完整性、性能指标达标以及无P1级严重缺陷。

4. 对于可能的变更是否能制定应急计划?
关键路径任务设有应急方案，但部分突发事件如外部依赖变更未完全覆盖。

5. 员工是否能够有效地处理意料之外的工作请求？
团队依靠良好的沟通与互助机制，能够较好地快速响应突发请求。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们认识到应急预案需要更全面，尤其要涵盖外部依赖和突发变化。未来将加强变更风险的提前评估和应急方案设计，确保项目更稳健，同时优化信息传递流程，避免遗漏关键人员。

五、设计与实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作由PM和队员们协商，时间安排合理，人员匹配恰当。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
遇到模糊问题时，会通过线下面对面讨论的情况进行解决。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
团队主要使用了 Apifox 进行接口设计与测试，结合前端单元测试（Jest + Vitest）和部分TDD实践，整体效果良好。项目后期实现与初期设计存在一定偏差，需及时更新文档以保持同步。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
pipeline联调的过程中出现的bug最多，因为模块是由不同的人设计并编写的。发布之后没有什么重要的bug，大部分都是前后端接口对接的小bug。设计和开发的时候有一些需求比较模糊，给了各模块开发者自由度，但这样在对接的时候会产生一些细节上的问题需要调整。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
Merge代码时，复审流程严格执行，显著提升了代码规范和一致性。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
认识到设计阶段需加强对模糊需求的梳理和边界条件的预判。未来将更加重视测试覆盖全面性，及时同步更新设计文档。代码评审继续保持严格，并增加自动化测试力度，提升整体质量。

六、测试与发布

1. 团队是否有一个测试计划？为什么没有？
团队有较为明确的测试计划。每个人首先对自己负责的模块进行单元测试，随后将这些模块串联进行联调测试。

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

3. 团队是否有测试工具来帮助测试？
目前手动测试占比较大，团队使用Apifox进行接口测试。未来计划完善自动化测试报告和结果差异比对，进一步提升测试效率和质量。

4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
使用JMeter进行接口压力测试，发现并发超500时响应时间明显延迟，基于测试结果对数据库索引进行了优化，效果显著。测试工作有效，但需增强持续监控和自动化性能测试覆盖。

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

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

• 测试计划需更早制定并强调自动化测试比例，减少手动测试负担
• 使用更多的工具链来丰富测试环节

七、团队协作与角色管理

1. 团队的每个角色是如何确定的，是不是人尽其才？
团队角色根据成员的专业能力和经验进行合理分配，确保大多数岗位人尽其才，发挥各自优势。

2. 团队成员之间有互相帮助么？
团队氛围良好，成员之间积极互助，协同工作频繁，整体效率较高。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
通过定期例会和飞书、微信等及时沟通解决问题，同时开展定期回顾会议，促进问题的快速收敛和改进。

对于其他组员帮助的感谢）

吴佳峻：感谢钟芳梽和熊晓焜同学能够准确定位ddl时间节点，督促大家及时完成任务
熊晓焜：感谢叶佩霖同学对前端的充分调研与深度参与，让前后端开发步调一致
钟芳梽：感谢大伙的相互合作，让接口对接顺利
林宇浩：感谢大伙的团结合作，互帮互助，让项目进展顺利
范兴堃：感谢大家的共同努力，让项目进展顺利
陈叙传：感谢大伙的不懈努力，团结协作，让项目进展顺利
叶佩霖：感谢大家的共同努力，让前后端接口对接顺利

八、总结与反思

1. 团队目前的CMM/CMMI档次
   团队目前处于 CMMI Level 2，流程和规范逐步建立，但执行仍存在不一致的情况。
2. 团队当前的发展阶段
   团队处于规范阶段向创造阶段过渡期，协作和流程逐渐成熟。
3. 相比前一里程碑的改进

​ 这可以算是本项目的第一个重要的里程碑（欢呼）

• 工具链逐渐完整，覆盖设计、测试和管理
• 流程更加规范，任务分工和完成都更加规律
• 团队成员间的默契和协作效率进步明显

目前最需要改进的方面
计划的可执行性与变更管理能力，需要提升预估的准确度，并完善应对变更的机制。

对照敏捷开发原则，团队做得最好的几个原则及具体事例：

• 团队成员之间关系融洽，遇到问题能够快速讨论并达成一致
  每次迭代都保持高频的面对面或即时沟通，快速解决问题。
• 欢迎需求变更
  保留需求灵活调整的空间，适时响应用户反馈和市场变化。

团队下一阶段提高软件工程质量的方向：

1. 代码管理的质量提高

• 引入更细粒度的代码规范，如命名、注释、代码格式等具体规则
• 加强Code Review制度，确保每次合并均有评审并记录审查意见，支持回溯与改进
• 引入静态代码分析工具辅助规范执行

2. 项目管理的具体提升

• 任务拆解更加细致，明确负责人和时间节点
• 加强风险识别和变更应急机制建设

3. 用户数据跟踪的计划改进

• 除了B端用户外还要寻找C端用户进行项目测评
• 利用数据可视化工具生成直观的表，用于分析用户的行为等

4. 项目文档

​ 制定统一文档模板，规范文档内容和格式

5. 人的领导与管理改进

​ pm与组员进行点对点沟通，建立定期1对1沟通机制，实时关注项目进度

6. 软件工程理论的心得体会

• 敏捷原则对早期团队和快速迭代非常有效，但大型复杂项目需要结合规范流程，二者互补
• 理论应用应结合实际情况灵活调整，避免盲目形式主义，注重落地效果
• 持续改进和反馈循环是软件工程成功的关键

全组讨论图片