软工实践个人总结博客——夏天会周而复始
| 这个作业属于哪个课程 | <2021春软件工程实践_W班 (福州大学)> |
|---|---|
| 这个作业要求在哪里 | <作业要求的链接> |
| 这个作业的目标 | <写上具体方面> |
| 其他参考文献 | .... |
- 总结博客
第一部分
提问博客
曾经提出问题的新解答
Question1-Chapter3软件工程师的成长
我阅读了第三章关于初级软件工程师成长的5个小点（P49），对于其中的积累问题领域的知识和经验和提升职业技能这两点感触颇深，
但对于同样成长的初级工程师如何去量化这两个方面的提升呢（作为学生）？还是说这样的积累是在工作岗位中不断累积
最终形成职业的晋升呢？这两个点的掌握程度上级可以通过面试评估出来但作为学生的我们又需要如何去提升它们呢？
NewAnswer:在经历了这学期的软工实践后我逐渐发现有开发经验的同学和没有开发经验的同学在面对困难时的解决办法是不一致的。
掌握开发能力必然伴随着开发项目经验的提升。提升开发能力必定伴随开发项目的进展。在学习生活中我们所掌握的开发能力诸如Java云云，大概率是会在后续工作中运用上的。
但是掌握开发相关技能并不代表拥有项目开发经验，能够面对代码出错解决bug的能力才是未来所必需的能力。
其实作为学生，只要能够真正着手进行项目开发就能够提升能力。只是只有极少部分人能做到。
Question2-Chapter3软件工程师的成长
我阅读了第三章练习与讨论中第四个问题。（如下图）我认为这是在程序开发过程中难以避免的问题，然而我们该 如何降低这种问题发生的频率 呢？（个人认为前期的面向对象分析与设计是很重要，可是没有投入到实际实践中空于理论一定是会产生偏差的。即使是我在完成学生成绩系统时，写到后面也会发现冗余的可能影响篇幅巨大的需要修改的地方。）
NewAnswer:在实际程序开发过程中，团队开发必定是先进行一系列的计划与设计，同时应当评估风险做好预案。
一开始我认为的在实际开发中不可避免其实是错误的，因为作为团队既然选择了这一方法，那就应当做好后续的设计与风险评估。
也应当有风险预案。如果没有这一系列的措施只能说明这个团队并不成熟。
Question3-Chapter5
我阅读了第五章对于团队模式的集中分类后，认为功能团队模式是最符合成熟的软件开发流程的，然而究竟是是团队创造项目还是项目主导团队，我依旧对此感到难以权衡。
NewAnswer:在经过这学期的学习之后，我有了新的理解。我认为是团队创造项目。因为一个功能团队模式已经有了成熟的软件开发流程了。
而对于他们而言，组内的人的想法经过共识之后就会形成团队共识，转变为项目雏形。在我们软工课程中的立题也是如此，有了想题目的人，团队才会创造新的产品出现。
事实上一个团队开发什么项目在软工课程中或者是在创业过程中，我们都是拥有有想法的人之后才组成这样的团队。
Question4-Chapter8需求分析
我阅读了第八章需求分析，在其中笔者提及调差问卷式的提问具有两个关键疏漏：实际答案并非我们所希望得到的答案（例：选择最喜欢的搜索引擎，用户给的回答可能是使用最频繁的）以及容易带有引导性。于是笔者引导我们去正确的设置调差问卷评估用户需求。然而个人以为，不论是一个新产品的问世还是一个新需求的呈现，无非都是具有极其强烈引导性的，因为我们要抓住用户的痛点，扩大化其痛点。与其不停的让痛点用户模糊的表述需求，似乎选择先行制造界面再引导用户修改效率更高？诚然，这样做会使得软件可能需要进行大规模修改，然后选择题和主观题是不是选择题更容易作答些。但换句话来说这两种方式皆有利有弊，个人偏向于先做demo再询问，私以为效率更高些。
NewAnswer:在进行软件开发模型的学习时发现确实存在这种开发方式，即先制作出原型再进行开发。但这一种开发模式的弊端在于后期进行制作时
可能需要删减部分功能还需要和用户进行对接。
Question5-Chapter8需求分析
我阅读了第八章需求分析中的功能分析四象限，对于其中的杀手功能有一些疑惑。我曾经想要开发一个类似于收集衣服搭配的软件，然而在我的不断设想中（当时还没有接触产品学习）我所谓的功能在不断的增加，新的功能（虚拟试衣）会覆盖之前的功能成为“杀手功能”，可慢慢的我发现这一新出功能慢慢的成为了这个软件中篇幅最大的内容，或者说他的内容超过了原先我认为的用户痛点（也就是搭配模块）。如果出现这种情况我们又该如何应对呢？就像我们常说根据用户需求或是软件发展添加新功能后，慢慢地隐蔽了原先的亮点。一个软件功能的扩充是必不可少的，可如果失去了主次会不会就像没有初心的人逐渐丧失竞争力一般。
NewAnswer:在这学期的软工实践中我进行了这个设想的重新规划。我发现需求设计还需要考虑到实际开发的可实现性以及明确我的用户痛点。
系统性的软件不一定是最优解，但是专且精这一方向是没有问题的。
Question6-Chapter9项目经理
在小组开会的过程中，我们总是会抓住很小的但是重要的点讨论非常久的时间，但整个主流框架都没有讨论清楚，花大量的时间在重要的末流过多的浪费了开会的时间，作为项目经理该如何去规避这个问题发生的频率呢？
NewAnswer:仿佛是命中注定一般，在这次开发过程中我充分意识到我“跑题”的问题。事实上到最后每次开会前期我都先行列举好会议大纲，
进行会议流程的安排。由于一开始选题过于天马行空导致我们小组成员对于我开会都有些抗拒。事实上一个成熟的项目经理在熟悉团队成员后，
分工应当是明确且适当的。但由于我和我的成员有一定的沟通成本，故前期花费了些许精力。
Question7-Chapter4两人合作
在第四章中看到这句话
结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力下降？
在这句话中我联想到前后端的合作，是否前后端也需要适当的角色互换才能够更理解互相交流时的需求呢？在实际生活中似乎少见这种互换的发生。
NewAnswer:（我简直太会提问了）在这次实践中，我重新审视了这个问题，发现我一开始对问题的理解是有误的，其实应当是开发和产品互换才能够互相体谅。
经历过角色互换之后，才能更理解如何将需求转换为开发，如何规划开发时间点，减少争执。
请问你在项目的需求/设计/实现/测试/发布阶段（一共5个阶段）中，每个阶段收获最大的知识或能力是什么？
-
需求
- 沟通能力:由于我不着重点的联想导致了团队开会时间很长，反馈之后每次开会进行了会议大纲的设置。
- 视角转换能力:站在用户的角度思考是否有实际痛点，设计的功能是否能够明确实现痛点，而不是为了新意追求新意，为了技术追求技术。
- 熬夜加班能力:不多赘述了
- 在需求设计阶段中，我和我的组员由于我沟通能力的问题（和大家不熟悉、标准不一致、开会没重点等）加重了沟通成本，组内氛围并不是很融洽，
当时我们小组由于只有我一位女生，普遍认为Outfits没有市场前景，但我将团队提及的每一个备案都进行了NABCD分析，通过理性的数据和分析
说服了他们（可能是因为死缠烂打），当然后来在答辩时大家也意识到了这个产品的市场前景。这件事情让我印象深刻是因为我意识到当无法互相说服的时候
需要一些数据来客观评估。诚然，遗留的沟通问题也成为后续组内的较大问题。
-
设计
- 需求转换能力:将用户需求转换至实际功能点。
- 标准统一的评价:应当团队建立统一的标准去进行材料任务的评估，而不是用个人的标准规定整组人。
- 抗压能力:这个时候和组员的部分沟通不是很融洽，由于标准不一致的原因，导致我重新修改审阅材料。
- 熬夜加班能力
- 在这一阶段由于标准不一致的问题并没有解决，导致我和部分同学进行了反复的材料修改。在原型答辩之后我开了一个全体大会，设定了责任小组，
也进行了标准统一的设立。经由小组长设定标准，我直线对接负责人。在这次制度的修改后，我充分的下放了权利。虽然后期有发生小组长不太负责的情况发生，
但也算是使得我们组内的责任明确化了。 - 同样，在这次开会后我充分意识到组内的成员们对于课程的目标是不一致的。我的目标是培养的我项目开发的产品经验。很大部分的同学仅仅是为了完成
课程要求，因为他们已经具备了充分的开发能力与经验，并不一定只有这门课程能够给他们带来教学。当我意识到这个问题时，我发现我并不能改变每个人的想法，
无法中和，只能勉强让大家完成任务。所以我提议在课程初期进行分组的时候就可以合理规划大家对实践课程的目标分数是多少以此来分小组，或许是个不错的想法。
-
实现
- 规划能力:项目的初期就要按照每日进度表规划一样去执行，否则后期会非常疲劳。
- 沟通能力:出现部分断联现象，但由于前期“负债累累”所以只能自尝恶果。
- 学习能力:学习了安卓开发，但效果并不显著。
- 抗压能力:每天不是在催材料就是在催材料的路上，收集不到每日进度，很多时候表格就只能置空。
- 在这一阶段，我后期大部分就是只负责博客撰写和答辩相关事宜。这个时候团队部分成员出现了懈怠的情况，可以理解也无法改变，
毕竟大家对于软工实践的课程要求并不一致。但这就导致文稿不及时，后期ddl疯狂补救的情况发生。
-
测试
- 风险评估能力
- 学习能力:短时间寻找测试工具学习。
- 代码规范很重要。
-
发布
- 调查问卷应当面向对象调查。
- 及时反馈能力
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
- 作为一个辅修工商管理并且意向做产品经理的人而言，这门课应当是非常锻炼我的能力的，也确实真真切切地让我感受到锻炼，虽然非常的痛苦。在这里也要谢谢汪璟玢老师、傅明建老师、张璟璇助教、林新宇助教、杨心逸助教、孙首男助教和徐明盛助教给我的帮助和教诲。
- 在个人项目中，我设立了短期内的发展方向与规划考量，虽然后期被我咕咕咕了，但是尝试去探索自己的发展路径和摸索这个行业的前景，是一项非常需要学习的能力。我学习了检索信息的能力，但在区分有效和无效的信息中还是有些迷茫。就如同摸索发展方向一般，但后续的软工实践就像引路灯一般带我亲身经历一番实际开发过程，或许他在真正的职场中还漏了部分环节，但总算是体验了一番产品的感觉。同样地，在进行代码编写的时候，0分的运行分让我充分意识到程序运行是非黑即白的，努力与实现它并没有联系。很多时候，只看目标不看过程才是常态。让自己达到满分的结果才是基础。（当然管理不能这么想）
- 在结对编程中，我充分意识到掌握一门技术的重要性。在软工之前，我学习了python-flask这门开发技术，这使得我在结对编程中少了许多学习的成本能够直接上手开发。但是学习是无处不在的，在结对编程中我第一次尝试爬虫程序的编写。但其实在很早之前，我就有机会去学习爬虫了。由于我的懒惰，导致了我在这个阶段还需要继续学习。这同样也让我意识到很早之前看到的一句话。
15岁时觉得游泳难，放弃游泳，18岁时遇到一个你喜欢的人约你去游泳，你只好说我不会呀。18岁时觉得英语难，放弃英语，28岁时出现一个很棒但要会英语的工作，你只好说我不会呀。虽然很不形象，但是很贴切。所有我逃避的最终都会回到我身上。结对编程的队友是我的舍友，我们之前并没有沟通成本，大家都追求能够有效认真的完成，于是我们相处的非常融洽。 - 在团队项目中，我真真切切的意识到自己的不足，学习到非常非常多。在我修习的辅修管理课程中，大多都是面向职场，我错误意识了学校中组长组员的关系与真正职场的不同，这就导致一开始我的“专断”。加之每个人针对这门课程的目标不同，我逐渐意识到无法让所有人都跟随我的标准，于是我开了一次会，下设了负责人，经由负责人统一标准，将小组制度化来改善这一情况。（如果这个问题能在组队时被发现就好了。）几乎是不可避免的产生了组内的矛盾冲突。后期联系不到组员，也就相当于自食恶果。我和部分组员只能在每次答辩之前疯狂赶工。这并不是良好的氛围，我理解，但是我造成了这个局面。真的心力交瘁。这门课极大程度的锻炼了我的抗压能力；意识到自己的管理能力有问题；意识到自己沟通能力有问题。
- 写总结博客的时候发现自己提的问题真的都是自己在实际发生的问题，泪目了。
- 发现了很多错误 ，也正在尝试改正，就是有那么一点点辛苦。
- 其实在这门课的过程中有无数次想说的话，但到了最后只想说“终于结束了”。
