[BUAA软工第四次]个人作业-提问回顾与个人总结

Posted 2023-04-08 刘兆薰_19373345

个人作业-提问回顾与个人总结

• “阅读和调研”文章链接
• 问题回顾 & 解答
• 所学知识点
• • • 需求
    • 设计
    • 实现
    • 测试
    • 发布
    • 维护
• 理解和心得

“阅读和调研”文章链接

[BUAA软工第一次]个人阅读作业-阅读和调研

问题回顾 & 解答

1. 在“软件工程概论”章节中有一句话：

   一个好的软件，即使功能和同类软件区别不大，但是会让人感觉到非常好用。这就是软件的“用户体验” (User Experience) 特别好。用户体验和数据结构，算法没什么关系，但是很多非常成功的软件就赢在这个方面。

   我的问题是，是否程序员也需要掌握用户体验设计的几大设计原理？我看许多互联网巨头公司都会有专门的用户体验设计师岗位，而且国外的很多名牌大学也在认知科学或者信息学系专门设置了这个专业方向。但是既然成功软件的很大一部分仰仗于其良好的用户体验，这也在无形中要求软件工程师需要掌握用户体验的设计原则。所以，为何长久以来用户体验设计师或者用户体验专业没有被软件工程师或者计算机系所代替？或者说程序员在哪些地方是必须依赖一个额外的用户体验设计师的？

   答： 从我们的开发实际情况来看，程序员了解一些用户体验设计的原则是非常必要的，尤其是对于在规模不大的公司中就职的程序员群体。当然，术业有专攻，我们不能完全指望程序员能够设计出一个使用感十分舒适的图形界面。老话说得好，隔行如隔山。就算我们作为软件工程师的设计出了自己认为不错的用户界面以及交互方式，实际做出来的其实往往远远达不到我们的预期。而这个现实和预期的差值往往需要一位经验丰富的用户体验设计师（UX Designer）弥补。我在这个学期中与一位用户体验设计师朋友谈论时他说到，UX Designer主要会在意以下几点：

   1. 设计思路：是否展示了完整的设计过程和思路？设计过程中是否充分运用了各种设计方式？是否有针对每个项目应用最合理的流程和工具？
   2. 以用户为中心的设计理念：是否有尽自己所能去了解目标用户？在设计过程中是否考虑到了不同用户的需求？设计的核心是不是为了解决实际问题？是否会操作用户测试、以及合理地根据用户反馈修改设计？
   3. 视觉功底：是否能熟练运用色彩、排版、字体？是否能正确应用各平台的设计规范？
   4. 创新能力：是否能突破框架尝试与众不同的方案？是否能在新奇的交互模式与可用性之间权衡？

   我们不难发现，这些知识往往是软件工程师不具备的。所以，在一个团队中，我们不能完全指望前端工程师可以提供出一个很好的界面以及交互设计方案，因为程序员群体普遍缺乏相关方面的训练。一个软件的成功，良好的用户体验是不可缺少的，故此UX Designer和软件工程师的良好合作也是不可缺少的。

2. 在“技能的反面——魔方与模仿”章节中，作者以这样的话做结语：

   那怎么才能考察出一个人“精通”魔方呢? 我想了这样一个办法:

   a) 给面试者一个各面打乱颜色的魔方

   b) 要求他把六面还原

   c) 如果还原了, 要求他把魔方恢复成我最初给他那个混乱的局面, 必须一模一样。

   我没有完全理解作者以这段话做结的意图。作者是想告诉我们必须有逆向思维吗？但是程序的逆向思维是什么呢？是编写完一个项目之后可以给别人讲出从最后一句到第一句是什么意思吗？但是这样做的意义似乎是不明确的。我不了解魔方，我认为将还原的魔方返回到最初的混乱状态是一个比较不可回溯的过程，然而程序的每一行都是清晰且可以回看的。这样的结语似乎第一无法说明任何问题，第二和前文重笔墨探讨的项目抄袭几乎没有关系，在我看来比较莫名其妙。不知道作者的真正意图是？

   答： 我在这次的开发过程中我体会到作者说魔方这个例子的用意其实没有那么晦涩深奥，其实是一个所有软件工程师都应该具备的一种复盘能力。我们在两次阶段开发项目展示时，都会遇到老师或者同学对我们进行提问，而为了回答好这种问题，我们往往需要回到程序开发的最起点，从架构设计开始说起一直到成品实现，这样才能让提问者对我们的产品有一个更加完整的认知。而这个在开发结束后回过头去说架构设计的行为其实就是“魔方”例子中说的还原成六个面之后再恢复到最初的混乱局面。

