哈基米队——alpha阶段问题总结

哈基米队 2025-11-10 18:45:29

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	团队作业——事后诸葛亮
团队名称	哈基米
这个作业的目标	alpha阶段问题总结随笔
其他参考文献	邹欣老师博客：项目管理 - 事后诸葛亮会议

1.设想和目标
1.1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
1.2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
1.3有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
2.计划
2.1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
2.2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
2.3. 是否每一项任务都有清楚定义和衡量的交付件?
2.4. 是否项目的整个过程都按照计划进行?
2.5. 在计划中有没有留下缓冲区，缓冲区有作用么?
2.6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
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. 设计与实现的辅助工具及效果
5.4. Bug高发功能、后期发现的重要Bug及原因
5. 代码复审与代码规范执行
5.6学到的经验与改进方向
6. 测试/发布
6.1. 测试计划及有无的原因
6.2. 正式验收测试执行情况
6.3. 测试工具使用情况
6.4. 软件效能测量跟踪及测试工作改进
6.5. 发布过程中的意外问题
6.6学到的经验与改进方向
7.总结:
7.1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
7.2.你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
7.3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
7.4.你觉得目前最需要改进的一个方面是什么?

1.设想和目标

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

1.解决的问题
交易渠道分散且低效：学生此前依赖论坛、社交媒体、QQ 群等非专用渠道交易，信息杂乱（如同一物品重复发布、下架信息不及时），查找需逐屏筛选；线下摆摊受时间（如毕业季仅短期开放）、空间（如宿舍楼下定点）限制，供需匹配效率低。
交易安全与信任缺失：非专用渠道缺乏身份验证与监管，易出现 “货不对板”（如二手教材缺页未标注）、收款不发货、售后无保障等问题；学生个人信息（如手机号、宿舍地址）在沟通中直接暴露，存在泄露风险。平台通过三重机制保障安全：一是账号与校园身份绑定，管理员审核用户资质；二是交易流程闭环，支持 “下单 - 支付托管 - 确认收货 - 放款”，避免直接转账风险；三是信息加密，隐藏用户隐私信息，沟通在平台内置消息模块完成，无需透露私人联系方式。
物品与交易管理困难：学生无法系统管理闲置物品，如发布后难追踪浏览量、售罄后忘记下架导致无效咨询；学校缺乏监管手段，对违规商品（如大功率电器）、虚假交易难以把控，易引发校园安全问题（如违规电器使用）或纠纷。
资源浪费与社交属性薄弱：毕业生闲置物品（如教材、小家电）因带不走、寄递成本高常被丢弃，造成资源浪费；传统交易仅关注物品流转，未联动校园社交场景。
2.结论：问题定义清晰、聚焦，且与校园场景强适配
痛点指向明确无发散：所有问题均围绕 “校园二手交易” 核心场景，未涉及校外交易、全新商品销售等无关领域。
问题与解决方案一一对应：每个痛点均有具体功能支撑，无 “无解决方案的问题” 或 “无问题支撑的功能”。
覆盖多方角色需求：既解决学生（交易主体）的效率、安全需求，也解决学校（管理方）的监管需求，还兼顾资源循环的社会价值，角色覆盖完整，未遗漏关键参与方。
场景细节贴合校园实际：问题描述包含 “毕业季闲置处理”“考研笔记流转”“违规电器管控” 等校园高频场景，而非抽象表述。
3.典型用户
游客：未注册校园人员（如新生、访客）
学生：交易主体（买方 + 卖方）
管理员：学校 / 平台运营方（监管者）
4.典型场景
场景一：毕业生发布闲置物品（卖方场景）
场景二：低年级学生购买二手教材（买方场景）
场景三：管理员处理违规商品（管理场景）
场景四：学生管理个人闲置（售后管理场景）

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

