事后诸葛亮分析

Student-Management-System 事后诸葛亮分析报告

1. 设想和目标

1.1 我们的软件要解决什么问题？是否定义得很清楚？

我们的软件解决传统学生信息管理系统操作复杂、功能单一、响应慢的问题，打造一个现代化的多角色协同管理系统。问题定义比较清楚，针对学生、教师、管理员三个典型用户，明确了各自的核心场景（如学生选课、教师录成绩、管理员权限配置）。

1.2 我们达到目标了么？

• 功能完成情况 ：实现了原计划的8个核心功能（用户认证、个人信息管理、课程选择、成绩查询、图书管理等），只有高级数据可视化功能没做。
• 交付时间 ：按原计划在Deadline前完成。
• 用户数量 ：Alpha版本面向内部测试，实际使用人数符合预期（约10人）。

1.3 和上一个阶段相比，团队软件工程的质量提高了么？

相比项目启动时，有明显提高：

• 代码规范 ：从"随便写"到建立了统一的命名规则和注释要求，后端代码注释覆盖率从10%提到35%。
• 测试意识 ：从"写完再说"到"边写边测"，单元测试用例从0增加到50+个。
• 协作流程 ：从"各自为政"到"每天同步进度"，Bug修复时间从2天缩短到半天。

1.4 用户量和用户接受程度与预想一致么？

用户量符合预期。用户对核心功能（课程选择、成绩查询）接受度较高，说"比原来的系统好用"，但对部分UI细节（如课表颜色）和响应速度（如批量选课时等待时间长）提出了建议。

经验教训

如果重来一遍，我们会：

• 更详细地调研用户需求，特别是UI细节偏好
• 提前规划性能优化方案，尤其是批量操作场景
• 更早地让用户参与测试，获取反馈

2. 计划

2.1 是否有充足的时间来做计划？

初期留了3天做计划，时间基本够，但对技术学习时间估计不足，导致后期赶工。

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

主要通过"讨论+投票"解决：
首先团队成员各自阐述观点和理由，然后由全栈柯程炜基于技术可行性、开发难度和用户需求综合判断。比如在"登录认证机制"选择上，张滨皓倾向于使用传统Session认证（认为更熟悉、容易调试），王佳俊则建议使用JWT认证（认为前后端分离架构更适合，无需维护会话状态），柯程炜分析后认为：JWT虽然学习成本稍高，但更适合前后端分离架构，能减少服务器压力，且便于移动端扩展，最终投票决定采用JWT认证方案，并由他负责核心实现，张滨皓协助调试。

2.3 原计划的工作是否最后都做完了？

大部分做完了，只有"高级数据可视化"功能没做，因为：

• 前端开发王佳俊对图表库（ECharts）不太熟悉
• 时间有限，优先级排在核心功能之后

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

有，比如我们花了1天时间美化登录页面的动画效果，后来发现用户根本不在意这个，反而觉得加载慢。

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

核心功能（如用户登录）的交付件很清楚（"能正常登录并返回token"），但一些辅助功能（如成绩趋势图）的交付件比较模糊（"能显示就行"），导致后期改了好几次。

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

前半段基本按计划，后半段遇到了RocketMQ集成问题：

• 意外 ：原本以为消息队列集成很简单，结果花了3天时间调试连接问题。
• 原因 ：对RocketMQ的配置要求不熟悉，没有提前学习。

2.7 在计划中有没有留下缓冲区，缓冲区有作用么？

计划中留了10%的缓冲区时间（约2天），主要用来解决RocketMQ的问题，正好用上了，很有作用。

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

• 增加技术预研时间，尤其是新技术栈
• 把缓冲区比例提高到15%
• 更细化每个任务的交付件标准

3. 资源

3.1 我们有足够的资源来完成各项任务么？

• 人力资源 ：3个人基本够，但前端开发王佳俊同时做测试，有点忙不过来。
• 技术资源 ：有网络资料，但部分新技术（如RocketMQ）的中文教程不多。
• 设备资源 ：测试设备足够，有Windows和Mac电脑。

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

主要凭经验估计：

• 核心功能（如用户登录）估计准确，误差5%以内。
• 技术集成（如Redis缓存）估计不足，误差30%。

3.3 测试的时间、人力和软件/硬件资源是否足够？

• 测试人力 ：只有王佳俊一个人做测试，时间有点紧。
• UI设计 ：低估了难度，原本以为1天能做完，结果花了3天，还不太满意。

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

有，比如：

• 后端张滨皓在做单元测试时，发现全栈柯程炜更熟悉测试框架，后来部分测试用例交给柯程炜写，效率更高。
• 前端王佳俊在调试样式时，柯程炜有经验，帮忙调了一下，节省了时间。

经验教训

如果重来一遍，我们会：

