往事如烟 忆苦思甜
| 这个作业属于哪个课程 | <2021春软件工程实践S班> |
|---|---|
| 这个作业要求在哪里 | <软件工程实践总结&个人技术博客> |
| 这个作业的目标 | 回顾整个课程进行具体总结 |
| 其他参考文献 | 《构建之法》 |
第一部分：课程回顾与总结
1. 回头看看
1.1 问题链接
1.2 问题解答
问题一：
解答：
在上面的问题中，我主要提出了因为每位成员在工作过程中的进度各有不同，有的人可能会整个团队的进度，那么该如何解决这个问题。
我对这个问题的答案是：
其实这个问题主要是项目负责人来解决的。
首先，项目负责人在布置任务的时候要尽量做到细化，每人的工作内容具体到天。在公司的实体项目团队中每天早上都是会开例会，来分析前一天做了什么，是否达到了昨天预期的工作任务，以及今天应该做什么。
其次，在感觉到团队成员有怠慢或者遇到一些情况时，项目负责人要做到及时跟进，了解情况。
① 如果是成员怠慢，要考虑一下是因为这个项目越做越没意思还是因为这个成员个人问题（三分钟热度，不能坚持等等），若是项目越做越没意思那么应该重新审核一下需求，若是成员个人问题，尽量与成员进行沟通，激发成员战斗力。
② 如果是因为成员在项目中遇到了一些难题（BUG等），要及时开会讨论，大家一起解决，不要把难题丢给一个人解决。
最后，如果遇到了你无法解决的问题时，一定要向上级反应情况。这种反应情况不是打小报告，而是你无力解决切为项目考虑的情况下向上级寻求解决方案。
问题二：
解答：
对于第二个问题我觉得是可行的
- 一方面是由于这个观点本来就是我自己提出的。（否定自己的观点很没面子的好嘛）
- 另一方面，我在比赛当中用的就是这种方法，让除产品外的成员负责一部分的需求工作能够让成员在有限的时间内更好的了解需求，明确自己应该做什么。让前端配合UI进行设计能让前端更好的理解设计原理，能够解决很多前端在布局方面的问题。让后端与前端配合能够更好的进行前后端接口的对接。对于这种配合方式我画了个图，如下：
问题三：
解答：
对于这个问题呢，其实我当时想的是比较片面的，回过头结合前面的内容再看这一段话，其实作者是告诉我们应该正确选择开发方式，确定敏捷开发是否适合本团队的使用。
我这里看到了一篇文章，我觉得放在这里很合适：
问题四：
解答：
对于这个问题嘛。。。。我的答案有这几点
- 对于需求来说，这块不用防也没必要防。在问卷调查的时候调查的是大家有哪些痛点，分析的是用户的行为，就算问卷被别人抄袭了，数据也未必能被抄袭。
- 在做项目的时候一定要快！要用最快的时间把需求、设计、开发等做完，尽早上线把握先机。在等别人还没来得及抄袭的时候就先把项目做好，让别人只能跟着你的步伐去走。
- 如果你的项目已经上线了，然后担心被抄袭，那么大可不必。在需求这块，我们没办法证明自己的版权，因为需求源于用户，用户是大众的。不过我们可以将这种行为认为是被模仿，有的时候被模仿并不是坏事，作为学生而言，被模仿是一种认可，而且往往很多创新都是从模仿、抄袭中借鉴而来的。（eg:QQ，这个就不多说了，懂得都懂）
- 对比需求的保护，我目前更看重技术的保护。一款产品的核心往往不在于需求，而在于技术。把握好核心技术，其他东西爱咋搞咋搞。（再次提一下，腾讯这块做的就很好）
问题五：
解答：
这个问题我们团队在软工实践中刚好就有遇到。以我现在的经验对这个问题的答复是：
- 在需求过程中，团队成员一定要做好需求复审，反复对需求进行考量打磨。如果前期需求阶段不愿意花费时间进行复审，那么在开发阶段可能会耽误数十倍的时间去”补裤档“。（数十倍一点不夸张）。
- 如果前期需求没做好，在开发阶段真的遇到了这种问题，那么最好的办法就是版本迭代。先将原来的需求实现，然后测试发布，在这之后让用户来告诉你这个需求合不合适以及要改哪些。最后进行不同版本的更新。
2. 硕果整理
我在项目的需求/设计/实现/测试/发布阶段（一共5个阶段）中，每个阶段收获最大的知识或能力是什么？
2.1 需求阶段
在这个阶段我收获最大的是将我书本学习到的关于需求方面的知识进行了实践。以前做的一些项目或赛题都是命题式的，而这次的项目确是一个开放性的，让我有了更大的施展空间。而且这次项目做的是游戏，我以往做的都是网站或者APP的服务式项目，游戏项目对于我来说是一种挑战。
2.2 设计阶段
设计阶段我们这个项目有很多灵感是来源于PC端的Super Bunny Man，我们将PC的界面设计成了移动端。在设计初我本来是想使用AXure来制作原型的，但我之前没做过游戏的原型，而且游戏中的动画效果在原型中也无法展现，因此我又get到了一个新技能，使用U3D来做原型。
2.3 实现阶段
实现阶段主要是编程和UI，在这块我主要做的是UI的部署，这也是我第一次做游戏的UI，在这个过程中通过不断的调试，让我对游戏UI的部署有了根深的了解。同时，在这个过程中我也学到了怎样与开发人员更好的沟通，怎样使用GitHub等工具。
2.4 测试阶段
在测试阶段我主要做的还是UI方向的测试，并且配合其他测试人员进行测试报告的撰写。从中更加熟悉了测试的相关工作以及对接相应人员。
2.5 发布阶段
发布阶段我主要的工作是用户问卷调查及反馈数据的分析，由于我们的游戏是Apk的形式存在的，没有在应用平台上线，所以体验的用户比较少。那么就将这些少量的用户作为目标用户，发放问卷并进行访谈。最后在将这些结果进行汇总。从中我收获最大的地方是在用户访谈，让我感受到了不同人的不同看法，这让我在以后的需求工作中对同理心的培养有着很大的帮助。
3. 静下来想想
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
我就来说是团队项目吧，因为团队项目周期比较长而且相对于个人和结对项目来说，在团队项目当中大伙付出的都比较多。
3.1 对团队项目的心得
在”疯狂TUT“这个项目中，我们在前期的时候本来是想做”王者荣耀“翻版的，但是我感觉做翻版并没有任何意义，对王者而言，PC端有LOL，移动端有王者，再做也没办法做出很好的创新，为此我们专门开了次会来讨论，最后决定将PC端的super bunny man移植为移动版，并进行创新。
在这次实践中，我第一次接触了游戏方向的产品工作，让我对游戏的开发也有新的认识，在Github等软件也有了更熟练的操作，并回顾了大三上学的C#编程。
对于这次的总结呢，因为我是做产品方向的，我最大的感触还是需求方面，起初，我们的需求非常乱，简直就是想一出是一出，有点像头脑风暴，但是风暴过后我们并没有整理归纳，导致在开发阶段问题百出，还要边开发边做需求。不过还好，最后还是做过来了，结果也得到了相应的肯定。总体来说是非常不错的。
3.2 对课程的心得
在课程的最开始，我记得老师说过，我们专业的每位同学必须要有编码，我有点不是很认可。
我认为一个标准的开发团队应该有产品经理，美工，开发人员，测试人员这四部分组成，但要清楚的是，在产品经理和美工这两个岗位是不需要编码的。如果这两块没有专人负责，那么整个产品线将会乱套。
我的建议是一个团队中，8或9个人里面有1~2人是可以不编码的。
说到这里有人可能会说：“软件工程的学生不会编码那应该干嘛？”
我的答案是：首先，不会编码和不编码是两码事。其次，软件工程难道考核的仅仅只是编码能力吗？如果是，那我们为什么不叫这个专业是程序专业，而为什么偏偏要叫“软件工程”。既然有了“工程”二字那就说明了它需要规划+设计+实现+测试这个过程。其次，《构建之法》当中也有专门说明：软件=程序+软件工程。
因此，我认为老师对代码要求卡的太死了。如果是为了避免有人划水，工作日志和任务表单是能够明确说明的。
虽说“三个臭皮匠顶，一个诸葛亮”。但在软件开发中，让专门的人做专门的事，比一群业余人士去做有用的多。软件开发更注重的是效率，而不是人力。（可能以我现在的身份和地位说这句话有点没权威性，但我认为它是对的）
第二部分：个人技术总结
1. 工作总结
其实做游戏是我之前没有想到的，在第一次作业的时候，我有两个目标，一个是在前端方向有更深入的学习，另一个是培养产品经理的思维与能力。
做了游戏之后呢，我在前端方面的学习就只能靠自己私下去学啦，那么该课程就全心学习产品经理。
因为之前有往产品方向进行学习，并且在服务外包与软件设计实验室也是设计组成员，对产品和UI有一定的基础。所以，在是整个软件工程当中呢，我大部分充当的是产品经理和UI角色。同时，为了让自己有一定代码量，我也参与了部分编码和测试。
作业要求说的是从“个人技术学习角度和团队开发技术角度中选择你最擅长的一个相关技术”，但我在整个课程中学习到的大多是产品方面。我觉得需求和设计两个阶段也是有技术的，而且并不亚于编程， 所以我想下面的个人技术总结主要写产品需求方面的，希望老师和助教谅解。
这里简单庆祝一下，通过不断的努力，我在上周拿到了京东产品经理岗的实习offer！嘻嘻。
2.技术博客
博客链接：
