事后诸葛亮分析
Alpha阶段事后分析报告（事后诸葛亮会议）
一、设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们构建了一个eSIM在线商店（esimstore），旨在为用户提供便捷的eSIM套餐浏览、购买与管理服务。
- 需求定义较为清晰，但初期对“套餐筛选逻辑”和“支付流程”的用户场景描述不够具体，导致部分功能反复调整。
-
我们达到目标了么？
- 原计划的6个核心功能（用户系统、套餐展示、购买流程、订单管理、支付集成、基础管理后台）完成了5个，管理后台部分功能延期。
- 按原计划时间交付了Alpha版本，但测试覆盖率未达到预期。
- 目前尚未进行大规模用户推广，内部测试用户约20人，与预期一致。
-
和上一个阶段相比，团队软件工程的质量提高了么？
- 代码注释覆盖率从60%提升至85%（通过工具统计）。
- GitHub Issues与PR流程更加规范，每次提交均关联任务。
- 团队协作意识增强，每日站会出勤率100%。
-
用户量、用户对重要功能的接受程度和我们事先的预想一致么？
- 内部用户对“套餐对比”功能接受度高于预期，但“订单导出”功能使用率较低。
- 购买流程的步骤数比用户预期多一步，需在Beta阶段简化。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 教训：需求描述应更场景化，尽早引入用户画像。
- 改进：在需求阶段增加用户故事地图（User Story Mapping）工作坊，明确每个功能的用户场景和验收标准。
二、计划
-
是否有充足的时间来做计划？
- 计划时间较紧张，需求分析仅用了一周，导致部分功能边界模糊。
-
团队在计划阶段是如何解决问题和对计划的不同意见的？
- 通过线上会议+匿名投票决定优先级，技术争议由技术负责人（张秉瀚）裁定。
-
你原计划的工作是否最后都做完了？如果有没做完的，为什么？
- 管理后台的数据报表功能未完成，因前期低估了数据处理复杂度，时间不足。
-
有没有发现你做了一些事后看来没必要或没多大价值的事？
- 早期花费大量时间讨论UI细节，而实际用户更关注流程流畅性。
-
是否每一项任务都有清楚定义和衡量的交付件？
- 大部分有，但部分测试任务的定义较模糊，如“测试通过”标准不统一。
-
是否项目的整个过程都按照计划进行？出了什么意外？
- 总体按计划推进，但第三方支付接口调试耗时超出预期2天。
- 未预估到团队成员期中考试时间冲突，导致进度短暂延迟。
-
在计划中有没有留下缓冲区？缓冲区有作用么？
- 留有5天缓冲区，用于应对支付接口问题和测试修复，起到了关键作用。
-
将来的计划会做什么修改？
- 增加技术预研时间，对第三方接口提前进行沙箱测试。
- 在计划中明确标注团队成员个人时间冲突（如考试、实习）。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 学到：计划应包含技术风险缓冲，任务定义需明确可验收。
- 改进：引入“三点估算法”进行任务时间预估，设立每周风险同步会。
三、资源
-
我们有足够的资源来完成各项任务么？
- 开发与测试资源基本足够，但UI设计和文案资源不足，部分界面由开发人员临时设计。
-
各项任务所需的时间和其他资源是如何估计的？精度如何？
- 基于经验估算，精度约70%，前端任务普遍低估，后端任务普遍高估。
-
测试时间、人力和软硬件资源是否足够？非编程资源是否低估？
- 测试时间紧张，人力足够但自动化测试工具不足。
- 美工设计和文案难度被低估，导致部分界面风格不统一。
-
你有没有感到你做的事情可以让别人来做（更有效率）？
- 部分前端调试工作由后端同学临时支持，效率较低，应更早明确前后端分工。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 教训：非编程任务（如UI、文案）应尽早介入，避免后期返工。
- 改进：在项目计划中设立“设计冲刺周”，提前完成高保真原型与文案定稿。
四、变更管理
-
每个相关的员工都及时知道了变更的消息？
- 通过微信群和GitHub Issues通知，但仍有2次变更未及时同步给测试人员。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能？
- 基于用户价值与实现成本矩阵评估，优先保留核心流程功能，数据报表功能推迟。
-
项目的出口条件（什么叫“做好了”）有清晰的定义么？
- 有定义：所有P0级Bug修复、核心功能流程走通、部署成功。但未量化性能指标。
-
对于可能的变更是否能制定应急计划？
- 部分有，如支付接口失败时降级为模拟支付，但UI大改无应急方案。
-
员工是否能够有效地处理意料之外的工作请求？
- 整体较好，但部分成员对突发Bug修复响应较慢，缺乏明确的值班机制。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 学到：变更通知需结构化（谁、何时、何地、如何同步）。
- 改进：建立变更管理板（Change Board），所有变更需经过评估与同步确认。
五、设计/实现
-
设计工作在什么时候、由谁来完成的？是合适的时间、合适的人么？
- 架构设计由张秉瀚、沈武钊在项目第二周完成，基本合适；但部分模块设计较晚，影响开发进度。
-
设计工作没有碰到模棱两可的情况？团队是如何解决的？
- 遇到接口返回格式不一致问题，通过线上会议+原型代码验证达成一致。
-
团队是否运用单元测试、TDD、UML等工具？这些工具有效么？
- 使用了单元测试（覆盖率约65%），未采用TDD；用Mermaid绘制简单架构图，较有效。
- 项目初期有粗略UML图，但后期未更新，与实际代码有出入。
-
什么功能产生的Bug最多？为什么？发布后发现了什么重要Bug？
- 支付模块Bug最多（共8个），因第三方接口兼容性问题。
- 发布后发现1个并发下单导致库存扣减错误的Bug，因未进行压力测试。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 通过GitHub PR进行，至少1人审查；基本遵循代码规范，但未使用自动化检查工具。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 学到：设计应尽早且持续更新，代码审查需结合自动化工具。
- 改进：引入ESLint/Prettier规范前端代码，使用SonarQube进行代码质量扫描。
六、测试/发布
-
团队是否有一个测试计划？为什么没有？
- 有基础测试计划，但未详细到每个模块的测试用例与责任人。
-
是否进行了正式的验收测试？
- 进行了内部验收测试，但未邀请真实用户参与。
-
团队是否有测试工具来帮助测试？
- 使用了Postman进行API测试，前端使用Jest进行单元测试。
- 改进计划：引入Selenium进行核心购买流程的自动化端到端测试，并自动生成测试报告。
-
团队是如何测量并跟踪软件的效能？压力测试呢？
- 使用浏览器DevTools监测前端加载性能，未进行系统化压力测试。
- 从结果看，前端性能较好，但服务器并发处理能力未知。
-
在发布的过程中发现了哪些意外问题？
- 部署时环境变量配置错误导致服务启动失败，耗时1小时排查。
我们学到了什么？如果重来一遍，我们会做什么改进？
- 学到：测试计划应包含性能与压力测试，部署流程应脚本化。
- 改进：使用JMeter进行压力测试，编写一键部署脚本（Docker + CI/CD）。
七、团队的角色、管理、合作
-
团队的每个角色是如何确定的？是不是人尽其才？
- 根据个人兴趣与技能自选+调配，基本人尽其才，但陈俊源在DevOps方面表现突出，可更早承担部署职责。
-
团队成员之间有互相帮助么？
- 有，特别是在调试支付接口和前端兼容性问题时，前后端同学协作紧密。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 通过每日站会同步问题，复杂问题召开专题会议，由PM或技术负责人协调。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 学到：角色应动态调整，让成员在优势领域发挥更大作用。
- 改进：设立“技术导师制”，经验丰富成员指导新人快速上手。
八、团队成员Alpha阶段贡献分
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 张秉瀚 | PM / 后端开发 | 24 | 项目规划、核心架构、购买流程开发、团队协调 |
| 沈武钊 | 后端开发 | 22 | 用户与订单模块、代码注释覆盖率85%、API设计 |
| 陈嘉煌 | 后端开发 | 21 | 支付集成、套餐管理、数据库优化 |
| 郑东楷 | 测试 / 前端 | 19 | 编写28个测试用例、提交18个Bug报告 |
| 邱宇彦 | UI/UX | 18 | 界面原型设计、交互流程优化、用户反馈收集 |
| 陈俊源 | DevOps / 前端 | 17 | 部署流水线搭建、Docker配置、前端组件开发 |
| 崔乐浩 | 测试 / 文档 | 16 | 测试执行、缺陷跟踪、项目文档整理 |
九、全组讨论照片
十、Beta阶段改进路线图
| 改进领域 | 具体行动 | 责任人 | 截止时间 |
|---|---|---|---|
| 需求管理 | 用户故事地图工作坊 | 张秉瀚 | 12月25日 |
| 测试自动化 | 引入Selenium进行E2E自动化测试 | 郑东楷 | 1月5日 |
| 代码质量 | 配置SonarQube + ESLint自动化检查 | 陈俊源 | 12月28日 |
| 文档同步 | 每个PR必须更新对应Wiki或API文档 | 崔乐浩 | 立即执行 |
| 部署流程 | 编写一键部署脚本并文档化 | 陈嘉煌 | 1月3日 |
浙公网安备 33010602011771号