掌中生活——α阶段问题总结（事后诸葛亮）

这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	团队作业—Beta冲刺+事后诸葛亮
这个作业的目标	按邹欣老师的事后诸葛亮模板，复盘 α 冲刺的设计/实现、测试/发布、变更管理、团队协作、设想与计划，形成 β 阶段可执行的整改项
其他参考文献	《构建之法》第2、13章；项目管理之事后诸葛亮会议模板；《掌中生活_软件需求规格说明书 v1.3》；《掌中生活_系统设计说明书 v1.0》；团队 α 冲刺 11 篇博客与 7 天站会纪要

目录

评分点对应：设计/实现和测试/发布在第五、六节；变更管理和团队角色/管理/合作在第四、七节；设想和目标和计划在第一、二节；资源是模板要求，放在第三节一起复盘。

零、复盘会怎么开的

复盘会安排在 11-13 晚上，线上开了 70 分钟。参加的是黄炫文、胡昊、陈志、杨俊鑫、吴军峰、李天赐和陈瀚楷，林铭宏 11-14 才入组，没有参与 α，这次只是旁听。

会前每个人写了三条"最后后悔的、觉得最值的、最想改的"，会上按模板的七个部分逐条过。有分歧的地方没有强行统一，先记下两种说法，能落到 β 整改的才算数。最后整理出 20 多条问题，归成 8 条整改，另外出了 β 的分工和完成标准。

有个口径要先说明：α 期间缺陷编号按天重排过，Day2 的 D-01 和 Day4 之后的 D-01 不是同一个问题。本文统一用后期收口的编号：D-01 注册失败补偿、D-02 口令长度、D-03 邮箱正则、D-04 改密后会话未失效、D-05 年份溢出、D-06 空备注掩码。

一、设想和目标

1. 软件要解决什么问题，定义清楚了吗

我们当时是这么描述它的：把散落在微信、邮箱、备忘录和纸质凭证里的生活信息，整理成一份带日期和状态的清单。现在看这个描述基本是准的。SRS 写了 11 个用户场景，包括考试报名、笔记本保修送修、家电保修拍照、租房、订阅、缴费凭证、证件换领、找发票、凭据保管、换机和借手机，四条交付场景也都落到了具体页面上。

但有一个变化，α 开始时没有说透。选题阶段写的是 Web 端、三类信息、不做账号凭据；作业 5 之后改成 Android 本地离线、四类信息、加敏感级别。方向本身没问题，离线才守得住"数据不出设备"，但它把安全从一个普通模块变成了核心模块。α 的计划里，加密和二次验证还放在"作业 7/8"。目标改了，计划没跟着改，后面安全相关的欠账都是从这里来的。

2. 达到目标了吗

如果只看任务点，是达标的。Backlog 21 项、156 点，第 6 天就烧到 0，第 7 天打包收尾。当时大家也觉得 α 完成了。

但如果问"一个普通用户能不能自己把事办完"，答案是不行。注册、登录、建记录、看详情、改状态这几步确实能走通，可受保护记录只能建不能改，账号凭据填了存不进去，附件没有入口，提醒不会弹通知，搜索点进去是占位页，备份也没有。真实用户量是 0，所有"好用"的判断都来自团队自测和模拟器截图。

所以准确地说，α 交付的是一个能运行的骨架，不是一个能交付的产品。这两个说法在 α 的博客里有时候混着用，是我们表述上的问题。

3. 用户接受度和预想一致吗

不知道，因为没有用户数据。原本计划 Day5 拉几个同学试用，后来被联调和缺陷挤掉了，理由听起来很合理：先跑通再说。但"跑通"的标准是团队自己定的，越晚见用户，返工越贵。β 把用户调查从"最后写的一篇博客"改成冲刺第一周就开始做的事，就是为了补这一课。

4. 学到什么，重来会怎么改

