| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 第一次作业的链接 | 第一次个人博客作业 |
对第一次作业疑问的解答
- 关于第二章2.1（P22）中介绍的单元测试，如何进行藕连模块的单元测试
问题描述：单元测试的作用是保证模块的稳定和正确。但在实际情况中存在模块之间的藕连，例如游戏中的跳跃模块和技能模块会出现藕连——比如某些技能需要依托跳跃释放。这种情况下如何设计单元测试？
解答：查阅之后得到的结论是主要有有全测（即测试覆盖所有模块）和全不测（即假设所关联模块是正确的）两种处理方法。而我的想法是能否根据模块间的关系将不同模块分组后设计一个大的组合单元测试来验证藕连模块之间的正确性。而在我们的团队项目的实践中，我们选择将这些藕连的模块组成一个场景，并对场景进行单元测试来做到对藕连模块的测试
- 关于第六章6.2（P117）中提到了几种敏捷开发会遇到的问题与应对情况，那么如何应对会议时间过长这个问题
问题描述：我在实习时发现每日例会占用了敏捷开发极大的时间，这个问题在策划层尤其明显，由于需要对接各个功能团队的工作，例会就包括了每日的对接会议。而另一方面决策会议往往一次无法有效的讨论出结果，这个问题无论是在小团队开发还是在大公司开发都会出现，即一个会议讨论了半个甚至一个小时以上都始终在争论一些细节的始末，从而无法有效推动会议进程。而这两点的结果往往是一天6小时的工作时间有两到三小时是在开会中度过的，极大的降低了开发效率，我想知道这种敏捷开发中遇到的问题要如何应对。
解答：这个问题在我们的团队项目中也确实出现了，且不提每天都要开会，在团队项目初期每次开会都会持续一个小时左右。我们对这个问题的处理主要是规范化会议的流程，并且控制会议每个环节的时间。我们将会议分为汇报今天进度、安排明天工作、讨论当前困难三个部分。随着会议流程的规范，会议的时间逐渐从一个小时缩减为半个小时左右，极大的提高了效率
- 关于第八章8.1（P157）软件需求中提到了软件需求主要由用户需求与技术性需求组成，由此我思考创新需求是否也是软件需求要考虑到的需求
问题描述：举个例子，随着iPhone等智能手机的推出，手机游戏的市场越来越大，而暴雪这家主要用户都是PC用户的公司想要向手游进军，但由于此公司长期开发PC游戏，手机游戏方面经验匮乏，需要开发一些手游来积累经验。此时出现了一种矛盾，暴雪的用户需求是新的PC游戏，而此时暴雪的创新需求（我自定义的需求）是手机游戏。作为一家互联网公司肯定不能墨守陈规而不积极求变，但是求变所需的创新与尝试又会与公司已经积累的用户的需求产生矛盾，这种矛盾是否需要考虑到软件需求中去，如果考虑进去，又该如何平衡这种矛盾？
解答：在团队开发阶段，我们主要是从一个团队的角度去看待需求而不是从一个公司的角度，因此解答会有所偏差。作为一个团队，我们的创新需求主要来自于用户需求，很多情况下是用户想要我们做什么我们就去研究这方面的技术，进行这方面的创新。而公司层面可能会考虑更多的行业走向，未来发展前景等问题从而做出不同于用户需求的设计。
- 第十五章15.1（P330）提到了几种面对软件发布DDL处理bug的方法，但却跳过了延期发布，我想知道什么时候应该选择延期
问题描述：书中关于延期发布的原文如下
有人会举出世界著名的公司为了“完美”而不惜推迟发布时间的例子，例如苹果公司的一些产品，著名的游戏“永远的毁灭公爵”，等等...请问：iPhone的第一个版本是完美的么？它连复制/粘贴的功能都没有，但他还是发布了
但其实这段话更在于强调产品发布时不可能完美而不是延期发布的方法不可行，不过后文也未将延期发布作为一种应对处理临近发布事态的一种办法进行介绍，而现实中有不少的产品均会选择在发售日期来临前延期，因此我想知道什么时候该选择延期而什么时候该选择按原计划发布。
解答：在团队项目中，由于发布时间是硬性要求不能推迟所以没有延期发布的选择。在个人理解中，延期发布是在软件开发连最低的发布条件都没有达到的情况下才做出的选择。而在正常情况下，已经达到发布标准的产品即使存在一部分小问题也是应该发布的，因为不发布就无法获取更多的用户反馈对产品做出进一步改进。
- 第十六章16.2（P362）指出过早的提出一些在业内人士看来优秀的创新无法被大众所接受，我在思考过早的创新也是有意义的
问题描述：即虽然创新不能被用户接受，但却能很好的启发同行，具有非凡的意义。例如世嘉于1999年发布的游戏《莎木》，虽然在当年却只有十分惨淡的销量，但是这款游戏在当年作出的电影式叙事方法和QTE系统等创新在如今无一不被主流游戏所频繁使用。而对于接受了这款游戏的创新的用户而言，这款游戏是完美的。这些用户的体验使得其他游戏公司看到了这些创新的价值并付诸实践，最终证明了《莎木》的游戏模式是具有时代意义的。可以说有些创新虽然无法取得商业成功，但也能具有推动行业发展的价值，所以过早的创新（超前于同行的创新）也是具有实现价值的。
解答：过早的创新即使没有商业价值也存在学术价值或其他的价值。但是站在一个公司的角度去思考，商业价值是首先需要考虑的价值。因此过早的创新在很多时候是不可取的选择。是否做出过早的创新取决于公司对自己的定位和对用户需求的定位。有的公司目标就是做出划时代的成就那么过早的创新对于他们而言就是值得冒险的行为。
产生的新的疑问
-
在团队项目中我意识到了推广的重要性，更好的推广意味着更全面的用户反馈。那么推广究竟应该在软件开发中占多少的比重呢，或者说我们应该在开发过程中就充分考虑推广的问题吗
-
当碰上进度比计划超前的情况时应该作何应对，是给组员放假还是快速指定新的计划来补足多出的开发时间
软件工程中学到的知识点
- 需求
除了学习到了NABCD需求分析法，还有就是意识到了用户反馈的重要性，很多时候需求是根据用户反馈决定的而不是平凭空想想的。
- 设计
设计方面学习了更为具体系统的功能规格设计和技术规格设计。而从实际的开发中我更加意识到前期设计的重要性，没有一个好的前期设计和规范，就可能会导致代码不断大规模重写的后果。而一个充分具体的设计书能够减少会议中许多不必要的细节讨论，极大提高开发效率
- 实现
实现方面最主要的知识点是沟通交流，一个沟通顺畅的团队开发效率不会低，而沟通不顺畅则会导致在开会上花去过多的时间，并且频繁的修改已经完成的工作。
- 测试
测试方面学到了制定测试计划，在以前测试只是简单的跑一跑。而在团队开发中，测试涉及方方面面，甚至需要有专人来负责。一个制定全面的测试计划能够有效保证发布软件的质量。而另一方面，我也认识到了单元测试、测试矩阵这些测试工具的重要性
- 发布
主要让我认识到了推广的重要性，好的推广就能换来更全面的用户反馈，而用户反馈能够帮助软件指定更合适的开发计划，很多时候，推广能决定一个软件的成败
- 维护
维护就是一个不断更具用户反馈对软件进行调整的过程，强调与用户社群的互动，积极的用户才能造就优秀的软件
个人总结
- 个人项目
在个人项目中我第一次体会了软件工程或者说敏捷开发的工作模式，也是第一次意识到了测试工作在软件开发中这极高的比重。可以说在个人项目中我学到了进行软件工程应有的素质
- 结对编程
结对编程是软工第一次与他人一起合作。虽然之前有过四五人小团队的开发经历，但像结对编程这样的开发模式是第一次体验。虽然由于疫情原因很多结对编程当中的技巧无法实施，但是依然让我感受到了这种开发模式带来的效率提升。结对编程对于我来说是一次很好的经历。
- 团队项目
Alpha阶段的收获大概就是学习了作为一个PM应当怎么管理一个团队，之前虽然有做过敏捷开发但是并没有负责过PM的职位，这次的软件工程给了我这么一个机会。对课程的建议是希望提供一个app发布的平台，现在国内对app发布的管控越来越严了，需要很多相关证明和文件才能发布。
在Beta阶段，作为一个PM主要学到的东西是如何为团队介绍一个新成员，包括对新成员的上手引导和工作安排，这些工作都是以前没有预想过的。另一方面，在软件开发上，我认识到了中间版本的重要性，通过发布中间版本，可以即时发现一些bug和设计上的问题，即时调整开发内容和方向
