2016-2017(2)软工总结——工程没有捷径

课程教学目标##

学生基于“做中学”的学习理念,以学生为主体,老师为主导,采用“工业界导师+工业界助教+学校教师”的模式,通过过程化考核,博客驱动的作业,Git驱动的代码实践等方式,使学生具备基本的软件工程知识和技能。

教学内容设计##

以“个人项目+结对项目+团队项目”为形式,具体内容参见:2016-2017(2)软件工程作业汇总

数据采集与反馈##

  1. 时间和代码实践量统计

    班级 平均每周(小时) (包括上课时间) **代码行(不包括注释、空行、单字符行) **
    1411 10 1200
    1412 14 1277
    1413 11 2447
    1414 24 3112
    从同学们所花费的时间可以看到,比起传统的软工课程——也许只要在课后花费1个小时做做练习题就可以了,的确花费的时间相对比较多,实践的代码量也有了一定的增加。
  2. 课前课后软工技能评估

    软工技能 班级 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余项

    一学期下来,评论共计240条,时间花费累计大约60个小时左右。一学期下来,收获也挺多
    本学期的助教工作,相比上个学期更为从容。有上个学期的经验加成,效率提高了些许,这是其一。
    其二经常在本班群里转发并AT大家。邹欣老师经常在班级群里分享一些东西,为了提醒大家看到,利用管理员的小特权@所有人
    其三成绩更新速度相比上个学期提高很多。上个学期在福州大学助教工作中,甚至因为个人原因有两周没发布成绩的情况出现,这学期由于助教团队的互相监督,有极大的改善。

    • 3班助教吴科桥的总结

    1 博客:可以要求一下统一的格式。
    2 coding:
    建议可以在课程初期增加对git使用的教学,并且有一个简单的项目贯穿始终,让同学基本每周都会有代码的check-in和check-out。而不是像最后团队里代码能力好的个人秀。
    3 评分:有同学建议结对编程过程中也引进互评。至于评分细则方面,认为每一次布置作业的博文中已经很详细的写出了,只要认真看,同学们是不会有遗漏点的。
    4 好多工具都只是走过场,比如leangoo或者PSP,大多数同学还是不能体会到其作用,可能得有一个良好的监督及执行制度。

    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 在作业布置前就让助教先做好评分标准,并放到作业博客上。这学期做的改进是在【评分基准】里给出了大致内容。之后最好能给出详细的评分标准,也就是这学期助教在评分博客中展示的评分标准。
    这样做的好处是让同学们能够随时知道自己哪一点没有做,哪一点没有做好,他们能得多少分自己能够大概知道。

  2. 写博客
    正如:Joel Spolsky在《软件随想录》里所说

    一个普通程序员与一个优秀程序员的区别,不在于他们懂得的编程语言谁多谁少,也不在于他们喜欢用Python语言还是喜欢用Java语言,而在于他们能否与他人交流思想。如果你能说服其他人,你的力量就可以得到放大。如果你能写出清晰的注释和技术规格说明书,其他程序员就能够理解你的代码,因此他们就能在自己的代码中使用,而不必重写。如果你做不到这一点,你的代码对其他人就没有价值。如果你能为最终用户写出清晰的使用手册,其他人就能明白你的代码是用来干什么的,这是唯一让别人明白你的代码有何价值的方法。

    写得越多,写作就会变得越容易。写起来越容易,你就会写得越多。这是一个良性循环。写博客恰恰就是一个很好的方式,也许刚开始写的时候会花费很多的精力和时间,但慢慢的就会发现写博客也不是一件很难的事。

  3. 更加贴合业界的开发流程
    本次团队项目采用敏捷开发流程,通过Alpha阶段和Beta阶段的两次迭代,严格按照流程进行开发。

  4. 大量工程工具的学习与使用
    例如在原型设计中使用原型根据,敏捷开发中采用Leangoo根据协作开发,代码实践基于Git和Coding平台的使用

  5. 严格的评分机制:如果有异议,在规定时间内提出,否则严格按照打分要求进行。在团队项目的冲刺阶段中,部分小组由于理解不到位,没有在规定的冲刺时间内完成7篇冲刺博客,虽然很遗憾,却只能按照事先规定的规则超过截止日期的博客为0分。

不足与改进##

如何能让教学有效落地,使学生能够明白软工涉及到的各个知识点和技能点?在本次教学实践过程中,仍存在不足,有待改进。

  1. 时间进度安排
    本次课程在团队项目的进度安排上存在不足,导致Alpha冲刺阶段的时间估计不足,Beta阶段的课堂演示无法安排,因此在今后的教学进程安排中,应当尽可能早的要求学生组队开始团队项目,并留有较充分的时间用于冲刺和团队项目复审。
  2. 课堂加强引导和讨论
    • PM的作用:加强对该角色的认识,并在团队项目中起到应有的作用。
    • 增加头脑风暴活动,提高学生的参与度
  3. 加强Git练习与使用
    改变传统观念:只有当项目代码彻底写好才上传。当写好一段代码构建成功即可commit,而且可由不同人commit,共同协作完成。
  4. 项目评分机制
    • 考虑项目难度分级
    • 团队项目复审采用自评+互评(不同班级之间)
    • 在布置作业的同时,将评分标准一并给出,使得同学们对于作业的得分点有一个清晰的认识
  5. 持续维护
    持续维护项目是非常必要的,跟进issue,是BUG就修复,是建议就思考。
    抓住痛点,解决痛点,根据用户反馈的建议和BUG,去修复这些BUG,并根据新需求去维护这个项目。
  6. 推广
    虽说是金子总会发光的,但是发光没人看也是没用的。适当推广自己的项目也是必要的,通过写作平台、技术博客、Android-Arsenal等平台推广。
  7. 单元测试
    尽量写单测,并持续维护单测。在结对编程的单元测试模块,由于事先布置作业考虑不周,导致同学们对于模块化设计和单元测试的练习与预想的差距甚远。

小结##

总结断断续续写了一周,实在有些汗颜。第一次采用这种方式完成一门课,摒弃了传统的理论+实验,让学生进行了大量的实践。的确,在执行的过程中,也存在有质疑和抱怨,所幸坚持了下来,累并快乐着!我始终坚信,《构建之法》所提倡的理念和教学模式是一种很好的实践方式,摒弃了传统软工教学的弊端,能够更好的切合实际,也能够给学生带来更多的工程体验。正所谓“工程没有捷径”,只有通过持续不断的大量实践,“做中学”理念的不断贯彻,才能够培养工程化思维和团队协作能力,实现理论与实践的密切结合。
正如14级同学们给学弟学妹的期待:希望软工这门课越来越好!
刘未鹏在《暗时间》中所说:持续行动,收到反馈这一模式就类似于一种良好的商业模式,催促着自己不断的成长与前进。
不忘初心,继续前行!

posted @ 2017-07-24 09:22  zhmin  阅读(413)  评论(9编辑  收藏  举报