[I.3] 个人作业：结课总结

[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2026春软件工程
这个作业的要求在哪里	个人第三次作业
我在这个课程的目标是	从理论到实践深刻体会软件工程的原理和方法，同时提升自己在团队合作中的能力
这个作业在哪个具体方面帮助我实现目标	反思与回顾该学期进行的结对与团队项目，总结自我，积累经验

一、提问回顾

来源：个人第一次作业

一、AI时代下技能的重要性是否发生偏移？

  正如我在第一次提问中提到的观点，我认为技能的重要性正在发生偏移。在真正的开发过程中，我们更侧重于通过文档对软件架构进行总体上层设计，而非纠结于具体的技术细节——这种做法反而能让整个开发流程更加清晰。落实到每周的工作节奏中，我们可以借助AI完成代码的主体生成，再由人工进行审查和打磨。这种方式大幅减少了人工重复劳动的时间成本，显著提升了开发效率。
  因此，在当前软件开发或任何项目工程启动之前，我们可以转变过去从底层语言逐步学起的路径，改为优先学习高层的架构设计，再通过AI将设计意图落地为可运行的代码，从而快速实现功能开发和需求交付。AI所带来的，不只是技能重心的迁移，更是对整个项目开发流程与方法论的重新塑造。

二、敏捷开发以及MSF框架模型在学生团队中如何实施？

  对于学生团队，我认为应当将敏捷开发和MSF框架进行结合，取各自的优点。
  首先如果纯粹采取敏捷开发过程，则项目并没有明确的项目管理人员，没有清晰的责任边界，如果发生课程考试等时间，开发节奏很容易被打乱，容易陷入一直在冲刺但是无法收尾的情况。
  如果采取纯粹的MSF框架，将人员划分为所述六个角色组，项目分为五个大阶段，则会面对两个现实的问题：责任过于细分，沟通成本增加；时间间隙缩短，项目开发压力更大。
  在真正进行开发过程中，我们组对角色进行了简单区分：项目管理、开发与测试，并且在两个阶段之间坚持固定时间开组会，向PM汇报工作，由会议共同商讨下一步迭代开发内容。我们在角色精简的基础上，将MSF的阶段规划与敏捷的迭代节奏结合起来，形成了适合学生团队的开发模式。

三、需求分析到典型用户设计的跨度问题

  我们应该将用户画像与敏捷开发中的回顾过程绑定，每次冲刺结束做回顾时，除了总结开发问题，也顺便讨论一下近期收集到的用户反馈，看看现有用户画像有没有需要调整的地方。如果发现哪里对不上，就及时更新画像，然后根据更新后的画像来调整下一轮的功能设计。
  这样一来，用户画像就不再是需求阶段写完就丢一边的文档，而是会随着项目推进不断更新的动态工具。每个冲刺既是在推进代码，也是在加深对用户的理解，两者同步进行、互相修正。即使一开始需求分析做得不够到位，也能通过后续的迭代慢慢纠正，不至于让初始的偏差一路错到底。

四、在需要长期运营的项目中稳定阶段的标准是否需要改变？

  需要改变，对于一次性开发产品，可以以解决bug为标准，实现功能需求为主要标准，但是长期项目逐个阶段在进行更新，不可能在每个阶段都进行所有bug修复。因此稳定阶段应该保证核心关键功能正确，避免系统功能级别的bug。与第三问的思路一样，可以分阶段收集反馈，遇到问题可以即使修复与迭代。我们不寻求百分百正确，但是务必保证项目稳定可用。

五、应该做猪、鸡、鹦鹉哪一个？

  从风险来看，猪风险最大，倾尽所有，以此项目为核心，必须为该项目负责；鹦鹉最小，若项目失败，仍可以投身于其他项目。然而，收益与风险并存，一旦成功，猪就成为核心技术人员。因此在真正发挥主观能动性下，我们需要合理评估自身能力与风险收益，选择适合自己的角色，并为之努力，一旦成为了猪，便努力精进技术，时刻为项目负责；若成了鹦鹉，则尽全力提升自己项目管理或者技术交流的能力，可以灵活的在不同项目之间给予贡献。不同角色是不同方向，真正选择完全取决于个人，但是只要努力，一定有收获。

二、未解决问题

  对于问题三中的跨度问题，我们团队在alpha阶段和beta阶段进行了用户画像的补充与修改，但是貌似在这两个阶段之间，对于学生团队获取的用户反馈较为稀少，用户画像更新幅度较低，那么其实对于这个跨度问题，并没有得到一个很好的解决。

三、新的问题

1、项目难度的评估问题

  在项目之初，我们在评估项目难度出现一些偏差，导致项目分工与进程之间出现了一点点小瑕疵。因此，如何在项目一开始就可以合理评估项目难度与工程量大小，亦或者在每个阶段重新评估重新分配工作，又如何分配？

2、任务分工问题

  我们团队在两个阶段进行了小的人员分工调整，这在学生团队中比较容易实现，但是在真正的大型团队开发工程中，具体的项目小组肯定是无法进行大的人员调动，那么对于两个进度难以匹配的工作小组，任务分配又应该如何平衡呢？

各阶段知识点

1、需求阶段

  该阶段教会我如何从需求分析到构建用户画像，再从用户画像逐步提取出功能需要。同时需求分析不是一蹴而就，而是需要持续收集反馈而不断更新。

2、设计阶段

  首先就是前后端的接口协调需要提前设计好，这样两端开发人员可以尽情发挥自己的实力，同时避免了后续需要重新对接接口的这种困难的工作。

3、实现阶段

  实现过程需要进行一个好的设计，保证项目的可迭代行，例如在结对编程中三个阶段，在第一阶段对玩家和卡牌进行结构体设计，后续阶段则可以很好的复用。

4、测试阶段

  实现了单元测试、端到端测试、压力测试、websocket模拟测试、覆盖率测试，并且将这些测试写入CI中，防止回归问题，同时每次合并PR时可以通过CI观察每次测试的报告。

5、发布阶段

  通过CI/CD实现自动化部署，代码合并到主分支后自动触发构建、测试并部署到服务器，每次合并都能快速生成可访问的线上版本。

6、维护阶段

  在完成功能的时候，需要添加信息反馈与日志系统来记录一下操作过程，同时有助于帮助错误发现，否则界面无法进一步操作，也无法帮助分析错误原因。

心得体会

个人项目

  在Lab1的时候重点观摩了需求文档、功能文档的内容，让我意识到一个好的文档不仅可以帮助快速构建一个软件的画像，同时其中对于边界功能的描写提醒了我们，让我们在后续编写文档的时候更加关注这部分。
  另一个印象更深刻的是Lab4的测试内容，既详细教学了手测中的测试报告书写过程，同时自己完整编写了测试代码，实现了自动化脚本测试，为CI上自动测试打好基础。
  Lab2关注从需求分析到架构设计过程，Lab3则是关注实现过程，同时引入了AI协助编程，四个实验从需求、设计、实现、测试这四个阶段向我们展现了一个完整软件的开发过程，提供了宝贵的经验。

结对编程

  我们在结对编程中花费时间较长，共约了四五次才真正进行完工。只能说虽然劳累，但是收获颇丰。
  在编程阶段，我们针对整体框架设计以及具体方法实现的激烈讨论，最终得出一个二人都满意的设计与实现。在讨论过程中，我们或多或少发现自己的设计的纰漏，学习对方的思想上的优点。
  同时阶段编程，一个人负责编写代码，另一个人可以即时纠错，可以避免由于误操作导致的细小bug；同时另一个人负责文档记录，可以很好地记录我们编程过程，使我们不断反思，在实践中真正进步。

团队项目

  首先在团队项目管理中收获丰富，学习到开发分支命名规范、issue提出的重要性、PR解决冲突的有效性以及CI/CD对于自动化测试与部署的价值。
  深刻体会到一个软件开发的全流程，从需求分析到任务分配，例会讨论与汇报，项目验收与测试以及最终的汇报展示。虽然这中间可能出现进度问题、功能实现问题，但是好在最后团队一起客服，呈现了一个完整的软件产品。
  对于我跟人，收获的不仅仅是测试方面的经验，更多的是团队合作的经验，我逐渐学会如何在团队协作过程中及时跟进项目推进，进行团队交流。
  总而言之，过程不易，但收获满满。