3. 在“两人合作要会做汉堡包”章节中有一句话：

   有一个说法, 创业家在创业初期必须要说服三个F: Family, Friend, and a Fool. 如果Family 和 Friend 都没人支持你的想法, 第三个F 估计也帮不了带大的忙。

   前两个F好理解，但是我们为什么要给一个Fool解释我们的计划并且要期待来自Fool的任何评论呢？既然我们已经知道对方是Fool，那么他的意见的建设性是不大的。我认为第三个F应该是Folks。Folks可以指普通人，即软件的普通用户。这部分人往往占据了一个软件大部分的适用群体，所以他们对于一款未发布产品期待与否才应该是软件团队关心的重点，因为这直接影响销量。
   答： 我们在此次敏捷开发的用户调研阶段发现，其实许多使用者甚至软件的投资者都是第三类人，即Fool群体。他们不具备或者不需要具备相关软件开发知识，也不需要关心软件团队具体的开发过程。一个软件工程团队获得的投资往往来自Fools，所以向他们解释清楚自己软件的杀手级功能是很关键的。然而，在这之前，正如书中所说，我们需要先获得Family和Friend的绝对支持，不然想要获得Fool的支持是很不稳妥的。

4. 在“用户调研”章节中提到了两个方法：

   深入面谈 和 用户调查问卷

   史蒂夫·乔布斯曾在苹果公司开发的iTunes饱受诟病时公开表示苹果公司永远不做市场调研，因为用户不知道自己想要什么。他们只会在你把新东西放在他们面前的时候他们才会说，哇，这才是我想要的！(“People don’t know what they want until you show it to them. That’s why I never rely on market research.”)

   我认为乔布斯的观点是正确的。用户除了一些基本需求（比如微信的云同步消息记录）希望软件公司做出改进，其实是根本无法作出太具有建设性和突破性的意见的。然后，软件的开发者也一定是使用者，我们知道一个好的软件需要做到什么，甚至比用户更加清楚和专业。我不否认需要在产品开发前细致入微地设计项目，但是我认为和用户深入面谈或者回收其调查问卷是几乎无意义的。
   答： 在经历了两个阶段的用户调查和开发之后我依然认为，对于普通软件的开发（不考虑专业软件，比如军工类软件和专业设计类软件），用户调查效率非常低下，因为用户其实自己对“好”也没有非常明确的定义，只有我们把产品放出来，用户才会有“这个好”或者“这个不好”的想法。我们这次做的这个计划软件就是典型的普通软件。但是，对于专业软件，用户沟通是必要的，因为软件工程师不具备相关专业知识，几乎一切设计都要根据专业用户来确定。

5. 在“开发阶段的日常管理”章节中有这样一段话：

   如果你是写一个商业项目，请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得 “写” 程序才是对项目有贡献，有时不写也有很好的贡献。如果他们有热情，就从测试开始学习吧。

   作者说一个从来没有接触过某们编程语言的人在项目组中从测试人员开始做起，但是我认为测试人员反而更加需要专业的语言能力。因为测试在我的心目中是稳定软件市场口碑的镇山石，如果测试人员对开发人员所用的语言完全不懂的话，我认为测试人员是无法对开发人员提出高效修改意见的。学习一门新语言很容易，但是能够一眼看出新语言的bug是会难很多的。所以在我的心目中，测试人员，至少在语言理解度上，需要比开发人员更强悍。
   答： 在我们这次的敏捷开发中我体会到其实测试人员并不需要太深刻的编程功底，但是这并不意味着测试团队不需要对软件本身有一个良好的理解。我们的测试团队由一个计算机学院同学和一个非计算机学院同学构成，我们发现这样的一个搭配是非常合理的。专业能力较强的同学可以专注于收集报错信息，找到问题所在，反馈给开发团队进行代码调试；专业能力较弱的同学可以专注于单元测试的管理，只需要发现问题。经过这次开发，我发现我在最初认为的测试人员角色其实是不准确的。