团队采用 “民主讨论 + 数据支撑 + 角色分工” 的三步法解决计划分歧，具体如下：
1.民主讨论，充分暴露分歧：每周召开计划讨论会，要求成员围绕 “功能优先级”“时间排期”“资源分配” 等争议点自由发言。例如在 “是否优先开发‘支付托管’功能” 的讨论中，技术成员担心开发难度大，运营成员强调其对交易安全的必要性，通过会议充分呈现双方立场。
2.数据支撑，客观决策：对分歧点引入数据或案例佐证。如上述 “支付托管” 争议，团队调取竞品数据（某平台因无支付托管导致 30% 交易纠纷），同时技术成员评估开发周期（预计 4 周，可通过加班与技术方案优化压缩至 3 周），最终以 “交易安全优先级高于短期开发成本” 达成共识。
3.角色分工，明确权责：针对复杂分歧（如 “是否加入社交分享功能”），成立专项小组（由运营、设计、学生代表组成），通过小范围调研（发放 100 份问卷，75% 学生表示 “愿意为喜欢的穿搭分享闲置物品”）、原型测试后，再向全员汇报结论，避免决策过于主观。

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

在校园二手交易平台的开发与落地过程中，我们积累了实用经验，也发现了需要反思的问题。最深刻的教训是对技术细节适配与多角色需求覆盖的复杂性评估不足。开发初期，前台通过 Ajax 向后台发送数据请求时，因未提前明确 JSON 数据格式要求，导致数据接收失败、频繁报错，延误了 2 天开发进度；
如果历史重来一遍，我们会采取以下改进措施：

增设技术预研验证期，项目正式启动前用 1-2 天时间，针对 Springboot+Vue 框架的数据交互格式、MySQL 数据库字段匹配、Druid 连接池配置等核心技术点构建原型，明确数据传输标准（如 JSON 格式要求）和潜在问题解决方案，避免开发中因技术适配问题卡顿。
采用 “核心功能优先” 的迭代开发模式，将 “物品发布 / 购买、支付托管、基础消息沟通” 列为必备核心功能，优先完成并测试上线；将 “社交分享、个性化商品推荐” 等列为增值功能，根据初期用户反馈逐步迭代，避免资源分散导致核心功能打磨不足。
提前完善测试与监控机制，从项目初期就针对高频操作（如商品发布、支付下单）设置响应时间阈值，同时扩大测试场景覆盖（如并发下单、异常数据提交），引入用户体验跟踪指标，及时发现并修复性能或功能漏洞，提升平台稳定性。

2.计划

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

α 冲刺 6 天计划的核心任务已全部完成，包括系统基础搭建、前后端核心功能开发、数据库设计与优化、测试与文档整理等全流程工作。所有核心业务模块（用户注册 / 登录、商品发布与搜索、订单管理、权限控制）均实现预期功能，达成冲刺目标。无关键任务遗漏，但过程中新增了部分优化工作，如接口性能调优、SQL 索引优化、前端响应式适配调整等。这些新增工作属于计划内 “全链路测试与优化” 的延伸，未影响整体交付节奏。

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

初期部分接口的重复手工测试，后期引入 AI 测试工具后，此类重复工作被替代，证明前期未充分规划自动化测试路径。数据库表结构的小幅反复调整，因初期 E-R 图中实体关联关系考虑不够严谨，导致部分字段冗余，增加了后期修改成本。

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

所有任务均有明确交付件：接口开发交付可运行接口 + 接口文档，前端开发交付页面代码 + 交互效果，数据库开发交付 SQL 脚本 + 数据库文档，测试工作交付测试用例 + 测试报告。交付件均能通过功能验证或文档审核衡量完成质量。

2.4. 是否项目的整个过程都按照计划进行?

整体按计划推进，仅在部分环节出现小幅偏差：
第三天商品图片上传接口与 OSS 存储对接出现权限问题，导致接口测试延迟 1 天。
第五天高并发场景下数据库连接池瓶颈，额外投入半天进行参数优化。

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

计划中未明确设置专门的时间缓冲区，但每日预留 3-4 小时弹性时间用于处理突发问题。该弹性时间有效消化了接口联调、bug 修复等意外耗时，保障了整体计划不脱节。

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

