软件工程实践总结——及之而后知，履之而后艰

222200105叶沈煜 2024-12-18 14:23:26

这个作业属于哪个课程	FZU_SE_teacherW_4
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	个人收获与总结
其他参考文献	《构建之法》

第一部分课程回顾与总结
以前问题思考的博客链接
问题回顾&再解答
新的问题
实践中的成长
需求阶段
设计阶段
实现阶段
测试阶段
发布阶段
理解与心得
个人项目
结对编程
团队项目
自我评价
目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。
目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。
目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。
目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。
目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。
目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。
目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。
第二部分：个人技术总结
第三部分：软件开发模式
项目开发过程：
参与的项目
项目目标
主要技术栈
关键决策
遇到的挑战
解决方案
软件开发模式的思考：
Scrum 对项目的影响
开发模式对比
不同场景的模式建议
我的理解和建议

第一部分课程回顾与总结

以前问题思考的博客链接

思考博客链接

问题回顾&再解答

花费时间越多，代表工作量越高吗？

在经历本学期的团队项目实战过后，再回看这个问题，我心目中的答案和之前相差无几。但是，我对于此前自己的回答，有了更加直观的感受。在项目的开发过程中，我们团队的成员大都经历了从技术生疏到熟练掌握的过程。在一开始想要实现一个简单的功能都会遇到各种各样的问题，其中很多都是对于开发软件和技术本身使用不够熟练导致的。而当项目进行到后期，各成员对自己负责的模块已经得心应手，每日燃尽图也能看出，工作效率的显著提升。除此之外，每个成员的技术水平不同，即便花费的时间相同，工作量也会有不小的差距。因此，简单考虑花费时间无法说明工作量的高低，技术水平的高低等因素也应纳入考量范围。
工作时是否应该带着个人、情感驱动的因素？

在这两次冲刺中，我也感受到这一因素对工作的影响并不小。由于我们项目是游戏开发，很多工作尽管被划分到不同的模块，但还是免不了会有一些重叠的文件。这些文件的合并涉及到很多冲突的解决。处理不好可能覆盖来覆盖去，甚至可能导致文件损坏，自己的工作都白费。在这种时候一些成员就容易把自己的情感带入到项目开发中，阴阳别人，造成团队的不和谐。因此，从个人角度出发，避免情绪对工作和团队的负面影响是很有必要的。
有了GPT类的应用，传统的搜索引擎是否会被完全替代？

现在看来GPT类的应用依旧不能完全替代传统的搜索引擎。这学期中，很多任务所涉及到的知识都是之前从未了解或不太熟悉的，如vue，spring boot以及网站的搭建、unity插件使用等等。尽管gpt可以给我提供大量的帮助，让我在做中快速学到了很多知识。但在很多时候，GPT提供的做法并不能解决问题，这时候，到搜索引擎上搜索前人总结的方法经验贴反而更为有效：如当我使用了一个unity插件，这个插件在我不知情的情况下将我的TimeScale设置成0，导致我的项目无法实现我想要的效果时，GPT并不会直接意识到这一点，因而没有办法给我正确的回复。
诸如此类的问题，往往触及到gpt能力的边界。这时候，尝试使用传统的搜索引擎，或许才能更好的找到解决问题的方案。
当然，GPT在大多数时候还是能够很好的回答我们的问题，并且不需要我们主动到网页上无搜索，可以很大程度上节省我们的时间。
所以我觉得可以优先考虑使用GPT，在GPT不能很好的解决我们的问题时，再试着去网页上搜索。
AI辅助编程，是一个银弹么？