6. 在“源代码管理”章节中作者提到利用好诸如GitHub这样的管理平台来检查提交代码的规范性，但是我不知道能否通过GitHub来检查提交的代码是否符合团队代码风格规范？我试图在StackOverflow上寻找答案，但是似乎没有人能够真正通过这种方法来检验比对代码风格。如果像GitHub这样的平台无法做到的话，是否只能先手动添加到自己的IDE中逐文件查看才能检查代码规范？
   答： 在本次开发中我们采取的代码规范管理方法是：1. 下发代码规范手册 .xml 文件；2. 在本机IDE中设置自动校对代码规范功能（如JetBrains WebStorm -> Preferences -> On Save）；3. 代码编写及检查完成后发起Merge Request，PM检查若无误则采纳，否则打回此次Request。我们发现，利用好相关IDE的开发功能，比如保存时自动检查格式，是非常高效率的，可以给PM或者代码管理人员带来不小的便利，同时也会规避由于代码风格而造成的大规模代码冲突。

所学知识点

需求

NABCD是由Need、Approach、Benfit、Competitors、Delivery五个单词的首字母组成，分别指需求、做法、好处、竞争、推广五部分。通过这五部分，可以清楚简明的把项目的特点概括出来，更好地确定软件开发目标。

设计

架构设计七大原则：1. 开闭原则：对扩展开放，对修改关闭，降低维护带来的新风险；2. 依赖倒置原则：高层不应依赖低层，更利于代码结构的升级拓展；3. 单一职责原则：一个类只干一件事，便于理解，提高代码可读性；4. 接口隔离原则：一个接口只干一件事，功能解耦，高聚合，低耦合；5. 迪米特原则：不该知道的不要知道，只和朋友交流，不和陌生人说话，减少代码臃肿；6. 里氏替换原则：子类重写方法功能发生改变，不应影响父类方法的含义，防止继承泛滥；7. 合成复用原则：尽量使用组合来实现代码复用，而不使用继承，降低代码耦合。

实现

代码管理原则：PM需要下发给特定人员不重复的、符合相关人员能力水平的任务，这对PM的管理能力是有一定的要求的。另外，在具体的代码实现中，代码规范的规定是需要严格遵守的，不然，在后期处理代码冲突会非常的没有意义。最后，在代码签入时，团队成员需要严格遵守团队规定的代码签入规则，这样才能避免代码管理紊乱。

测试

单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

发布

持续集成(CI - Continuous Integration)是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不影响工作。持续部署(CD - Continuous Deployment)是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品，持续部署在某种程度上代表了一个开发团队的更新迭代速率。持续交付(Continuous Delivery)是在持续部署的基础之上，将产品交付到线上环境，因此持续交付是产品价值的一种交付，是产品价值的一种盈利的实现。

维护

1. 更正性维护(纠错性维护)：诊断和修正系统中遗留的错误，就是纠错性维护。 纠错性维护是在系统运行中发生异常或故障时进行的。核心：出现错误后纠正，叫做更正性维护；2. 适应性维护：适应性维护时为了使系统适应环境的变化而进行的维护工作。核心：环境发生变化。若环境没发生改变，而对系统做出的改进不是适应性维护；3. 完善性维护：在系统的使用过程中， 用户往往要求扩充原有系统的功能 ，增加一些在软件需求规范书中没有规定的功能与性能特征，以及对处理效率和编写程序的改进。核心：基于用户对软件完善。例如：用户觉得某处不行，我们去改，这就是完善性维护。4. 预防性维护：系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护， 即选择那些还有较长使用寿命， 目前尚能正常运行， 但可能将要发生变化或调整的系统进行维护， 目的是通过预防性维护为未来的修改与调整奠定更好的基础 。核心：预防。也就是说，目前尚可工作，为了预防而做出改变。

理解和心得

我想通过几点心得体会来描述我对软件工程理论的理解：

• 专业性
  显然，开发团队应该具备出色的编程技能。此外，优秀的开发团队除了传统的开发，也会重视创新对重要性。并且，团队成员善于跟上技术趋势，知道如何以务实的方式使用它来提高绩效。

• 定期和清晰的沟通
  沟通是让任何团队运作良好的关键，团队需要确保沟通有规律（频率取决于需要）和清晰（没有秘密，意见可以自由分享）。有两种类型的沟通至关重要：团队内部的沟通和与第三方（利益相关者）的沟通。在团队中，领导者应该鼓励团队以健康的沟通来产生有效的流程、工具和解决方案。在与第三方沟通时，在沟通的帮助下，团队可以清晰地设定目标、审查流程、讨论新机会、选择正确的工具等等。

