软件工程实践总结&技术博客
| 这个作业属于哪个课程 | 2021春软件工程实践|W班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 1、 回顾自己列出的5到10个问题：尝试解答、继续分析、提出新问题 2、5个阶段中，每个阶段收获最大的知识或能力是什么？ 3、结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得 4、技术博客 |
| 其他参考文献 | 《构建之法》 |
一、回顾问题
为了征求用户意见，所给出的核心功能是一种假设（假设用户会使用）吗？假设和实际用户使用如果存在很多差别怎么办？
在软件工程实践过程中，有一环【需求分析】的过程，在这个过程中，团队运用NABCD模型进行需求分析，基本确立产品的需求。后续通过KANO模型，将需求分为基础型、兴奋型等，对需要实现的需求有更进一步的了解。这两个环节的分析，均是基于前期用户需求问卷调查的结果进行的，因此初步保证了解了用户需求，产品中的核心功能会是用户需要的。在后期，产品一般会经过正式发布前，邀请具有代表性的用户进行【用户测评】，了解用户对成品的评价，进一步确认用户对核心功能的使用情况，帮助开发团队正式发布前对产品进行修改。
虽然结对编程存在开发者之间可能就某一问题发生分歧，产生矛盾，造成不必要的内耗等缺点，但就效率来说依旧是一种高效的工作方式。那碰到沟通不合、不喜欢公开工作方式和技术水平的合作伙伴，选择什么样的方式会比较好呢？
个人认为，就工作内部而言，沟通不合产生的原因有可能是双方没有提前确立开发功能的具体细节，那么久需要两位开发人员在正式开发前确立双方的工作内容，并确立结果论。同时，在确立工作内容之后，双方可以各自进行开发，给双方的隐私（工作方式和技术水平）保留余地，最后交接时只需要分享开发结果即可。就工作以外的内容，那么就依赖于各自的性格和沟通方式等等，并不应该是工作中需要考虑的内容。
敏捷对团队的要求前两点皆为“自主”，若是有一个团队同时具备老手和新手，每个人能力不尽相同，此时应该用木桶原理去评判这个团队吗？
个人认为，不能就木桶原理概括所有的团队合作。在木桶中，每一块木头之间没有任何联系，而在实际开发中，每一位成员不是机械的、不与他人产生联系而独自存在的。每一位成员都在接收来着团队其他成员的影响，或增长技术，或改进沟通方式。如果通过木桶原理，希望说明团队的实力取决于短板，我认为这是片面的。在开发过程中，团队成员的实力是在动态变化的，每位成员都有成长的可能。在本次软件工程实践中，团队中经常有互帮互助的小组存在，团队分前后端开发，即使团队中每人实力不相同，团队整体的任务进度并没有收到过大的影响。
但是，本次项目团队基本由熟人组成，团队中互帮互助的现象是自然产生的，由此，我不认同单一的木桶原理觉得团队实力的结论。那么，在企业级项目团队开发过程中，团队成员的互帮互助是否是必要的呢?
当项目的需求与软件的利益相对立的时候，团队该如何做选择呢？
在前期，我在博客中提出广告相关内容，我依旧有当广告的利益与用户需求产生矛盾时，软件团队如何做选择这个困惑。如果抛弃软件的这个实体，回到软件的利益上，运营团队/销售团队或是其他软件直接获益者可选择的、获取软件利益的方式还有很多种，比如，知识付费，个人认为这是一种对用户良好的获取利益的方式。所以，在选择上，也许可以通过讨论获取利益的具体方式解决团队面临的选择。
如何判断自己的想法是可行的呢？如何找到创新的方向呢？
实践出真知，一般认为实践是检验想法的最优方法。不过，我认为可以添加一些实际的要求，比如，提前确立目标，当发现目标不可达时及时止损。
如果去了解一些创新者的故事，可以发现很多创新的想法是来自于生活中的观察。创新也是在建立满足需求的基础上，而在分析需求的时候都会分析【痛点】，痛点来自于生活中出现的问题，所有找到创新的方向应当从发现问题开始。
二、个人收货
需求阶段
在需求阶段，项目团队去构思一个产品，并设计问卷进行问卷调查，了解用户需求。然后使用需求分析模型对需求进行分析，确立需求。接着，绘制UML类图、活动图、用例图，设计原型，编写需求分析文档。最大的收货主要是如何高效开会和如何处理团队中不同的意见。首先是会议，在会议前对会议内容进行梳理，并在会后进行会议记录对高效开会非常有帮助，会议时长明显缩短，工作安排更清晰，也把需要讨论的内容都完成。
设计阶段
在设计阶段，项目团队依照前期进行的需求分析开始系统设计和数据库设计，在系统设计中，注重设计体系结构和功能模块。在设计阶段，由于有了前期明确需求，这个阶段开展比较顺利。主要学习的内容是如何在自己无经验和不了解的情况下展开工作，在本阶段开始时，大家对体系结构的部分几乎不了解，也没有设计经验，所以在第一个小阶段会议上一起讨论这个部分，并分配给两位成员一起完成。
实现阶段
在实现阶段，项目团队开始进行开发，在alpha阶段基本完成前台，beta阶段完成后台。在实现阶段，我的工作基本是进行项目管理和团队管理，在这个阶段很多是对前面获取到的组织会议、解决问题的能力的使用。在alpha阶段，团队在前后端连接中出现了沟通不畅的问题，在冲刺结束后，小组进行反思，在beta阶段，该问题得到了改善。
测试阶段
在测试阶段，前期前后端的单元测试、功能测试及界面测试都很好完成了，但是集成测试由于接口对接存在问题，在两次冲刺中都是稍微延后进行的。在这个阶段就认识到，沟通真的很重要很重要，很多小的错误，可能是由于后端忘记修改接口文档，可能是变更没有让全体成员完全知晓，可能是出现问题没及时去找后/前端开发人员沟通，现在看来，这都是通过沟通可以解决的问题，所以在冲刺阶段，及时、有效的沟通非常重要。
发布阶段
在发布之后，项目组进行了用户使用调查，根据调查结果分析软件使用情况、是否符合用户需求等。在这个阶段，通过用户反馈，可以看到很多站在开发者或管理者角度没有考虑到的问题。比如，发布的第一个版本包含网络检查的功能，项目团队认为这个功能可以提升用户体验感，是用户友好的功能。然而，在发布之后，该功能是用户反馈最多的功能，用户提到，该功能会带来流量消耗和过多的动画影响整体使用感受。之后，项目组基于此决定取消该功能。由此认识到，用户的需求和项目组分析的需求可能会存在偏差，用户并不会完全以我们想象的方式去使用产品。
三、心得体会
-
沟通很重要。如前文所示，项目在进行前后端连接时，有效、及时的沟通能帮助解决许多问题。同时，沟通也有很多种方式。在结对编程中，我和结对的小伙伴发现，直接的对话比间接发信息，沟通效率更高。因此，在结对过程中，前期我们选择QQ语音通话进行沟通，后期我们选择线下编程进行讨论。
-
站在用户角度考虑，有时能帮助决策。这是在项目团队实践的整个过程中体会到，在项目开发过程中会面临许多【需求】，如何去挑选最核心、最基础的需求，是团队需要考虑的问题，在这个问题上，个人认为，站在用户角度能够帮助决策，通过用户使用场景的模拟，确定最核心、最基础的需求。
-
解决问题的能力很重要。无论是在结对编程还是团队编程中，或多或少都会遇到各种问题，可能是技术上的bug，可能是设计细节没有明确，可能是需求设计不明确，可能是实现方式不清晰，在遇到问题时，选择“我也不知道诶”、“不懂诶”、“随便吧”的答案会把问题，像是把黄豆留在鞋垫下一样，永远停留在【待解决】的状态。在两次实践中，我学习到，解决问题基本是找到问题来源，梳理，给出解决方案，只需要比回答上述答案多一点点的耐心。
四、技术博客
技术概述：本节通过传声筒游戏，为初学者讲解Promise对象的属性及常使用方法、执行机制等。在开发中，读取文件、axios都使用了Promise。本节难点是then方法的执行机制。