利用AI来辅助编程给我的感觉就是，把GPT类应用当成了一种比高级程序语言编译器更加高级的编译器来使用。用自然语言向AI描述程序的执行过程，让AI将自然语言转化成高级语言，这一步就如同编译器将高级语言转成汇编语言一样。在高级语言还没有出现时，人们直接使用汇编语言进行编程，开发效率远远比不上现在使用的高级语言。而如果能直接使用自然语言进行编程，相信效率也会更进一步提高。不过现如今的AI还没有办法达到这样的能力，仅仅能够提供一些比较模板化的程序。因此我认为当下的AI还不足以成为一个银弹。不过，如果能更进一步的发展，或许有朝一日能够真正做到这一点。
低层次的问题能依赖工具解决么?

从历史的角度来看，文明的演进都伴随着工具的优化和升级。工具的存在，让生产效率得到提升，人们就可以将注意力放在更高层次的问题上。可以说，科技的进步很多时候都是朝着便利人们的方向的。因此，对于一些低层次的问题，如常用的算法或者功能，借助GPT或者现成的插件来实现可以很大程度上避免我们把精力花在造轮子上。这对于实际的开发应该大有帮助。不过过分依赖一项工具，让自己丧失自主思考的能力反而是不利的，因此，学会怎么妥善使用工具解决低层次问题也值得我们注意。

新的问题

在绩效考核中，究竟如何更为准确的描述每个人的工作量？在我们的绩效考核中，我们尝试从多个角度，如代码量，工作难度，参与度等角度，进行定量分析，给每个维度进行打分，最终得出结果。尽管这样的方式看似比较客观，但是，实际上每个维度的打分还是以主观的方式进行衡量。况且这样的考核方式可能没有办法很好的衡量团队成员对于项目的态度和负责程度。有些成员对于功能的实现可能止步于能用就行，而有些成员则会不断地打磨，追求功能地完整和合理性。尽管这些可以体现在最终的完成质量上，但完成质量的好坏评判是否精准又与测试工作相挂钩。如果测试不够完全，可能会有不公平的结果出现。因此，一个成员的最终得分与另一个成员工作进行的细不细致相关联，这是否也不合理？
以及如何权衡开发效率与开发质量来分配任务这一问题。在团队中每个人的技术水平不同，开发的效率也有所差异。对于技术相对较薄弱的成员，可能只是浅浅的学习技术就想开始开发，这导致完成的质量不理想。这种时候往往会陷入两难的境地。究竟是为了追求质量，而让技术较好者揽下更多的工作，承担更多压力，还是为了追求效率，让任务分配更加平均一些，但伴随着的是项目质量的下降。这样的问题又该如何解决？

实践中的成长

在本学期的项目开发中，我担任的是PM和开发人员的职位，对于项目的参与程度较高，因此，也获得了不少收获。

需求阶段

在需求分析阶段，由于我们想要开发的项目在此前并没有类似的项目。所以我们进行了细致了思考和可行性分析、风险分析。对一些已经成功的算法教育类游戏和模拟经营类游戏进行了反复的分析和总结，考虑如何将二者进行融合，并对游戏性和教育性二者进行权衡之后，最终确定我们的项目的实现方式、玩法、以及模块的划分。
这一阶段是我们项目的起始阶段，因为还没有一个确切的项目，每个人对于这个项目的想象都不太相同，为了统一大家的想法，我们进行了原型设计和玩法的初步设计。在这之中，我也意识到，需求分析不单单只是浅浅的知道用户需要什么，以及我们该做什么，更需要深入的剖析，尝试设计原型。比方说，我们在最初考虑，应当以什么样的方式呈现排序算法时，我们设想了很多方案，但是有些方案实现的难度较大，有些方案的可玩性较差等等，这些都是在实际进行设计之前，无法准确预料的。因此，我觉得，在需求分析阶段，我收获到的最大的能力，应该是进行需求的表述和利用原型设计来评估方案的能力。

设计阶段