• 里程碑按"用户能完成什么"写，不按"模块做完没有"写。M7 如果写成"用户能建一条带附件的证件记录，并在到期前收到提醒"，后面的取舍会不一样。
• 范围变了，计划、验收和排期要一起改。α 改了形态也加了范围，但没有重排安全模块的工期。
• 第一周就要有外部用户，哪怕只有三个。

二、计划

1. 有充足时间做计划吗

有。作业 3 到作业 5 连续做了选题、需求、原型、系统设计和数据库设计，接口契约在 Day1 冻结，这在课程项目里算准备得比较充分的。问题不在计划时间够不够，在颗粒度。我们能拆到"某天完成某 8 点任务"，却拆不出"加密做完的标准是什么""UI 好看的标准是什么"。

2. 计划阶段的分歧怎么解决

一般是站会讨论、组长裁决，涉及接口的走契约变更单。有效的例子是接口契约 Day1 冻结，F1 状态机提前三天完成，实现时签名一行没改。无效的例子是 D-02 口令长度，8~20 还是 32，Day3 就测出来了，一直到 Day7 才裁决，中间 SRS、契约和代码常量三处各说各话，测试探针一直红。分歧本身不可怕，拖着不裁决才麻烦。

3. 原计划的工作都做完了吗

Backlog 里的 21 项都做完了。但有一些"计划外但必须做"的事没做完，而且它们不在燃尽图里：受保护记录的编辑和凭据保存（依赖加密，没排期）、掩码的 UI 层接线（只做了 domain 纯函数）、DB v3→v4 迁移测试、LoginActivity 渲染层测试、D-01 和 D-06 的合入。这些事在 α 结束时的总结里都提过，但没有变成任务点，也没有人真正负责。

4. 有没有做了但事后看没必要的事

有三件。

一是三个人各自搭了一套 kotlinc 加 JUnit 的等价验证环境。出发点没错，本机没有 Android SDK，总得想办法验证。但三个人搭了三套，脚本还不完全一样，重复劳动不少。正确做法是用胡昊那台能跑 Gradle 的机器开一个共享脚本或容器，其他人拉下来用。

二是 Day6 提前清零后，把缓冲拿去做 Z2 掩码投影，而不是修已经红了三天的 D-01。掩码确实提前落地了，但 D-01 拖到 Day7 才在 c23441b 修，还没合入。缓冲被"看起来更出活"的新功能占用了。