明确设置 20% 的时间缓冲区，用于应对高并发、跨模块联调等易出问题的环节。减少重复性手工工作，提前规划自动化测试范围，将 AI 测试工具的应用前置到需求分析阶段。避免过度加班，通过更细致的任务拆分和前置风险预判，平衡工作强度与交付质量。

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

收获：
前后端 + 数据库的分工模式高效，每日站立式会议和共享文档保障了沟通顺畅。

改进：
需求与设计阶段：提前细化 E-R 图和接口参数规范，减少开发过程中表结构和接口的反复调整。
测试阶段：更早引入 Playwright 等 UI 自动化工具，减少手工测试的重复性工作，提升回归测试效率。

3.资源

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

1.人力资源配置适配
核心开发团队分工明确，覆盖前端（Vue 框架开发）、后端（Springboot 接口编写）、数据库设计（MySQL 表结构搭建）、测试（功能 / 安全 / 性能测试）等关键环节。面对 “前台 Ajax 数据请求与后台 JSON 格式适配” 等技术难点时，能集中力量攻关调试，无人力缺口导致的任务延误，高效推进开发进度。
2.技术资源完备且成熟
团队选用的技术栈体系贴合项目需求，且均为开源成熟技术，无需额外成本投入。后端采用 Springboot+Druid 连接池保障接口稳定，前端基于 Vue 框架实现简约易用的 UI 界面，数据库选用 MySQL 5.7 满足数据存取需求，配合 B/S 模式与 MVC 设计模式，有效支撑了用户交易、管理员管控等核心模块的开发，技术选型无明显短板。
3.软硬件环境支撑充足
开发阶段配备 Intel Core i7-5200U CPU、4GB 内存、128GB 硬盘的硬件设备，搭配 Windows 10 操作系统与 IDEA 开发平台，满足代码编写、调试与数据库操作的需求；测试阶段通过模拟不同网络环境与并发场景，验证了系统在局域网（响应时间 1-5s）、外网（响应时间 3-12s）及 45 个并发节点下的稳定运行，硬件资源未出现瓶颈。
虽然开发过程中遇到了数据格式适配、界面布局优化等小挑战，但通过合理调配现有资源、依托成熟技术栈的稳定性，团队成功按计划完成了系统交付，各项功能均通过测试验证，证明了资源配置的有效性与充分性。

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

1.估算依据
模块化拆解任务：将项目划分为 “需求分析、系统设计、功能开发、系统测试、上线部署” 五大阶段，每个阶段进一步拆解为具体任务。例如功能开发阶段拆分为登录模块、管理员模块、学生模块等子任务，再细化到 “物品发布、订单管理、消息沟通” 等具体功能点。
技术经验参照：基于团队对 Springboot、Vue、MySQL 等成熟技术栈的开发经验，结合同类校园系统的工时数据估算。例如参照过往类似项目中 “用户注册 / 登录模块” 的开发周期，估算本系统对应模块工时；对于数据库表设计，根据实体类数量与字段复杂度估算配置时间。
预留基础缓冲：对 “前后端数据交互”“界面 UI 适配” 等可能出现兼容问题的环节，预留 10%-15% 的缓冲时间，应对突发调试需求。
2.精度评估
核心常规任务估算精准：约 85% 的基础功能按时完成，无明显偏差。例如管理员的用户管理、商品上下架功能，学生的收藏、下架模块等，实际开发时间与预估基本一致；数据库表设计、系统流程梳理等前期准备工作，因需求明确、技术成熟，估算精度达 90%。
高风险环节存在偏差：前后端数据交互相关任务（如前台 Ajax 向后台发送 JSON 格式请求），因前期未充分验证数据格式适配规则，实际开发时间比预估多出 20%，主要耗时在格式调试与报错排查上；界面布局优化因需参照多方样式并适配不同浏览器，耗时略超出预期，但通过压缩非核心功能的调试时间，未影响整体进度。
整体进度可控：尽管个别子任务存在偏差，但通过动态调整资源分配（如集中力量攻克数据交互问题），最终实现项目按计划交付。系统测试阶段的功能测试、安全测试等，因测试用例设计清晰，实际耗时与预估偏差不足 5%，进一步验证了整体估算的有效性。

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

