事后诸葛亮分析

一、设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
核心问题定义清晰：解决图书馆图书管理、读者服务的高效化问题，涵盖图书借还、检索、读者管理等核心场景；但初期对 “统计分析模块” 的功能边界界定模糊（如未明确 Alpha 阶段仅做基础标签打标，而非完整推荐功能），导致开发初期存在方向分歧。典型用户（管理员、普通读者、临时读者）及场景描述较完整，无严重偏差。
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）
功能达成：原计划 Alpha 阶段实现的 7 个核心功能（图书检索与筛选、读者信息管理、图书借还、预约与优先级管理、多渠道提醒、管理员基础界面、检索算法优化）全部落地，完成率 100%；
交付时间：按进度计划在第 13 周完成开发，第 14 周完成测试，无延期；
用户数量：邀请 20 名目标用户（17 名读者、3 名管理员）参与测试，达到原计划用户量目标。
和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
有显著提高：
代码规范：从无统一规范到制定命名、注释标准，核心模块注释覆盖率达 70%（初期为 0）；
测试流程：从 “无序测试” 到建立 “单元测试 - 集成测试 - 系统测试” 分层策略，Bug 发现效率提升 40%（初期 1 周发现 3 个 Bug，后期 1 周发现 5 个）；
文档完整性：从仅 1 份简单需求初稿，到输出 6 份完整文档（需求说明书、架构设计文档等），完善度提升 60%。
用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
一致。测试用户量符合预期，核心功能（借还、检索）接受度达 90%，预约功能接受度 80%；相比项目启动时 “仅完成功能雏形” 的状态，当前系统已能满足图书馆日常基础运营需求，离 “高效、易用的智慧图书馆管理系统” 目标更近一步。

二、计划

是否有充足的时间来做计划？
有，项目前期预留 2 周（第 9-10 周）用于需求调研与计划制定，但团队成员初期对 “任务拆分、工时预估” 经验不足，导致部分任务时间预估偏差（如检索算法优化原预估 12 小时，实际耗时 18 小时）。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
通过 “周例会 + 即时沟通” 讨论，PM 统筹协调最终拍板，但缺乏结构化意见表决机制。例如关于 “是否在 Alpha 阶段做批量导入功能” 的争议，仅依赖 PM 经验判断推迟，部分成员仍有顾虑。
你原计划的工作是否最后都做完了？如果有没做完的，为什么？
核心任务全部做完，1 个辅助任务（书评）未完成，因后期发现时间紧张，经团队协商推迟至 Beta 阶段。
有没有发现你做了一些事后看来没必要或没多大价值的事？
有。初期过度设计管理员端界面细节（字体、按钮尺寸），前后修改 3 次，占用 8 小时开发时间，Alpha 阶段只需界面简洁可用即可，美观度可后续优化。
是否每一项任务都有清楚定义和衡量的交付件？
核心任务（接口开发、界面实现）有明确交付件（接口文档、可运行界面），但辅助任务（测试数据准备）未明确标准，导致重复工作（颜嘉盈准备 100 条图书数据，何昊天又补充 50 条）。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
整体计划执行度 90%，无重大意外。未预估到 “第三方短信接口对接延迟” 风险，原计划 1 天完成，实际因接口文档不清晰沟通 2 天，原因是初期未评估外部依赖的沟通成本。
在计划中有没有留下缓冲区，缓冲区有作用么？
留了 20% 时间缓冲区（如原计划 10 天开发，预留 12 天），作用显著。检索算法优化、并发问题排查等超出预估的工作，均在缓冲区内完成，避免项目延期。

三、资源

