2016-2017(2)软工总结——工程没有捷径
课程教学目标##
学生基于“做中学”的学习理念，以学生为主体，老师为主导，采用“工业界导师+工业界助教+学校教师”的模式，通过过程化考核，博客驱动的作业，Git驱动的代码实践等方式，使学生具备基本的软件工程知识和技能。
教学内容设计##
以“个人项目+结对项目+团队项目”为形式，具体内容参见：2016-2017(2)软件工程作业汇总
数据采集与反馈##
-
时间和代码实践量统计
班级 平均每周(小时) (包括上课时间) **代码行（不包括注释、空行、单字符行） ** 1411 10 1200 1412 14 1277 1413 11 2447 1414 24 3112 从同学们所花费的时间可以看到，比起传统的软工课程——也许只要在课后花费1个小时做做练习题就可以了，的确花费的时间相对比较多，实践的代码量也有了一定的增加。 -
课前课后软工技能评估
软工技能 班级 1411 1412 1413 1414 对软工整体的理解 课前 2.7 2.1 2.6 1.9 课后 4.9 4.3 5 5 SE: Requirement （需求分析，典型用户，场景，创新 课前 2.8 2.4 3 2 课后 4.9 4 5 6 项目管理 课前 2.5 2 2 2 课后 4.4 4 4.2 5 架构设计，模块化设计，接口设计 课前 2.5 2 3 2.0 课后 4.4 4 5 5 效能分析，效能改进 课前 2.6 2 3 2 课后 4.3 4 5 5 阅读代码的能力，实现，单元测试 课前 2.8 2 2.9 3 课后 4.7 4 5 6 测试方法、测试工具、测试实践、代码覆盖率 课前 2.6 2 2 1.7 课后 4.7 4 5 5 Software Tools 课前 2.5 2 2 2 课后 4.1 4 5 5 代码复审/代码规范/代码质量 课前 2.7 2 2.7 2 课后 4.7 4 5 6 编程语言 课前 2.9 3 3 2.2 课后 4.7 4 5 6 应用开发 课前 2.5 2 3 2 课后 4.4 4 5 5 计划任务，估计时间和优先级 课前 2.8 2 2.4 2 课后 5.0 4 4 5 按照质量要求、按期完成任务 课前 3.0 2 3 2 课后 4.8 4 5 5 协同工作，提供反馈， 说服别人 课前 2.9 2 3 2.3 课后 4.9 4 5 6 报告项目状态，提出想法，写博客等 课前 2.7 2 3 2 课后 4.8 5 5 6 数字备注：1: 最低水平; 3: 基本的书面知识;5: 基本的理论和实践知识, 可以通过企业的面试; 6: 具有经实战考验过的技能；可通过最高水平企业的面试;8: 可以像专业人士一样自如地运用； 能发表权威技术博客;10: 全面精通理论和实践，成为公认的专家。 从数据的统计结果看，经过一学期的软工训练，同学们课前和课后的评估对比，软工各方面的技能有了相应的提升。
课程收获##
-
引入助教
非常感谢邹欣老师、周筠老师和飞龙博士的帮助，在本学期提供了四位助教：郑蕊、大史、吴科桥、西瓜。助教的引入，对每次作业的评分标准制定和打分，通过与学生的交流互动，弥补老师的业界经验不足，并能够更好的管理各班级。- 1班助教郑蕊的总结
累计评论博客350篇，根据个人笔记本manic time记录的时间sum(excel+cnblogs+edu.cnbglos+markdownpad2+shimo+coding)=60H，本学期在软件工程这门课上投入60小时。当然这其中可能也有屏幕开着但可能在洗脸等没有干活的时间，但这其中没有包括在单位的零碎时间，以及出差时在旅途中的零碎时间。本学期一共16周，所以每周用在软件工程上的时间大概4小时左右，这样看来应该是比去年当助教时效率提高了。
本学期与教师的互动较多，应该超过50次吧，只算和张老师的个人聊天记录我的发言就超过30多条了。
与同学们互动至少200次吧，没具体统计，在班级博客中发言就超过100多条。
在石墨中制定的评分标准或参与修改的作业达10余项- 2班助教大史的总结
一学期下来，评论共计240条，时间花费累计大约60个小时左右。一学期下来，收获也挺多
本学期的助教工作，相比上个学期更为从容。有上个学期的经验加成，效率提高了些许，这是其一。
其二经常在本班群里转发并AT大家。邹欣老师经常在班级群里分享一些东西，为了提醒大家看到，利用管理员的小特权@所有人
其三成绩更新速度相比上个学期提高很多。上个学期在福州大学助教工作中，甚至因为个人原因有两周没发布成绩的情况出现，这学期由于助教团队的互相监督，有极大的改善。- 3班助教吴科桥的总结
1 博客：可以要求一下统一的格式。
2 coding：
建议可以在课程初期增加对git使用的教学，并且有一个简单的项目贯穿始终，让同学基本每周都会有代码的check-in和check-out。而不是像最后团队里代码能力好的个人秀。
3 评分：有同学建议结对编程过程中也引进互评。至于评分细则方面，认为每一次布置作业的博文中已经很详细的写出了，只要认真看，同学们是不会有遗漏点的。
4 好多工具都只是走过场，比如leangoo或者PSP，大多数同学还是不能体会到其作用，可能得有一个良好的监督及执行制度。- 4班助教西瓜的总结
1 强制要求同学们使用 Markdown 。这学期只是推荐使用Markdown （软件工程第一周预备作业），同学们的博客排版看起来不太舒服。
当然也要考虑到同学们学习 Markdown 的难度。虽然在我们看来，Markdown 的语法超级简单，但是对于第一次接触 Markdown 的他们，可能需要有好的资料来帮他们适应。
2 强调 Git 和 Coding 的使用。源代码管理是软件工程的一项内容，而只有极少数人学到这一项。直到 Beta 冲刺结束后，4班的所有团队都没有用好 Git 和 Coding，我在他们博客下面反复说和扣除分数都没用。希望老师能当面强调。
3 这一项是很重要的评分依据。可以看到同学们每天实际上都做了什么，做的东西是否跟博客上描述的【已完成任务】一致。但是几个团队都是好几天提交一次，那么【已完成任务】就可以造假。
4 Coding 的使用主要包括：
Fork
Pull Request
issues （讨论）
用 Coding 上的 issues （也就是【讨论】）来代替 Leangoo 。Leangoo 的好处在于生成燃尽图，坏处在于不公开。在两个团队将我加入 Leangoo 后，我看到他们的燃尽图是假的，用于应付而生成。
5 虽然可以让各个团队将助教加入他们的Leangoo，但是除此之外的其他人仍然看不到。
不过如果不使用 Leangoo，那么如何生成燃尽图呢？这是一个问题。如果解决不了，只能忽略该建议。
有人做出将 GitHub issues 转化为燃尽图的工具，但针对 Coding 的工具却找不到。
6 在作业布置前就让助教先做好评分标准，并放到作业博客上。这学期做的改进是在【评分基准】里给出了大致内容。之后最好能给出详细的评分标准，也就是这学期助教在评分博客中展示的评分标准。
这样做的好处是让同学们能够随时知道自己哪一点没有做，哪一点没有做好，他们能得多少分自己能够大概知道。 -
写博客
正如：Joel Spolsky在《软件随想录》里所说一个普通程序员与一个优秀程序员的区别，不在于他们懂得的编程语言谁多谁少，也不在于他们喜欢用Python语言还是喜欢用Java语言，而在于他们能否与他人交流思想。如果你能说服其他人，你的力量就可以得到放大。如果你能写出清晰的注释和技术规格说明书，其他程序员就能够理解你的代码，因此他们就能在自己的代码中使用，而不必重写。如果你做不到这一点，你的代码对其他人就没有价值。如果你能为最终用户写出清晰的使用手册，其他人就能明白你的代码是用来干什么的，这是唯一让别人明白你的代码有何价值的方法。
写得越多，写作就会变得越容易。写起来越容易，你就会写得越多。这是一个良性循环。写博客恰恰就是一个很好的方式，也许刚开始写的时候会花费很多的精力和时间，但慢慢的就会发现写博客也不是一件很难的事。
-
更加贴合业界的开发流程
本次团队项目采用敏捷开发流程，通过Alpha阶段和Beta阶段的两次迭代，严格按照流程进行开发。 -
大量工程工具的学习与使用
例如在原型设计中使用原型根据，敏捷开发中采用Leangoo根据协作开发，代码实践基于Git和Coding平台的使用 -
严格的评分机制：如果有异议，在规定时间内提出，否则严格按照打分要求进行。在团队项目的冲刺阶段中，部分小组由于理解不到位，没有在规定的冲刺时间内完成7篇冲刺博客，虽然很遗憾，却只能按照事先规定的规则超过截止日期的博客为0分。
不足与改进##
如何能让教学有效落地，使学生能够明白软工涉及到的各个知识点和技能点？在本次教学实践过程中，仍存在不足，有待改进。
- 时间进度安排
本次课程在团队项目的进度安排上存在不足，导致Alpha冲刺阶段的时间估计不足，Beta阶段的课堂演示无法安排，因此在今后的教学进程安排中，应当尽可能早的要求学生组队开始团队项目，并留有较充分的时间用于冲刺和团队项目复审。 - 课堂加强引导和讨论
- PM的作用：加强对该角色的认识，并在团队项目中起到应有的作用。
- 增加头脑风暴活动，提高学生的参与度
- 加强Git练习与使用
改变传统观念：只有当项目代码彻底写好才上传。当写好一段代码构建成功即可commit，而且可由不同人commit，共同协作完成。 - 项目评分机制
- 考虑项目难度分级
- 团队项目复审采用自评+互评（不同班级之间）
- 在布置作业的同时，将评分标准一并给出，使得同学们对于作业的得分点有一个清晰的认识
- 持续维护
持续维护项目是非常必要的，跟进issue，是BUG就修复，是建议就思考。
抓住痛点，解决痛点，根据用户反馈的建议和BUG，去修复这些BUG，并根据新需求去维护这个项目。 - 推广
虽说是金子总会发光的，但是发光没人看也是没用的。适当推广自己的项目也是必要的，通过写作平台、技术博客、Android-Arsenal等平台推广。 - 单元测试
尽量写单测，并持续维护单测。在结对编程的单元测试模块，由于事先布置作业考虑不周，导致同学们对于模块化设计和单元测试的练习与预想的差距甚远。
小结##
总结断断续续写了一周，实在有些汗颜。第一次采用这种方式完成一门课，摒弃了传统的理论+实验，让学生进行了大量的实践。的确，在执行的过程中，也存在有质疑和抱怨，所幸坚持了下来，累并快乐着！我始终坚信，《构建之法》所提倡的理念和教学模式是一种很好的实践方式，摒弃了传统软工教学的弊端，能够更好的切合实际，也能够给学生带来更多的工程体验。正所谓“工程没有捷径”，只有通过持续不断的大量实践，“做中学”理念的不断贯彻，才能够培养工程化思维和团队协作能力，实现理论与实践的密切结合。
正如14级同学们给学弟学妹的期待：希望软工这门课越来越好！
刘未鹏在《暗时间》中所说：持续行动，收到反馈这一模式就类似于一种良好的商业模式，催促着自己不断的成长与前进。
不忘初心，继续前行！
