微信款款说软工——听取蛙声一片【HansBug与WPB同学*于2021.4.14凌晨的对话】
前情提要
HansBug视角：
课程是2021年北京航空航天大学计算机学院本科敏捷软工课程，大三下学期开课，同时有另外两个并行课程可供选择（我们这边是软件工程三选一，分别是敏捷软工、嵌入式软工和AI软工）。在本年度的课程中，之前的结对部分进行了一定程度上的改革，虽然略有问题但是还算是圆满结束。事情发生在简要需求分析部分，由于之前的一些安排失误以及需要邀请业界人士和大众评审团，故需求部分的答辩安排在了周三上午（2021-4-14）。在周二晚上（2021-4-13），助教们对各组的成果进行审核的时候，发现部分组的内容过于简略，且近期助教工作压力也很大，故在学生群中用语略微激烈地对学生表述了意见，由此在学生群体中引发较大争议。本段对话即在事情发生后，联系到了一向相对客观中立的WPB同学，与之进行的一段深刻且有价值的意见交换。
谜语人队视角：
在摆脱了痛苦的结对阶段后，我们迎来了我们对软件工程这门课程的主要预期阶段——团队阶段。在周六（2021-4-10）发布团队选题后，我们玩了一个黄金点游戏，并于当天晚上22:25确定了选题优先级，此时我们优先级为4号，因此放弃了之前商议的航概题库选题，转为自选题目。我们决定在周日（2021-4-11）这个大家都有空的时间进行讨论，确定选题。当天16:58，发布了团队项目需求分析，该作业显然是需要在讨论出选题之后才能进行。因此我们紧锣密鼓地讨论了自选题目后交给HansBug进行审核。被否两次后，被通知自选题目具有较高门槛，因此我们在周一（2021-4-12）再次讨论选题，最终选定了数据集管理和可视化这个给定选题，并于周二（2021-4-13）凌晨得到了该选题可行的回复。由于当天有四位同学需要进行计网实验，因此我们非常紧迫地完成了两个需提交的作业，并于完成后不久看到了一条令人感到不快的消息。在水群中发泄了自己的情绪后，我们认为需要对课程组进行反馈，此时恰好HansBug向WPB发送消息想要调查相关事件，因此我们决定通过这个方式进行反馈。
当事消息
@所有人
紧急通知：助教团正在提前查阅并审核各团队的博客作业，发现部分团队存在一些较严重问题，比如：没有视频链接，没有说明发布平台及预计用户量等一些作业要求中明确规定的要点。这些内容都需要提前给旁听人士，学弟学妹，助教老师查阅观看，质量过低影响的不仅是单个团队，
严重影响班级博客整体质量，严重带坏作业提交敷衍风气，严重耽搁助教提前准备工作。因此请各团队再次审核团队作业博客，尽快将作业要求中要求的全部内容完成，若继续不合作业要求并给课程组增加负担，将会承受贵团队应受的惩罚。
及时完成！及时完成！及时完成！（视频
聊天记录
- 注：为了阅读的流畅性，我们整合了一部分聊天记录，修改了一部分聊天记录的说法和格式，并人为地进行了分段且概括了主要内容，原文在此：https://shimo.im/docs/cQ3GKqxtwCpxQtVD 。
同学们情绪的直接原因和深层原因，课程组和我们对软件工程课程的理解不同
HansBug：老哥，问个问题啊，你觉得这波因何而起？直接原因和深层原因都谈谈呗。
WPB：我感觉直接原因就是时间太紧了，大家压力都比较大，导火索就是那个通知。
WPB：我感觉深层原因是我对软工的理解和老师对软工的理解不太相同。
WPB：我在组长群里问能不能选难度高，但创新度低的项目作为选题，就是想跳过找点子，找用户这些。
WPB：我理解的软件工程，是客户提出需求，我们探索客户需求，重点放在大规模代码的管理上。
WPB：但是现在感觉是，我们要提出一个点子，去市场调研，创新，推广，这部分工作量比较大。
WPB：我来罗杰老师班上的原因是：1.和队友做点东西；2.学一下互联网公司的前后端技术，为未来工作积累经验。
HansBug：可以理解你们的这一看法
WPB：核心是我是技术导向，现在有点像产品导向
HansBug：我们对自选题的定位，是让一些特别有点子的组，在有大把握的情况下，搞大事情；而不是让人人都去从零开始整，我们想的是对于能力不够，或者如你所言这样想的组，选个给定的题目，或者干脆继承项目，搞一下也行啊
WPB：我们是这么想的：给定的选题里，2应该是个非常标准的互联网项目吧，8个组我觉至少有4个想选，前后端，高并发，各种技术都能学
WPB：剩下的题目里：1. 我们不想做AI；3.用户推广难，做AI的人不会写代码可视化感觉有点很怪；4. 感觉全是前端；
WPB：继承项目，要么想不出来创新，要么创新难度不可控：1. vlab，我们想加协同，但是他用了成熟的前端编辑器，我们不太可能改；2. 知识路书，看不出来有啥用，更别提创新；3. 表情包制作：怀疑是怎么进入选题里的，同类软件满天飞；4. visualpytorch：感觉直接是把nn.sequential做了个gui，感觉没啥意义
课程组和我们对自选题的理解不同
HansBug：我明白，不够你们其实搞偏了一件事，既然我让你们继承，选择现有题目，那就意味着我们知道其中深浅，同时也意味着本来你们就不太可能出乎我们意料
HansBug：而自选题，最怕的是一群人都来搞个大一学生那样的图书管理系统，那就真的...[衰]。所以自选题，必须会让你们讲出个所以然来
HansBug：
团队软件工程的总体目标：
- 研发出符合用户需求的软件说明：要通过实际的工作收集、推导、提炼需求，并在软件发布后通过实际数据验证需求的确被满足了。需求来自于实际，而不是自己想象出来的“需求”或者人云亦云的需求（例如：图书馆管理系统）。
- 通过一定的软件流程，在预计的时间内发布“足够好”的软件说明：这个软件不是期末前两天由两三个同学熬通宵赶出来的急就章，而是经历了一定的软件流程，通过全体团队成员的努力，在一个学期内逐步完成的。
- 并通过数据和其他方式展现所开发的软件是可以维护和继续发展的说明：例如，对用户需求有详细的分析，包括对将来这类软件发展的趋势的分析。主要功能都有设计文档，源代码完整，有修改记录，并有最后版本。关键模块有可以执行的单元测试、压力测试脚本，等等。对于已知的bug和将来的工作都有详细的记录。
HansBug：软工某种意义上和OO是一个类型的，思想和思维才是上品
WPB：这就是我们对软件工程理解的偏差了，我们希望关注技术，你们希望关注产品
HansBug：大概清楚了。那今天的问题可以说是因那个通知而起？
WPB：1. 思维和产品点子很重要，时间不够：2. 一开始我们不知道会有说传承和定题要求会低
WPB：通知只能说是导火索，引爆情绪而已。时间不够，大家好不容易赶完，然后来了一个有点厉声质问怎么还没尽善尽美的感觉
WPB：软工，我只能表达下我们一小部分人(不大于5个)的想法，用一定的甚至较多的技术，去做一个经典的题目，加入一点点自己的私货获得点成就感
HansBug：诶，我大概清楚意思了，这波我们确实没表达清楚，我还奇怪为啥这届人都一个一个去自选题呢，以前自选的组并不多
HansBug：我当时其实，以为不少组早在酝酿大事情了，那会发问卷，你们几乎都没选题想法的时候，我挺意外的，自选本来就不是让你们三天搞定一切的，而是对于早就想搞事情苦于没机会的组（或者已经在搞事情且不想搞两份的），一个不被栓死的机会
WPB：大家没想到这点，你们也没提前说；而且到头来天降ddl，然后突然还来厉声要求，就导火索了
HansBug：确实，我们的问题，一些准备做的并不全乎，而且新改革，很多事情也没想到，发现不对劲了才能采取行动（比如群里补充一波，小心社区类项目，这样的）
反馈说明课程组的部分失误由同学们承担后果，需要补正机制
WPB：所以，我认为的问题就是，课程组做的准备不够充分，然后信息上也有误差，不管怎么说，最终结果是学生实际工作量远大于想象。但是最后，学生们只有承受这个结果，可能是缺乏一个补正的机制吧。
HansBug：虽然我也认为那位助教的话很不应该，不过也看得出来这阵子助教们其实肝也快炸了；我们也很想如果可以的话，延后一些，推迟一周，这样一切都会自然非常多；不过这学期真的短，而且不方便把我们的课安排进考期，所以就很僵硬，只能硬上了
WPB：这就是一部分情绪的来源了，小白鼠实验中出现了一些问题，下次的小白鼠里当然好好注意，而且这次小白鼠也需要一些治疗一些补正啥的
HansBug：现在情况变成这样，是该有个交代，而且也得有个实惠地交代
HansBug：以及我想问下，你们组这边感觉整体是否还好？
WPB：
对课程安排，我会有怀疑。首先是这几天，确实有很多问题，后续不敢确定是不是有，这种问题经常有影响，而且我们也没怎么得到弥补。
我们有结对项目和个人作业。比起其他软工班级少的不是一星半点，时间上本来就很紧，后续安排感觉会有问题。 然后对这个题，能做，但只限于能做，我也说过，这个题我们是排除法做出来的。毕竟必修课，肯定会做下去，但投入多少热情，难
HansBug：
这么说吧，我个人理解是这样的，结对不说了，都过去了，你们也都看到了。然后团队部分，实际上个人理解，特别关键的部分就是这个选题 需求部分，这个部分搞出问题的话，一步错步步错，咱就算不题那些特别高大的命题，即便对于分数本身，一个歪了的选题也会必然有影响。我们这波本意还是“助”，帮大家指指问题，有的放矢。
然后后续部分，虽然不能说不重要，但是像现在这样处于咽喉要道的情况会少得多甚至与没有。后续的alpha beta阶段，基本还是正常的节奏，只不过今年会有更多的互动，目的也是更多了解你们的日常工作情况，多一些指导，长远来看都是为你们好（我知道很多人对这话ptsd，但是这就是掏心窝子话，我嘴笨也不知道换个什么词更好听）。WPB：
- 对过去的问题没有追责预防和补偿机制，这就是我之前觉得的的一部分情绪的来源
- 重要的部分，然后只有三天，我们相信助教的目的是好的，但是实际结果是与时间大量的工作量和没有的补正机制，最后我们就承受了这个影响
HansBug：你也提到了补正、补偿的概念，关于这部分，有啥具体的意见没
WPB：我不太确定，因为这个和你们课程组的安排非常相关，可能只有你们才能做出决定。但是我只能说确定应该要有这样一个机制，并且让大家看见
HansBug：恩，我明白你们的顾虑，我只是问下，如果可以的话，你们希望什么样的补偿机制
WPB：你看，这个还是得助教团队内部去想，我之前这个补偿机制什么的，目的是论证，不应当由学生承担后果，或者代替课程组做课程组该做的，然后包括现在这个，也有点，怎么说，让学生来做课程组要做的事的感觉了
HansBug：不，你理解错了，我只是想了解你们的意思，你们的希望，我们是帮助学生的，总得了解学生吧？对不。不过如果确实不方便给也无妨，你说的也有道理，我明白
WPB：核心就是，不应当由学生承担课程组这边导致后果，具体是补偿还是怎么做，这个我是没有想法的
HansBug：好，懂了，理解万岁
后续我们沟通了对本聊天记录可否公开以及如何公开
事后进展
在谈话进行完之后，课程组顺利地组织了这次答辩，总体来看大家还算有所收获。而在整理完对各组的问题、建议以及答辩纪要后，HansBug在学生群里进行了一段必要的回应，以下聊天记录取自“2021软件工程学生群”，日期为2021-4-15：
HansBug 11:34
各位同学，我们这边对之前需求答辩、需求汇报博客下的讨论以及课程组审阅时的问题和建议内容进行了一个整理，汇总成了一个文档提供给大家：https://www.cnblogs.com/HansBug/p/14661665.html ，希望可以帮助到各位，大家在后续的部分中对所述问题进行一些必要的优化或回应。
首先，对于2021年4月13日晚上在群里的助教通知，我们表示歉意。近期由于本学期时间偏短，以及涉及到借教室、邀请企业工程师和大众评审团等多方面原因，故时间安排较紧，助教和学生的压力都很大，出现这样的通知给同学们带来了很不好的感受，此事因我们内部工作疏忽未充分考虑到学生情绪所致，实非课程组本意，我们再次表示深深的歉意，实在是很抱歉。我们课程组一直致力于帮助学生更好的学习敏捷软件工程，助教们也将一个“助”字放在至关重要的位置上，我们会做深刻反思并引以为戒，始终做到不忘初心。
HansBug 11:35
此外，鉴于之前的情况，课程组感觉有些问题需要进行一些必要的解释。在这学期的选题设计中分为继承选题、推荐选题以及自选题三类，其中自选题我们的本意是希望已经有明确成熟点子的组（或者有已经在做的且希望在软工课上继续进行的项目的组）来进行选择，以实现让能力突出的组不必受限于继承选题和推荐选题，并更好的完成这门课程团队部分的实践学习。为了确保自选题目的学习效果，以及后续环节中可能存在的潜在困境（例如较难推广的产品、较难入手的技术栈等），以及自选题目本身的实际价值性，所以会在需求性和创新性等环节进行一定的审核。而对于继承选题和推荐选题，由于是课程组所提供，所以很大程度上要有迹可循得多，故部分要求也相对没有那么严苛。而且本次组织答辩，其首要目的是在于帮各组的项目进行一个初步的把关，而不是最终评审，邀请企业工程师和大众评审团也是为了获得更多视角下的不同意见，本意在于帮助各组，而这个阶段实际上后续依然还有持续完善的时间。然而我们在发布选题以及后续与各组沟通的环节中，没有较好的传达上述考虑，以至于造成了较为严重的误会，对于这件事情我们表示深刻检讨，并对同学们表示歉意，实在对不起。
HansBug 11:35
另外，之前跟部分同学进行了交流，发现可能部分同学对软工课的教学目标存在一定的理解偏差。在此这边引用一下《构建之法》中对团队软件工程的总体目标：
- 研发出符合用户需求的软件说明：要通过实际的工作收集、推导、提炼需求，并在软件发布后通过实际数据验证需求的确被满足了。需求来自于实际，而不是自己想象出来的“需求”或者人云亦云的需求（例如：图书馆管理系统）。
- 通过一定的软件流程，在预计的时间内发布“足够好”的软件说明：这个软件不是期末前两天由两三个同学熬通宵赶出来的急就章，而是经历了一定的软件流程，通过全体团队成员的努力，在一个学期内逐步完成的。
- 并通过数据和其他方式展现所开发的软件是可以维护和继续发展的说明：例如，对用户需求有详细的分析，包括对将来这类软件发展的趋势的分析。主要功能都有设计文档，源代码完整，有修改记录，并有最后版本。关键模块有可以执行的单元测试、压力测试脚本，等等。对于已知的bug和将来的工作都有详细的记录。
其中包含了一个产品完整的流程，从需求分析和提取，到软件技术设计，到代码实现，再到测试部署，且需要对未来可能存在的迭代留出空间。实际上软件工程课的教学目标并不只是去实现一个能run的工程代码，而是去了解体验一个完整的工作方法，并从中理解到更深层次的思想。换言之，软件工程课并不是在学习一项类似程序语言那样的具体技能，而是在学习一种思维，是一个悟道的过程，就像是OO课也并不是在学习Java一样。关于这件事情希望大家可以理解，以及如果有疑问、困惑或者建议，可以直接在群里说或者私戳助教或老师们，我们会竭诚为大家服务。
HansBug 11:35
关于后续的需求分析部分，我们为大家提供了汇总文档（地址：https://www.cnblogs.com/HansBug/p/14661665.html ），希望各位可以进一步优化需求分析等相关内容。此外，对于现有选题，我们还会保持一定的审核，这是出于教学效果的考虑还希望各位同学多多理解，因此为了接下来尽可能进展顺利，故希望各组能多多与老师或助教进行相关沟通，并不断优化以确保审核可以通过，我们会竭诚为大家服务。
最后，感谢大家的支持与理解，敬请期待接下来的部分。
助教L 11:45
未来几周内课程将参考往年的计划推进，听取去年同学们对团队项目的建议后，今年我们会提供一个每日例会报告的标准模板，并将原先每日例会报告降低频次为至少每两日汇报一次。目前课程组的计划后续安排如下，同学们如果有疑问或者建议欢迎在群里或联系任意助教指出，谢谢大家对课程的支持！
助教L 12:00