• 对目标的承诺
  设定明确和可实现的目标对任何团队都至关重要。在制定长期和短期计划并将任务交给团队之前，确保每个人都知道他们在项目结束时的目标是什么。

• 明确的角色和职责
  为了正常运作，团队需要了解流程的所有方面，以及他们的职责和责任。团队成员还应该了解他们的角色和职责与项目目标的关系。

• 理解数字产品的业务逻辑
  优秀的开发团队了解他们真正的客户。通过与产品所有者和利益相关者的沟通，他们真正了解最终用户的需求，因此能够做出正确的技术）决策。这是创建成功的定制软件的唯一方法。

• 自由与灵活性
  每个团队成员都应该可以自由地自行寻找新出现的困难的解决方案。在一个优秀的团队中，团队成员可以灵活地选择工具和与之合作的技术堆栈。当他们以目标为导向并受到启发时，他们会尝试找到最佳解决方案。有些时候，PM对他们的规范不太严格也许可以提供更好的代码，并让开发人员在工作时更快乐。一定的试验自由度有助于开发人员建立具有内部流程和文化的团队模型。
  优秀的开发团队也可以灵活地规划他们的工作日程，因为人类不可能整天保持生产力。他们需要时间放松，在咖啡机旁聊天，或者去健身。所有人都需要一些放松来创新和创造。通过这样做，他们确保了高动力，从而在特别需要时最大限度地提高生产力。

[BUAA软工]个人总结

软工总结

一、课程初阅读提问博客

link

Q1.1： 敏捷开发对于产品的可靠行要求不高？

这里的可靠性应当是相对而言，对于安防国防领域的软件，由于自身特性，在软件设计时首先考虑可靠性。相对来说，敏捷开发对于产品的可靠性要求要低一点点，容忍度好一点。

Q1.2: 这本书适合作为教材吗？

我个人还是觉得，这本书和教材的定位并不同，让我选，是不会用这本书作为教材的。如果从开始筹划一本教材，那么它一定是完全针对于某一门具体的课，融合进多年的教学经验，凸显学习过程中的重点难点的，旨在为同学们构建一个完善的牢固的知识体系。而这本书，感觉要点在于对于已经有一定经验的产品经理，通过优化很多方面的细节，让其水平得到全面的提升。

Q1.3: 大学生如何创新？

现在觉得，创新可大可小，大学生的创新可以在很多小的方面，比如在科研上的小尝试，做web时的界面优化，做算法是的小优化，都可以算是创新，就算其中很多可能失败，也能够为将来更大的创新奠定基石。

Q1.4: 如何评价软件的道德与否？

写软件的人可以道德，也可以不道德，用软件的人可以道德，也可以不道德，软件本身的衡量更多在平庸还是excellent.

Q1.5: 软件说明书写的多详细为好？

能够清晰讲清楚软件的功能和需要注意的细节即可，项目小，那么说明书也可以小，项目大，那么说明书也需要相对大一些。

二、学到的知识点

请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。

• 需求：对用户的需求的主动了解，不止在项目初期才有，而是贯彻项目始终的，甚至用户也可以参与到项目的开发中来。
• 设计： 设计阶段，项目的划分非常关键，针对组员的特长，合理划分项目，常常能够使得项目开发事半功倍
• 实现： 实现中，面向对象编程的技巧，多线程，进程间交互的细节，都非常重要，这些需要一定的技术上的经验积累。
• 测试： 好的测试，需要对于语言本身，框架本身，或者说技术本身，了解得足够透彻，才能在不破坏测试对象的基础上，构建出优雅的测试。
• 发布： 发布和推广十分重要，实际上，发布是要及早提上日程规划的，有一定的不可控因素在其中。
• 维护： 如果项目设计的足够好，那么日常的维护应当是轻松的，更多在于监控项目是否有异常状态，这对软件的安全性提出了一定的要求。

三、理解和心得

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

• 个人：个人开发中应当注意磨炼自己的技巧，努力提高自己的代码水平。
• 结对：阶段编程中的沟通应当占首位，最好能做到每日check一次进度。
• 团队：组建一个好的团队不容易，应当努力开发出每个人的潜力，激发组员的热情。

总的来说，终于是完成了一个比较好玩又挺有用的项目，过程非常艰辛，此处不提。惯例的感谢和总结，也不想说。想写的东西，只有对于敏捷软工这门课的建议了。我想我作为一个上了这门课的同学，是可以说一些话的。以下。

