Sprout新苗——Alpha阶段问题总结

[Sprout新苗]

这个作业属于哪个课程	https://bbs.csdn.net/forums/2401_CS_SE_FZU
这个作业要求在哪里	https://bbs.csdn.net/topics/619428294
团队名称	新苗Sprout
这个作业的目标	Alpha阶段问题总结
其他参考文献	无

目录

• 1. 设想和目标
• 1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
• 1.2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
• 1.3 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
• 1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
• 1.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
• 2. 计划
• 2.1 是否有充足的时间来做计划?
• 2.2 团队在计划阶段是如何解决同事们对于计划的不同意见的？
• 2.3 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
• 2.4 有没有发现你做了一些事后看来没必要或没多大价值的事?
• 2.5 是否每一项任务都有清楚定义和衡量的交付件?
• 2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
• 2.7 在计划中有没有留下缓冲区，缓冲区有作用么?
• 2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
• 2.9 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 3. 资源
• 3.1 我们有足够的资源来完成各项任务么?
• 3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?
• 3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
• 3.4 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
• 4. 变更管理
• 4.1 每个相关的小组成员都及时知道了变更的消息?
• 4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
• 4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
• 4.4 对于可能的变更是否能制定应急计划?
• 4.5 小组成员是否能够有效地处理意料之外的工作请求？
• 4.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 5. 设计/实现
• 5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
• 5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
• 5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
• 5.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
• 5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
• 5.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 6. 测试/发布
• 6.1 团队是否有一个测试计划？为什么没有？
• 6.2 是否进行了正式的验收测试？
• 6.3 团队是否有测试工具来帮助测试？
• 6.4 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
• 6.5 在发布的过程中发现了哪些意外问题？
• 6.6 我们学到了什么? 如果重来一遍, 我们会做什么改进?
• 7. 团队的角色，管理，合作
• 7.1 团队的每个角色是如何确定的，是不是人尽其才？
• 7.2 团队成员之间有互相帮助么？
• 7.3 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
• 8. 总结
• 8.1 你觉得团队目前的状态属于 CMMI 中的哪个档次?
• 8.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
• 8.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
• 8.4 你觉得目前最需要改进的一个方面是什么?
• 8.5 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

1. 设想和目标

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

1. 解决的问题：大学生活对于新生来说是一个全新的阶段，他们不仅要适应新的环境和改变生活方式，还需要处理社交关系、生活习惯的改变以及自我成长等多方面的挑战。然而，很多新生可能缺乏对校园生活的了解和经验，导致在面对各种问题时感到困惑和焦虑。传统的信息获取方式可能不够及时和便捷，例如询问学长学姐或在校网站查找信息等，这些方式存在信息不全、反馈慢、无法及时获取有效信息等问题。
2. 软件定义："新苗同学"是一款以帮助大学新生顺利适应校园生活为目标的移动应用。面对大学新生面临的诸多挑战和困扰，我们致力于提供一种全新的解决方案。通过整合学校资源、提供个性化服务和引导学生参与校园活动，我们的应用旨在为新生们搭建一个友好、便捷的校园生活平台。
3. 典型用户：大一新生，刚进入大学，处于适应新环境的阶段，面临许多未知的挑战，缺乏对校园生活的深入了解，情感上可能感到迷茫或焦虑。
4. 典型场景：
   1. 场景一：新生刚入学，面对一系列开学准备工作（如注册登记、领取物品、寻找宿舍等），可能感到无所适从，不知道从哪里开始。
   2. 场景二： 新生对校园内部的各个地点（如教室、图书馆、宿舍等）并不熟悉，经常迷路或浪费时间寻找。
   3. 场景三：新生缺乏自我管理和任务完成的习惯，常常错过重要的任务和活动，导致生活变得混乱。

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

原计划已全部完成。完成管理端+学生端+AI共计93个接口。前端也完成相应功能，并成功对接。我们团队充分利用项目时间，按时交付任务。

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