我们有足够的资源来完成各项任务么？
人力、硬件资源基本充足，但缺乏标准化测试数据集，测试数据准备耗时 6 小时；前端开发初期无专业美工支持，界面设计由开发人员承担，效率较低。
各项任务所需的时间和其他资源是如何估计的，精度如何？
时间估计依赖成员经验，初期精度 60%，后期通过 “每日站会同步进度”，精度提升至 80%；对非编程资源（文档编写、用户调研）难度预估不足，如需求说明书完善原计划 2 天，实际用 3 天。
测试的时间，人力和软件 / 硬件资源是否足够？对于那些不需要编程的资源 (美工设计 / 文案) 是否低估难度？
测试人力充足（颜嘉盈 + 黄思博），但测试工具仅用基础的 Postman、JMeter，缺乏自动化测试工具，功能测试以手动为主，效率不高；
严重低估美工设计难度，开发人员因缺乏设计经验，界面布局前后修改 3 次，占用核心开发时间。
你有没有感到你做的事情可以让别人来做（更有效率）?
有。前端 CSS 样式设计若由专职美工负责，开发人员可聚焦功能实现，效率提升 30%；测试数据准备可由专人整理标准化数据集，避免重复劳动。

四、变更管理

每个相关的员工都及时知道了变更的消息？
是。团队集中办公，变更信息（需求调整、接口修改）通过即时沟通工具同步，响应及时。如 “图书删除需校验借阅状态” 的需求变更，当天同步给所有成员。
我们采用了什么办法决定 “推迟” 和 “必须实现” 的功能？
采用 “功能四象限” 方法（按重要性 + 紧急性划分），快速决策。如 “批量操作功能” 重要但不紧急，推迟至 Beta 阶段；“预约优先级判定” 紧急且重要，Alpha 阶段必须实现。
项目的出口条件（Exit Criteria – 什么叫 “做好了”）有清晰的定义么？
有。Alpha 阶段出口条件：核心功能 100% 可用、连续运行 24 小时无崩溃、支持主流浏览器、页面加载时间 < 2 秒，成为测试与发布的核心依据。
对于可能的变更是否能制定应急计划？
不能。对需求变更、接口故障等无预设应急计划，如短信接口对接失败时，临时切换为站内信提醒，浪费 1 天时间。
员工是否能够有效地处理意料之外的工作请求？
能。规定所有意外工作请求先同步至PM，由PM评估优先级后分配，避免开发人员被频繁打断。

五、设计 / 实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
架构设计、数据库设计在第 11 周完成，时机合适，由PM黄思博统筹、技术骨干颜嘉盈主导。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
碰到过。如 “预约优先级算法” 设计有两种方案（按读者等级 / 预约时间排序），通过讨论达成一致：优先按读者等级排序，等级相同则按预约时间排序。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
运用了单元测试、UML、ORM 框架（SQLAlchemy）：
单元测试：后端模块覆盖率 60%，执行单元测试的模块 Bug 数量比未执行的少 40%，效果显著；
UML：初期绘制核心实体关系图，后期增加违规记录模块未及时更新，文档与实际脱节；
SQLAlchemy：简化数据库操作，提升开发效率 30%。
区别：缺少新增模块的关系描述，原因是无 “文档同步更新机制”；后续必须更新 UML 文档，确保与代码一致。
什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的 bug? 为什么我们在设计 / 开发的时候没有想到这些情况？
图书借还功能 Bug 最多（3 个），因涉及多模块联动（读者资格校验、图书状态更新、逾期计算），未考虑 “读者逾期未还仍能续借” 的边界场景；
发布后未发现重要 Bug，未想到的场景源于用户调研不够细致，未覆盖边缘情况。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
初期采用 “交叉复审”（黄思博复审袁斯楷，颜嘉盈复审何昊天），后期因进度紧张审核力度减小；
代码规范执行较好，核心模块无严重风格不一致问题，仅少数变量命名不规范，已在复审时修正。

六、测试 / 发布

团队是否有一个测试计划？为什么没有？
有。制定了完整的测试计划，明确测试类型、进度、负责人，避免了无序测试。若未制定计划，测试会陷入 “想到哪测到哪” 的混乱状态。
是否进行了正式的验收测试？
是。由测试人员颜嘉盈与 PM 黄思博共同执行，依据出口条件判定，未出现 “迫于压力隐瞒问题” 的情况，测试结果客观。
团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
有。使用 Postman（接口测试）、JMeter（性能测试）、Wireshark（安全性测试）；
改进计划：Beta 阶段引入 Selenium 实现核心功能（登录、借还、检索）的自动化测试，编写 30 + 条自动化脚本；通过 Jenkins 生成自动化测试报告，对比每次测试结果的差异，标记新增 Bug。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
效能测量：通过 JMeter 记录核心功能响应时间，统计页面加载耗时；
压力测试：模拟 5000 用户在线、100 用户并发检索，验证系统稳定性；
作用：发现了 “大量数据加载卡顿” 的性能问题，为优化提供依据；
改进：补充长时间稳定性测试（72 小时连续运行），增加大数据量测试场景（如 2000 条图书数据检索）。

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

