一、提问回顾
问题一：个人在团队中应该只是一个流水线上的机器吗？
教材P47有如下段落：
软件开发有很多个人的、感情驱动的因素……我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续明天的工作，最终你会有所成就。
在作者关于团队对个人的希望这一小节中，为了说明个人需要在工作中保持理性，引用了Chuck Close所说，但是在我看来，灵感更是一个专业人士所需要的素质，固然在一个团队的合作中，按照规定的代码风格、项目流程来进行开发是极为重要的，但这与灵感和创造力并不冲突。在教材P51页中谈及了人们对职业的态度有哪些等级，对于那些处于第五层——理想的呼唤的人们而言，这不仅仅是工作，更是一种创造。
经历了软件工程一学期的学习后，对于这个问题，我依旧保持原来的观点，灵感对于软件开发来说是极其重要的，开发是一群思维活跃的人在一起进行思维的碰撞的过程，最终将在灵感中诞生完美的产品，而相比于一个死板、毫无生气的产品来说，无疑是更具有魅力的。然而，这种灵感并不是说对规则的否定，我们在开发中依旧需要规范来保证开发和迭代稳定的进行。优秀软件开发离不开规范，也不可缺少灵感。
问题二：结对编程对于在二者能力有一定差距的情况下，其作用到底在“代码复审”还是在“人肉教程”？
教材P79有如下段落：
每个人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。
结对编程是代码复审的一种极致，在两人成组的代码开发中，“领航者”能够更好的监督正在编写程序的一方以免“偏航”，然而，面对能力较为悬殊的两人，能力较弱者在行使审查机制时，是否真的能高于能力较强者的自我审查的作用呢，而能力较弱者在进行代码实现中，能力较强者的审查机制有极大的可能成为另一种编写代码的方式——即你说一句，我写一句，这无论从对于二者的公平性上，还是对开发的效率上，抑或是结对编程所期望的复审机制上，都无从谈起，倒不如是说“带新人”。
在本学期的结对编程中，对于我原来所作出的回答，变得更加深有体会了，结对编程能够顺利进行的前提是需要双方有着一定的能力作为基础，也许你代码编写速度快，逻辑性强，也许我思维抽象性强，对架构的设计感更好，从每个人的强项来看，确实自己的优势和对方相比十分悬殊，但二者起到了一定的优势互补，反而能够将两个人的短板进行弥补。然而，假若一方什么都强，或者另一方什么都弱，这在结对中不仅弱势的一方有一种使不上力的感觉，强势一方也会将任务担在自己身上，两个人都不好受；即使强势的一方将任务分给弱势的一方，由于二者水平的差距，甚至可能让双方的对接产生问题，最后的结果就是重构，这种现象已经出现了。
问题三：激励一个敏捷的团队的动机是什么？
教材P116有如下段落：
自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。
敏捷团队能够不断迭代开发，及时跟进用户需求并保证进度推进和质量，其最重要的能力在于自主管理，然而，对于一个敏捷团队而言，什么是激励他们自主管理和不断迭代的动机呢，或者说，该怎样对敏捷团队整体的贡献进行评价呢，团队内部可以从分工和任务中评判个人贡献度，但是从一个公司的角度，对于敏捷团队的的贡献，应该是用户的满意程度，抑或是迭代开发的次数，还是完成项目的时间花费呢？从哪种角度进行考核，来产生一个既能够激励敏捷团队跟进用户、不断迭代、自我纠错，又能够合理的评价其贡献的方法。
对团队的激励太重要了，人是有惰性的，用什么去激励一个团队不断向前呢？在企业中，无非是工资和绩效，对于创业者，更多的是对未来前景的期许和对开发的巨大热情。对于一个学校中在软件工程课程的小组而言，其实处于中间的位置，首先，我们是一群学生，“分、分、学生的命根”，对于小组最大的推动力之一，正是课程对学生的考核本身，然而，考核起到的只是PUSH的作用，要想发挥每个人的主观能动性，使团队具有更高的效率和更完美的表现，就需要别的激励因素，那就是利用创业团队的热情来进行开发，让产品富有魅力，不仅是对用户而言，更是对开发者而言，只有团队喜欢这个产品，才有更大的激情去开发，去迭代。
问题四：WBS在分而治之中如何避免子节点的相互覆盖？
教材P178有如下段落：
做好WBS的几个要点：
- 保证所有子节点覆盖了全部父节点包含的内容。
- 保证各个子节点不要相互覆盖。
我们在实际的项目划分中，很难做到真正的将子节点任务完全划分开来，在有些任务中，会出现“我中有你，你中有我”的情况，例如，假设在用户注册部分，输入密码中必须包括大小写字母，然而，这一部分的实现可以在前端进行处理后提示用户，也可以在后端处理后反回拒绝注册的信息，在此时，二者在划分中就产生了重合。上例描绘的较为牵强，但是在笔者进行开发的过程中，常常出现分配任务中有着不可避免的重叠而发生类似“三不管地区”的情况，因此，产生了是否真的能够保证WBS进行子节点划分时不产生重叠的方法。
在本次团队任务中，作为PM，我在团队内的分工并没有按照按人头分配任务的方式，而是将组内划分为2到3组，按组分配任务，这也是主角们总说，为什么任务的划分这么粗粒度，其实这种方式还是有一定的好处，组内分组，每组再选出负责人，对该组组内进行任务划分，也许体系层次增加了，但是能让任务的分配在更小的组内完成，从而有更高效的调节能力，也让这在分而治之中存在的相互覆盖问题得以解决，那就是，所有交互的节点，由负责人出面，和有重叠的小组进行对接，由于在组间任务分配时，已经尽量避免任务的重叠，因此在对接时只需要小组负责人出面，即可完成不同功能之间的合并。担心组内可能的“三不管区域”？负责人的出现，正是为这些三不管区域而负起责任的，他们能够做到对无法划分的问题进行人员的二次调配。
问题五：渐进发布对于用户使用体验和市场评价的影响？
教材P331有如下段落：
又如微软公司在Windows10的发布过程中，同样采用了不同目标人群+不同发布频率的方式：……
自从Windows10以来，微软改变以往大版本更新，采用每半年进行一次小幅度更新的方法提供最新的操作系统，与此同时，也带来了Canary、Windows Insiders等体验版本，然而，这些版本在使用中不够稳定，在我平日的使用中，常常出现蓝屏等现象，大大降低了使用体验，并且，在20H1稳定版本中依旧出现了大面积严重Bug的问题，导致微软更新不得不设置门槛，在这种渐进发布和小版本迭代中，虽然确实能够看到系统在功能上的不断丰富，但操作系统作为个人电脑使用的基础和核心，稳定性是其核心竞争力，然而，在Insiders版本的大量使用和正式版依旧不够稳定的状况下，确实影响到了用户对于这款操作系统的评价，因此，渐进发布的弊端该如何去降低，又如何达到一个利弊的平衡点呢。
当时还是Windows10，然而现在，Windows11已经新鲜出炉（笑哭）。可以看到，Windows10每半年一次大更新的频率确实让OS的稳定性有着一定的损害，然而，视角看相其企业版产品，似乎更新的并不是那么频繁，仅仅对相关的漏洞进行修补，就算是对企业的一次更新了，这也许正是微软的一种平衡吧。对于互联网的大多数产品，其实是需要更频繁的迭代的，“吸睛”是互联网产生盈利的重要方法之一，没有快速的产品迭代来吸引消费者的眼球，怎么带动自己的流量经济呢？其实这个平衡点，就是所谓的产品的出口条件该如何设置，更多的特性与更稳定的体验哪一个更重要，即需要考量产品的定位，也需要观察市场的反应。
问题六：创新者不是一马当先吗？
教材P345有如下段落：
其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。又如Apple的音乐播放器iPod……
创新不仅仅在于你是否是这个领域的开拓者，Google能拥有世界绝对优势的市场份额，只是因为他很幸运？其搜索引擎依靠算法优势，依靠对用户需求的把握，依靠自身建立起来的Gmail、YouTube等等产品所打造的巨大王国所支撑着，这些都不是创新吗？Apple依靠对美和艺术的产品抓住了用户的心，虽然音乐播放器、手机等早已出现很久，但设计感这种创新依旧让他成为巨鳄。创新不是狭义的仅仅开创了这个领域的产品才叫创新，更何况，如果智能手机的开创者是先行者，大哥大对于智能手机而言又是什么呢。
依旧，创新是相对的，发明是一种创新，而改造也是一种创新，原答案中我认为自己已经做了比较清晰的思考，苹果发布了iPhone，可以说是对原本手机的一种改造，但同样可以说是发明了“智能手机”，每个创新者都应该是先行者，但也都是后来者。（有点哲学的味道）
问题七：刷课软件是否合乎道德和公平？
教材P410有如下练习题：
- 刷课软件和刷票软件
……
大家都喜欢给分高又可以摸鱼的大水课，然而，这种课总是人满为患的，以前，大家准时等待电脑屏幕面前拼手速，现在，大家一个个写起了脚本软件拼技术。对于这个问题，没有一个法律规定抢课是违法的，但从道德的角度思考，抢课软件是否合乎我们的道德观念呢。有人说，不是所有人都会写脚本软件，只有你这种计算机学院的同学学过这个，这种技术上的不公平，难道真的合适吗？但也有人说，我花了时间学习技术，花了时间实现软件，这就是我应得的报酬，有什么不合适？你行你上啊？而且又不是没课选不能毕业了，有能力就值得更好的。这个问题真的很矛盾，双方各自站在自己的利益上考虑，又谈什么公平与否呢，如何对这种行为的道德或公平与否下结论，真的很让人迷惑。
原答案这种说话的方式，其实就是说不道德啊！虽然不违法，但是真的不道德……电子健康码对于一个没有智能手机的老人而言就是一种绑架，互联网产品和电子科技的创造和进步不是为了竖起高墙，让弱势者更弱，强势者更强，而是因为有了他们，使弱势者得以平等的在社会中存在。
所学知识
需求
本学期在团队开发中使用了NABCD方法进行产品的需求分析，我们从需求、做法、好处、竞争、交付五大方面来思考和论证该产品在市场中的需求是否是存在的，对它展开的各种商业活动是否可行，这个工具或架构给我们一个很好的分析产品需求的途径，在实践中真的深受启发。
设计
对于我们的产品，在功能设计、系统设计中，使用了流程图、UML图等方法进行具体架构的设计描述。
实现
实现过程也是一种学习过程。
实现的目标不再是写让自己能够理解的代码，而需要让别人去理解你的代码。
需要团队内做相关代码和项目结构的规范。
测试
测试对于Unity的UI部分还是比较难测试的，很多的触发器，而逻辑代码很少。
后端的Django等测试，要看安全性，要写gitignore，要选择覆盖的范围。（我真的错了）
发布
发布不是简单的把下载链接发到朋友圈就行，需要有针对的设计面向用户的文案，需要设计好看的软件主页。
Alpha阶段的发布很及时，收集了很多用户信息。但Beta阶段做的不好，加上内测阶段，仅仅涉及了6天的用户信息。
个人主页的美观性，宣传设计的人群选择，还需要进一步优化和提高。
维护
很多团队利用微信群、邮箱来进行维护，我们制作了一个Blog来进行用户反馈的搜集。
上线真的能够收到很多Bug反馈，利用这些反馈可以更好的优化我们的APP。
三、个人总结
个人博客
本课程的第一阶段是一堆需要阅读的东西和一堆要写的个人博客，好久好久没写过这么多的字了，以前上学写一篇800字的作文真是煞费苦心，现在水一篇一万字的博客，也就是多花点时间。但这些阅读材料确实让我在很短的时间内获得了一定的基础理论知识的补充，这位后期的结对编程和团队项目都起到了一定的指引作用。但回过头来看，尤其是对于本博客所作的第一部分的问题回顾，我对一些问题的看法并没有太大的改变，不过，对于合作的感触，确实由书本的接触变成了实实在在地领悟。
结对编程
结对编程完成了一个内存中文件管理系统的制作，和我的好队友ZYH共同完成，这一部分真是又苦又累，课程组旨在让学生体验结对编程的感受，但其实没有强制要求必须按照结对编程的做法，这也无从进行考核，结果最后就变成了一个小二人合作开发项目，虽然对于是否起到了最初的目的依旧存疑，但确实是为团队合作开了一个好头。很官方的讲，这一部分，在一定程度上提高了双人合作能力，同时了解了结对编程的具体做法，在实践中真真切切地感受到结对编程的利与弊。然后复习了OO。
团队项目
团队项目算是一个挺让人无奈一个阶段，很多理念感觉和课程组是有冲突的，因为相信开发的灵感大于一切，所以不喜欢外人指指点点。一开始的需求分析，某软件工程班级花费大约1个月时间来进行调研和思考，我们一周内甚至完成了答辩，不能说不急，定题中发生了很多，有人反对这个，有人支持那个（非组内），真的，该听谁的？开发中，刚熟悉起来的Plastic，课程组忽然说只能用Gitlab，其实也真无所谓，初衷只是希望提高开发中版本控制的效率，最后，就当是老板说必须完成，助教也说了Gitlab的很多优点，但是有一点让人想不通，选题也是自定，技术栈也是自定，一个版本管理和仓库管理工具的选择，硬生生要强制，不理解，真的，争不动了。中间的换人阶段，其实我明白课程组的想法，提供一个真实的开发场景罢了，但难做的是我们每个人，怎么选自己队伍内的人啊，这不就相当于踢人啊，课程组可以选择帮每个队伍选择的方法来实现换人，有时候给予选择也是种残忍（笑哭）。
其实Beta阶段评审结束后，看到和团队们的大家一起做的游戏，真的有一种自豪感。别的不论，该课程确实很好地提供给学生一个协作开发的环境，让学生在实践中体会软件工程的意义，即使有很多抱怨，对于课程的核心目的，没有任何不满。