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

[21373074-朱宇]

项目	内容
这个作业属于哪个课程	2024年北航敏捷软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	具备成为一名合格软件工程师所需要的基本素质
这个作业在哪个具体方面帮助我实现目标	对本学期课程学习的总结回顾

对阅读与提问的解答

阅读与提问

问题一：结对编程的侧重点是效率还是创意？

在本学期的结对编程实践中，我似乎感受不到它给编程效率带来的提升，在工作上虽然互有分工，但双方对题目的理解不同，对题解的思路不同，还需要花去很多时间在讨论上才能达成共识，并找到更好的解决方法。双方各自独立完成编程任务所花费的时间反而并不是很多。因此，在本学期的结对编程作业中，我认为结对为作业带来最大的提升在于质量与“创意”，而非简单的工作效率。对于这个作业，有可能一个人独立完成花费的时间反而更少一些。

这也可能是结对编程任务工作量并不大（因为采取的方法较简单），且时间较短导致的。结对双方实际的差异往往比预估的更大，而矛盾统一的过程也是事物发展的过程，虽然沟通花费了一定时间，但从长远来看，其所提升的质量减少了问题的发生，这实际上也是一种效率。我想在实际编程中也不仅仅是侧重于效率和质量的其中一方，而是要找到一个平衡使得工作稳步推进，这才是最好的效果。

问题二：如何把握引导用户需求的程度？

这个问题似乎可以对应到课程中团队项目开题的过程，找产品的核心竞争点。我体会最深的一点是，我们课程的一个团队开发的“伴航”所提供的spoc作业汇总的功能确实能够在一定程度上回答这个问题。在学习生活中，我向来都是听老师布置才知道spoc上留了哪些作业，经过老师助教提醒才回想起已经布置的ddl，如此一不小心就会错过ddl。这个团队抓住了spoc平台没有汇总所有ddl的痛点，从而在他们的应用中实现了这个功能，我觉得还是挺实用的，很符合一个J人的使用习惯。

这算是挖掘需求的一个比较好的例子吧，从实际生活感觉不便的痛点出发，然后发掘出需求。这本质上又能涉及到软件是为谁服务的问题。一些应用从群众中来，到群众中去，自然是切实为群众的实际需求着想。一些应用为盈利而生，因此在必要的服务型之外，必然也存在着影响被服务者体验盈利性质，这也无可避免。（例如伴航这个应用如果只给付费vip用户提供ddl汇总的功能，就有部分盈利性质了）我们当然希望每个人都能享受到更好的软件服务，然而世界上的资源终究是有限的，需要通过一定秩序进行分配。

问题三：在未来，人工智能能够帮助我们完成spec之后的开发任务吗？

本学期的团队项目，我参与了一款游戏的制作。伟大的项目 PM 对《明日方舟》这款游戏怀有极高的热情，在项目之初就为我们擘画了以明日方舟和肉鸽玩法为方针的宏伟开发蓝图。但在开发过程中，将塔防和肉鸽这两个元素组合起来也并不是件容易的事，在玩法设计上许多地方是需要创新的。

是的，创新。功能说明书书写的时候，作为三维生物的人类不可能事无巨细地将未来一些游戏的玩法细节面面俱到地构思完毕，有一些玩法上的细节其实是边开发边构想的。人工智能作为虚拟的存在，无论噢诶背了多少传感器，它也只能接收有限的输入，并无无限的现实的体验。一定范围内的未来里，人工智能也不可能完全模拟人类玩游戏的过程，得到人类游戏中的体验然后对游戏进行优化。一款游戏给玩家的体验体现在许许多多的细节上，并不是框架性的功能说明书能够做到的，死板机械的游戏会令人感到索然无味。因此游戏需要玩法上吸引人，并在细节上不断地创新，才能让玩家不感到厌倦。

人工智能的感受是有限的，因此它只能打造出一种过时的工具，而不能创造出与时俱进的作品，或者说艺术。（至于未来的人工智能会发展成什么样，这是无法预测的事情）