四、 课程的形式

能够理解，整个课程是想要真实模拟产业界团队开发管理模式，让学生能够在以后的任职过程中有备无患，提升软件工程素养。一学期体验下来，觉得课程更加偏重管理, 比如项目流程控制, 质量监督, 人员管理，项目资源管理。

4.1 阶段划分

三个阶段真的太多，相比于嵌入式软工、ai软工，敏捷软工这边的工作量明显大很多，这是问过很多同学了的。那么我们应该骄傲吗？明明是一门课，工作量差别太大是不合理的。分程两个阶段会好一点，也少写一些博客。

再之前的个人作业和结对编程对后面大团队作业有帮助吗？我想应该是有一定的作用的，不过我觉得直接开始团队作业，更加节约时间，也有更多功夫去把一个项目真正做好。

• 两个阶段 alpha & beta 足够了。
• 直接开始团队作业，取消结对。可以在个人作业阶段教开发规范，测试规范，用评测机来测评。或者取消个人作业，直接结对编程，然后上评测机。

4.2 评分细则

我想计算分数的助教一定非常累，结对作业中，博客50分程序60分，评分的单位小到0.5，评测过程中的问题也是有很多，可以仿照面向对象课程做一个评测机。一个两学分课的一次小作业，评分这么细碎，有点不合适。alpha阶段的评分，虽然也细碎，但是综合多方的评价是非常可取的。

主要问题在于，似乎，在alpha阶段结束了才放出评分规则, 4月25日好像展示完了，然后分数和评分细则是5月12号发的，令人困惑。

其次，学生互评似乎是只做了参考，用来印证老师和助教的给分？学生更应该是给分的主力军，毕竟学生是大多数，至少应该把分数算进去。

然后，博客占分是否太多，展示分数总共150分，博客分数130，而且博客写的好还能加分，这................................

我一个高中语文课代表实在觉得有失远迎（开个玩笑）。讲道理，课程组让我个人觉得有一点点太过于重视博客，在这次过程中，博客确实是一个团队展示自己的一个途径，但是博客写的不好，也可以创造出一个好的软件。

• 展示150，博客50，会好很多。
• 评分细则要在课程最开始就放出来，让学生有方向，不要放在助教博客，放在博客园班级置顶。
• 评分可以再简化一点，不必那么细碎，当然这是课程组自定义的事情。

4.3 项目选题

为什么要按照黄金点选题呢，自主选题会更好吧。

选题本来就应当自由选题，会有更好的项目和idea涌现，比如做pytorch的可视化模型构建。往届项目应当作为没有好的idea的组来备选的。还是说课程组往届遇到大量的自主选题的情况？那是好事啊我觉得，大家都很creative，有想要实现自己东西的欲望，通过软工课上学到的东西让这些点子很好地被完成，会是很有成就感的事情。好的项目是有生命力的，好的idea会一直有人想要去做，让学生自主选题，发挥自己的创造性，会有更多有生命力的吸引着一届又一届学生的好项目出现的，甚至有得项目能够真正落地，开创一个公司，甚至是王朝。当然课程组给出的几个项目都不错。

• 所有团队都自主选题。

• 好的项目，结束后投票决定谁能传承给下一届。

4.4 博客

一共大概24次的博客作业，实际团队一共47篇博客，个人博客3篇包括内容比较少的30篇每日例会博客。负担太大。
（统计于6.17）

1. 每日例会有必要或者说有用吗？讲道理，在课程中团队推进项目时，是非常有用的，因为团队成员很可能划水，及时开会可以了解进度.
2. 那么有必要写成博客吗？我觉得没有必要，很多东西在github上都有记录，而且要想伪造博客，也很容易，但是现在我们却需要专门的写文档的人去负责搞定。
3. 发布博客，发布博客是有必要的，毕竟要展示给课程评分人员我们做了一个什么样的东西
4. 测试博客，这可以合并到发布博客，为了评分需要单独划分，也行。
5. 展示博客，这真的是个有点匪夷所思的东西，博客是一个适用于阅读的载体，在展示能力上，它完全比不上PowerPoint， alpha阶段用博客讲演的时候，真的是要多别扭有多别扭。
6. 总结博客，有必要的，可以和下一阶段的预期计划(这个博客要求没有，课上通常说加在功能规格说明书中)可以合并在一起，总结完了，计划和展望未来不是很合适嘛？
7. 采访博客就...没必要了，形式上好，似乎有种承接前人经验的感觉，后面自己做项目感觉帮助也不大，对于做往届项目的组，想采访也行..，还有很多组直接重构重来。
8. 技术博客可以有更多要求，每个团队拿出3，5篇好的应该都不成问题。