在设计阶段，我主要负责体系结构设计和接口设计。这两个部分的设计会对之后的开发有较大的影响，决定着这个项目的好坏。不过由于我们项目和web项目不同，不能简单的套用web项目的体系结构，同时，接口设计部分，因为是单机游戏，也没有web类项目的网络接口，所以，我们在设计时，也遇到了不少的阻碍。我们在这部分也花费不少的功夫，好在最后设计出一个比较合理的方案，极大提高后面开发的效率。
由于以前做项目都是直接从开发阶段开始，从来没有在开发前认真设计过，而这次的经历也让我意识到，磨刀不误砍柴工，设计一个好的体系结构和接口，尽可能做到高内聚低耦合，并提高程序的复用性对于项目的开发有着极大的帮助。

实现阶段

项目实现是我们整个开发流程中时间和精力花费占比最多的一个阶段。同时，这一阶段也是小组成员之间联系最为紧密的一个阶段，尽管我们已经尽量的将项目按照每个独立功能，划分成多个模块进行开发，但是，由于我们项目是游戏开发。这些独立的功能虽然互不干扰，但是会存在处于同一个游戏场景中的情况。这种时候两个模块就会有版本冲突，由于游戏场景的文件是由unity自动生成的，内部的逻辑我们并不了解，有时候解决冲突的方式不妥当就会导致整个场景的损坏。这往往会导致两个模块中的工作成果只能保留其一，另一个再重新制作。再这个地方，我们被迫浪费了很多的时间。期间尝试划分出新的分支来解决问题，但是着只是将问题延缓，到最后合并时同样需要解决这个问题。不过，之后我们试着将场景生成一个副本，将两个功能的开发工作彻底的分离，在每日工作结束之后，再将一个场景中的新增加内容转移到另一个场景中，这样我们就解决了这一问题。
在这一阶段，我们遇到的最大的问题就是版本控制。由于之前并没有参与多人项目的经验，因此，版本控制的使用还有些生疏，并且有些时候常规的处理方式在特殊的情景下（如unity的场景）并不奏效，这种时候就需要自己寻找解决办法。
因此，这一阶段中我最大的收获就是学会了如何进行版本控制，避免团队不必要的时间浪费。

测试阶段

我们游戏项目的测试与常规的项目测试有所不同，我们的测试绝大部分来自于成员的手动测试，通过游玩游戏来检测游戏时候存在bug。这同样需要耗费不少时间，同时，让模块负责人自己测试往往不太能找到问题。因此，我们就有专门的人员进行项目的测试，当然除此之外，也让一些用户参与到我们的测试，这也很大程度上缓解了我们组人手不足的情况（可以省掉一部分测试工作，投入到开发优化中）。这不仅有助于我们发现问题，还能收集到一些用户反馈，并进一步进行优化。例如用户反馈我们的游戏的一些地方交互上给的提示不够，或者交互不够友好，让用户游玩起来不是特别方便，那么我们就可以针对这一部分进行改进。
总的来说，在这一阶段，我最大的收获就是切身体会到到进行游戏内测的意义。让更多的人参与进来，不仅减轻工作量，也能以多个不同的角度来审视我们的项目，给我们提供更多的建议。同时用户也能提前游玩到游戏，对于各方来说，都是有利的。

发布阶段

我们游戏的发布过程相对而言比较不那么顺利。在进行项目打包时，发现原先代码中的很多方便开发的设置现如今却成了打包的阻碍。由于这些设置只能在编译器中使用，导致打包时一直报错，并且这些错误遍及各个脚本，而且内容又有所差异，没有办法进行自动的替换，只能一步步手动修改。这一问题本质上是我们对于打包环节的一些细节不够了解造成的，没有提前使用预处理命令将Debug和release两种情况分开。
除了这一问题，我们组在beta版本发布之前，发现了一个重大的bug，在进行存档切换并退出游戏重新进入后，会导致游戏内场景切换直接卡死。因为我们的项目不是以网站的形式发布，所以没办法在发布之后再进行修复，必须在发布之前就改好。所以我们也进行了紧急的修复，最终赶在发布之前修复了bug。
经历了两次冲刺的发布之后，我对unity打包有了更加深入的理解，更加清楚在这个过程中一些配置的作用和意义（以前只要点击构建就直接完成打包）。

