朝花夕拾，温故知新——提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 学习软件开发的工程化方法，第一视角体会结对编程、团队协作的软件开发流程 |
| 这个作业在哪个具体方面帮助我实现目标 | 对本学期软工课程进行总结和回顾，回答学期初自己提出的问题，从实践中收获理论 |
| 个人博客 | 提问博客连接 |
提问解答
问题一：为什么要在大学软件工程课上专门实践敏捷开发？
作为一名学生，我从没实践过任何一种软件工程方法论，相信大部分同学也是这样。那么课程组在一门必修课上选择敏捷开发是有什么缘由吗？
这个问题可能需要课程组回答，但是在这里我给出自己的理解。敏捷已成为当今互联网的一大特征之一，互联网市场、用户需求都在快速变化，敏捷开发能指导我们在快速更新迭代自己产品的同时能够尽可能保证软件开发质量，让团队中的所有人职责明确且发挥最大效率。另外，我个人认为我在敏捷软工中的锻炼让我受益颇多。
这学期的软工实践让我体会到敏捷开发鲜明的特点：
- 适应性
- 在团队项目的过程中，我遇到了开发软件的难处——开发过程的不可预测性。在我们的开发过程中，首先需求是不确定的，我们从软件使用者转变为软件开发者，因此思考的角度也需要转变，我们要站在用户的角度思考软件的功能；课程组会对我们的进展提出意见和建议，这有时使得我们做出一些改变，例如助教指出我们的issue划分粒度太粗，指出我们的例会记录形式的不合理之处，指出我们的燃尽图曲线的不合理指出等等；另外，我们可能会遇到实现与设计无法匹配的情况，这也要求我们尽快做出调整。
- 得益于敏捷开发，我们能“敏捷”的适应变化，因为这些问题都能在下一次的例会上得到“敏捷”的解决。
- 充分发挥人的能力
- 敏捷开发使得项目团队全员参与到软件开发中，无论是PM还是DEV。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队成员的沟通，任何问题的解决都建立在充分的沟通的基础上。这要求项目成员需要全身心投入开发，充分发挥自己的创造、沟通能力。
问题二：敏捷开发的同步应该怎么管理？
敏捷开发之下，一个项目会被划分成具有一定依赖关系的需求/任务，那么具有依赖关系的两个任务的负责人肯定需要同步，但是，每个人都会有自己认领的多个任务，而且对自己认领的所有任务全面负责，同步关系也是纷繁复杂。
我们试想这样一种情况：AI 完成了一项任务，等待与 BB 同步，但是 BB 的进度落后，AI 和 BB 两部分与另一边的工作也需要尽快同步了，但是，AI 负责的别的任务还在做，另一边的 CC 等着同步，那么 AI 是选择帮 BB ？还是选择自己的另一项任务？又或者说，这个决定是由整个团队来决定？
这个问题在我看来，首先需要明确敏捷的目标——完成最小可行性产品，再通过多轮迭代进行完善。明确了这个目标，那么我们能得到开发过程的关键路径，理性而言，如果某项任务停滞，而它恰好在关键路径上，那我们必须把它的优先级抬高，降低影响。当然，前面提到敏捷软工适应能力很强，能够快速变化，AI的决定牵扯到许多人，那么我认为他需要在下一次例会上提出这个问题，无论他选择如何，都应该制定迎合这个选择的团队计划。
问题三：敏捷开发究竟敏捷在哪？
我的疑惑在于，冲刺阶段竟然有每日例会，每个人都需要准备这个会议，进度报告、制作图表，这难道不浪费时间？还是说这是必要的牺牲？
能不能少开会，大家约定俗成，反正有看板制度，这样责任明确，任务也可追溯？
要回答这个问题，我认为必须明确每日例会的作用。结合我这学期的16次例会，我认为例会的作用：
如果没有例会，“约定俗成”很难真正实现，平常自己一个人开发的时候，总会有别的事情打乱节奏，大部分情况会导致推进软工项目的优先级一降再降；而如果有例会，那么就相当于设置了一系列短期KPI，在例会上，我们需要汇报自己的工作以及领取下一阶段的任务，如此这般，谁在拖慢团队节奏将会一目了然，其次，例会要求全员参与，这样方便大家对接工作，讨论并解决开发过程中遇到的问题，有时还需要讨论并修改原先的设计，紧凑的例会往往会带来高效的工作。
问题四：如果一个团队长期担任 PM 的人离职了，团队和新 PM 如何应对？
此问题出自第九章《项目经理》
本章着重介绍了什么是 PM 、 PM 的作用、以及怎样算是一个好的 PM 。我最大的感受是，团队不能没有一个好的 PM ，PM 相当于一个GPS 导航，粘合剂，风险预警装置，除了开发和测试，剩下的“脏活累活”都是 PM 负责的，可见 PM 的重要性。
基于本章以及自己的经验考虑，程序员和 PM 是平等的，需要靠长期的磨合来和平相处，如果在某个项目的开发过程中，原来和大家共事愉快、得到支持、得到尊重、积极影响团队的 PM 离职了，我想会团队以及新 PM 都会面临不小的挑战。那么我们应该怎么应对？
本次团队项目换人阶段，我们组的PM-QSY同学认为自己参与软件本身开发较少，因此主动申请交换，回想起QSY同学所承担的工作，我想PM离职这件事情还是需要谨慎处理的。QSY同学负责主持会议，协调工作，把握进展，宣发，前端设计等多方面工作。我认为，新PM到来，需要首先进行一次团建，目的在于让新PM快速融入团队，快速打破不熟悉带来的隔阂；然后大家在新团队第一次例会上列出所有任务以及对应的天数，说明人力资源情况，确定验收时间点等，以便PM了解情况并评估进展以及开展下一步的规划。
问题五：业余剧团模式“中央指挥”需要怎么选择？
问题六：“中央指挥”面对不同的人希望选择同一个角色的情况该怎么处理？意愿优先还是能力优先?
业余剧团模式 (Amateur Theater Team):
这样的团队在每一个项目（剧目）中, 不同的人会挑选不同的角色。在下一个剧目中, 这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中, 这样的事情经常发生。
- 这个“中央指挥”需要怎么选择？
- 泛化而谈，也就是一个 Team 的 leader 怎么选？
- 进一步， leader 的职责范围一般是如何的？
- leader 指导安排太过是否会变成主治医师模式或者明星模式
- “中央指挥”面对不同的人希望选择同一个角色的情况该怎么处理？意愿优先还是能力优先?
- 意愿和能力如何平衡？
中央指挥——PM，alpha、beta，虽然负责前端还是后端不会变，但是每个人需要面对的都是全新的工作。我们给出的答案是“工作经验”也即是否开发过类似的功能优先和能力优先（PM也是如此选的，QSY毛遂自荐，综合日常印象，我们认为QSY同学有能力担任）。意愿往往需要服务于团队，如此才能齐头并进，快速开展相关工作。（事实证明，QSY同学在确定产品功能、接受或拒绝开发团队的工作成果、细化工作、决定发布的日期和发布内容、bug修复等等过程中达到了合格PM的标准）
新问题
问题一
敏捷开发是要一直敏捷下去吗？或者说是否到一定程度就不需要敏捷了？
问题二
beta之后，我们预期的大部分功能已经完成了，对于产品的维护或者进一步的拓展还需要敏捷吗？
知识点
需求阶段
- NABCD
- 确定需求需要经过完整的需求调研、用户分析
- 在团队项目-初次邂逅，需求分析作业中，我们起初对于“题士”项目需要实现哪些功能进行了充分的讨论，确定了如支持不同模式下的题目训练（如顺序、按章节、随机出题）、题目推荐、快速做题、关键词搜索、题目收藏、错题收集、题目笔记、题目评论、问答社区、资源共享社区、在线问答pk、做题排行榜、倒计时设置（考试时间倒计时等）等等功能。但是我们很快意识到这样的需求分析确定出来的结果仅仅只是我们意向出来的用户想要的，我们需要真正倾听用户的声音。因此，我们决定采用线上问卷调查的方式收集用户对于一款面向学生考试刷题、学习交流等目的的刷题软件的需求，问卷问题就是针对我们讨论出来的功能进行打分，分值为1-7，功能重要程度逐渐递增。另外，为了保证收集的问卷的有效性，我们将问卷投放到目标用户群体所在的微信群/QQ群，并且进行了一定的宣发措施，这样，我们在需求评审答辩前收集到了202份有效反馈。具体的结果在题士需求分析博客，这篇博客指导了我们接下来需要开发的功能，意义重大。
- 另外，我们对于“题士”所支持的平台也进行了讨论，初步确定希望做移动端，这样使用起来更加方便快捷。我们一致认为不做web端，主打移动端，但是由于IOS端审核较为严苛，因此为了不放弃IOS端的用户，我们决定同时开发微信小程序。
设计阶段
-
前期设计只能做到尽可能完备，后期往往会出现对前期设计的不理解、质疑甚至是反对，这时候需要尽快解决，有时牵扯到其他组员的开发还需要及时沟通讨论
- 在“题士”beta开发阶段，除了航概，我们需要支持更多课程，例如计算机导论和经管。但是这样面临一个问题，就是切换课程，准确来说，本质上是切换数据。前期设计考虑的比较简单，只需要把题目进行切换就行，因此在数据库中把题目和课程进行关联即可。但是实际上，后期开发资源社区、问题社区、考期日历和知识卡片等功能时，我们意识到可能也需要涉及数据的切换，最后，我们认为用户切换课程后，应该想要寻找针对这个课程的资源、讨论贴和知识卡片，因此这三个功能需要进行数据切换，因此在数据库层面也需要和课程进行关联，需要修改数据库和接口API，而对于考期日历，我们认为无论用户是否切换课程，所有的考期日历都应该进行展示，以防用户遗漏。
实现阶段
- 实现阶段不注意代码风格以及基本测试，后期测试和维护大概率面临很多问题
- 在alpha阶段，我需要实现错题推荐以及模拟考试功能，这两个功能一次需要查询多次数据库，且数据量较大，实现阶段想着怎么简单怎么来，结果在测试阶段的压力测试过程中发现这两个接口延迟达到几秒，而且无法承受高并发，之后经过查阅，我发现我没有理解nodejs的异步特性，循环执行sql语句，每一次循环都会await，实际上根本没有利用异步编程，经过一段时间的学习，我利用Promise将互不相关的sql查询一起请求，查询结果异步到达，优化后的接口延迟降低为几百毫秒。
测试阶段
- 与用户输入相关的代码往往很容易出错，因为我们无法预知用户的行为。
- 团队项目的实践过程中，我们自以为经过了充分的测试，大家都误以为什么问题都没有，但实际上bug往往在不经意间就冒了出来。举个例子，alpha阶段临发布的时候，我使用自己的微信账号登录我们的“题士”小程序，但是发现我怎么都登不上去，就算登上去了，个人信息也不对，还经常请求错误，但是这个问题我的其他组员都没有遇到，所以大家也都没有特别在意，最后才发现原来是我的微信名称存在单引号，这导致解析的时候出现问题，简单处理后很快得到解决。这样的问题在beta阶段也遇到了，助教使用自己的微信登录，发现也登录不上，我看到助教的微信名称带有emoji，立马就意识到需要把数据库的编码改为utf8-mb4以支持emoji的存储，否则我们的讨论区、评论区啥的也将被emoji攻陷。
发布阶段
- 宣发很重要，同时要关注竞品的动向。
维护阶段
- 维护阶段往往会面临很多用户意见，bug要修，但是一些涉及用户体验的地方不一定要improve，因为说白了用户体验这个东西主观性很大，只有那些严重影响大量用户使用的才需要尽快解决。
个人项目
初入本课程，上来就是一篇热身阅读作业，在这次作业，我回顾了自接触计算机以来自己的心路历程，有对大学生活的吐槽，也有对自己个人学习的总结，最后让我重新思考了未来的发展。
紧接着是个人阅读作业#2，在本次作业，我阅读了《构建之法》，了解软件工程需要考虑的方面，并且学习了提问的艺术，另外，我还学习如何使用CI/CD工具。课程前期对于软工还是有许多问题的，但是现在，经过长达半学期的软工实践之后，我认为我对于软工的已有初步的了解。软件工程是一门研究用工程化方法构建和维护有效、实用和高质量的软件的学科，软工突出工程化、高质量，这在我们的实践中也是重中之重，工程化体现在敏捷开发流程的实践、各种文档的书写，高质量体现在CICD的部署、充分的测试以及维护。
然后是案例分析作业，这是我第一次系统性的分析对比市场上同一领域的软件，了解软件评测基本方法。印象深刻的是找bug的环节，解锁各种使用软件的新姿势， 角色扮演了一位进入酒馆点炒饭的顾客。
结对编程
得益于强力的队友my，我在结对编程期间充当“领航员”的体验一直都很不错。在实践过程中，队友身上有许多我值得学习的地方，比如严格控制每个方法的复杂度，若出现无法避免的高复杂度方法，则应立即进行覆盖性单元测试，比如良好的记录习惯，由于结对项目的工作量并不小，有时候初步完成编码，但面临许多有待商榷的地方，这时候我们有两种方式进行记录：1. 注释和TODO代码块；2. 项目issue区记录，比如通过基础测试后，队友总是想方设法构造极端样例与其他组对拍，并利用性能分析工具查看压力测试下的鲁棒性。另外，每次博客我们都会记录结对过程每个阶段所耗费的时间，有时可能会暴露出问题，这些问题会在下一次结对得到解决。总而言之，结对编程的实践使我受益匪浅，有许多收获值得我铭记。
团队项目
团队项目给我带来的体验大多是从未有过的，首先就是队伍人数是以往课程组队从未达到的，这使得我们面临的挑战也并不是一个量级的；其次，很庆幸自己能够遇到一群优秀的队友，一起开发出“题士”这款至少我很满意的软件，在每个人不遗余力的努力下，我们顺利完成“题士”的Alpha阶段和Beta阶段，整个过程较为顺利，体验尚佳。
我在项目中负责一部分后端开发和测试的工作，虽然之前数据库课程实践的也是后端，但是，这次的项目的复杂度和灵活性要远远大于以前的项目，因此在设计、实现和维护上遇到了不少棘手的问题，但寻求了队友以及网络的帮助后都顺利的解决了这些问题。
总的来说，团队项目让我痛并快乐着，从设计阶段所有人几乎每周都要肝文档到凌晨两三点，到冲刺阶段每两天一次例会，甚至五一小长假连肝三天，再到发布阶段QSY带我们一起做宣发以及接受评审……我们团队一路走来，一步步实践着敏捷软工，让我直到结束还意犹未尽。
最后，感谢删库跑路对不队全体成员的辛苦付出！感谢课程组以及同僚们对我们项目的所有评测与建议！
