2022北航敏捷软件工程 第四次博客作业

2022北航敏捷软件工程 第四次博客作业

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	了解软件工程的方法论、在实践中学习软件工程的各个层次、获得以敏捷流程进行软件开发和产品构建的相关经验、尝试以软件工程的方式来实现脑中想法。
这个作业在哪个具体方面帮助我实现目标	了解软件工程的方法论：结合第一次博客的问题，结合所学软件工程理论重新回顾当时的不解之处。在实践中学习软件工程的各个层次：站在团队开发的终点，结合实践总结课程所学。获得以敏捷流程进行软件开发和产品构建的相关经验：团队开发采用敏捷形式进行到开发终点。尝试以软件工程的方式来实现脑中想法：团队开发完成了基本成型的产品。

Author 19373540 熊安杰

Date 2022.06.24

《解》

个人阅读作业-阅读和调研

学期肇始的阅读作业包括了以下几个方面的问题，完成课程之后，对应记录下对每一个议题的体会和自我解答。

“过早优化是一切烦恼的根源”：那么，如何界定早晚？

——比起界定早晚，不如分类“优化”。

好的架构是成功的一半。 在团队开发过程中，以我们的前端开发为例：前端基于 MVVM 架构开发，在此基础上，开发团队在 Web 端 VM 层上进一步抽象出网络层，分离 API 交互实现与客户端离线功能，提高 Web-app 的鲁棒性。并且，模块化进行视图层开发，引入中间件等复用代码、为平台逻辑提供统一实现。这样开发完成的招聘者前端因为其架构优势，具有清晰的代码结构和很高的可维护性。架构层面的优化没有所谓“过早”一说，基于成熟的设计模式在**开发前*8就对架构进行充分的考虑和优化，是开发中不可缺失的过程。

重构什么时候开始都不晚。 团队开发过程中，团队为适应需求的变更和扩展性的需要，进行了规模有大有小的数次重构，都取得了较好的成果。重构本身应当动态地进行，在项目低耦合、模块化设计、开发规范清晰、协作机制通畅的前提下，重构并不会带来很高的成本——背着重担的代码反而更难生长。

需求分析：“最好”还是“最合适”？

——软件开发的需求分析和功能设计，在于提供一套最有效率的机制，帮助用户解决问题。

在实际的需求调研、场景分析、功能计划和最终的软件实践过程中，“需求”只是用户对于实际问题最迫切和直接的观察和表达。软件开发者与其说是要引导用户表述需求并被动地听，不如说是要借由用户的心声去了解一个专有领域的问题，并从软件实现如何产生作用的角度出发，主动地思考能为用户提供哪些“接合点”。

这样的“接合点”一方面来源于用户既有流程所暴露的“接口”——既有解决方案的流程中哪些步骤需要软件的辅助，（更重要的）另一方面则来源于软件能对流程带来的创造性改进：我们的平台在原有的微信发布消息、邮件联络的框架之外，为校园科研需求的初始阶段定义了统一的范式和流程，并为相关的两类用户角色都提供了效率更高的选择和实践。我认为抵达这个层面的需求分析才能符合软件开发的需求。

测试与质量管理：软件开发的合与分

从结对编程两人合作完成项目并构建单元测试，到团队项目开发过程中在团队内部建立和实践测试机制，本学期的软件工程实践中，多次体验了实际的软件测试流程。

团队项目开发中，在团队 QA 成员的带领下，团队针对各 API 功能组、用户端模块和操作流程，完成了单元测试、场景测试、压力测试等多维度、全方位的测试。对后端稳定性和预期功能、安全性，前端交互体验、视图逻辑等方面做了尽可能全面的测试。

测试本身，有一套详尽的方法论可以采取以实践。测试的框架应当“合”起来考虑，各模块的单元测试应当交由实现者负责，各方面的测试工作也可以互不牵涉地“分”出来进行。——最重要的，是所有团队成员的质量管理意识。同时，交叉进行的 Code Review 也很有必要，这一工作能弥合大家的经验差异，为团队的总体开发质量带来提升。

质量管理也要在始终触达用户的情形下进行：开发过程中，团队提供了一套 BUG 收集及反馈机制，并通过直接访谈、或用户群的方式触达用户，虽然时间紧迫，但仍收获了不少宝贵意见。

敏捷流程：构建“玩具”的方法？

敏捷流程是一套思考的方法论，事实上是指导软件开发工程师应对变化的思维模式。在具体实践上，团队保障项目健壮性、可扩展性的努力是多样的。应对方法论并没有明确指出的问题本身，也是“敏捷”向开发者提出的要求，和它蕴含的价值取向。

“惊喜功能”：先有鸡还是先有蛋？

惊喜建立在精确的需求定义之上，为这份“喜”亦须铺垫好基础的功能、解决用户的基本需求。