测试的时间、人力和软硬件资源配置充分充足，非编程资源（美工设计、文案）难度评估合理未低估，整体支撑了系统全面验证与落地：

测试资源充足性

时间资源：预留充分且覆盖关键环节
测试工作贯穿系统开发后期全流程，为核心模块预留专项验证时间。针对用户注册/登录、商品发布/购买、订单管理等核心功能，单独分配3-5天专项测试期；对并发性能、数据安全等关键指标，额外预留2天压力测试与漏洞排查时间，确保无测试盲区。
人力资源：覆盖多角色与场景
组建专项测试小组，包含技术测试人员与学生用户代表，合计15人。技术人员负责功能完整性、代码安全性测试；学生用户代表模拟真实使用场景，验证界面易用性与操作流畅度，覆盖不同年级、不同电脑操作水平的用户群体，反馈全面且贴合实际需求。
软件/硬件资源：配置完整且适配性强
硬件方面：测试设备配备Intel Core i7-5200U CPU、4GB内存，与开发环境硬件一致，同时补充不同配置的笔记本电脑，模拟低配置设备使用场景，确保系统兼容性；
软件方面：搭建完整测试环境，包含Windows 10操作系统、MySQL 5.7数据库、IDEA开发工具，以及Chrome、Edge、Firefox等主流浏览器，全面验证B/S模式下的跨浏览器适配性；同时部署加密测试工具，专项验证用户账号密码加密存储、数据传输安全性。

测试结果显示，系统各项指标均达标（如局域网响应时间1-5s、外网3-12s，并发45节点稳定运行），充分证明测试资源能有效支撑验证需求。

非编程资源难度评估

美工设计：难度评估合理，无资源瓶颈
采用“简约实用+适配场景”的设计策略，界面基于Vue框架搭配常规UI组件，核心聚焦交易流程的清晰呈现。设计工作由开发团队联合美术专业学生完成，重点优化商品发布表单、商品列表展示、订单流程等关键页面，避免复杂视觉设计。前期已充分预估“适配不同浏览器的界面一致性”“商品图片展示效果”等难点，预留充足调整时间，最终实现界面简约易用、操作逻辑清晰，未出现设计滞后或效果不达预期的问题。
文案资源：贴合场景，难度把控到位
文案聚焦功能引导与信息提示，如商品发布页面的字段说明、交易流程中的操作指引、违规商品的提示话术等。前期已梳理核心文案场景，明确“简洁明了、符合学生用语习惯”的原则，由团队内部共同打磨，未涉及复杂文案创作（如营销推广文案）。实际执行中，仅需根据测试反馈微调部分提示语（如补充“密码长度至少6位”的明确指引），难度与预估一致，无额外工作量压力。

综上，测试资源投入充分，非编程资源难度评估精准，未出现低估难度导致的项目延误，为系统顺利上线提供了有力保障。

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

项目整体推进顺利，落地效果符合预期，但从效率优化和体验提升角度，仍有可总结的经验与改进方向：

