问题思考与解答
-
问题1
工程教育中，应该以量作为评价标准吗？在工程教育中，的确大量的练习得到的经验是非常必要的，但是如果只以量来评分，假设学生以追求高分为目标，难免会有学生随便对付，没有理解，只有机械重复，没有提高，就像中小学的题海战术，往往只对部分人有效。我觉得以量评分至少要因材施教，并确定某一质量底线，否则完全以量评分并不能够使得所有的同学能发挥出自己最大的潜能。
质量互变规律：量变是质变的必要准备，质变是量变的必然结果；质变和量变是相互渗透、相互依存、相互贯通的，在总的量变过程中有阶段性和局部性的部分质变，在质变过程中也有旧质在量上的收缩和新质在量上的扩张。量变引起质变，在新质的基础上，事物又开始新的量变，如此交替循环，形成事物质量互变的规律性。质量互变规律体现了事物渐进性和飞跃性的统一。
要想获得质变，量变是必要的。因此工程教育中以量作为评价标准是有合理性的，眼高手低不可取，工程教育注重“做中学”，这对量有了更高的要求。个人以为，对“质”和“量”的要求，还可对应对“结果”和“过程”的要求。工程教育以量为评价标准，是一种更注重过程的体现，有助于学生对知识更好的理解和学习。
-
问题2
代码的作者最了解代码的实现的局限性吗？我感觉代码的作者很有可能会“不识庐山真面目，只缘身在此山中”，往往不能跳出自己的逻辑检查代码的局限性，所以我对这一点存疑。
通过实践，我发现要从两个角度看这一问题。一方面，作者的确最了解代码实现的局限，因为作者最了解代码的实现细节，所以作者知道自己实现了什么、使用什么技术实现的、实现到了什么程度，使用的各项技术可能产生的后果，这样作者也就了解了代码的局限性。另一方面，作者有时候会局限在自己的思路里；抑或采用了自己并不熟悉的技术，未能意识到技术的局限，此时作者便不能认识到代码的局限。
-
问题3
面对疫情，我们结对编程的两个人根本无法面对面工作，只能远程交流，这种情况下对教材中的“结对编程”做出怎样的改进，才能在“远程结对编程”的情况下获得尽可能高的投入产出比？
远程结对编程虽然不能像面对面那样做到高效监督，但其实也有很多沟通方式，结对伙伴使用微信QQ可以随时交流对项目的想法和意见；很多软件提供屏幕共享功能，使得二人面对一块屏幕一起编程成为可能；而且，远程交流其实对“自闭”“社交障碍”的人非常友好，可以缓解面对面的尴尬，结对伙伴反而更能专注代码。以自己的实践来看，结对编程的形式（面对面/远程）对项目成果的影响不是很大，如何在短时间内做好队友磨合，快速投入项目实践才是更重要的事，而这需要队友齐心协力的付出、充分的意见交流和合适的时间分配。
-
问题4
''敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。" 这样也就导致了敏捷开发会议很多，交流成本很大，所谓的敏捷开发是一个坑吗？这个问题下有答主提到，敏捷开发的会议很多，而且很多时候这些会议并没有起到应有的作用，我们应该怎么做才能尽量避免采坑，学到真正的敏捷开发？
在没有开始团队项目时，我先入为主的认为，敏捷开发的会议过多且可能会流于形式。但是经过这学期的实践，我发现会议是敏捷开发中至关重要的一环。一方面，本身团队之间需要对项目细节进行很多的沟通和交流，高频的会议恰好提供了交流平台，且在会议中所有组员一起语音交流，更是提高了交流效率。其次，高频的会议也使得项目中出现的问题能够及时的暴露出来，PM也能够对之后的工作安排作出调整。最后，会议也起到了推进项目进度的作业，使团队不至于在DDL截止前才把工作提上日程。而且我发现每日的会议其实并没有耗费过长时间，所以这不是一件费时不讨好的事。要避免采坑，需要明确会议任务，并在会议上踊跃交流，这样才能发挥会议的作用。
-
问题5
在市场竞争中，市场中的先来者，是该以创新立命，以不断创新为首位，还是先稳固市场，建立这一市场的进入壁垒？
一方面，要发挥先动者优势，需要率先占有关键资源，率先获得市场份额，率先建立转换成本，这样才能守着市场，另一方面，不断创新不落伍，才可能长久的占有市场，也才能不断地做大市场。盲目做大市场只会给后来者可乘之机。在率先占据市场的情况下，建立进入壁垒的同时，吸纳后来者的优点，不断创新，企业才能长久发展。
各阶段学习到的知识
-
需求
在需求分析时，不仅需要考虑受众需求，还需要调研市场中的竞品及其优势与劣势，知己知彼，更能找到合适的、独特的突破口，进行产品设计。
-
设计
设计阶段十分重要，尤其在团队项目中。从功能设计来讲，要根据之前的需求调研，找出用户痛点，确定核心功能。从代码设计来讲，前端、后端等部门之间应该协商设计好对接用的接口，规范化的接口文档是非常有效的部门间沟通方式。
-
实现
实现阶段我主要负责的是安卓前端的开发工作，学到的知识大部分是关于我们所选框架flutter的具体技术知识，比如UI的编写，交互逻辑的实现等。
-
测试
不同部门的测试要有不同的测试方式和侧重点。对于后端来讲，进行完备的单元测试、代码覆盖，才能保证功能的可用性和正确性。而对于APP/网页前端来讲，使用实物进行黑盒测试，能够更好地模拟各种使用情况，并对之进行调整。
-
发布
发布软件的时间、地点、形式对用户量会有很大影响。例如，我们的团队开发的是一个校园教务助手的APP，在beta加入了课程评价功能，这个功能明显在考试后/出分后/选课阶段的需求量更大，但我们的分布时间却是临近烤漆。在不甚恰当的时间发布APP，会损失很多可能的潜在用户。
-
维护
维护阶段不仅仅是修复功能上的bug，还需要对用户的合理反馈进行处理，因此，及时获取用户使用反馈是十分必要的。对于APP类软件，可以通过各大应用商店的评价(若上架)、在APP内置用户反馈功能等渠道获得反馈。
心得体会
课程起始的个人项目和结对编程给我的感觉与之前类似课程的作业类似，而在团队项目中，我有了独属于这门课程的心得和体会。首先，我在团队项目中学会了团队合作。很荣幸能够作为顶级理解团队的一员，参与软工课程中来。在项目中，我们有PM作为主心骨，拿决定、提意见，推进度；各部门内和部门间也通过微信群、每日会议等高效交流沟通，团队氛围良好；团队规划细致合理也是项目可以有效推进的原因。这些都让我认识到一个优秀的团队的重要性，并得以从中吸取团队合作的经验。另一个令我印象深刻的是开发阶段的“一日一会”制度，相较于其他课程仅规定DDL，团队项目中的这个制度细化了对开发过程的要求，“一日一会”配合其他量化指标，使团队成员每天的工作都能得到量化和及时反馈，每天的会议既总结了前一天的工作，也使成员有了高效的交流的平台，还可以及时对之后的工作安排做出调整，这有助于团队磨合，也对项目推进起着重要作用。