忆往昔，还看今朝
| 这个作业属于哪个课程 | 2021春软件工程实践S班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 回顾软件工程实践课程及总结 |
| 其他参考文献 | CSDN、bilibili |
目录
问题链接
问题解答
问题1.团队模式会因为哪些因素而发生变化
重新思考：除了原来思考中的认为和上级的指示、项目的性质和团队模式的成熟度有关，还有包括和任务的特点有关，比如面临“只用一次”的程序、“看了就扔”的原型还有一些不实用的演示程序就可以采用写了再改模式，我们软件工程实践作业恰好符合这三点要求，但是如果要进一步追求做一个有实际用户、解决实际需求的项目，这个方法缺点就太大。而当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队还会采取交响乐团模式。所以引起团队模式变化的因素应该是多个且综合的。
问题2.在用户长期使用但逐渐厌弃该软件，这是用户的问题还是开发团队的问题
重新思考：我认为这和软件性质有关，下载的软件如果分为需要且频繁(如微信)，需要且偶尔(如淘宝)，娱乐软件（如微博），对于第三类被替代性很强的软件似乎才有讨论意义。如果是因为软件的某个小设计不满意的话，其实不影响整体使用，用户不会放弃使用；而往往是除去软件本身的设计问题令用户可以放弃一款长期使用的软件，如微博上评论区一些引战现象，所以应该既不是用户由于使用时间长而产生厌倦问题，也不是开发团队问题。又或者，是找到了替代软件，替代软件更受用户青睐，所以这个问题本身的提问就很有问题，我推翻我的原先看法。
问题3.对PM来说，开发和测试并不是硬性要求对吗
重新思考：在构建之法中提到微软公司有几类PM，包括有做功能设计的PM，这类PM需要深入掌握各个计算机科学分支的专业知识，其他类的PM相对来说有更重视的能力，比如有些需要对商业和客户有很强的了解能力，比如有些需要具备广泛的经验和知识面。但总体而言，成为一个合格的PM，需要有观察、理解和快速学习能力，分析管理能力，一定的专业能力。和原答案一致，"对于PM来说，最大、最独特的贡献是保持团队的平衡，作为PM，更重要的是有自己的产品思维，有同理心，协调项目的进度，在程序员和客户之间充当沟通的桥梁。编码能力不是产品经理的硬性要求，但懂一些编程知识能够更有利于PM和程序员的需求沟通，也能很好缓和二者关系。"
问题4.代码的容易维护是站在复审人员认为的容易还是代码达到了团队规定的编译警告等级
重新思考：感谢助教老师在之前博客的评论，“因为团队的编译警告等级是团队事先规定并配置好的，而复审人员是经验丰富的开发者，对于提交上来的代码进行走读”，所以其实代码的容易维护和团队规定的编译警告等级不搭边。
问题5.是否代码量越多，该程序员能力就越强
重新思考：《构建之法》中提到初级软件工程师的成长可以看作以下几个方面，包括积累软件开发相关的知识，提升技术技能(如对具体技术的掌握、动手能力)，积累问题领域的知识和经验，对通用的软件设计思想和软件工程思想的理解等，可以知道，代码量的积累只是可以帮助我们提升这些能力。而如果只是单纯的搬运代码，代码量增加，但这些能力也没有得到提升。另外，书中还提到了量化指标，在团队工作中，稳定、一致的交付时间也是衡量一个程序员的能力的重要方面。
新问题：在开发团队项目中，其他组做App在测试阶段测试了前端后端，测试机制较为完善，而一个游戏要想有较为完善的测试要测试哪些方面，用什么工具测试呢？
各阶段收获
需求阶段
在结对作业、团队作业做项目的过程中，我学到的有
要充分考虑产品需求，要确保这个东西做出来能用且在自己的范围内能实现
之前，对于需求阶段并没有觉得多么重要，但在结对作业以及团队冲刺中发现需求阶段很重要，尤其在极限冲刺中，起初的需求阶段没有商量统一好需求，只是口头表述真的不行；同时也要结合用户的需求，毕竟做出来最终受益者是用户，尽量站在用户角度看待问题，用同理心去看待产品很重要；学习到了通过NABCD分析法来分析需求，确认即将着手的项目是有必要付诸实现的。
设计阶段
设计阶段要根据需求阶段得到的结果，比如生成的原型图及PRD文档来进行设计，包括框架设计和数据库设计，还要注意在开发前定下代码规范，并且严格遵守，在一个团队中尤其要注意代码规范，包括变量的命名、适当的注释等，否则别人有时候需要看你的代码只会一头雾水。
实现阶段
Scrum站立会议很重要，有利于把握总体进度
站立会议中每个人汇报改日的进展和困难，对于项目的进度总体安排心中有数，对于自己接下来的任务轻重缓急心里也有个大概，可以起到督促自己的作用；而且，将自己遇到的问题口述出来，常常会获得队友们的经验分享和建议，对于接下来困难的解决会有一定帮助。学会了使用github来管理项目，其中的issue每次关闭都有成就感，也学会了用Plastic SCM来管理unity项目，方便快捷。
测试阶段
要学会回归测试，而不要最后着急忙慌的进行统一测试
在alpha阶段，我们游戏的测试是最后时间一边整合，一边测试，整合的时候时常会出现Bug，而在最后时间其实心态也容易焦虑，如果能够在开发阶段中穿插整合环节，其实对于整个项目的把握会更好。
发布阶段
整合发布游戏后，将整合后的初版本给一些用户体验，并获得反馈有利于进一步的版本修改。
通过问卷调查来获得用户反馈，再进一步分析问卷情况，就可以发现项目有些点确实可以进一步改进，能帮助更好的完善项目再进一步发布。
阶段理解与心得
个人项目
个人任务中写词频统计程序第一次接触了单元测试这个概念，并学会了初步使用IDE的插件来进行单元测试，而且，还学会了github的push、pull等操作。但当时没有考虑完善，有个别情况没有考虑，而且，审题也没有认真看，所以导致最后测试结果并不理想。。
结对项目
使用前后端太密切联系的框架是件很难受的事，结对项目中使用了Php语言和Yii2.0框架和结对队友一起编写顶会热词项目，但划水好多，基本都靠队友带，感谢队友呜呜。
团队项目
在多次团队作业中逐渐学会了合作和反馈的重要性，也通过unity教学视频对unity有了更多的理解，包括实现场景切换功能，做出菜单功能，创设场景等，熟悉了团队合作的流程，每日一会这个环节对于整个团队来说很有必要。而且，一个规划进度、统筹安排的组长对于整个项目来说至关重要，除了分配任务以外，主动去了解每个队员的进度或者接收队员主动的反馈，再根据反馈来分析团队的进度是否符合预期安排，是不是有些环节要早点开始以便后续的操作，这些都很重要。团队合作真的很重要，一群人为同一个目标共同努力真的很美好。加入饱满骑士后，我发现这和我最初寒假作业所想的往前端方向学习是不一样的，虽然没有去前端开发，却也获得了一点unity学习的经验以及结交了热爱游戏且非常可爱的骑士们，非常幸运，我甚至觉得我的拖延症好像在此次开发过程中有那么一丢丢改善。。且更能清楚意识到自己的代码知识匮乏，希望在今后学习中能够逐渐加强。
第二部分 个人技术总结
个人技术博客
概述：实现了Unity中玩家可以自由设置按钮的功能
