事后诸葛亮分析

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的项目OJ判题服务平台的主要解决学习编程需要题目连写的问题，并提供自动化的判题服务。定义得很清楚。系统主要用户包括编程学生及管理员。典型场景包括学生提交代码，系统自动判定，显示测试结果；管理员可以设定编程题目，查看学生提交情况；管理员可以管理用户、题目及系统配置。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

功能实现：我们按计划完成了各种基本功能；但一些附加功能（如管理用户信息）未完全实现。
交付时间与用户数量：项目按时交付，初期用户数量较低，随着系统稳定性提升，用户量会逐渐增加。

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

质量提高：从上一阶段来看，团队对代码质量、测试覆盖率以及模块化设计有了明显提升。我们增加了单元测试，减少了手动测试的依赖，功能模块也做了更严格的界定。
衡量：通过引入代码审查工具，减少了bug的数量；代码提交频率和协作度也有提升。

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量与反馈一致性：用户量逐步增长，符合预期，重要功能（如判题准确性、题目提交信息显示等）得到了用户的认可。部分用户反馈系统存在bug，需优化。
目标距离：离我们的目标越来越近

5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

经验教训：在功能开发上，我们按时交付了大部分核心功能，但由于初期的规划不足，导致了一些功能的延误。
改进：下次我们会加强初期需求分析与功能优先级排序，避免低优先级任务影响整体进度

计划

1. 是否有充足的时间来做计划?

我们有很充足的时间来做我们的计划

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

在计划阶段，团队成员就项目的技术栈选择、功能优先级等问题展开了充分讨论。通过会议达成共识，并根据开发周期调整了一些功能的实现顺序

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

大部分计划中的工作都按时完成，但某些附加功能未完全实现，原因是我们低估了实际开发中遇到的技术挑战

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

没有，所有事情都是有价值的

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

每一项任务都有清晰的交付件定义，如功能实现、代码提交、单元测试等

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

整个项目的制作并不是完全顺利的。在开发过程中，数据库性能瓶颈、并发问题等未在计划阶段充分预见，导致部分模块无法按计划进行

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

项目中并未设置专门的缓冲区，导致一些意外情况发生时缺少足够的时间进行调整

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

将在未来的计划中增加对资源瓶颈的预判，并为项目留出一定的缓冲时间
经验与教训：如果重来一次，我们将更加强调功能的优先级排序，避免功能膨胀，确保项目按期交付。

资源

1. 我们有足够的资源来完成各项任务么?

我们小组人数多，有足够的资源

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

初步估计较为精确，但在功能复杂性较高的部分，如判题系统优化、并发处理等任务上，低估了所需资源

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试资源充足，尤其是人工测试上。美工设计资源有所短缺，导致部分页面的设计相对简陋

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

我们发现，某些技术任务，如数据库优化和负载均衡，原本可以由更有经验的成员来处理，以提高效率

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

如果重来一次，我们会将测试和设计阶段的资源提前规划，特别是美工和测试工具的配置

变更管理

1. 每个相关的员工都及时知道了变更的消息?

变更管理过程中，变更信息传达及时，所有团队成员都能迅速响应并进行调整

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

在项目过程中，团队采用优先级排序和紧急程度的评估来判断功能是否推迟或必须实现

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

项目的“完成”标准较为清晰，主要包括基本功能的实现、性能优化和用户反馈的积极响应

4. 对于可能的变更是否能制定应急计划?

在变更处理方面，团队准备了应急计划，但由于时间较紧，有些应急响应仍显得不足。

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

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

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

如果重来一次，我们会更早考虑潜在的变更风险，并在项目初期就制定更详尽的应急计划。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作由经验丰富的成员完成，且按阶段推进。但部分复杂模块的设计时未能预见到后期实现中的难点，导致部分设计需要重新调整

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

团队通过讨论的方式解决设计中的不明确问题，部分设计需求也通过文档形式达成一致。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

在设计阶段，团队使用了UML工具来帮助设计，但并未完全遵循TDD等方法，后期的Bug发现也反映了测试覆盖的不足

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

功能产生的Bug主要集中在并发处理和判题模块，设计时未能预见到高并发情况下的性能瓶颈

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码审查的严格性逐步加强，但部分成员在代码提交时未严格遵守规范，导致一些格式问题未及时被发现。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

如果历史重来，我们会加强前期设计和详细测试，更好地预见系统瓶颈。

测试/发布

1. 团队是否有一个测试计划？为什么没有？

项目初期缺乏正式的测试计划，部分功能的测试被拖延，导致Bug频发

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