理解与心得

个人项目

在做个人项目时遇到的最大的阻碍不是程序实现（因为很多功能都可以通过现成的jar包实现），而是对于数据的爬取。因为此前都没有了解过web相关的知识，并不知道要从哪里获取数据。我尝试去借鉴往届学长的做法，但是发现我们这次要爬取的奥运网站与之前有所不同，很多数据并非通过网络请求获取到的，而是直接将数据放在源代码中，这就需要我一个一个翻找才能找到，此外还有一部分数据是通过API接口获取到的，而这些API的命名都很冗长，并且每个日期，每个赛事阶段都对应一个API，这就意味着我要通过大量的APi才能获取到全部的数据。不过好在这些数据处理，我可以通过编写程序，帮我批量的进行处理，节省了很多的时间。

总的来说，个人项目是我第一次切身体会到什么是做中学，也深刻理解这样做的意义。在一个给定的时间之内，既要完成知识的获取又要基于这些知识完成项目的开发。在这中高压的环境下，能迫使我们更积极的获取知识，更快的掌握知识，也能在短时间内让知识得到运用，即能提高学习的效率又能在实践中加深对知识的理解。这也是我在本学期绝大多数实践作业中学习的模式，可以说它让我的学习小v得到很大的提升。
不过，需要注意的是，每次项目实践的时间终究是有限的，想要全面深入的学习一门技术还是比较困难的，而且在这过程中我也发现，前一个阶段学到的知识在一段时间没使用后，马上又会变得生疏，这可能是也是这种模式的一个小弊端：由于快速学习导致缺乏时间沉淀，知识无法在脑海中扎根，来的快，去得也快。要避免出现这种情况的发生，就需要在事后不断进行练习巩固，可以开发一些同类型的项目来加深对技术的掌握。

结对编程

结对编程是我第一次和其他人一起完成项目，也是第一次部署网站。期间遇到了不少技术上和配合上的困难。在技术上，由于不清楚如何将程序构建并上传到网站上，以及对跨域问题不太了解，耗费了大量的时间，同时，在网站的原型设计时两个人的意见也会有出入，所以需要学会怎么统一两个人的想法。不过，除了这些困难，结对编程也带来了很多的好处，两个人开发的效率远比一个人开发来得高，并且两个人在设计中的思想碰撞也能得出更加满意的设计方案。并且，当一个人在某个地方陷入头脑风暴时，另一个人来代替他做这个工作，有助于对问题重新进行审查，说不定能找到解决问题的方法。

这一过程中对于任务的分工和两人之间的配合为我们积攒了经验，为后面的团队开发奠定了基础。此外，也让我初步感受到多人开发的意义。

团队项目

我在团队项目中担任的是PM和开发人员的角色。因此，如何根据任务量、难度和成员的能力，分配好每个成员的任务对我来说是一个考验，在上文中也有提及，在开发中究竟是要追求效率还是要保证质量，一直是我在思考的问题。在有限的时间下，我们无法做到最好，只能有所取舍。因此，我的做法是在一些核心功能上保证质量，尽可能地保留我们项目的特色。在一些比较次要的，用户不太关注的地方上可以放宽对质量的要求。除此之外，由于我的双重身份，很多时候需要来回不停的切换。在开发时，其他组员有什么疑问或困难找我时，我就需要放下手上的开发工作。当解决完问题之后又需要重新回到开发中。有时候，一段时间内会有很多成员过来询问，这时候就很难再进行自己的开发任务。就算继续开发，也很难保证效率。这也一度让我头疼。不过后面我将两种身份的任务分开，在每天中我的开发时间主要集中在上午，到了晚上就做一些总结和次日任务安排，与其他成员开发时间错开，这样就能保证我的开发效率不被影响，也不会让成员的工作停滞。

