事后诸葛亮分析

一、设想和目标

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

• 问题：解决高校、企业和个人废品回收流程繁琐、计价不透明、缺乏正规发票渠道的问题。
• 清晰度：定义较为清楚。我们在需求文档中明确了三类用户（学生、企业行政、居民）的典型使用场景，例如“学生毕业季卖书”和“企业定期批量处理废纸”。

2. 我们达到目标了么？

• 功能实现：原计划的核心功能（下单、接单、地址管理、多身份认证）已全部实现。但“微信支付”因资质问题降级为“模拟结算”，“消息推送”推迟至 Beta 版本。
• 交付时间：按计划完成代码冻结和发布。
• 用户数量：原计划达到 50+ 种子用户，目前通过班级内部推广和朋友圈邀请，注册用户数为 35 人，略低于预期。

3. 和上一个阶段相比，团队软件工程的质量提高了么？
提高显著。

• 具体表现：Git 管理从“互相覆盖代码”进化为“Feature Branch 工作流”，冲突率降低 60%。接口文档（Swagger/Apifox）与代码实现的同步率达到 90% 以上。引入了 .http 自动化接口测试脚本，回归测试效率提升了 3 倍。

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

• 用户对“高校教材回收”的溢价功能非常感兴趣，接受度高于预期。
• 但企业用户反馈“填写税号和发票信息”过于繁琐，这是设计时未预料到的阻力。
• 总体来说，我们离“构建校园回收生态”的目标更近了一步，核心逻辑已验证闭环。

经验教训 & 改进：
如果重来一遍，我们在立项初期会更深入调研企业用户的实际操作习惯，可能会引入 OCR 识别营业执照功能来简化录入，而不是让用户手动填几十位的税号。

二、计划

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

时间比较仓促。Alpha 阶段仅有 7 天，Plan 阶段仅占半天，导致部分技术难点（如地图组件适配）预估不足。

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

采用“PM 拍板 + 核心开发评估”机制。例如在争论“是否要做企业端 Web 后台”时，前端开发评估工期不够，PM 最终决定 Alpha 版本仅做小程序端，Web 端砍掉。

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

没做完的：真实微信支付、实时物流地图轨迹。
原因：支付是因为外部资质审批卡流程；地图轨迹是因为技术复杂度超出 7 天冲刺的能力范围。

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

有。前期花了两天时间设计了一套复杂的“积分商城”UI，但 Alpha 版本后端根本没时间写积分兑换逻辑，导致这部分前端页面变成了摆设。

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

大部分有。我们使用了 GitHub Project/看板管理任务，每张卡片都有“Definition of Done (DoD)”，例如“接口调通且通过测试脚本”。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？

意外：Day 6 决定临时突击“企业模块”，导致数据库表结构大改，前端不得不重写表单验证逻辑，最后两天全员加班。

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

没有留缓冲区。这是最大的失误，导致 Day 7 遇到 Git 冲突时非常被动，差点延期发布。

8. 将来的计划会做什么修改？

必须预留 15%-20% 的 Buffer（缓冲时间）。
引入 Code Freeze（代码冻结） 时间点，发布前 12 小时严禁提交非 Bug 修复类代码。

我们学到了什么?
“拥抱变化”不等于“随意插队”。在冲刺末期插入重大的业务模块（如企业下单）是高风险行为，以后应严格控制需求变更范围。

三、资源

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

有

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

凭经验估计，精度一般。前端页面的开发时间通常被低估，因为 UI 调整（如 1px 的对齐）非常耗时。

3. 测试的时间，人力和软件/硬件资源是否足够?

美工设计被低估。找素材、切图、设计 Logo 花费了大量非编程时间，导致前端开发不得不压缩写代码的时间。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

有。文档编写工作（API文档）如果能自动生成（如完善 Swagger），就不用方馨手动去维护 Markdown 文档了。

经验教训 & 改进：

下次我们会提前准备好 UI 素材库（Iconfont 等），不再在开发过程中浪费时间找图。测试工作应发动全员参与（交叉测试），而不是全压在测试经理一人身上。

四、变更管理

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

基本及时。我们保持了每日站会（Daily Scrum），任何 DB 字段变更都会在群里 @所有人。

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

MoSCoW 法则：必须有（下单、登录）、应该有（发票管理）、可以有（消息推送）、这就不要了（积分商城）。

3. 项目的出口条件（Exit Criteria）有清晰的定义么?

有。定义为：P0/P1 Bug 清零，核心业务流（下单->接单->完成）在真机上跑通。

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