项目发布前进行过验收测试，但测试工具和自动化测试的使用还不够成熟

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

团队有测试工具来帮助测试

4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

初期未做充分的压力测试，导致部分用户高并发访问时系统响应较慢

5. 在发布的过程中发现了哪些意外问题？

尚未发布。

我们学到了什么? 如果重来一遍, 我们会做什么改进?

学到如何进行测试。如果重来一次，我们将提前规划并执行充分的自动化测试和性能测试

团队的角色，管理，合作

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

团队成员的角色比较明确，每个成员根据自己的特长分配任务，且基本人尽其才

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

团队成员之间互帮互助，遇到技术问题时及时沟通解决

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

团队通过定期的沟通会议，及时解决项目管理中出现的问题

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

根据我们目前的项目进展和团队的工作方式，团队大致处于 CMMI Level 2 (管理和定义过程的初步阶段)。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

团队目前大致处于 磨合阶段。我们已经完成了项目的初步需求和设计，团队成员之间逐渐适应了各自的角色和职责，但在沟通效率、资源调配和协作细节方面仍有提升空间。团队的工作方式还没有完全稳定，仍处于调整和改进中

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

相较于前一个里程碑，团队的 沟通效率 和 任务分配 有了显著改进。我们通过定期的会议和任务拆解，使得每个成员的工作更清晰，也减少了重复工作和信息误解。此外，代码管理和测试流程也有所加强，增加了自动化测试覆盖率和代码复审的频次，提升了代码质量。

你觉得目前最需要改进的一个方面是什么?

目前最需要改进的方面是 团队成员之间的协作效率，特别是在需求变更、功能扩展和技术难题的解决上。在一些复杂的功能开发中，部分成员的协作较为分散，缺乏足够的前期讨论和信息共享。需要进一步加强团队的跨部门沟通和知识共享

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

以人为本：团队成员之间相互支持和帮助，成员之间的合作日益紧密。在任务分配和协作中，大家都能积极主动地交流想法，及时分享遇到的问题和解决方案。
交付可用的软件：我们每个版本发布时都保持了较高的代码质量，确保了可交付的软件的稳定性。每次发布后，我们都会进行验收测试，并根据反馈快速修复问题，确保最终用户能够得到高质量的软件。

软件质量的提升计划

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

强化代码复审：要求每一段代码都必须经过至少一位团队成员的复审，确保代码符合规范且易于维护。
优化代码规范：通过统一代码风格和规范，减少代码中的潜在问题。将代码规范文档化，并定期进行培训和检查。

2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

进行架构重构：根据现有的系统瓶颈，评估架构的可扩展性、性能和可维护性，进行必要的重构，例如引入微服务架构，或者改善数据库结构和缓存机制。
通过单元测试和集成测试 衡量架构的质量，确保每个组件能够高效稳定地运行。

3. 其它软件工具的应用，应该如何提高？

我们计划引入更多的自动化工具

4. 项目管理有哪些具体的提高？

进一步优化 任务拆解和进度管理，确保每个任务的目标、进度和责任清晰，避免资源浪费。
强化风险管理，定期评估项目的风险，并及时调整计划，确保项目按时交付。

5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

我们计划引入 用户行为分析工具，如 Google Analytics 或 Mixpanel，来跟踪用户的活跃度和行为数据，以便实时调整产品功能和优化用户体验

6. 项目文档的质量如何提高？

强化文档的结构化，确保每个文档都包含必要的内容，如需求分析、设计文档、API 文档等。
增加文档的可读性，采用标准化的写作方式，确保文档清晰易懂

7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

进一步加强团队成员的激励机制，鼓励创新和积极性；
采用更加透明的沟通方式，确保每个成员都清楚项目的进展和自身的职责

8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

通过本项目，我深刻体会到敏捷开发的迭代与反馈机制对于项目成功的重要性。尤其是在需求频繁变动的环境下，持续的反馈和灵活的调整能够确保最终交付的产品满足用户需求。同时，我们也意识到 技术债务的积累是一个潜在的威胁，需要定期重构和优化代码，以保持系统的健康

团队讨论照片

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

名字	角色	团队贡献分	可验证的贡献
陈国金	项目经理、后端	20.8	管理项目、后端开发
凌枫	前端、文档编写	20.7	编写博客、前端开发
陈卓恒	前端	20	前端开发
谭立业	前端	19.9	前端开发
廖俊龙	测试	19.8	测试
曾平凡	测试	19.7	测试
曾俊涛	后端	19.6	后端开发
薛秋昊	后端	19.5	后端开发