1. 质量提升： 和上一个阶段相比，团队的软件工程质量有了显著提升。具体体现在以下几个方面：
   1. 代码质量： 团队加强了代码审查，减少了不必要的重复代码，并通过自动化测试工具提高了代码的可维护性。
   2. 用户体验： 在UI/UX设计上，我们通过多次测试反馈和迭代，优化了界面的可用性和交互流程，使新生能够更轻松地使用应用
   3. 功能稳定性： 系统的稳定性有了明显提升，应用崩溃率和Bug数量明显减少，用户反馈更加积极。
   4. 团队协作： 团队成员之间的沟通和协作更加顺畅，分工明确，工作效率提升。
2. 衡量方式： 通过内部人员体验、BUG修复率、功能使用频率等指标来衡量软件质量的提升。

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

项目已上线，但仍然属于内部测试阶段，还未开放面向大众。在内部测试时，我们已经解决和改进已完成的重要功能。离目标必定是更近了。

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

1. 经验教训：
   1. 需求调研的重要性： 在项目初期，虽然我们对用户需求有一定的预判，但实际需求和我们最初设想的有所差距。
   2. 技术难题的预估： 在一些技术实现上，我们低估了技术难度，导致部分功能的开发周期延长。应提前做好技术可行性的评估和备选方案。
2. 改进措施：
   1. 增加迭代频率： 在开发过程中进行更多的小范围迭代和测试反馈，避免功能偏离用户需求。
   2. 技术准备： 对可能遇到的技术难题进行充分的预研，制定应对策略，减少技术开发过程中的不确定性。

2. 计划

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

在 Alpha 阶段，我们评估了时间管理和规划的充裕程度。结论显示，团队在这一阶段拥有足够的时间来制定计划。这表明当前项目时间表合理，未出现明显的时间紧迫或规划受限的情况。

充足的时间为以下方面提供了保障：

1. 目标明确性：团队能够花时间清晰定义项目的目标和优先级，确保每个成员都理解任务方向。
2. 方案可行性：有更多时间进行需求分析、可行性研究和风险评估，减少后续调整的频率。
3. 团队协调性：为内部讨论和跨部门协作留出时间，从而提高沟通效率和一致性。

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

在 Alpha 阶段，团队明确了在计划阶段处理意见分歧的策略，具体分为两种情况：

1. 小事听从组长：
   1. 对于影响范围较小或重要性较低的决策，团队选择由组长直接拍板。
   2. 这一原则能够快速推进决策过程，避免因琐事浪费过多时间，同时发挥组长对项目整体的把控作用。
2. 大事民主集中：
   1. 对于涉及项目全局、资源分配或长期影响的重要决策，团队采用民主集中制原则。
   2. 首先，充分听取每位成员的意见和建议，确保所有可能的方案都被讨论和评估。
   3. 其次，由组长或核心团队综合讨论结果，结合实际需求和团队目标做出最终决策。

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

对于Alpha阶段的工作，小组成员基本都做完了，甚至超额完成了（bushi）。

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

在 Alpha 阶段的回顾中，团队发现了一些事后看来价值有限的工作，主要体现在以下两个方面：

1. 过度深究中间件或新技术：
   1. 在开发过程中，团队尝试使用了一些不熟悉的中间件或新技术，原本目的是提高模块的性能或扩展性。
   2. 然而，由于缺乏经验，在研究和探索这些技术时耗费了过多时间，导致相关模块的开发进度滞后。
   3. 结果，这一滞后影响了与其他小部门的同步进度，引发了一些前后端对接上的问题，例如数据接口未能按时完成或功能测试延误。
2. 对项目的实际价值有限：
   1. 部分技术的实际收益未达到预期，或者在当前阶段并非必要。例如，某些性能优化的需求可以留待后期迭代，而非在 Alpha 阶段投入过多资源。

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