• 更合理地分配任务，根据每个人的专长分工
• 提前学习必要的技术，避免临时抱佛脚
• 考虑引入外部UI设计资源，提高页面美观度

4. 变更管理

4.1 每个相关的员工都及时知道了变更的消息？

大部分时候能及时知道，主要通过微信群通知，但有时候一个人改了代码没说，导致后面合并时冲突。

4.2 我们采用了什么办法决定"推迟"和"必须实现"的功能？

• 必须实现 ：直接影响核心流程的功能（如用户登录、课程选择）。
• 推迟实现 ：非核心功能（如高级数据可视化、移动端适配）。

4.3 项目的出口条件有清晰的定义么？

基本清晰，我们认为"做好了"是指：

• 核心功能能正常运行
• 没有致命Bug
• 页面能正常打开
• 能通过基本的测试用例

4.4 对于可能的变更是否能制定应急计划？

简单的变更（如修改一个字段名）有应急计划（"先备份，不行就回滚"），但复杂变更（如重构一个模块）没有。

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

能，比如突然要求增加"图书预约"功能，我们调整了计划，加班赶了出来。

经验教训

如果重来一遍，我们会：

• 建立更规范的变更通知机制（如每次代码提交必须写说明）
• 制定更详细的应急计划，尤其是复杂变更
• 每周预留一定时间处理突发需求

5. 设计/实现

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

设计工作在项目第2-3天完成，主要由全栈柯程炜负责，后端张滨皓参与讨论。时间比较合适，因为在开发前就确定了架构。

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

有，比如在设计"课程时间冲突检查"时，对"什么算冲突"有不同意见：

• 柯程炜认为"同一时间段（如1-2节）有重叠就算冲突"
• 张滨皓认为"只要上课时间不完全重合就不算"
  最终我们查了学校的选课规则，确定了"同一时间段有重叠就算冲突"，解决了分歧。

5.3 团队是否运用了单元测试、UML等工具？

• UML ：柯程炜画了简单的类图，但后来开发时有些类结构变了，比如原来的User类后来拆成了Student和Teacher，所以UML文档没更新。
• 单元测试 ：用了JUnit，写了50+个用例，效果很好，提前发现了很多Bug。
• Postman ：用来测试API，很方便，节省了手动测试时间。

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

课程选择模块产生的Bug最多（8个），主要原因：

• 逻辑复杂，涉及时间冲突、学分限制、权限校验等多个条件。
• 边界条件考虑不周，比如"选课人数已满"的情况没处理好。
• 前后端交互多，容易出现数据不一致。
  发布后发现的重要Bug："退课后课表没更新"，因为后端更新了数据库，但前端没重新请求数据。

5.5 代码复审是如何进行的？

采用"交叉复审"：

• 后端代码由柯程炜复审
• 前端代码由张滨皓和王佳俊一起看
• 每周五下午开1小时代码复审会，主要检查命名规范和逻辑漏洞
  基本执行了代码规范，但有时候赶工就没严格检查。

经验教训

如果重来一遍，我们会：

• 开发前更详细地设计，考虑更多边界条件
• 及时更新UML文档，保持和代码一致
• 更严格地执行代码复审，尤其是赶工时

6. 测试/发布

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

有简单的测试计划，主要是"功能列表+测试点"，但没有详细的测试用例文档和测试时间表。

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

进行了简单的验收测试，由柯程炜和张滨皓模拟真实用户使用，发现了3个小问题，都及时修复了。

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

目前主要用Postman测试API，用浏览器手动测试前端，没有自动化测试工具。 改进计划 ：准备引入Cypress进行前端自动化测试，重点测试核心流程（登录、选课、成绩查询），自动生成测试报告，比较每次测试结果的差异。

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

主要通过：

• 浏览器开发者工具看页面加载时间
• 手动计时API响应时间（比如批量选课时数秒）
• 没做压力测试，因为不知道怎么弄
  测试工作有用，发现了一些性能问题，比如成绩统计页面加载慢，后来优化了SQL查询，速度提高了30%。

6.5 在发布过程中发现了哪些意外问题？

• Safari浏览器下课程表PDF下载失败（后来改成了截图功能）
• 首次部署时Redis连接超时（后来调整了配置）
• 低分辨率屏幕下页面布局错乱（后来加了响应式设计）

经验教训

如果重来一遍，我们会：

• 提前学习自动化测试工具，提高测试效率
• 学习压力测试方法，确保系统在多用户下稳定运行
• 更详细地测试不同浏览器和屏幕尺寸

7. 团队角色、管理和合作

7.1 团队的每个角色是如何确定的，是不是人尽其才？

角色是根据每个人的技能确定的：

• 柯程炜：有前后端开发经验，当全栈开发
• 张滨皓：熟悉Java，当后端开发
• 王佳俊：会Vue，当前端测试
  基本人尽其才，但王佳俊同时做测试，有点忙。