产品的竞争力不只包括功能的全面性，亦包括功能的特异性。团队完成的产品面向校园内部实习信息聚合的细分领域进行需求调研和规划，针对学生们在机会寻觅、导师和在职校友们在信息发布上的痛点，立足校内信息优势，构建校内私有的资讯领域和交流通路，与现有类似产品进行差异化竞争——这是我们为用户提供的“惊喜”所在；实际的实现过程中，我们针对市场上的同类产品做了尽可能充分的调研，力图补齐主流求职类 APP 所具备的各项功能（简历存储、一键投递、关注收藏、标签系统、Offer 推荐、简历版本管理等），这是我们为留住用户所做的努力。——能下蛋的鸡必然从蛋中诞生。

《行》

知行合一，软件工程课是一门讲求实践的课程，项目实现阶段带给我如下收获。

需求

需求分析要贴近用户。 第一部分已经谈到过这个问题。总的来说，团队在需求分析上进行了一对一的调研访谈、广泛的问卷调查、针对性的典型用户随访、组建用户群组等多种实践，划定了较为合理的功能集。不只是在项目的初始阶段，在项目开发的全流程都应该把用户放在思考的核心，始终关注需求，并不断引入迭代变更优化。

设计

架构设计的层次化、模块化解耦。 实际开发中，前端做了 MVVM 架构设计、网络层抽象，完成了视图组件的剥离和开发；后端做了基于 RESTful 规范的 API 构造和设计，这都是对这一思想的体现。

实现

DevOps是重要的。 由于团队（尤其是后端）在自动化工具上采用了高标准和最优实践，BUG 的出现大大减少，代码统一且高质量，为平台的稳定性提供了充分保障。

测试

质量管理来源于团队整体的质量控制意识——还有一位好的 QA（几位会更有安全感！）。 对于后一点，第一部分有介绍过测试方面的实践不再赘述。对于前一点，由于单元测试的编写和开发工作是同步进行的，开发者保证每个面向用户的功能都有完善的单元测试，并从尽可能多地覆盖使用场景出发设计测试，最终我们的单元测试覆盖率达到了92%，基本实现了全覆盖。正是由于所有成员的质量控制意识都稳定在线，我们的项目才得以保证足够的健壮性。

发布

推广发布应当提前布局、持续跟进。 在 ALPHA 阶段，从项目调研阶段开始，团队成员就提早布局，与熟识的潜在用户——实验室导师及内推学长学姐们沟通，了解他们发布实习信息、招生、招聘工作的各个环节和需求；在项目发布阶段则进一步与意向入驻的需求发布者沟通，邀请他们体验求职者侧的使用流程，解说平台定制的需求发布、求职者申请和信息反馈机制。团队亦立足学生（求职者）对暑期实习的迫切需求，通过朋友圈、学生群聊等方式精确触达产品信息。BETA 阶段，团队一方面持续跟进，对接之前沟通过的老师、学长等，帮助他们使用本平台进行需求信息的发布；另一方面继续维护既有的求职者用户社群，借由团队的持续宣发和用户的自行推广，在面对不可抗力因素的状况下，仍然获得了用户量的增加。

维护

应当由专门人员（或团队）进行产品维护。 团队内在 DevOps 方面有较深刻理解的一名成员担任“管家”，从工作流的角度出发参与考量开发规范。他负责处理 CI/CD 等自动化工具，解决硬件设备选型、服务器部署和服务上线的具体问题，完成服务器运维和数据分析与监控的相关工作，帮助产品持续平稳运行。产品维护需求相关人员对产品的功能设计、架构实现都具有足够的了解，并且需要较大的精力投入以保持操作的一致性。无论是专人维护，还是组建专门维护团队的场合，持续维护操作日志及部署文档等都是必要的。

《格》

所谓格物致知，回顾和分析本学期的软件工程课程实践，每个阶段都为我带来了相当的收获。

软件案例分析让我按照给定的指引，对现有软件产品进行成体系分析，并进行模拟规划体验，从而对软件工程有了初步的认识。结对编程让我通过实践学习结对编程的有关知识，了解了最小的合作场景——二人合作的方法，以在接下来的团队开发中进一步推广到多人的场合。

团队开发过程中遇到了非常优秀的各位队友，并作为 PM 完成了一次难得的产品开发实践。团队的所有人共进退，共同面对挑战、克服困难、消解疑虑、各尽所能。在 ALPHA 阶段，我们曾在初夏的阳光下兴奋地讨论产品，也曾在深夜的新主楼 G 座里一人一台电脑啃着麦当当奋战到天明。在 BETA 阶段，即便分隔在四海八荒，仍然能并力做有效的工作。十分庆幸，团队的七个人能走到一起，不只是完成一门课，更是完成一款雄心勃勃的产品，为用户带来真正的好的改变，留下一段虽可能仍有缺憾但绝对足以笑出来的回忆。我本人也从这段经历中对软件工程的各个方面有了更深刻的认识，受益匪浅。

站在课程的终点，我相信——

我正站在漫长开发与创造旅途的起点，我正满怀信心。