较弱。当 Day 6 企业模块字段剧增时，我们的应急方案只是“加班”，比较简单粗暴。

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

能够处理。后端同学（在接到变更后迅速调整了 Entity 和 DTO，响应很快。

我们学到了什么?
数据库变更是牵一发而动全身的。以后任何字段变更必须先在文档中确认，再同步修改前后端代码，严禁“口头变更”。

五、设计/实现

1. 设计工作在什么时候，由谁来完成的？

Sprint 开始前 2 天，由 PM 和核心开发共同完成数据库设计和 API 定义。

2. 设计工作有没有碰到模棱两可的情况？

有。关于“高校用户”的定义，一开始纠结是“定位在学校里的人”还是“学信网认证的人”。
解决：团队讨论后，决定 Alpha 版简化为“用户自选学校+上传学生证照片人工审核（模拟）”。

3. 团队是否运用单元测试，UML 等工具？
使用了 JUnit 做部分工具类的单元测试（如 JwtUtil）,使用了 UML 类图设计实体关系。
有效性：UML 帮助我们理清了 User 和 Order 之间的一对多关系，非常有效。Alpha 结束后的类图与设计初稿相比，增加了 EnterpriseInfo 和 CampusInfo 两个附属结构。

4. 什么功能产生的 Bug 最多，为什么？

价格计算功能。因为涉及“试点期上浮”、“新旧程度系数”、“基础单价”三个变量，逻辑组合多，容易算错。设计时只考虑了理想情况，没考虑空值处理。

5. 代码复审（Code Review）是如何进行的？

主要在合并分支（Merge Request）时进行。是否严格？Day 1-5 比较严格，Day 6-7 为了赶进度有所放松，导致一些注释没及时更新。

我们学到了什么?
复杂的业务逻辑（如计价策略）不能只靠脑子想，必须先写出 伪代码 或 流程图，再进行编码实现，否则 Bug 频出。

六、测试/发布

1. 团队是否有一个测试计划？

有。测试经理制定了详细的测试矩阵（Test Matrix）和回归测试流程。

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

是。发布前由 PM 对所有 Story 进行了验收（Acceptance Test）。

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

使用了 IDEA 的 HTTP Client 编写脚本（OrderTest.http），实现了“一键登录+下单+查单”的自动化接口测试。这比手动点 Postman 效率高太多了，是一个巨大的改进。

4. 团队是如何测量并跟踪软件的效能的？

目前仅通过肉眼观察页面加载速度。压力测试尚未进行。
改进：Beta 阶段需要引入 JMeter 对抢单接口进行压测。

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

云服务器的 MySQL 数据库连接数被占满，导致服务启动失败。原因是开发环境没有正确关闭数据库连接池，连接泄露了。

我们学到了什么?
自动化测试是生命线。特别是在重构代码后，一键运行测试脚本能给团队巨大的安全感。

七、总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI Level 2 (Managed - 已管理级)。我们有基本的计划、需求管理、版本控制，但流程还需要进一步量化和优化。

2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范 (Norming) 阶段。经过 Alpha 冲刺的磨合，大家已经熟悉了 Git 工作流和协作模式，不再是单打独斗。

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

最大的改进是 有了“交付意识”。以前写作业是“写完就行”，现在是“必须要能跑通、能部署、能给用户用”。

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

代码规范与自动化部署 (CI/CD)。目前部署还需要手动传 jar 包，比较原始且容易出错。Beta 阶段希望能配置好 Jenkins 或 GitHub Actions。

七、团队成员在Alpha阶段的角色和具体贡献

姓名	角色	贡献分	🏅 核心贡献说明 (可验证的贡献)
林欣然	PM和后端	97.5	统筹全局。建立了兑换商品的数据库、兑换商品模块的相关代码、兑换商品模块的接口以及测试了接口的正常运行
周纯微	后端	98	独立开发最复杂的“订单流转”与“企业定期计划”逻辑，编写全链路自动化测试脚本。
陈文婉	前端	99	搭建 Uniapp 框架，实现复杂的身份切换组件与表单验证，负责前后端接口对接。
周诗涵	后端	98.5	完善地址管理与用户中心，修复逻辑删除失效 Bug，确保了 MyBatis-Plus 的稳定运行。
李思淇	前端	88	所有页面 UI 美化，开发企业批量下单表格组件
许潆之	测试	87	质量把关。全模块回归测试负责人，发现了“分页索引不一致”等 P1 级 Bug，守住了发布质量。
方馨	测试，文档撰写	97.6	撰写完成项目开发过程中全部七篇博客，补全 Swagger 注解，辅助测试

会议讨论照片：