「BUAA SE Individual Work3」提问回顾与个人总结
Part 1 前言
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2023年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人作业-提问回顾与个人总结 |
| 我们在这个课程的目标是 | 熟悉结对编程的方法论，并通过实际开发实现最长英语单词链这一产品进行实践。 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过在最长英语单词链这一应用中实践结对编程的方法论。 |
- 教学班级 ： 周四班
- 提问博客地址：「BUAA SE Individual Work1」阅读和提问
Part 2 对自己曾经提出的问题进行解答
问题1：根据软件的不同、团队规模的不同以及团队成员的不同，最合适的团队模式肯定有所区别。那么在一个团队刚成立的时候，该如何快速先行选择一个团队模式开展工作，且这个模式虽然未必最佳但是至少是次最佳？
在本学期的软工团队项目中，我通过实践和讨论找到了这个问题的一个解决方案。
具体地，在项目开始前，我和一些选过本门课程的学长学姐沟通讨论，了解他们的团队合作方案，其中对我帮助最大的是去年的无际软工队，是我们团队合作学习的榜样。
另外，我们还进行了团队内的讨论，了解彼此的擅长和不擅长的工作，尽可能发挥各自的长处，这也让我们的团队合作模式具有特色。具体地，我们由1PM+4前端+2后端组成，我作为PM主要负责进度协调、文档管理、运行维护、博客撰写等工作，前端和后端以常见的模式分工。这带来了巨大的好处，也就是我们基本保证了每位成员都在做其擅长且较愿意做的工作。
当然，这个过程也不是一成不变的。在项目推进中，我们也根据实际情况逐步调整了合作模式与具体分工，更好地适应了变化。
问题2：如何合适地分而治之？
在团队项目中，我通过实践找到了这个问题的一个解决方案。
我作为PM，确实没有对前后端所有技术都精通，但是得益于过去的项目经验，我对前后端的技术和工作都有一定把握。在这个基础上，我们主要采用团队敲定项目内容和实现方案后，由开发人员具体来进行时间安排和进度规划，PM主要进行协调以及判断是否可行，是否留有了充分的时间缓冲等。
问题3：如何推行高效工作工具如源代码管理工具Git等？
在本学期，我通过实践和讨论解决了这个问题。
首先，在项目开始前，我和 @TA熊 深入讨论了推广团队合作工具的问题：讨论：关于团队的技术栈和项目管理工具选择，这一富有成效的讨论得到了一个初步解决方案：结合工具的特点、人的特点、过去工作/项目的经验，尝试设想【真实的场景和需求】，而非被创造的需求。具体地，我们采用了如下方案：
- 代码托管平台：GitHub
- 部署：GitHub Actions + 云服务器（可能选择腾讯云等提供商，已经有过成功案例）
- 即时通讯：微信+腾讯会议（进行碎片化的、快速的沟通）
- 【待确定】文档管理（公共知识库）：notion /飞书（工作场景包括数据统计、协作编辑、信息组织、公共作业完成、开发规范、任务分配、进度（看板）管理等）
可以注意到，上述工具链中有不少“老熟人”，其中的GitHub、腾讯云、微信、腾讯会议都是大家日常生活中就常用的生产力工具，唯一的新面孔是notion，而其支持markdown语法的特性也大大平缓了大家的学习曲线。
在实践中，我们通过上述方案快速搭建起了一套行之有效、易于上手的工具链，真正做到了让团队不沉迷于工具的选择层面，而更专注于业务本身。
问题4：对于渐进发布的产品，如何使用合适的工具或解决方案以实现最佳DevOps？
我通过实践搞清楚了这件事。
在本学期软工之前，我就对DevOps、Docker、CI/CD等工具有所耳闻，但是只停留在听说过的程度，对其长什么样，如何使用，有什么效果还是整体比较模糊的。在本学期的团队项目实践过程中，我大量调研了GitHub Actions、CI/CD、Docker、DockerHub等工具，最终确定并实践了我们的解决方案，搭建了行之有效的DevOps工具链，真正做到了持续部署持续交付。同时，在本学期我还进行了一次Talk，主题就是CI/CD，向大家介绍我们的工作经验，取得了良好的反响。
问题5：如何用科学的方法或者技术辅助提高领导力进而快速带领团队成长？
我通过实践弄清楚了这件事。
对于软工团队项目这样规模的组织，既需要有个人魅力和领导能力的PM，也需要精简高效的组织架构和规则，两条腿走路才能不偏废。
具体地，本学期中我们在初期即确定了奖励和惩罚规则，规则的数量不多，但是为大家划定了清晰的要求，大家也都在本学期中充分遵守了这些规则，一套简洁有效的组织架构就此诞生；另外，我作为PM也较有责任心和规划意识，对关键的时间节点和应有的进度有清晰的把握，我相信这也给成员们带来了安心和踏实，也让我们有信心应对可能发生的突发情况。
总的来说，本学期初提的五个问题都已经得到了良好的解决，至少找到了一个不错的切实可行的解决方案，这也让我更加深刻意识到了软件工程是一门实践的科学。
Part 3 在项目的需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”
需求
主要的设计和架构比较清晰，但是对于用户的使用需求的把握仍有进步空间。如果可以重来的话，我们会进行更完善的用户调研，对各项工作的优先级进行更细致的划分；在用户使用方面，我们发现出现了明显的倾斜，如学生们对物理答疑的需求较大，但是物理的辅导师人数却相对较少，且回答热情不高，这是本软件之外的问题，但是也应作为现状和用户需求的一部分纳入考虑，如进行更广泛的宣传动员、实施更行之有效的奖励激励政策。
设计
设计部分，我学到了使用EoLink等现代工具辅助可以达到事半功倍的效果。在ER图绘制中，需要反复磋商讨论确定前后端的对接方案，但是即使如此，在实践过程中仍可能需要将进行一些调整，需要让每一个团队成员都清楚地了解设计的变更。
实现
在实现过程中，我充分意识到了官方文档、GitHub、StackOverflows等工具的重要性，不能只依赖中文资料。具体地，在实现一个向窗口发送 ctrl + C 命令时，在中文互联网查了很多，但没有得到有效的解决方案，而一旦切换到英文搜索，就在StackOverflows找到了答案。
测试
充分的测试必不可少。在Alpha阶段的第一个内测版本中，我们进行了部分测试即上线，立刻收获了内测用户的大量问题反馈，这充分说明当时我们的测试不够充分和全面。而在Beta公测前，我们就在测试服进行了较全面充分的测试，最终上线时也顶住了压力，没有出严重的问题。
发布
软件的发布需要团队成员一起确认，以防止开发分支存在已知的重要问题上线到生产环境产生问题。数据库的迁移也十分重要，如表的新建与更新等，需要可向前兼容地合并到生产环境。
可靠性和鲁棒性是十分重要的，一些花哨的功能实现的不好或者没有实现影响不大，而核心功能不能出任何问题，向前兼容也是必须要实现的功能。
维护
CI/CD是非常行之有效的运维工具链，本学期我通过GitHub Actions、Docker等工具充分实现了持续部署和持续交付，实现了复杂动作的自动化，提升了项目的可维护性。
Part 4 理解与心得
在个人项目中，我对代码托管平台进行了较为充分的调研，让我从用户转变到开发者的角度近距离观察了这一和我们工作生活关系紧密的工具，让我对软件有了更深刻的理解。
在结对编程和团队项目中，我都非常幸运拥有非常棒的队友，他们强大、可靠、善于沟通，我们一起完成了非常有影响力的工作，没有他们的帮助，也没有这个学期产出的优秀项目；在这之中，我也大大锻炼了自己的合作能力，提高了沟通能力和技巧，为以后的团队合作奠定了基础。
This is copyright.