在 Alpha 阶段，团队在任务定义和交付件管理方面表现出色，所有任务均有明确的交付标准和衡量依据。这一做法为项目的高效推进和质量保障奠定了基础。具体体现如下：

1. 清晰的需求分析：

在任务启动前，团队完成了详尽的需求分析，将用户需求转化为可执行的任务目标。需求文档包括功能描述、优先级和验收标准，确保所有成员对目标有一致的理解。

1. 接口文档：

2. 后端团队为每个接口编写了详细的接口文档，包含请求方法、参数说明、响应格式和错误处理等内容。这些文档在前后端对接时起到了关键作用，避免了因信息不对称导致的开发延误和返工问题。

3. 数据库设计：

4. 数据库设计在开发初期就已完成，定义了数据结构、表关系及约束条件，为后端逻辑开发提供了坚实基础。数据库设计文档清晰记录了每张表的字段含义和用途，确保后续扩展或修改时有据可依。

5. 后端以接口为单位交付：

6. 后端团队采用模块化开发方式，每个接口作为独立交付单元。每个接口交付后都会经过严格测试，包括功能测试和边界条件验证，确保符合需求文档中的验收标准。

7. 前端以组件为单位交付：

8. 前端团队将用户界面划分为多个独立的组件进行开发，每个组件对应特定的功能或界面元素。组件开发完成后通过组件库或演示页面展示交付成果，方便进行单独测试和后续集成。

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

在 Alpha 阶段，项目整体按照计划推进，但仍然面临了一些意外问题和未能提前识别的风险。

1. 计划执行情况：
   1. 项目整体按照计划顺利进行，核心功能开发和测试未受到重大阻碍。
   2. 开发过程中出现了一些小 bug，这些问题均通过及时修复得以解决，未对大局造成影响。
2. 项目中的意外问题：
   1. 中间件重新部署：部分中间件在实际运行时未达到预期效果，团队需重新配置和优化，导致部署时间略有延长。
   2. 服务器性能问题：原计划的服务器配置未能满足实际运行需求，出现了性能瓶颈（如高并发场景下的响应延迟）。最终，团队决定迁移到新的服务器进行部署，避免了进一步影响项目进度。
3. 未能预估的风险：
   1. 服务器性能问题：团队在早期阶段的规划中未充分考虑服务器性能需求，忽视了高并发场景的压力测试和负载评估。
   2. 未能估计到的原因：
      • 主要原因是项目初期重点聚焦在功能开发和模块实现上，缺乏对基础设施（如服务器配置）的深入分析。

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

计划中预留了缓冲区，但因实际进度完成较快，缓冲区并未发挥实质作用。不过，缓冲区在心理上为团队成员提供了较大的支持，缓解了开发过程中可能产生的时间压力，让大家更从容地完成任务。

2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

• 增加缓冲区：预留更多的缓冲时间，以便在遇到意外问题时能够从容应对，避免因赶进度带来的额外压力和混乱。
• 避免冲刺阶段任务叠加：将 PPT 等展示性工作的时间前置，避免与开发任务冲突，确保代码和展示材料均有充分时间完成，避免因冲刺阶段修改代码而影响最终成果展示的质量和效率。

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

通过这次项目的经验，我们学到了以下几点：

1. 合理规划时间和缓冲区的重要性：虽然我们预留了缓冲区，但在实际过程中进度完成较快，缓冲区未发挥实质作用。不过，缓冲区为团队带来了心理上的支持，使大家在遇到问题时能够保持冷静。在未来的计划中，我们会增加更多的缓冲时间，确保在遇到意外问题时可以从容应对，避免匆忙赶进度带来的不必要压力。
2. 明确基础设施的需求和风险预判：这次项目中，服务器性能问题和中间件的调整提醒我们，早期的基础设施规划非常关键。未来会加强对服务器性能的预估，避免项目后期因服务器配置不当影响进度。
3. 前后端工作协调的重要性：文档和接口设计对团队协作至关重要，今后将进一步优化文档管理和共享机制，确保前后端能无缝对接。

