zq践地组 —— 凡事预则立（Beta 冲刺计划）

Alpha 的结论很直接：主链路是通的，但管理端有缺口、测试启动太晚、发布靠手工、角色只有开发。Beta 不再追求"功能更多"，而是把这三件事补上，并把每个目标写成可验收的标准。

首要整改项：答辩指出的并发测试问题

计划的第一条不是新功能，而是 Alpha 答辩现场老师直接指出的问题：

老师的问题："你们联合测试的并发量只有 10 个，怎么证明系统能扛高并发？"

Alpha 用 10 并发抢 5 个名额，只能证明"没有超卖、没有 500"，属于并发正确性，不能当作性能结论。因此 Beta 把并发与容灾强化列为 P0 的 F8，并给出硬指标：

验收不看"跑过脚本"，只看报告：没有指标、没有与 Alpha 10 并发的对比，F8 不算完成（见 F8 与第七节验收清单）。

一、Beta 的功能范围

1.1 要改进完善和新增的功能

其中 F8 直接来自 Alpha 答辩现场老师的点评："你们联合测试的并发量只有 10 个，怎么证明系统能扛高并发？" Alpha 的 10 并发只验证了"不超卖、不出 500"的并发正确性，既没有把连接池和队列压满，也没有 P95、错误率、资源占用等指标，数据规模与压测时长都不够。Beta 把这一条当作必须闭环的整改项，不通过就不算完成。

1.2 明确不做（避免范围膨胀）

二、团队分工的改进

2.1 Alpha 的问题

Alpha 实际只有 3 个开发角色（林嘉祚、张祺、甘羽潇），PM、测试、文档、部署由开发兼任，结果是指标性的工作（测试、文档）被挤到最后两天，且单点阻塞明显。

2.2 Beta 的 6 人角色

2.3 分工原则与互备

2.4 贡献度规则（11-15 公布，冲刺期不再改）

贡献度 = 实际工时占比 × 60%
       + 交付物验收得分 × 30%
       + 组员互评 × 10%

• 工时台账：每人每晚 22:30 填一行（日期 / 任务 / Issue 号 / 工时 / 产出链接），P6 每周日汇总；
• 交付物验收：组长与模块负责人按"是否按时、是否返工、完成度"打 0–5 分；
• 组员互评：匿名给其余 5 人打 1–5 分，去掉最高最低后取均值；
• 结果归一到 100%，单项浮动不超过 5%，超出需台账支撑。

三、工具与流程的改进

3.1 每日冲刺 SOP

3.2 红线

1. 每人每天必须有可入账的产出：写代码给 commit 链接，做测试给截图；
2. 站立会议照片每天新拍，复用当天日志不计分；
3. 博客当晚发，不留到第二天；
4. 不提前占位提交，不伪造提交；
5. 不套用组内相同模板句与图片；
6. 群内通知 deadline 前必须完成。

四、博客计划（14 篇）

每篇冲刺随笔固定包含：Scrum 表格（昨天到现在完成了什么、花了多久、还剩多久 / 问题 / 到明天的安排）、开发 commit 与 Issue 链接、测试截图或报告、当天站立会议照片、PM 报告（任务总量/已完成/剩余 + 燃尽图 + 任务总量变化图）、项目运行截图或 gif。

五、七天冲刺计划（11-16～11-22）

六、风险与兜底

七、Beta 验收清单

• 13 项功能按 P0/P1 全部有结论（完成/部分完成/未完成 + 原因）
• 每个 P0 功能有接口契约、401/403 用例、运行截图
• 冒烟脚本入库，一条命令跑通主链路
• CI 红灯不合并；测试报告可下载
• 100/500 压测报告含 P95/P99、错误率、QPS、资源占用，并与 Alpha 10 并发结果对比（答辩整改项）
• 备份恢复与对账任务演练通过
• 可运行地址/二维码可用；回滚演练完成
• 14 篇博客全部发布并挂入置顶索引
• 贡献度按台账 + 验收 + 互评结算并有记录