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

个人作业：结课总结

项目	内容
这个作业属于哪个课程	首页 - 2025年春季软件工程（罗杰、任健） - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件开发流程，完成一次完整的软件开发经历，提高开发和团队合作能力
这个作业在哪个具体方面帮助我实现目标	回顾课程内容，总结收获

链接博客

[I.1] 个人作业：阅读和提问

---

提问解答

问题1

两人在同一台电脑前同时工作就意味着两人必须同时理解当前电脑屏幕上的代码，也就是说，当其中一人不了解有关技术栈时，结对编程就有可能退化成单人编程甚至更劣。按着这样理解，用结对编程理想的实现一个项目就需要两人都参与到全栈开发中。而参与课程的我们在组队时往往考虑的是在技术栈上有所互补的对象。这样，组队的结果，可能就无法真正实践结对编程所描绘的工作过程。或者说，也许结对编程还有其它的实践方法？

经过课程的结对编程项目，我发现在实际结对编程过程中，其核心价值不仅要靠两人技术栈的动态互补、角色分工来解决技术差异问题，还要确保实时的代码审查和想法的碰撞：这才是结对编程的核心。贪吃蛇项目中，一人编写蛇移动的测试用例，另一人实现代码并通过测试，再互换角色，这样类似“乒乓球”的过程，更好地保证了代码的质量，也确保双方逐步掌握项目的全部逻辑。

问题2

在ai可以参与帮助编写代码的现在，当我们所苦恼的低层次问题可由ai和智能插件辅助编写解决时，技能的提高是否就只是用“时间和脑力来解决较高层次的问题”呢？如果不是的话，不断“刷”低层次的问题是为了什么呢？若是为了能够更好提高对工具的熟练度的话，那编写高层次问题的代码不也可以起到作用吗？

本次的结对编程和团队项目中，个人用到了AI作为自动补全的工具，也尝试通过AI提供设计上的灵感。我认为：AI不是能力的天花板，而是地板。它解放了我们的双手，但唯有通过低层实践的淬炼，才能让大脑拥有指挥AI的“资本”——否则，再高层的设计也可能是空中楼阁。就像在自动贪吃蛇项目中，没有反复调试移动逻辑的经验，我们根本不敢挑战AI决策算法。这种阶梯式的能力沉淀，才是应对技术浪潮的锚点。

问题3

"如果你的团队很弱, 那么强行把Scrum （或者其它高级方法）套在上面也没有用, 也许还会适得其反，往往需要多次Sprint 才能让Scrum 走上正轨。换句话说, 如果你的团队已经是这么厉害 （self-managing, self-organizing, cross-functional）的一帮人, 那么用不用Scrum 都能写好软件! "

诚如作者所言，拥有“self-managing, self-organizing, cross-functional”的团队，也许不需要什么指定的方法论就能有效率的完成任务指标.那么问题来了，对于作者所言“很弱”的团队（大学生临时组的队伍可能就会属于这种），他们又该如何实践scrum呢？

在本次的团队编程中，我们的团队作为大学生临时团队就需要通过实际情况采用团队框架，弥补团队经验不足，并在实践中逐步培养能力。我们的团队全员参与决策，在Sprint计划会议中，要求所有成员共同拆解任务、评估工时。同时我们的角色存在兼任，全员参与开发，我们团队无资深产品经验者，所有由组织能力较强的成员担任PM，但需明确PM的核心职责是协调会议、清除障碍而非全权管理。

问题4

那么谁来当领导呢？来自教师或是成绩的赋权或许很有信服力，但是忽视了领导者自身的意愿（领导者自身不想当领导者）或能力（领导者有技术，但自身没有领导能力）。来自团队中非正式的、在交流中默认选出的领导者，ta可能是一个技术大牛（ta如何兼顾项目开发与维持团队稳定、开展决策等领导者工作），可能是一个社交达人（ta能展现技术上的威信吗），可能是一个能激发人情绪的演讲家（ta会变成说自己是“鸡”的“鹦鹉”吗）。另一方面，团队出现多个领导者的竞争者，又该如何选取以维护团队稳定性呢？

萌芽期领导者的选择应当优先选择高意愿+中高能力者（即使技术或社交能力单项不突出），避免强推低意愿的“被动领导者”，而出现两名及以上领导者时，就有可能出现团队的分裂。所幸我们团队有社交达人主动申请当领导者PM，且我们团队无异议地认同了。

问题5

对于学生团队而言，在需求分析和项目建议时套用NABCD是一个很好的选择，但是得出的讨论结果往往并不能很快或无法转化成一个实际的成品。学生团队在此阶段往往是接触熟悉软件工程的开发流程，掌握基本方法，难有“独特的招数”，更难以讨论竞争。类似于问题3，我们究竟该如何实践NABCD呢？

实际上，软件工程课程应该希望我们团队去尝试用NABCD思考选题，对有关竞品做出分析，对于实际成品的实现，我们需要做出所需资源（比如时间等）上的取舍。对于我们项目的需求分析上，我们更多地考虑了现有产品没有的玩法，以及更主要的，实现的成本。

---

实践总结

项目各阶段中学到的知识点

需求

一方面，分析了各个竞品的主要特征，另一方面从用户视角出发，用思考用户想要实现什么。

设计

设计方面，首先考虑的就是各个模块的实现可行性，对于unity的团队项目，在开发时间上可能会有点紧张，因此反复商讨了各个模块的取舍。其次，对于内容的策划做了一定的功课，花了意料外的时间。

实现

学习了大量的unity项目实际开发的经验，包括如何利用MVC架构在unity中实现从数据库模型控制到游戏中的UI显示，对于美术素材的利用和UI的设计，以及更多的是对于不同组件的了解和使用（这一过程中也花了一定时间阅读了有关手册）。

测试

代码提交时应首先进行一定测试，在每一次完成开发并进行交付对接后，额外进行测试检测各个模块之间的影响。

发布

发布前在不同场所提供宣传，我们团队还建立了一个网页进行宣传，发布后充分收集用户反馈，即时记录问题。

维护

发布后参与对bug的修复和版本的更新。

心得

这次软件工程课程，是我首次投身于一个真实unity软件项目全生命周期和首次参与一次结对编程项目。团队的unity软件项目覆盖需求分析、设计实现、编码测试、发布维护每一个环节，挑战与收获并存。曾以为开发不过是功能实现，如今方知团队协作与流程管理才是核心。结对编程、敏捷开发这些方法论，其价值唯有实战方能显现。最令人振奋的时刻，莫过于看着自己实现的模块功能成功落地，游戏内的背包系统、经济系统、物品制作和科技树系统，每个模块的完成都给予我巨大的成就感。