如果历史重来一遍，我们会提前做好服务器性能的评估、增加项目的缓冲时间，并确保任务能够合理分配。通过这些改进，我们的新苗团队可以更加高效地运作，减少意外问题对进度的影响，提升整体工作体验和成果质量。

3. 资源

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

从当前的资源配备和执行情况来看，我们的资源是充足且合理的：

1. 人力资源：团队配置齐全，各模块均有明确负责人，协作顺畅，鲜少出现瓶颈。
2. 时间资源：项目计划合理，任务分配明确，整体进度在预期范围内，且保留了一定的缓冲时间。
3. 硬件/软件资源：测试和开发环境完善，设备覆盖面广，能够支持多平台和多机型的需求。

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

时间和资源估算的准确性较高，以下几点值得肯定：

1. 估算基于过往项目经验，结合敏捷方法中的小步迭代，使得误差范围较小。
2. 充分考虑了需求变更的可能性，预留了灵活调整的空间。
3. 核心任务优先级明确，各阶段按时完成，未出现明显超时或资源浪费的情况。

目前来看，80%-90%的任务都能在估算范围内顺利完成，精度令人满意。

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

测试和非技术性资源安排充分：

1. 测试环节：时间、人力和设备充足，回归测试和兼容性测试均有条不紊地进行。
2. 美工设计/文案：设计团队与文案团队配合流畅，任务完成质量和效率都符合预期，未出现资源低估的情况。

测试和设计环节与整体开发流程衔接良好，基本没有问题。

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

目前项目推进顺利，有一些值得总结的经验：

1. 需求分析：清晰的需求冻结时间点确保了开发工作的高效推进，减少了后期变更的影响。
2. 资源预留：适度的资源冗余为应对突发情况提供了保障，是一个成功的决策。
3. 团队协作：定期的团队沟通和任务梳理确保了整体节奏一致，是效率提升的关键。

如果重来一次：我们可能会进一步优化需求分析阶段的效率，使整个规划更加简洁，但整体方案无需大的调整。

4. 变更管理

4.1 每个相关的小组成员都及时知道了变更的消息?

是的。我们通过以下方式确保变更信息的及时传递：每天一次的项目组全员会议，总结进度并通报变更情况。此外还会使用QQ或飞书等工具，确保消息即时传递。

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

与核心目标直接相关的功能优先完成，例如学生端的任务大厅与管理端的任务审核模块。提高学生与管理员使用效率的功能，例如自适应布局与仪表盘统计界面，被定义为“必须实现”。功能的技术复杂度和可用资源评估决定是否推迟，如AI相关功能部署较复杂，但对主线业务的影响较小，部分被推迟。对系统性能或安全性有重大影响的功能，如用户鉴权与数据安全模块，始终优先实现。

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

有清晰的定义。每项功能需要通过完整的单元测试、集成测试和用户验收测试。前端自适应布局与设计稿完全一致，兼容主流设备。系统经过压力测试和长时间运行测试，错误率低于 1%。技术文档、用户手册与部署手册均齐全。 这些出口条件为我们的里程碑验收提供了明确标准。

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

可以。系统架构采用高内聚低耦合设计，使模块变更对其他部分影响最小。在开发过程中通过使用Git分支策略（如主干开发+功能分支），确保变更独立处理，减少冲突。

4.5 小组成员是否能够有效地处理意料之外的工作请求？

小组成员能够较好地处理意料之外的工作请求。首先小组内的每个小组成员对其负责的模块有足够了解，对于需要预料之外的工作需求会互相沟通，及时交互，保证任务的完成。通过对接其他团队（如AI团队与后端团队），及时获得技术支持。 尽管偶尔出现延误，但整体效率较高，未对项目进度造成重大影响。

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