在这个阶段我最大的体会就是参与团队开发时，不能只顾自己的开发，还要管理好整个团队，协调各方的工作。要做到这一点，最好的方式就是保持良好的沟通，保证成员了解与自己负责模块相关联的其他模块的工作，并尽保证代码风格的一致性，避免系统变得复杂难懂。

自我评价

目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。

评分： 98
解释： 通过这几次的实践作业，我也认识到作为软件工程师，应该技术能力与责任共存，以伦理和道德约束自己。在信息管理类系统中（如我们开发的含有用户个人信息的竞猜网站），要对用户信息保密，避免信息泄露，保障用户的安全，因此我们需要对用户信息的存储进行加密。在我们的团队项目中，我学会与同行（队内成员）之间互帮互助，保持良好的心态。同时我也在课上讲到的一些案例（如删库跑路的程序员）中，深刻认识到严重违反职业道德规范的后果，也会以此为鉴，警醒自己要时刻端正自己的思想。

目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。

评分： 95
解释： 在需求分析的阶段，我熟练掌握需求分析工具和方法的运用。准确提取了目标用户的需求，如算法可视化、不同难度模式的平衡性等，并通过用户故事、用例图和流程图对需求进行规范化表达。从需求捕获到原型设计，每一步都认真落实。不过，面对复杂需求时，可能还需要花费较多的时间思考才能准确表达需求和设计。

目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。

评分： 92
解释： 在团队项目中，我深入参与了软件开发的全过程，从需求分析到体系结构设计再到软件的开发以及最后的发布。在项目实现前，依照体系结构设计方法和基本的设计原则，对自身和团队成员的工作内容进行修正，并再最后由老师进行技术评审。我们再依据老师的建议，对我们的设计方案进行调整。在项目实现时，我们依照改进后的设计方案，实现了高效的开发。不过由于一些设计细节在原先可能考虑不够全面，导致我们在实现这些功能时遇到了不少的困难，最后重新返工对这几个功能再设计后，才解决这些困难。因此我认为我在这方面还有提升的空间。

目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。

评分： 95
解释： 我们创造性地提出了将算法融入到模拟经营类游戏中，并对不同算法和数据结构的展示效果、教育性、游戏性进行了评测，通过对比，优选了适合的算法表现方案和游戏机制。虽然成功设计了难度调整和算法学习的创新机制，但对游戏优化（如在地图生成、npc路径生成时的性能优化）还需更多经验积累。

目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。

评分： 96
解释： 我对每一个阶段的文档设计都全权负责，完成了需求规格说明书、系统设计说明书、系统测试报告的撰写，以及数据库设计说明书的把控。掌握规范表达设计思路和测试方案的能力，在与其他团队成员交流时，这些文档提供了良好的沟通基础，极大地提高了我们地开发效率。

目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。

评分： 94
解释： 作为团队的PM，我在每次实践任务一发布，就按照任务量和难度，做好任务划分，并依照团队成员的特点结合团队成员的个人意愿，给他们分配好任务。并且与每位成员都保持有效的沟通，积极处理帮助每位成员解决问题。保证每次都能按时按量的完成任务。

目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。

评分： 91
解释： 在项目管理中，我划分了游戏开发的里程碑阶段，使用飞书作为任务分配的工具，并理清任务结构，在飞书上给每个成员都发布了详细的任务要求。使用甘特图进行任务规划，按时完成了开发目标。但在估算工作量和资源分配上有时偏乐观，导致部分功能的完成时间比预期更长，需要进一步提高进度规划和风险控制能力。

第二部分：个人技术总结

个人技术总结——基于AstarPathfindingProject的NPC自动寻路
概述：AstarPathfinding Project 是 Unity 中一个强大、灵活的寻路解决方案插件，提供基于 A* 算法的路径寻路功能。它适用于 2D 和 3D 游戏场景，可以处理动态场景、复杂地形、多层地图等寻路需求。

第三部分：软件开发模式

项目开发过程：

参与的项目

我参与的项目是我提出的融合算法的模拟经营类游戏《码农物语》。