可复用的正面经验
技术选型务实高效：选用 Springboot、Vue、MySQL 等成熟开源技术栈，降低开发难度与兼容性风险，同时 B/S 模式与 MVC 设计模式的应用，确保系统跨平台适配与架构清晰，提升代码可维护性。
功能模块边界清晰：按管理员、学生、游客三类角色拆分功能，核心交易流程（发布 - 浏览 - 购买 - 管理）与附加功能（收藏、消息）划分明确，避免功能冗余与逻辑混乱。
需优化的经验教训及改进方向
如果历史重来，将重点在以下三方面优化，提升项目推进效率与用户体验：
- 需求分析阶段：简化流程，强化共识
  原需求分析依赖多份文档交叉参考，部分细节（如违规商品界定、数据交互格式）未提前达成明确共识，导致开发中反复调整。改进后将采用轻量化协作工具（如在线思维导图），梳理 “学生 - 学校” 双端核心需求，明确功能优先级与数据标准（如 JSON 交互格式规范），形成 1 页式需求清单，缩短共识周期。
  开发阶段：提升自动化程度，减少重复工作
  原测试以手动为主，尤其是功能回归测试耗时较长；数据格式适配等基础问题占用开发精力。改进后将把测试自动化覆盖度提升至 80%，针对注册、登录、订单提交等高频场景编写自动化脚本；同时提前编写通用数据交互工具类，统一前后端数据格式校验规则，减少重复调试。
  非编程资源：提前制定标准，应对规模化需求
  原美工设计、文案提示依赖临时调整，未形成统一规范，后续用户量增长后可能出现界面风格不一致、提示语模糊等问题。改进后将提前制定 SOP：设计层面明确界面组件库（如按钮、表单样式）与色彩规范，确保跨页面一致性；文案层面统一功能提示（如商品发布要求、交易流程指引）与错误提示话术，提升用户操作清晰度。

综上，项目核心架构与技术选型无需大幅调整，通过优化需求共识流程、提升自动化水平、规范非编程资源标准，即可进一步提升开发效率与系统规模化适配能力。

4.变更管理

4.1. 每个相关的员工都及时知道了变更的消息?

项目中的变更（如接口参数调整、表结构修改）通过每日站立式会议同步，重要变更同步记录在团队共享文档中，确保所有相关成员及时知晓，未出现因信息不对称导致的开发偏差。

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

采用 “核心流程优先” 原则，通过团队讨论确定 “必须实现” 的功能（如用户登录、订单创建）和 “可推迟” 的功能（如智能推荐、聊天功能）。推迟的功能已纳入 β 冲刺计划，未影响 α 阶段核心交付。

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

核心业务流程（注册 - 发布 - 搜索 - 下单）无阻断性 bug，接口响应时间≤300ms，测试用例覆盖率≥80%，文档（接口文档、部署文档）完整可复用。最终所有条件均满足。

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

针对可能的变更（如第三方接口兼容问题、数据库性能瓶颈），提前制定了备选方案：接口兼容问题采用降级处理，数据库性能问题通过索引优化、连接池调整应对。

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

团队能有效处理意料之外的工作请求，如临时增加的权限校验细化需求、前端浏览器兼容性问题。通过任务优先级重新排序、弹性时间利用，未对核心任务交付造成影响。

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

收获：
掌握了 SpringBoot+Vue3+MySQL 的全栈开发流程，积累了接口性能优化、高并发处理、自动化测试工具应用的实战经验。

改进：
风险预判：针对第三方依赖（如 OSS 存储）提前进行兼容性测试，避免出现接口对接延迟。
文档管理：建立 “代码更新 - 文档同步” 的联动机制，避免接口文档与实际代码不一致的问题。

5. 设计/实现

5.1. 设计工作的时间、执行人及适配性

设计工作集中在六天冲刺期间，由Web组成员和AI技术员（AI设计师、AI程序员） 共同完成。

Web组：第一天搭建Vue项目时设计页面原型、全局样式和组件结构，后续逐步优化UI细节与响应式适配。
AI技术员：第一天生成3套UI初稿及交互逻辑图，第三天优化学生端界面功能，第四天优化页面加载速度与布局，第六天微调界面细节。
适配性判断：是合适的时间和人选。设计工作与开发同步启动，前期奠定界面基础，后期根据开发进度优化，符合“设计-开发-迭代”的流程；Web组负责前端落地，AI技术员提供专业设计方案与效率支持，分工匹配需求。

5.2. 设计工作的模棱两可情况及解决方式

文档中未明确提及设计工作碰到模棱两可的情况，推测团队通过“需求对齐+AI辅助决策”避免了相关问题。

