事后诸葛亮分析报告
设想和目标###
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
主要解决了多种功能集成和高并发的问题项目的典型用户包括教师、学生以及系统管理员，场景涵盖了信息管理、成绩管理等。对于这些场景，目标清晰。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
根据项目进展，原计划的功能基本完成，消息的高效处理等方面。如果按照原计划，目标用户数量应当有明显增长，但具体的交付时间和用户增长需要进一步的量化数据。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
后端服务的高效性和可扩展性方面，应该有明显提高。可以通过系统监控、响应时间、错误率等指标来衡量。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
后端服务的高效性和可扩展性方面，应该有明显提高。可以通过系统监控、响应时间、错误率等指标来衡量。
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在实际开发过程中，可能低估了消息同步和用户处理的复杂度。如果重来一遍，可以在设计初期更早考虑到系统的负载均衡和扩展性问题。
计划
1. 是否有充足的时间来做计划?
如果按团队的规模和资源来看的话，可能在初期阶段对功能的规划和预期时间上有所高估。可能有一些时间分配不当的地方。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
在项目初期的计划阶段，可以通过定期的会议和团队协作来协调不同的意见，确保每个成员能理解并认同最终的目标。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
根据反馈，项目大部分目标都已完成，但某些复杂功能（例如消息历史的增量加载）可能在时间上略有延迟。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
可能对于某些历史数据加载的机制设计过于复杂，实际中发现一些优化空间。
5. 是否每一项任务都有清楚定义和衡量的交付件?
在项目中，任务分配明确，交付件有明确标准，比如API接口的开发，前后端功能的集成等。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目进展过程中有一些意外的风险，比如上线时的负载高峰测试，虽然未能完全预测到，但通过提前的压力测试已做出调整。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
项目中并未设置专门的缓冲区，导致一些意外情况发生时缺少足够的时间进行调整
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
将在未来的计划中增加对资源瓶颈的预判，并为项目留出一定的缓冲时间
经验与教训：如果重来一次，我们将更加强调功能的优先级排序，避免功能膨胀，确保项目按期交付。
资源
1. 我们有足够的资源来完成各项任务么?
资源上，开发人力和基础设施能够满足需求，但对于测试阶段的投入可能还需加大。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
对时间和资源的估算略有偏差，尤其是涉及到数据库优化调优时。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
可能低估了测试对性能压力的需求。尤其是在高并发的消息传输和历史数据处理上，应该更早开始性能测试。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
团队内部通过日常会议等沟通工具进行变更通知，但外部的变更和需求变动可能没有及时评估影响。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
功能需求的调整主要基于实际情况做出决定，通过每日站会及时讨论并调整。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
项目完成的标准（如系统稳定性、响应速度、用户量）明确，但部分功能的复杂性可能未在初期阶段评估到位。
4. 对于可能的变更是否能制定应急计划?
采用了灵活的应急处理策略，如分阶段部署和灰度发布策略来应对可能的变更和风险。
5. 员工是否能够有效地处理意料之外的工作请求？
员工总是能有效的处理没有安排的工作请求
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目初期由资深架构师完成，但一些具体细节在后期的开发中仍需要优化。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
主要集中在消息的序列化和离线消息同步策略上。团队通过讨论和调研，最终确定了基于时间戳和seqId的顺序管理方案
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
团队在实现过程中采用了单元测试，并结合UML和系统设计文档进行需求分析。但UML文档在后期没有完全跟进更新
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
初期消息同步和用户状态管理方面产生了较多Bug。发布后，发现了一些高并发情况下的消息丢失问题。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审流程严格执行，团队遵循统一的代码规范，部分成员在实际开发过程中严格按规定进行单元测试。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
团队有测试计划，但可能对性能和压力测试的考虑不足，尤其是在群聊消息高并发场景下。 无
2. 是否进行了正式的验收测试？
团队有测试计划，但可能对性能和压力测试的考虑不足，尤其是在群聊消息高并发场景下。
3. 团队是否有测试工具来帮助测试？
无
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
无
5. 在发布的过程中发现了哪些意外问题？
发布过程中，部分高并发请求的响应时间较长，导致了短时间的系统瓶颈。可以通过增加负载均衡和微服务拆分进行调整。但由于技术原因来不及实现
我们学到了什么? 如果重来一遍, 我们会做什么改进?
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队成员的角色比较明确，每个人都会有自己擅长的任务，而且都是人尽其才
2. 团队成员之间有互相帮助么？
团队成员之间互帮互助，遇到技术问题时及时沟通解决
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队通过定期的沟通会议，及时解决项目管理中出现的问题
总结：
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- CMM/CMMI档次：目前团队的过程可能处于CMMI的2级，具备一定的规范和流程，但在部分领域（如需求管理和性能优化）仍有待改进。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 团队发展阶段：团队目前可能处于磨合阶段，虽然有一定的规范流程，但仍需进一步优化协作与沟通效率。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 最需改进的方面：团队目前最需要改进的可能是性能优化和测试阶段的资源投入，尤其是对于高并发和复杂场景的压力测试。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 敏捷开发原则：团队做得较好的是持续交付和快速反馈原则。例如，通过短周期迭代的方式及时响应用户反馈和需求调整。
软件质量的提升计划
1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
应该加强代码复审的规范，推动开发者进行自我审查和代码改进。
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
可以通过微服务架构的进一步优化和数据库查询的重构来提高系统性能。
3. 其它软件工具的应用，应该如何提高？
应用更多的自动化测试工具，并加强团队对于测试工具的熟练掌握。
4. 项目管理有哪些具体的提高？
需要在项目管理中加强对于风险的预测和应对，提前做出缓冲计划。
5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
可以在用户行为分析和日志监控方面进一步加强，了解用户需求和产品使用情况。
6. 项目文档的质量如何提高？
文档应更为全面和及时更新，尤其是设计文档和接口文档。
7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
领导和管理方面，需要提升团队成员的自主性和责任感，同时在绩效评估上更加明确和具体。
8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读
领导和管理方面，需要提升团队成员的自主性和责任感，同时在绩效评估上更加明确和具体。
团队讨论照片
| 姓名 | 角色 | 团队贡献分 |
| 王展锐 | PM | 20.8 |
| 李卓荣 | 开发 | 21 |
| 吴建民 | 测试 | 20.9 |
| 达仁·江布尔 | 测试 | 20.6 |
| 林诗琪 | 开发 | 20.8 |