在项目开发的过程中，我们学到了变更沟通的重要性，会通过规范化的变更流程，避免了信息不对称。同时，模块化、灵活的架构设计为我们应对需求变更提供了保障。此外我们合理划分了“必须实现”和“可以推迟”的功能，确保项目主线顺利推进。

如果历史重来一遍,我们会更早规划AI功能，因为AI相关功能较为复杂，若能提前介入，将减少后期整合压力。而且还需要优化测试流程，在开发中更多地使用自动化测试工具，以提升测试效率并减少人工出错几率。最后我们会增强资源配置的灵活性，以保证在关键任务开发阶段，增派更多资源以减轻压力。

5. 设计/实现

5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在需求分析阶段和概要设计与数据库设计阶段完成。其中UI设计由梁心恬完成，客户端系统架构设计、学生端功能模块设计、UML设计由徐煜晖完成，前端系统架构设计、管理端功能模块设计由吴荣榜完成，后端系统架构设计、接口设计由翁鹏和徐文彬完成，AI系统架构设计、AI功能模块设计由叶宇滟完成，数据库设计、数据库验收标准设计由连文桢、杨知麟、陈宇共同设计。团队成员具备相关的设计经验，能够胜任设计任务，但是在一些细节的处理上可能因为需求不够明确导致设计上略有瑕疵。如果能更早引入设计环节，并且团队成员能进一步沟通交流、相互帮助，相信能够完成得更好。

5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有碰到，比如原型设计与某些功能对不上、接口设计的请求参数与返回结果的格式上有分歧等。面对这些情况，我们团队有时会直接开线上的飞书会议来进行讨论、或者直接在群里提问然后其他队员一起沟通解决。

5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

我们团队用了IDEA自带的单元测试配合Junit对后端的一些核心业务逻辑进行了测试，但因为时间问题，测试覆盖率还不够高。我们在设计阶段还使用了StarUML画了用况图和类图，但实际开发中因需求变化和技术调整， UML 文档有更新但是不及时。关于工具的使用，我们还用了apifox来测试后端接口、为前端提供mock数据，使用墨刀完成移动端和管理端的原型设计，这些工具都有效提高了我们团队的开发效率和协作质量。

5.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

Bug最多的地方是任务的创建，因为输入的数据较多，可能开发时漏了不少数据边界的校验、有些特殊输入没处理好，然后任务创建的后续逻辑较为复杂，一些情况没有考虑周到。这些Bug其实有的可以通过更充分的测试提前发现，有的可能是我们当时没想到用户会这么用。下次可能要花更多时间在测试和用户场景模拟上。

5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

Code Review是在codeart上对新pr的代码进行审查，代码确定无误后才允许合并。虽然有规范，但有时候为了赶进度，审查可能不够细，比如变量命名、注释这些小问题有时候会漏掉。核心功能部分还是挺严格的，但一些边角功能可能就稍微放松了。如果再来一次，应该会更重视整体的规范统一，尤其是加班赶工的时候也不能偷懒。

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

我们学到了需求明确的重要性，模糊的地方往往会在后期变成返工；测试覆盖也很关键，特别是边界情况和用户的特殊操作；文档需要及时更新，不然设计和实现对不上会影响效率。如果重来一遍，我们会在需求阶段花更多时间明确细节，在测试上覆盖更多场景，尤其是复杂输入和性能优化，同时保证设计文档和实际实现同步更新，让后续工作更顺畅。

6. 测试/发布

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

团队是有测试计划的，具体内容可以参考我们的Sprout新苗——测试随笔。

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

是，为了确保项目能够全面满足既定的验收标准，全体团队成员实施黑盒测试。通过这种方法，我们能够从最终用户的视角出发，对系统的功能完整性、性能稳定性以及用户体验等方面进行全面评估，从而保证软件产品在交付前达到最优状态。

6.3 团队是否有测试工具来帮助测试？