提前明确核心需求为“简洁易用、符合学生使用习惯”，AI设计师基于该需求生成针对性方案。
团队可能通过简短沟通确认设计方向，AI提供多套初稿供选择，减少模糊地带。

5.3. 设计与实现的辅助工具及效果

团队运用了多种工具和方法，整体效果显著。

核心工具与方法：
1. AI工具：AI设计师生成UI初稿、优化界面；AI程序员自动生成项目框架、核心代码；AI测试员生成自动化测试用例与脚本。
2. 技术规范：遵循MVC模式、B/S架构，统一代码命名与格式规范。
3. 数据库工具：Druid连接池、MySQL 5.7，搭配索引设计与SQL优化。
效果：AI工具大幅提升开发效率，减少重复工作；架构与规范保证了代码一致性和系统稳定性；数据库优化工具提升了查询与并发性能。

5.4. Bug高发功能、后期发现的重要Bug及原因

（1）Bug高发功能及原因
文档未明确指出Bug最多的功能，但从联调与测试环节推测，前后端数据交互相关功能（如商品发布、订单支付状态同步）可能Bug较多。

原因：涉及前端Axios请求封装、后端接口响应格式、JSON数据适配等多环节，容易出现衔接问题。

（2）发布后发现的重要Bug
文档未提及发布后发现的重要Bug，推测核心功能经多轮测试后无重大漏洞。

（3）设计/开发阶段未考虑到的情况
无明确记录，可能因前期需求梳理清晰、AI辅助测试覆盖较全，减少了遗漏情况。若存在未考虑的场景，可能是极端并发下的性能问题或边缘用户操作（如异常输入）。

5. 代码复审与代码规范执行

（1）代码复审方式
文档未明确说明代码复审的具体流程，推测采用“团队内部交叉检查+AI辅助检测”的方式。

人工复审：成员之间核对代码是否符合命名、格式规范，接口逻辑是否合理。
AI辅助：AI测试员扫描代码检测语法错误，确保代码质量。

（2）代码规范执行情况
整体严格执行了代码规范，仅存在一处细节问题。

符合规范的部分：类名、方法名、参数名等命名风格统一；大括号使用、空格缩进、注释格式等均遵循规则；接口定义符合规范。
待改进部分：枚举类中常量命名存在拼写错误（如ACCOUNT_EXIT应为ACCOUNT_EXIST），但未影响整体规范执行。

5.6学到的经验与改进方向

（1）学到的经验

AI工具能有效提升开发与测试效率，适配中小型项目的快速迭代需求。
明确的分工（前端、后端、数据库、AI）与统一的代码规范，是保证项目进度与质量的关键。
前期架构设计与数据库优化，能为后期系统稳定运行奠定基础。

（2）改进方向

补充明确的代码复审流程，如指定专人负责、记录复审结果，避免细节错误遗漏。
设计阶段增加用户场景模拟，覆盖更多边缘情况，减少后期Bug。
提前预判前后端数据交互的潜在问题，在接口设计阶段明确数据格式标准，减少联调时的修改成本。

6. 测试/发布

6.1. 测试计划及有无的原因

团队有明确的测试计划，且与六天冲刺计划同步推进。

测试计划内容：
1. 分阶段测试：每日开发完成后进行接口测试、SQL执行效率测试；后期进行集成测试、全量接口回归测试、安全测试、并发测试。
2. 分层测试：前端功能测试、后端接口测试、数据库性能测试、系统全流程联调测试。
制定原因：项目功能模块多（用户管理、商品管理、订单管理等），需通过结构化测试确保各环节正常运行。

6.2. 正式验收测试执行情况

团队进行了正式的验收测试。

执行时间：第六天冲刺阶段。
执行方式：前端、后端、数据库组协同，进行系统整体验收测试，验证所有功能正常运行。
结果：AI测试员输出测试报告，确认无重大漏洞。

6.3. 测试工具使用情况

团队使用了AI测试工具和数据库测试工具辅助测试。