项目目标

我们的项目旨在将算法学习和运用的过程融合到模拟经营类游戏中，让玩家既能感受到模拟经营的乐趣，又能够在游玩中学习到每个算法合适的运用场景，以及每个数据结构的特性。让玩家在游玩中感受到算法学习的乐趣。

主要技术栈

由于我在开发过程中参与了很多部分的工作，因此涉及到的技术栈也是unity的各个方面。
主要有URP渲染技术、动画控制器、TextMeshPro、AstarPathfindingProject、DOTween

关键决策

在这次开发过程中，我的主要决策在于算法游戏化的实现方式。参照了很多的编程类游戏后发现，如果要仿造这样的实现模式，就会让这个项目的开发难度急剧上升，可能无法在最后按时交付。因此我就把目光投向了算法运用方向上，借鉴了一些知名游戏的玩法之后，我们决定以一个紧张刺激的贩卖农产品过程来迫使玩家为每一种数量级和数据分布，选择尽可能高效率的排序道具，让玩家体验到游戏性的同时又能对每一种排序有更深的认识。

遇到的挑战

接上文，在确定了算法的表现方式后，紧接着又遇到了新的困难——如何计算每一个算法道具的执行效率，模拟出每一种算法的效率差异。并且，这种差异并不是固定的，例如，在逆序对占比接近最大值的情况下，冒泡排序的执行效率就会很差，但是在逆序对接近0的情况下，冒泡排序的效率甚至可能好于快速排序。所以如何更加真实的模拟这些算法成了一个问题。

解决方案

我一开始的解决方案是想记录真实的排序函数的执行时间，通过多次执行的数据，求和取均值得出时间，再将这个时间放大成秒数级别，但是这样的方式没有办法很好的体现出每个算法的特点。因为测量的执行时间实际上是会受到硬件、线程等因素的影响的，并且这些影响很大。
所以，我最后采用了模拟的方式实现。通过多维度分析每个算法的效率，包括时间复杂度，数据量，数据分布，逆序对，数据交换成本等等因素最终计算出一个执行效率。具体可以查看此前的alpha冲刺博客。通过不断地调参，这个计算公式最终能在很多场合下都能很好的拟合真实的排序效率。

软件开发模式的思考：

我们所采用的软件开发模式
在我们的模拟经营类融合算法游戏项目中，我们采用了Scrum模式。这种模型特别适合需要频繁调整和快速交付的项目，就比如我们的游戏项目。
优缺点

优点

快速响应需求变化：Scrum 强调迭代开发，能够快速调整和优化功能。
清晰的任务分配：通过 Backlog 和 Sprint 目标，每个人都清楚自己的职责。
提高团队协作效率：每日站会和定期回顾会议，确保团队成员始终保持一致。

缺点

对团队要求高：需要成员具备自我管理能力，且熟悉敏捷开发流程。
可能会积累技术债务：短期目标的快速实现可能忽略了长期代码质量问题，这点在我们的项目中深有体会。一个功能实现的扩展性不强，就导致后面要添加新功能时变得极其困难。
Sprint期间变更成本不好控制：在Sprint期间需求的变更困难。

Scrum 对项目的影响

开发效率
每个 Sprint 都有明确的目标，使开发效率大幅提高。
玩家反馈能够迅速转化为新需求，推动游戏的不断优化。
团队协作
角色分工明确，团队成员之间的沟通更加顺畅。
每日站会和评审会议增强了团队的凝聚力。
最终交付
每次 Sprint 结束都有一个可用版本，确保项目能及时交付，并且能够接收到用户反馈，为下一阶段中，游戏里的一些细节如数值的调整提供建议。

开发模式对比