是，团队采用 Apifox 作为主要测试工具，在接口测试和自动化测试方面取得了显著成效，整体效率较传统的部署后测试方式有了大幅提升。利用 Apifox 的 API 文档管理功能，我们在开发初期定义好接口规范，确保前后端开发人员对需求理解一致，并快速生成测试用例，覆盖各种输入条件和边界情况。同时，Apifox 强大的调试工具使开发人员能够在编写代码的同时即时验证接口行为，减少了后期调试的时间成本。我们构建了自动化测试套件，并将其集成到 CI/CD 流程中，确保每次代码提交后都能自动运行测试，快速发现潜在问题。通过这些措施，我们不仅大幅缩短了测试周期，提高了测试结果的准确性和一致性，同时在开发阶段就能及时发现和修复问题，避免了后期大规模返工，降低了项目风险。

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

通过 JMeter 对后端接口进行压力测试，主要模拟高并发请求、批量数据处理和复杂事务流程，测试后端的承载能力和性能瓶颈；通过 Locust 对 AI 部分接口性能进行压力测试，主要模拟用户行为，评估用户请求的响应时间以及并发访问的稳定性。

从软件实际运行的结果来看，这些测试工作是有用的，帮助团队了解系统的性能表现和稳定性，目前没有失败请求，说明基础功能运行良好。但部分接口响应时间较长，存在优化空间。

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

页面加载时间延长、功能操作反应迟钝，甚至在高并发情况下系统无法及时响应用户请求。

6.6 我们学到了什么? 如果重来一遍, 我们会做什么改进?

在软件开发过程中，尽早发现和解决问题比后期集中修复更加高效且成本更低。开发过程中忽略的细节或未注意到的错误，往往会在前后端集成时暴露出来，延误进度并增加修复难度。

如果重来一遍，我们的前后端开发人员将会更频繁地沟通和同步接口文档，避免因理解偏差而导致的问题，在开发初期增加小范围的集成测试，逐步覆盖更多功能，减少集中调试的工作量和风险。

7. 团队的角色，管理，合作

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

是的。我们根据每个人擅长的技术栈进行任务分工，确保每个人都能够在自己擅长的领域完成工作。

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

有的，比如我们的后端不止一人，然后后端出问题的时候，都是大家一起排查的，在解决问题上互帮互助。

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

首先在群里提出这个问题，然后大家一起协商看看要怎么解决，基本上就是及时把问题提出来，然后一起商量一个解决方案，这样子矛盾就不会积攒。

8. 总结

8.1 你觉得团队目前的状态属于 CMMI 中的哪个档次?

量化管理级。在新苗同学项目的开发过程中，整个过程有预先的计划，并通过每日commit、站立式会议等方式得以量化，项目进度通过燃尽图体现，能够预测项目结果。

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

创造阶段。新苗同学团队有共同而清晰的目标，而且各自分工明确，达到了高度自治。团队内各成员地位平等，遇到问题或者有不同的意见时，会以平和的心态进行讨论，找到共同观点，进而得到解决方案。成员的积极性比较高，愿意主动承担任务、完善已有成果。

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

相比团队建立之初，在为项目的明确目标努力的过程中，团队成员间的凝聚力、沟通能力得到了提高。此外，成员的代码能力也获得了相应的提高。

8.4 你觉得目前最需要改进的一个方面是什么?

代码能力的提升。部分成员对于所接触的技术栈可能是新手，在10天的Alpha阶段后都已基本熟悉，但如何做到精准编程，降低问题率，仍然是我们需要持续思考的问题。

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

代码管理与代码质量方面，后续可以考虑引进代码互审、代码重构等措施加以改进。

程序架构上，要遵循面向对象的架构设计准则，包括单一职责原则、依赖倒置原则、接口隔离原则等等，当发现代码出现劣化的时候，及时地进行重构。

工具应用的方面，我们应该利用工具提高自动化率。例如用ApiFox实现自动化测试、文档自动化，用飞书实现项目进度管理，等等。

项目管理方面，争取在后一阶段的每日会议上提升效率，用更短的时间明确今日进展和明日需求。