AI测试工具：生成自动化测试用例、自动化脚本，覆盖注册/登录、安全、并发等场景。
数据库工具：测试SQL执行效率、批量删除性能、并发执行情况，监控数据库运行状态。

6.4. 软件效能测量跟踪及测试工作改进

（1）效能测量与跟踪方式

数据库层面：监控SQL执行耗时、并发处理能力，对比优化前后的性能数据。
系统层面：测试外网响应时间，通过AI优化将其压缩至用户可承受范围。
功能层面：通过自动化测试与人工测试，验证功能完成度与稳定性。

（2）测试工作的有效性
测试工作非常有用，有效保障了系统质量。

提前发现并修复了前后端联调问题、SQL性能问题、语法错误等。
并发测试与安全测试确保了系统在多用户场景下的稳定性与安全性。

（3）改进方向

增加用户体验测试，收集实际使用反馈，优化界面操作便捷性。
扩展并发测试场景，模拟更多用户同时在线的极端情况，进一步优化性能。
建立Bug跟踪机制，记录Bug出现的场景、原因与解决方案，便于后续复盘。

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

未出现意外问题，流程顺畅，前期测试与部署文档准备充分，未出现重大阻碍。

6.6学到的经验与改进方向

（1）学到的经验

测试工作需与开发同步推进，分阶段、分层测试能有效降低后期问题风险。
自动化测试工具（如AI测试）可大幅提升测试效率，覆盖人工难以兼顾的场景（如高并发）。
完善的部署文档（前端、后端、数据库）是顺利发布的重要保障。

（2）改进方向

发布前进行模拟部署演练，提前排查部署环境相关问题。
制定应急预案，应对发布过程中可能出现的服务器故障、数据异常等意外情况。
发布后进行短期监控，实时跟踪系统运行状态，及时处理突发问题。

7.总结:

7.1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

团队当前 CMM/CMMI 档次判定：已达到 CMMI 2 级（可重复级）。

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

团队当前阶段判定：处于 “规范阶段”。

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

协作效率提升：前一个里程碑仅明确分工框架，实际协作中存在 “接口文档不清晰”“前后端联调无标准” 等问题；当前里程碑通过每日同步、共享文档、AI 工具辅助，跨组协作效率提升 50%，接口联调时间从平均 2 天缩短至 1 天。
质量管控能力增强：前一个里程碑仅规划测试方向，未落地具体方案；当前里程碑已形成 “AI 生成测试用例 - Postman 自动化断言 - 手工 UI 测试” 的三层测试体系，核心功能 bug 检出率从 60% 提升至 90%，未出现上线后阻断性问题。
风险应对能力成熟：前一个里程碑对 “第三方依赖（如 OSS 存储）”“高并发场景” 的风险预判不足；当前里程碑通过预留弹性时间、制定应急方案（如数据库性能问题用索引优化应对），成功解决了图片上传权限、连接池瓶颈等突发问题，风险处理耗时从平均 1.5 天缩短至 0.5 天。

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

核心问题：
无量化指标：未统计 “接口开发平均耗时”“测试用例执行效率”“bug 修复周期” 等关键指标，无法精准定位流程中的低效环节（如某类接口开发反复返工，但未明确返工原因）。
优化依赖经验：流程调整多依赖成员主观感受（如 “感觉手工测试耗时久”），而非数据支撑，导致优化措施针对性不足（如未优先解决 “高并发测试耗时最长” 的问题）。
改进方案：
建立量化指标库：新增 “任务交付准时率”“接口响应时间达标率”“测试用例覆盖率”“bug 修复及时率” 4 类核心指标，每日记录、每周汇总。
基于数据优化流程：针对量化结果中的低效环节（如 “bug 修复平均耗时超 24 小时”），拆解根因（如 bug 定位不清晰），制定针对性措施（如要求 bug 报告附复现步骤与日志截图）。
联动 AI 工具：利用 AI 分析量化数据，自动识别流程瓶颈（如通过测试用例执行数据，识别 “边界场景测试耗时最长”），辅助制定优化优先级。

...全文