7.2 团队成员之间有互相帮助么？

有，比如：

• 柯程炜帮王佳俊调试前端样式
• 张滨皓帮柯程炜写了部分后端接口
• 王佳俊测试时发现的Bug，柯程炜和张滨皓及时修复

7.3 当出现项目管理、合作方面的问题时，团队成员如何解决？

主要通过讨论解决，比如有一次因为代码冲突吵架，后来冷静下来一起查原因，制定了"先pull再push"的规则。

感谢

• 柯程炜：感谢张滨皓帮忙写了成绩管理的后端代码，节省了我很多时间；感谢王佳俊认真测试，发现了很多我没注意到的Bug。
• 张滨皓：感谢柯程炜在我遇到Redis配置问题时耐心指导；感谢王佳俊帮我测试了后端接口，提出了改进建议。
• 王佳俊：感谢柯程炜帮我调试了课程表的样式问题；感谢张滨皓在我测试时及时修复了Bug，让我能顺利完成测试。

8. 总结

8.1 团队目前的状态属于CMM/CMMI中的哪个档次？

应该是CMMI的第1级（初始级），因为我们虽然能完成项目，但过程不规范，主要靠个人经验。

8.2 团队目前处于哪个阶段？

磨合阶段，成员之间已经有了基本的信任和协作，但还没形成固定的工作模式，遇到问题需要沟通解决。

8.3 团队在这个里程碑相比前一个里程碑有什么改进？

• 协作更顺畅，从"各自为政"到"团队协作"
• 代码质量更高，从"随便写"到"讲规范"
• 测试意识更强，从"写完再说"到"边写边测"

8.4 目前最需要改进的一个方面是什么？

测试自动化，因为目前主要靠手动测试，效率低，容易漏测。

8.5 对照敏捷开发的原则，做得最好的是哪几个？

• 响应变化胜过遵循计划 ：我们能根据用户反馈及时调整功能，比如把PDF课表改成了截图功能。
• 工作软件胜过详尽文档 ：我们先做出可用的软件，再逐步完善文档，而不是先写一大堆文档。
• 个体和交互胜过流程和工具 ：我们更重视团队沟通，遇到问题及时讨论，而不是严格按流程走。

8.6 如何提高软件工程的质量？

1. 代码管理质量 ：

   • 严格执行代码规范，用ESLint和CheckStyle自动检查
   • 每周固定时间进行代码复审，记录问题并跟踪改进
   • 学习Git分支管理，避免代码冲突

2. 程序架构质量 ：

   • 学习设计模式，优化代码结构
   • 定期进行代码重构，比如把重复代码提取成公共方法
   • 用SonarQube等工具测量代码质量，目标是把Bug密度降到1个/千行

3. 软件工具应用 ：

   • 引入自动化测试工具（Cypress、JUnit）
   • 用Jenkins做持续集成，自动构建和测试
   • 用Swagger自动生成API文档

4. 项目管理 ：

   • 每周开站会，同步进度和问题
   • 制定更详细的项目计划，包括每个任务的时间和交付件

5. 用户数据跟踪 ：

   • 计划在Beta版本加入简单的埋点，统计页面访问量和功能使用频率
   • 每周分析用户数据，了解哪些功能常用，哪些没用

6. 项目文档质量 ：

   • 用Markdown写文档，保持简洁清晰
   • 每个模块写完后及时更新文档
   • 文档放在代码仓库里，方便查阅

7. 人的领导和管理 ：

   • 学习《构建之法》中关于PM的内容，提高项目管理能力
   • 建立简单的绩效考核机制，比如根据完成的任务量和质量评分
   • 定期组织技术分享，提高团队整体水平

8. 软件工程理论体会 ：

   • 体会到"没有银弹"，没有一种方法能解决所有问题，需要根据实际情况调整
   • 理解了"早期发现Bug成本低"，所以要重视单元测试和代码复审
   • 认识到"团队协作比个人能力更重要"，一个好的团队能把普通人变成高手

全组讨论照片

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

名字	角色	团队贡献分	可验证贡献
柯程炜	全栈开发	35	系统架构设计，核心前后端开发，技术文档编写，主要Bug修复
张滨皓	后端开发	30	后端模块开发，数据库配置，单元测试编写，辅助Bug修复
王佳俊	前端开发兼测试	25	前端页面开发，测试用例设计，Bug发现与系统测试，验收测试执行

结语

通过这次项目，我们学到了很多软件工程的知识，从只会写代码到学会了项目管理、团队协作、测试等。虽然遇到了很多问题，但都一一解决了。我们知道自己还有很多不足，比如测试自动化、架构设计等，但我们会继续学习，在Beta阶段做得更好！