问题四：工科研究生所做的到底是什么？

可能就本学期的课程而言，它并没有涉及到这部分内容。如果勉强回答的话，研究生们会接受导师学术上的指导，进行一些科技创新；他们也会参与一些实验室负责的项目，在项目实践中应用自己所学，锻炼自己的能力。创造价值和自我提升并行，也就是“知识->金钱->知识”的循环吧。这个问题提的怪怪的，忘记当时怎么想的了。

问题五：重大决定由 “猪” 来定夺，真的就合理吗？

仅从课程中团队项目的收获来讲，我能感受到的是，在时间比较紧张的情况下，开发者和PM在功能实现的取舍上有时产生冲突，而这些决定完全由开发者定夺可能不全是合理的，因为一些功能若被舍弃，可能会影响 PM 对未来项目开发的设想，从而影响整个项目的面貌，开发者可能无法想得太长远。而现实中，有时也会出现因为某个人的坚持从而造就了团队的胜利这样的情况。

就这个问题而言，我认为，在项目完成之前，无论是“猪”“鹦鹉”还是其他成员，团队各成员之间最重要的还是信任吧。开发者要相信PM或其他领导们的坚持自有他们无法妥协的道理，PM也需要相信开发者对工作进展的预估。双方互相理解，从而达成共识，作为团队整体对重大决定进行定夺，这才是理想的处理方式。

然而现实中的团队有许许多多复杂的利益关系掺杂，不可能仅仅像课程项目的团队一样纯粹。因此，重大决定由 “猪” 来定夺这个结论，可能也是面对现实情况时的一种无奈。

在项目的 需求/设计/实现/测试/发布/维护阶段（一共 6 个阶段）中都学到了什么“知识点”

• 需求：需要通过调研以及组内的讨论确定项目相对于竞品的核心优势，精准抓住用户需求。
• 设计：产品设计需要不偏离之前的需求分析，并且对于产品的设计可能也会在开发实现时同步进行。
• 实现：开发中需要把控项目质量和效率的平衡，及时通过小组会议等方式把控进度，统一思想。良好有效的沟通是团队合作的关键。
• 测试：不能忽视测试环节，集成测试中暴露出来的问题可能很多。
• 发布：不仅需要确保发布产品的完整性和稳定性，还需要考虑如何让用户更快地了解所发布的产品。
• 维护：维护的动力一方面源于开发者的意愿和热情，另一方面也源于用户群体的支持。

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得

千言万语道不尽心中所感，千思万想也只能说出几句感谢。

感谢互联网时代。感谢理想主义的开源文化，让我对计算机这条道路仍然怀有希望。

感谢结对编程的队友。共同完成作业，不间断奋战 9 个小时到深夜的经历充实而富有收获，这是极致的投入，也是内心的富足。尽管结对编程狠狠蚕食了清明假期，但这比在空虚中迷茫的时间甜蜜得多。

感谢团队项目的伙伴。感谢 PM 发现了眼神凶恶，朋友也很少，但其实心地很善良的我，在我做好躺进分配的心理准备时，将我拉进了一个优秀的团体，我这才得以有机会和许多学院内闻名遐迩、大名鼎鼎的大牛们合作，完成了一个其实差强人意的游戏，在开发的过程中我也学到了很多很多。能有这样的机会实现自己的价值，完成项目期间的汗水完全不算什么，这是本科期间难忘的幸运。尽管今后我们也就分道扬镳，但这一段充实的经历永远会铭刻在我的心中。或许将来有一天，我会和身边的朋友分享新闻里看到的某位计算机行业领军人物，然后骄傲地跟他们说：“哈哈，我曾经和ta上过同一节软工课，并且一起开发过一款名叫 Collapser 的游戏。Collapsar 是一款极具创意的 Rougelike 塔防游戏，...”我会一直期待这一天的到来。我们一起加油！也祝福每一位同学都能前程似锦，奔赴美好的未来！