团队的每个角色是如何确定的，是不是人尽其才？
角色基于成员技术特长确定：前端能力强的袁斯楷负责界面开发，数据库经验丰富的颜嘉盈主导数据层设计，协调能力强的黄思博担任 PM，何昊天负责性能优化与后端开发，实现人尽其才。
团队成员之间有互相帮助么？
有。例如：
袁斯楷前端开发遇接口调用问题，颜嘉盈提供清晰的接口文档并协助调试；
何昊天优化并发处理时，颜嘉盈提供性能测试数据支持；
黄思博整理文档时，全体成员补充各模块细节。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
通过 “即时沟通 + 周例会讨论” 解决。如开发初期 “统计模块分工” 问题，通过集体讨论确定 “先基础后优化” 的分阶段实施策略。

八、总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
处于 CMMI 2 级（可重复级），已建立基本的项目管理流程（计划、测试、变更管理），但流程的标准化、自动化程度仍需提升。
你觉得团队目前处于 萌芽 / 磨合 / 规范 / 创造 阶段的哪一个阶段？
处于 “规范阶段”。团队成员明确角色职责，协作流程顺畅，已形成统一的工作规范和沟通机制，相比项目初期的 “磨合阶段” 有显著进步。
你觉得团队在这个里程碑相比前一个里程碑有什么改进？
项目管理更规范：从 “无序推进” 到有明确的计划、测试、变更流程；
技术实现更成熟：运用了单元测试、ORM 框架等工具，代码规范度提升；
协作效率更高：成员间分工明确、互助频繁，问题解决更高效。
你觉得目前最需要改进的一个方面是什么？
自动化测试覆盖率不足，导致功能测试效率低、重复劳动多，是当前最需改进的方面。

九、团队成员 Alpha 阶段角色与贡献明细

姓名	角色	团队贡献分	可验证的贡献
袁斯楷	Dev（前端开发 + 原型设计）	22 分	1. 完成读者端检索界面、个人中心界面及管理员端核心操作界面开发，累计编写 1600 + 行前端代码；
			2. 设计系统交互原型，明确模块跳转逻辑，优化用户操作流程；
			3. 参与前后端联调与集成测试，协助修复界面兼容性 Bug8 个；
			4. 编写前端代码注释 120 + 条，确保代码可读性；
			5. 整理会议记录与项目文档，输出前端开发总结。
颜嘉盈	Test（测试 + 后端开发）	21 分	1. 完成数据库设计与初始化，编写数据库脚本及基础接口文档；
			2. 开发图书检索接口并优化检索算法，降低查询响应时间 30%；
			3. 执行单元测试与接口测试，设计测试用例 50 + 条，发现并提交 Bug11 个；
			4. 验证 Bug 修复效果，其中 5 个关键 Bug（含密码加密、借阅状态校验）已确认修复；
			5. 协助整理测试报告与数据统计分析，提供性能优化建议。
黄思博	PM（项目统筹 + 测试统筹）	19 分	1. 制定项目整体进度计划、任务分解及资源协调；
			2. 主导需求改进与原型优化，输出完善版需求说明书；
			3. 设计测试计划与核心测试用例，统筹系统测试与用户反馈收集；
			4. 开发读者信息管理接口及权限校验逻辑，完成 12 小时开发任务；
			5. 组织迭代会议与问题复盘，推动团队协作。
何昊天	Dev（后端开发 + 性能优化）	18 分	1. 开发图书预约接口及优先级算法，实现预约逻辑闭环；
			2. 对接多渠道提醒服务，完成短信接口集成与测试；
			3. 优化系统并发处理能力，支持 100 + 用户同时在线操作无卡顿；
			4. 参与系统稳定性测试，排查并修复数据加载卡顿问题；
			5. 编写后端核心模块注释 80 + 条，协助团队成员理解业务逻辑。

附：全组讨论照片