模型	特点	优点	缺点	适用场景
瀑布模型	分析测试是线性的，各阶段都会产出大量的文档，详细描述需求、设计、实现、测试等内容	流程简单直观易于理解和实施便于跟踪和管理	不能很好的适应变化、客户到最后才能确认项目	政府项目、医疗软件等需求明确、流程规范的项目
敏捷模型	开发过程分为多个小的迭代客户和开发团队有紧密的沟通	灵活适应需求变化，快速反馈、强调团队协作和用户参与	需要团队经验和沟通能力文档较少，后期维护困难	游戏开发、互联网产品等需求不确定或变化较大的项目
螺旋模型	强调风险管理开发过程呈螺旋形态，不断循序渐进	开发风险得到控制、有持续不断的客户参与	风险分析失效可能导致项目失败	复杂的工程项目，如航空、军事软件，不适合运用在信息类系统中，也不适合开发时间较为紧张的项目
DevOps	实现开发与运维一体化自动化测试和持续交付	自动化工具提升交付效率、开发与运维协作，快速迭代与发布	需要高度的自动化工具支持（可能需要付费）	持续交付的系统、微服务架构项目。

不同场景的模式建议

在需求明确、变更少的项目中，如嵌入式系统、政府项目、医疗软件等，建议可以使用瀑布模型
对于小型项目而言，瀑布模型（前提是充分了解）和原型模型都是不错的选择
对于大型项目而言，比较适合使用螺旋模型，使得开发的风险得到控制
对于需求变化快、用户参与高的项目，如我们此次的游戏开发，web类项目、移动应用开发等，适合敏捷开发模型
对于需要频繁发布和持续交付的项目，如电商平台、在线服务，DevOps 是理想的选择。

很多时候，一个项目会具有很多特征，而每个特征对应适合的过程模型可能不相同，例如，一个项目涉及到一些前沿的技术，那么就会有较大的开发风险，这时候很想当然地会考虑螺旋模型，但是，于此同时，给这个项目的开发时间又很紧张，需要尽快上线以抢占市场等，那么螺旋模型可能就不太合适，因为大量地风险分析会消耗掉很多的时间。

我的理解和建议

考虑团队特点
在实际的软件开发过程中，熟练掌握每种过程模型，能够依照项目特点选择合适的模型固然重要，但是很多时候不能单纯的考虑项目本身。开发团队的特点同样需要我们关注。例如敏捷开发要求团队高效沟通和快速响应能力，在这点上，由于我们成员平常的交流时间较多，因此就能很好的适应这一点。
合理地调整模型
此外，在运用过程模型时，依照项目进行合理的调整有助于更好地开展项目并保证项目地质量。即使在敏捷开发中也应考虑文档和代码的规范性，这对项目后期的维护至关重要。
拿我们的项目来说。算法的游戏化方案如果不写成规范的文档，那么在之后的维护过程中，其他人甚至是开发者自身就很难理解这个实现过程。如果出现了bug或者需要新增别的算法进去，那么就会变得极其困难。
再者，代码的规范也同样重要，在使用某一语言或者某一引擎开发时，应当尽可能地遵循业内地规范。在我们的项目中就有出现类似这样的问题，由于成员代码的不规范，导致其他成员阅读和修改这些代码时，变得困难。此外，一些变量的数据类型的选择（如数组、小数）如果没有按照规范，自己选择一些比较怪异不常见的类型定义的话，在进行对接时，就要额外进行数据类型的转换，这种转换有些时候需要自己手动编写程序或者调用函数实现，凭空多出工作量。
动态使用模型
在我的理解里，开发模式不应该是一成不变的，每个项目都有其自身独有的特点，如果只是简单的套用模板，可能效果并不会很高效。可以试着采用混合的模式，即将几个模型混合起来。
在我们的项目中，敏捷开发模式的灵活性和快速反馈让我们迅速地调整玩法和算法模拟的呈现方式。然而，我们也发现过于频繁的迭代会导致一些技术债务的积累。因此，未来的开发中，可以在敏捷开发的基础上引入部分 DevOps 工具来自动化测试和发布，以提高整体开发效率并降低维护成本。

...全文