三是分支命名整改花了半天。中文"测试"分支、feature/* 不统一，确实该改，但如果 Day0 用模板和命名检查解决，就不用在冲刺中返工。

5. 每项任务都有清楚的交付件吗

任务点有，交付件定义不够。举两个例子。F2"状态流转 UI"完成了，8 点也拿了，但入口挂在一个四个文件都不存在的详情页上，Day6 站会查 ls-tree 才发现，最后靠"记录列表长按"临时挂上去。还有 P4 详情页，代码 review 看着没问题，dev 上四个文件却是零文件。任务点完成和功能可用之间，差的就是"用户从哪个页面点到这个按钮"。

β 的每个任务卡都加了一列验收物，就是要逼着大家先想清楚做完是什么样。

6. 过程按计划走了吗，有哪些没估计到的意外

大体按计划，但有五个意外：

意外	影响	为什么没估计到
多数成员本机没有 Android SDK	无法本地跑 Gradle，验证分散	组队时只问了会不会 Java/Kotlin，没问环境能不能跑
Room 的 @Entity 表达不了 CHECK，建表脚本被 CREATE TABLE IF NOT EXISTS 整条跳过	约束静默丢失，差点带着脏数据继续	默认 Room 会尊重 SQL 脚本，没验证两套 DDL 的执行顺序
CI 体验版构建机 30 分钟限制、gradlew 权限、JDK 缺失	三轮才跑通，完整构建没落地	把 CI 当"最后配一下"，没当基础设施
Windows 凭据管理器缓存旧凭据	git push 卡死，排查半天	环境类问题没有 checklist
JDK 25 与测试框架不兼容	测试环境反复重搭	没锁 JDK/AGP/Gradle 版本矩阵

共同点是，这些都是环境和工具链问题，不是业务逻辑问题。这类问题最容易被"先把功能写了"挤到最后，然后一次性爆掉。

7. 计划里留缓冲区了吗，起作用了吗

形式上没有独立缓冲，实际上 Day6 提前清零形成了一天缓冲。但它被新功能占用了，没有起到兜缺陷的作用。Day7 一边回归一边修 D-01/D-06、改 D-02、补迁移测试、打包，节奏很紧，能出包有运气成分。

8. 将来的计划怎么改

• Day7 设为硬缓冲，只做回归、修 P0/P1、打包和彩排，不接新功能。
• 每个任务卡必须有验收物和依赖，没有验收物的任务不进 Backlog。
• 环境和工具链任务放在 Day0 到 Day1，不放到最后。
• 缓冲区只用于缺陷和风险，挪用要站会决议并记 CR。

计划的价值不在排得多满，在留了多少能吸收意外的空间。α 的计划表很漂亮，但它假设每个人环境都能跑、每个接口一接就通、每个缺陷一修就好，这三个假设后来都错了。β 把环境、集成和回归当成一等任务排进去，不再当成顺便做。

三、资源

1. 资源够吗

人手够，7 个人加 AI 技术员。设备和环境不够。能跑 Android 模拟器或真机的只有胡昊和杨俊鑫两台机器；测试只有陈瀚楷一个人，而且他本机没有 SDK，只能做源码拷贝加 ViewModel 桩的等价测试；没有 UI 自动化、没有 Monkey、没有性能采集；美工和视觉只有吴军峰一个人兼职，没有设计稿交付流程。

2. 任务时间和其他资源是怎么估的

按半天估，认领人自报，组长再压 10%。业务逻辑估得比较准，状态机和日期计算基本按期。安全、附件、UI 这类跨层且依赖环境的任务系统性低估：Z2 掩码只估了 domain 层 8 点，UI 接线和验证弹层根本没进 Backlog；附件在 α 里直接写了"作业 7"。

3. 测试的时间、人力和软硬件够吗，设计和文案低估了吗

不够。测试人力 1 人，测试机 1 台，测试时间被压在每天 22:00 之后。结果是 390 条 JVM 测试很扎实，UI 层几乎空白：掩码六个展示场景只测了纯函数，登录页渲染层没测，附件、通知、搜索这些新交互完全没有测试资产。

设计和文案明显低估。α 的界面是能用的控件堆在一起，14 个设计令牌只落在颜色和间距上，没有组件规范、没有空态和错误态文案、没有图标体系。答辩时评委说"功能挺全，但不像一个产品"，这个评价是准的。

4. 有没有"你做的事别人做更有效率"

有。契约文档由胡昊写、PM 评审，最后 PM 又花了很多时间对齐口径。如果 Day1 就由 PM 主笔、胡昊提供数据模型，会省一轮。测试报告由陈瀚楷手写加 AI 起草，其实 AI 出结构、人填结论更快。反过来，安全审查必须李天赐做，别人替不了。

学到的是，资源计划里必须写设备、环境和设计三项，不能只写人天；UI 设计要有交付物，不能边写边看；测试要从 Day1 参与契约评审，用例跟接口一起冻结。

四、变更管理

1. 相关的人都及时知道变更了吗

大部分知道，靠站会、群公告和 CR 单。α 期间出了 CR-20261026-01、CR-20261027-01/02、CR-20261028-01/02、CR-20261029-01/02 等变更单。但"知道"不等于"同步到所有载体"。D-02 口令长度裁决后，契约改了，CR 写了，SRS 和测试期望没改，代码常量也没改，导致文档说 8~20、代码收 32、测试探针红，这三件事并存了五天。

2. 怎么决定推迟和必须实现

站会拍板，没有正式的 MoSCoW。结果是会哭的孩子有奶吃：谁的任务卡住了，谁就占站会时间；安静但重要的任务，比如加密和迁移测试，一直往后排。β 改成显式分层，P0 必做、P1 应做且有降级方案、P2 不做，每次调整记 CR。

3. 项目的出口条件清晰吗

不清晰，这是 α 比较突出的管理问题。我们的出口条件是 156 点清零，不是四条验收场景通过。于是出现了几种情况：D-01 注册失败但账号已落库，红了三天，仍然宣布 Backlog 清零；D-02 探针一直 FAIL，仍然宣布缺陷收口；D-06 修复代码在分支上没合，缺陷清单标了"待合入"；P4 详情页四个文件在 dev 上不存在，F2 仍算完成。

不是大家故意隐瞒，是"完成"的定义允许这种模糊。β 的 DoD 七条加 AC-38 逐条留痕，就是针对这个。

4. 对可能的变更有没有应急计划

有，但没演练。α 计划里写了砍非核心页面、只保留登录加记录主路径、提前录屏，实际一次没触发，也没人验证过砍完之后演示还能不能讲圆。β 的降级方案要提前写好"砍了怎么讲"，不能现场想。

5. 员工能处理意料之外的工作请求吗

能，但靠个人加班。作业 5 答辩和 Day1 重叠、作业 7/8 和冲刺并行、临时补测试报告，都是靠晚上补。短期有效，长期不可持续，也让计划失去意义。

学到的是，变更管理的核心不是记录变更，是让变更到达每一个会被它影响的地方，代码、测试、文档、演示脚本一个都不能漏。α 的 CR 单写得不错，但缺少影响面 checklist 和关闭验证。

五、设计/实现

1. 设计什么时候、由谁做的

作业 3 到 5 完成：选题和 NABCD 是全员，需求规格黄炫文统稿，原型陈志和杨俊鑫，系统设计胡昊，数据库设计胡昊加陈志。时间合适，人也基本合适。缺的是 UI 设计没有对应的责任人和交付物，原型是线框，视觉规范只有 14 个令牌，没人对最终长什么样负责。

2. 设计有没有模棱两可的情况

有四处比较典型：

模棱两可	表现	怎么解决	教训
敏感级别默认值	物品/财务明文，证件/凭据受保护；SRS 与原型不完全一致	按"就严"执行（B-7）	默认值要写进契约，不靠口头
口令长度	SRS 820，代码 32，测试按 820	Day7 裁决方案 A，代码列入作业 7 第一批	裁决要当天落到代码
验证锁定的粒度	单条记录、单个类别还是整个应用	暂定整个应用 5 次锁 5 分钟	安全策略要有唯一出处
提醒与待办的关系	待办读 date_node 还是 reminder_task	α 先读 date_node，reminder_task 表空着	设计了但没用，是纸面设计

3. 用了哪些工具，有效吗，UML 和现状差多少

用了 JUnit（390 条）、Kotlin 纯 JVM 等价测试、Room schema 导出、verify_db.py（15 表、2 视图、14 触发器）、check_local.sh 和契约驱动的接口冻结。有效的地方很具体：状态机和日期计算的穷举测试，把跨月、闰年、月末、同一天多节点这些边界提前打出来了；verify_db.py 把"我确认过"变成"每次都能确认"；契约冻结让 7 个人并行开发不用回头改签名。

UML 和现状的差异也不小。类图里的 Attachment、ReminderTask、KeyVault 在代码里基本是空表或空壳；页面清单 P6、P7、P8、P9 没有实现；v_todo_summary 视图改成了直接查 date_node。这些差异没有回写设计文档，β 要用契约 v1.1 和设计说明书 v1.1 的增量章节补上。

4. 什么功能 Bug 最多，为什么，发布后发现了什么

Bug 集中在两处。账号和会话有 D-01 到 D-04：注册失败补偿、口令长度、邮箱正则、改密后会话未失效。根因不是算法，是跨层接线。AccountService 三件套在 dev 上，但全仓零调用方，ServiceLocator 没装配，sessionPersistence 桥接没实现，四处断点没有一处是"代码写错"，全是"没人负责接"。状态和日期边界有 D-05、D-06：年份溢出到 178958996，空备注掩码返回 8 个圆点。根因是写断言时没想到极端输入，测试跑出来才发现。

发布前发现的重要问题是 D-01 的风险升级。以前账号在内存里，杀进程就没了；账号落 Room 之后，每次失败注册都会真写 app_user，清理成本翻倍。这个缺陷从 Day2 红到 Day7，是"缺陷不过夜"的反面教材。

5. 代码复审怎么做的，严格执行规范了吗

李天赐做了全量审查，逐条核对 AccountServiceImpl 和 Day2 回调约定的 7 项、RecordServiceImpl 和 TodoServiceImpl 对 SessionService 的用法、ServiceLocator 注释里自报的"core 区 import service.impl 违反契约 2.2"，产出了对接审查文档，指出 3 个阻断真跑的缺口。这是 α 质量方面最有价值的动作之一。

但复审有两个问题。一是复审在合并后做，不是 MR 前做；二是复审只看代码，没看页面是不是真的可达。P4 四个文件零文件、F2 入口挂空，代码 review 都发现不了。β 的 MR checklist 加了一条"入口可达 + 截图"。

学到的是，设计文档不是写完就归档，接口、表、页面变更必须回写；跨层接线要有 owner，不能接口文件一人、实现文件另一人、调用方没人；复审要前移到 MR，而且必须看用户怎么点到这个页面。

六、测试/发布

1. 有测试计划吗

有。陈瀚楷 Day1 出了测试计划 v1.0，按天迭代了 4 次。问题是计划偏单元测试和功能测试，缺三块：UI 和交互测试、安全专项（加密、掩码、验证、日志）、性能和兼容性。β 的测试计划 v2.0 把这三块列为增量。

2. 做了正式的验收测试吗

做了接近正式的。终测聚合 84 条，81 通过 3 失败；全量回归 390 条 0 失败；数据库 15/15；闭环冒烟 10/10；verify_day5_sql 23/23；check_local 165 条。α 答辩 5 份评分平均 90.5，其中"测试与质量"16.8/20、"文档一致性"13.4/15 是得分率最低的两项，外部评价和我们的自评指向同一处。

更关键的是，没有按 SRS 的 AC-01 到 AC-38 编号逐条留痕。验收证据散在 5 份测试报告和截图里，助教和老师没法一眼核对某条 AC 过没过。β 会做一张 38 条的表，一条一行，通过、失败、阻塞都写清楚。

3. 有测试工具帮助吗

有 JUnit 4.13.2、Kotlin 2.0.21/2.4.21、Room schema、SQLite JDBC、verify_db.py、check_local.sh 和 CodeArts 流水线。没有 Robolectric/Espresso、没有 Monkey、没有性能 profiler、没有通知和权限的自动化。α 的测试是逻辑层很硬，交互层很软。

4. 怎么测量和跟踪软件效能，测试有用吗

基本没测效能。冷启动、内存、列表帧率、加解密耗时、搜索耗时都没有数据。测试有用是肯定的，390 条里抓出 6 个缺陷，其中 D-05 年份溢出是人眼很难看出来的；verify_db.py 把数据库约束从"相信脚本"变成"每次验证"。但测试的价值被"修了没合"打了折，D-01 和 D-06 的修复在 c23441b，测试在 dev 上跑，当然还是红。

5. 发布过程中发现了哪些意外

• Debug APK 7.2MB 能出包，但没有 Release 签名，也没有安装、升级、卸载的完整验证；
• CI 体验版构建机 30 分钟限制，完整 Android 构建没跑通；
• D-02 常量没改，测试探针仍然 FAIL；
• 掩码 UI 没接，只有 domain 层；
• DB v3→v4 迁移脚本没有测试，升级路径是黑的；
• 演示靠模拟器加本地数据，没有预置账号和数据的脚本。

学到的是，验收要按 AC 编号做表，一条一行，别让助教帮你拼图；"修了"必须"合了 + 回归绿了"才算关闭；发布物从 Day1 就按 Release 标准做，不要最后一天才想起 debug 不等于 release。

七、团队的角色、管理、合作

1. 角色怎么确定的，人尽其才了吗

自荐加能力加组长协调。整体合适：胡昊扛基建和数据，李天赐扛安全和审查，杨俊鑫扛页面和联调，吴军峰扛 UI 和列表，陈志扛日期和状态，陈瀚楷扛测试，黄炫文扛 PM、博客、CI 和答辩。三个不太匹配的地方：PM 承担的事务比较集中，站会、博客、CI、契约、答辩、作业提交全在一个人身上，Day1 和答辩撞车时只能把站会压到 25 分钟；测试人力只有 1 人，而且本机没 SDK，只能做等价测试；UI 没有明确的负责人，吴军峰同时做列表、分类、状态 UI 和设计令牌，视觉打磨自然排到最后。

β 的调整是，林铭宏接测试，胡昊明确为集成负责人，杨俊鑫明确为答辩负责人，李天赐负责 PPT 和安全文档，PM 只留计划、博客、对外和答辩统筹。

2. 成员之间互相帮助了吗

帮了不少。杨俊鑫一个晚上补齐了 AuthViewModel 调 ServiceLocator.accountService、ServiceLocator 从只装 sessionService 扩到五项、sessionPersistence 桥接三处缺口，I1 才能闭环。胡昊修了吴军峰分支的两处编译错误（attachSession 不在接口、savedInstanceState 取不到），并统一了 ServiceLocator 装配。李天赐全量审查 dev，指出 AccountService 零调用、AuthViewModel 写死 E_NOT_IMPLEMENTED、sessionPersistence 未实现三个阻断项。陈志把 verify_db.py、吴军峰把 check_local.sh 维护成公共回归资产。陈瀚楷每天把当天全部提交拉下来写用例，D-01 到 D-06 基本都是测试先红。

3. 出现管理和合作问题时怎么解决

站会裁决，群里对齐，文件级归属。两个典型例子。

ServiceLocator 撞车，李天赐和吴军峰分别做了 service/api 和 core/locator。Day3 发现，Day4 站会定"统一到 core/locator，不再保留两套"，后续装配由胡昊负责，之后没再冲突。

DateRepo 任务重叠，陈志和胡昊同时实现，返工约 1100 行。Day6 站会复盘，定"同一文件只能一人负责、接口文件单独指定 owner、契约 13.5 写清楚归属"，并把这条写进 β 规则。教训是，任务归属写进文档不等于不会重叠，必须细到文件。

4. 感谢

感谢人	被感谢人	因为什么事
黄炫文	李天赐	全量审查 dev 提交，把"敏感字段必须经 CryptoService"从口号落成硬约束，Day7 也顶住了没有乱动核心安全代码
胡昊	陈志	建表脚本与 verify_db.py 的 DBAC 验收口径对齐；Room 吞 CHECK 时一起定下 onCreate 先 DROP 再重建的策略
陈志	胡昊	修 ServiceLocator 五项装配和队友分支的编译错误，让 G1 日期节点能真正落地
杨俊鑫	吴军峰	Day4 一夜补齐登录链路三处接线，第二天 I1 闭环联调才能走通
吴军峰	李天赐	审查指出 AccountService 三件套全仓零调用方，避免"服务写好了没人用"的假完成
李天赐	陈瀚楷	用 53 条用例把"看起来能跑"和"符合规格"的差距量化，D-01 到 D-06 都是测试先红
陈瀚楷	胡昊	修 D-01/D-06 并补测试替身，让缺陷清单能真正清零

学到的是，角色要按交付物分，不按模块分，每个交付物只有一个 owner；测试必须从 Day1 进契约评审；感谢要具体到事，不然就是客套。

八、总结

1. 团队现在在什么水平

CMMI 大概在 1 级到 2 级之间。有计划、有跟踪、有配置管理（Git、MR、Issue、CR）、有测试资产，这些是 2 级的特征；但度量不稳定，燃尽按任务点不按价值，缺陷预防没有制度化，同类问题反复出现，过程也没有裁剪依据，所以还不敢说已经是"已管理级"。

塔克曼阶段在规范期后段，往创造期走。标志是冲突能靠规则解决，比如文件归属、契约变更，不用靠嗓门；但还没到不用 PM 催、大家自动补位的程度。

2. 相比上一个里程碑有什么改进

α 之前我们更多是在写文档，α 之后能出安装包了，这是最大的变化。契约先行和接口冻结，让 7 个人并行没有大面积返工，答辩 90.5 分里"安排计划与实现"14.1/15 是得分率最高的一项。测试从 0 到 390 条，缺陷从感觉变成清单，但"测试与质量"16.8/20 最低，说明有测试和测得让人信服还有距离。CI、脚本和回归资产开始沉淀，不再靠"我本地能跑"。

同时也新增了"任务点完成不等于功能可用"的坏习惯，这是 β 要还的债。

3. 最需要改进的一个方面

完成定义。只要完成还是任务点清零，D-01 这种红了三天的缺陷就会继续被"完成"掩盖。β 把完成改成 DoD 七条、AC-38 逐条留痕、"修了必须合"，这是所有整改里最重要的一条。

4. 对照敏捷原则

做得最好的是每日站会。7 天没断过，线上也开，站会决议当天闭环，ServiceLocator、DateRepo、D-02 都是站会定的。自组织也还可以，杨俊鑫半夜补三处接线、胡昊主动修队友编译错误、陈志把口头结论写成脚本，都是没人指派的自发补位。持续改进也在做，CR 单、站会复盘、每天随笔里的"存在问题"不是摆设，β 的 8 条整改全部来自这些记录。

做得最差的是"可工作的软件是进度的首要度量"。我们用任务点和燃尽图度量进度，结果燃尽归零时，用户还不能完整用。β 的燃尽图会同时标可演示场景数，让两条线互相校验。

5. β 的 8 条整改

#	整改	对应 α 问题	验收
1	完成定义改为 DoD 七条加 AC-38 逐条留痕	出口条件模糊	总结博客附 AC 表
2	缺陷全局 ID（B-01 起），"修了没合"不算关闭	D-01/D-06 未合	缺陷清单加合并记录
3	Day7 硬缓冲，只回归、修 P0、打包，不接新功能	缓冲被挪用	站会纪要
4	统一构建机和 CI，消灭三套等价环境	环境重复劳动	每日构建记录
5	契约变更四处同步（SRS/契约/测试/演示），当天落地	D-02 口径不一致	CR 关闭检查表
6	文件级 owner，含接口文件，同一文件一人	DateRepo 1100 行返工	契约 13.5 归属表
7	UI 设计令牌加走查清单，UI 也排任务点	UI 不像产品	走查清单加前后对比
8	用户验证前置，Day1 起拉真实用户	用户量 0	≥15 份调查报告

6. α 数据看板

指标	数值
Backlog	21 项 / 156 任务点
燃尽	Day6 归零，提前 1 天
代码提交	100+ 次，MR 10+，工作项 7 个
缺陷	6 个（D-01~D-06），Day7 仍有 3 个未闭环
单元测试	390 条 JVM 回归 0 失败
终测	84 条，81 通过 / 3 失败
数据库验收	15/15（15 表 / 2 视图 / 14 触发器）
闭环冒烟	10/10
交付物	Debug APK 7.2MB；测试报告 5 份；契约 v1.0；测试计划 v1.0
真实用户	0

相关文档：代码仓库 https://codehub.devcloud.cn-north-4.huaweicloud.com/10668555b4754395b09a3ce886e8a3d8/software-schoolwork-lifemap。