9. 团队作业结束后，团队管理经验博客也可以有，课程中学到的东西，什么有用，什么没有用，讲个清楚，给我们的课程组更多的经验。

   功能规格说明书x1 + 技术规格说明书x1 + 2x阶段x(发布博客 + 上阶段总结与下阶段计划博客) = 6

   功能规格说明书x1 + 技术规格说明书x1 + 2x阶段x(发布博客 + 测试博客 + 总结与计划博客) = 8

   功能规格说明书x1 + 技术规格说明书x1 + 3x阶段x(发布博客 + 测试博客 + 总结与计划博客) = 11

   采访 + 项目选择 + 功能 + 技术 + srcum_meetingx30 + 贡献分规则 + 3x阶段x(展示+测试+发布+分析) + 博客目录 + 团队贡献分汇总 = 47

• 博客应当大幅减少，写博客不是目的，学到了什么才是目的。
• 博客的内容也可以有调整，形式化的博客要尽可能少。

4.5 人员及转会

转会这个制度好吗？我觉得很好，如果是三个阶段，应该两个次换人，谁表现差换谁。社会只会比大学里要残酷，要模拟真实环境，那么转会制度应该更强力。团队留不住人，组员自己不努力，都自己负责，甚至使用淘汰制度也不是不行。（当然这里可能考虑不周）

另外，一开始的组队的规则太严了一点，比如说，如果我现在想要找一个好的前端，但了解到班级里面前端做的好、态度又端正的就那么一个，还和我同系或同班或同寝室，那就完全没办法。

课程组的初衷我猜想是模拟真实条件下，我们总会遇到新的成员，模拟磨合的过程，那么问题来了，我们一般是不会遇到所有人都是完全新的状况，而且公司招聘，一个组内的人，大家水平通常都差不多，谁也不会太坑，招聘是拿着需求去挑人的，我们组队也是拿着需求去挑人的，但是公司招聘他们有的选，还要选好的，而我们组队，就这一个班，在相对严格的组队要求下，我们没得选。而且就算是自由组队，也几乎都会遇到不熟悉的人，况且再不济，也还有换人制度，容易换到陌生的人，仍然可以模拟真实团队。

• 完全的自由组队。
• 更好的转会制度。

五、 课程的内容

《构建之法》很有水平，技术也很好。

但我更想看到更多我们北航老师自己的经验，如何投标，如何引资，如何拿到关键技术，如何监督团队进展，什么什么什么局需要什么什么功能规格说明书，所以我们需要会写技术规格说明书，什么什么技术是我们将来一定会遇到的，git的常用指令和高级用法，统计一下目前世界五百强使用的项目管理方式，技术，开发与测试与PM的比例，要看到数据最好，是吧，学生你看你未来是一定要用到git的，一定会需要开组会的，一定会遇到各种各样的测试，而且产品经理会很烦人，怎么个烦人法呢，巴拉巴拉，可说的东西一定是很多的。软件开发环境国家重点实验是在我们北航，一定有非常多东西可以教给学生们。

如果讲开发的时候请一线大厂程序员来讲45分钟会不会更好，讲测试请专门做测试方面研究的老师来讲或者请一线测试人员讲讲自己真实做测试的时候用的什么工具，一个项目写了多少测试用例，他们一线工作的PM用过哪些软件工程方法，觉得什么方法更使用于他们的项目，这就很有价值了吧。

模拟终究是模拟，不是真实的工作实战，如果软工能够和生产实习挂个勾，找个合作单位，让年轻的程序员们去当免费劳动力，锻炼一个学期，会不会更好？或者让企业中毕业的北航自己的学长回校当一个学期的助教，甚至直接带一个项目，带一个团队，带个一周也好，薪资给够，会有人来的吧。和企业合作，那么企业一定会对表现突出的苗子非常有兴趣招揽吧，而且代码风格差的人，码力弱的人，也可以通过企业的标准来认识到自己的不足。（当然都是理想化的猜测，只是觉得这学期的课上下来，总觉得还可以更好，和企业合作或许很难完成）

以上。