上一篇:提问与回复
下一篇:从命令行开始逐步培养编程能力(Java)

目录:

** 0x00 Handshake
** 0x01 点评
** 0x02 评分
** 0x03 知识储备
** 0x04 明确课程主线条
** 0x05 项目设计
** 0x06 重视基础过程中各环节的质量
** 0x07 问卷/调查/统计/领骑黄衫
** 0x08 为什么要每周报告进度 | 20英里行进法则

0x00 Handshake

• 了解《构建之法》作者参与软件工程改革的一些背景: 专访《构建之法——现代软件工程(第三版)》作者邹欣
• 理解师生关系模型: 现代软件工程讲义 0 教学方法

0x01 点评

---

A. 汉堡包模型

• 软件工程讲义 3 两人合作(2) 要会做汉堡包
• 基本过程:
  • 基于内容／知识点／博客／代码事实的肯定，鼓励。但不放水，坚决打击南郭先生。
  • 在肯定鼓励之后，使用祈使句提出改进要求:“请xxx”
  • 按需追加回复。
  • 交叉索引知识点链接，这就是为什么需要通读／熟悉本文档推荐的链接。
  • 好的作业，可以给博客点赞， 好的回复点支持。
  • 根据数据说话，坚持衡量／分析原因／建议
  • COST: 问答类题目，助教可选择深入回答一个问题即可，其他由学生在总结后自己回答

B. 点评内容上的建议

• 软件工程(FZU2015)助教总结
• 软工+C(第1期) 题目设计、点评和评分

C. 教师／助教的点评历史记录:

• @SoftwareTeacher
• @ffl
• @vertextao
• @GreyZeng
• @SivilTaram

D. 点评的目标有:

• 消灭零点评，需要有节奏的安排点评的时间段，多利用碎片时间+批处理。
• 可以观察班级博客上的学生作业提交频率的规律来安排自己的时间
• 可以利用班级博客的【打开零回复博文】按钮一次点评页面那的零点评博客
• 交流，思辨和交流也是大学生学习的重要途径。
• 交叉索引。
  • 在点评学生博客的时候，使用知识点相关的链接。
  • 如果某个学生的博客和其他学校学生的博客有类似的问题，可以互相索引。
  • 抄袭别人的博客，直接post出原文链接。
• 学生们往往会get不到此处应该是和什么关键知识点相关，此时给出链接的目的有:
  • 给出再次阅读的时机，
  • 刚好遇到这个问题，此时再读有明确的目的
  • 缺少某些必要的有条理的过程，此时，给出相关模版／列表，建议其改进。
  • 如果有抄袭，严格执行扣分机制，认识到不严格执行对于认真学习课程和完成项目同学来说是不公平的。这点要一开始就和授课教师讨论并明确。

E. 检查点:

• 本节4个点你能做到么？
• 你打算这样做么？
• 你点评对路了么？请看:点评应该符合SMART的原则(@vertextao)

0x02 评分

---

A. 规则:

• 软件工程课的分数系统，和打分方法
• 软工+C(第2期) 分数和checklist

B. 工具:

• 熟悉班级博客(edu.cnblogs.com)的评分系统
• 熟练使用Excel评分, 并设计评分排行榜的柱状体，参考:
  • 【1414软工助教】团队展示 得分榜
  • [北航软工教学] 前七周个人排行榜
• Excel表格转MarkDown的工具:
  • 转换Excel表格到MarkDown：exceltk

C. 代码:

• 如果是命令行程序，可以编写针对命令行程序的自动测试程序，并提供2进制测试程序给学生，要求学生的程序能通过自动测试程序的调用，自动测试程序还能给出给出统计得分，参考: 结对编程-四则运算(挑战出题)
• 如果是App，可以要求最终(例如Alpha结束)发布程序到应用商店。
• 助教可以写批处理 自动 git clone下学生的程序代码，抽样编译运行，并做覆盖性的code review，例如: 软件工程(DBSD2016) Git Review

D. 协作

• 一个班级被拆分成多个子班级，评分规则需要统一，可选的方法:
  • 在教师题目设计的同时，在题目里就设计好题目的所有checkpoint得分点，由题目设计直接确定，多个助教执行。
  • 在教师题目设计review确定后，由一个助教针对所有的checkpoint提出评分规则初稿，其他人review，再确定，可轮流做这个环节(值日)
• 在作业项目的截止日期过后2天内及时达成目标
  • 发布作业评分／小结，其中包含分析优秀博客，重点问题，提供有用资料等
  • 完成大部分博客点评(最好是消灭零点评)

E. 检查点:

• 本节4个点你能做到么？
• 你打算这样做么？

0x03 知识储备

---

A. 通读构建之法，对轮廓了如指掌，以便在题目设计／点评中有的放矢:

1. 怎样算学会软件工程:
   • 有效掌握软件工程知识
   • 使用软件工程知识有章法的过程开发
   • 发布有人用的软件
2. 软件工程的完整环节
   • 每个环节的过程规律，例如构建之法里的(学生的作业过程中有类似规律):
     • 萌芽/磨合/创新/稳定/退出...
   • 每个环节的关键方法，工具
   • 每个环节有哪些常见的模型
   • 每个环节有哪些不同角色，作用分别是什么，各自需要怎样的专业技能？
3. 理解师生关系模型:
   • 教学方法
     • “怎么有效地教这门课。为了达到这个目的，我们要讲在这个课程中建立什么样的师生关系，怎么样让学生投入进课程中，老师采用什么样的教育方法，如何判分，如何让学生学到软件工程的技能。 ”
     • 明确健身教练／学员模型为主，理解教练／保姆的区别。
   • 助教的工作原则

B. 通读／熟悉两个常用索引，以便在点评／讨论中快速链接:

• 现代软件工程讲义 目录
• 《构建之法》参考书和链接汇总

C. 通读过去的教师／助教／学生的博客，学习所有的经验:

• 助教:
  • @GreyZeng 助教博客文章快速通道
  • @schaepher 2017春季JMU1414软工助教链接汇总
  • @宝玉 南通大学《构建之法》课程助教总结
  • @VeryBigMan 现代程序设计-homework
  • @SivilTaram 北航软工教学助教个人总结
  • @SivilTaram 我对软工有话说(上)
  • @SivilTaram 我对软工有话说(下)
  • @孟晨 石家庄铁道大学 2016 上半年软件工程课助教总结
  • @大史 2016福州大学软件工程收官个人作业成绩汇总
  • @大史 2017上半年集美大学1412软工实践_助教总结
  • @toughever 集美大学网络1413助教总结
  • @vertextao 北京电子科技学院_2016-2017-2_程序设计与数据结构助教总结
  • @郑蕊 2018西北师范大学_助教总结
  • @ffl 软件工程(FZU2015)助教总结
  • @ChildishChange 2017BUAA软工助教
  • @刘园园 2020春软件工程助教工作期末总结
• 教师:
  • @福州大学张栋老师 软件工程实践链接汇总
  • @东北师大杨桂福老师 作业成绩发布
  • @集美大学张敏老师 软件工程作业汇总
  • @集美大学张敏老师 2016-2017(2)软工总结——工程没有捷径
  • @福州大学汪汪璟玢老师 2018秋软件工程实践课程总结
  • @西北师范大学代祖华老师 2020年春季学期《软件工程》教学总结

D. 小节训练:

• 通读上述所有博客，并做一个分类对比，评价各自优缺点。
• 到edu.cnblogs.com上阅读10篇线上学生博客，并
• 对内容给予针对性知识点的点评
• 使用上述博客中的链接做交叉索引式点评

E. 检查点:

• 本节4个点你能做到么？
• 你打算这样做么？

0x04 明确课程主线条

---

A. 阶梯项目类型，思考下每个环节的关键作用是什么？

• 个人项目，是否可以先做一遍这些题目？
  • 个人和结对项目 - 英语单词词频统计
  • 个人或结对项目 - 动态显示程序运算的过程
  • 现代软件工程作业 – 计算最长英语单词链
• 结对项目
  • 怎样的领航员和导航员是合格的？
• 案例分析(思考点:案例分析的目的是什么？)
  • 个人作业2——英语学习APP案例分析
  • 第三次作业——个人作业——软件产品案例分析
  • 第四次作业——个人作业——软件案例分析
• 团队项目Alpha
  • 学生项目敏捷冲刺多久合适？
  • 过程中哪些是应该重点检查和推动的地方？
  • Alpha总结／互评／测试／事后诸葛亮(思考点:为什么要在这个时候做？)
  • 请在上一节的索引页面里找出 事后诸葛亮 的模版
  • 模版的作用是什么？
• 团队项目Beta
• Beta分析／总结／产品发布
• 软件工程总结

B. 不同课时训练目标的核心点不同，思考下为什么需要安排这些环节？

• 16周类型，参考构建之法的“给教师和助教的讲义”里的16周课时安排
• 9周／12周类型，参考邹欣老师的排列组合:
  • 快速阅读全书并提问， 描述自己的课程目标(一周)，
  • 随后是分析现有项目，决定团队项目(张老师的班级做的优秀项目 一周)，
  • 结对编程(一周，熟悉软件开发的工具)
  • 然后做团队项目alpha (重点强调使用原型设计工具和项目计划，WBS，两周，保证有 7 天的冲刺)
  • alpha总结(一周，可以请校外专家来交流)
  • 团队项目/beta (两周，保证 7 天冲 刺)
  • beta 总结 + 个人总结(一周，可以请校外专家来交流， 每个同学回答自己课程开始时提的问题，再继续提问)。
  • 个人项目(可选，适合那些想得高分的同学)

C. 课时过程和工具的结合，怎样在课程里让学生们有效掌握工具的使用？

• 参考链接: 《构建之法》课程进度之Github、Travis等工具融入篇

D. 小节训练:

• 结合自己所在班级的课程，提前在教室群里与教师讨论并确定课程的计划轮廓
• 提交协作式文档，将计划内容确定下来，并针对每次环节明确核心要达成的目标，特别是时间点的确定。

E. 检查点:

• 本节4个点你能做到么？
• 你打算这样做么？

0x05 项目设计

---

A. 协作工具

• shimo.im 建立一个班级题目设计专用的共享石墨文件夹
• 邀请教师／助教进入共享文件夹协作编辑
• 通过微信群组织过程

B. 教师设计项目初稿

• 整个学期的整体进度(环节)计划，具体到周
• 每个环节快结束到下一个环节开始之前几天，设计项目初稿
• 分享到教学微信群，协作编辑，改进

C. 复审设计的题目:

• 题目的开始／结束截止时间
• 题目的检查点(checkpoint)是否清晰
• 题目是否直接定好了评分的checkpoint及其分值？
• 题目的内容是否抓住本环节的核心内容
• 提供必要的工具，参考说明和示例:
  • 软工+C(第5期) 工具和结构化
  • 结对编程2——单元测试

D. 发布

• 教师在教学博客上发布定稿的项目作业
• 助教跟踪并发布到学生班级群

E. 检查点:

• 本节4个点你能做到么？
• 你打算这样做么？

0x06 重视基础过程中各环节的质量

---

A. 排版，请一开始就让学生使用markdown:

• 极简MarkDown排版介绍(How to)
• 代码的格式必须是正确的，博客园有插件可以用。
• 只贴关键的代码，不要所有的都贴。

B. 时间／风险估计

• 预估／矫正，例如PSP的有效使用
• 耗时估计的有效使用／训练
• 学生团队的PM是否合格？

C. 版本管理

• 请一开始就设计实验课，在课堂上step by step要求学生通过git的命令行操作测试
• 这需要教师／助教自己对git的使用熟悉。
• 代码仓库可以使用:
  • coding.net
  • git.oschina.net
  • github.com

D. git 工具:

• Git-for-windows
• Git自助手册

E. 燃尽图:

• 使用Github生成燃尽图
• excel表格绘制也可以，关键是内容

F. 敏捷冲刺过程

• 每日冲刺应该做什么？《构建之法》课程进度之Github、Travis等工具融入篇
• 遇到的BUG是否合理分类？
• 怎样在繁杂的日常开发中控制节奏？

G. WBS怎样才有效？:

• 分而治之(Work Breakdown Structure, WBS)
• 怎样算有效利用WBS？

H. 检查点:

• 你身边的工作环境里，大家重视这些过程么？为什么？
• 你打算怎样做？

0x07 问卷/调查/统计/领骑黄衫

---

A. 单次作业可以使用问卷调查某个单项数据

• 例如:到目前为止写了多少行代码，计划在本学期写多少行代码。
• 匿名问卷可作为适当的辅助工具。

B. 期中期末对班级做匿名问卷调查

• 对问卷调查总统计分析，小结
• 将统计结果发送给任课教师，累积教学数据，以便于一门课程的学期间迭代／改进
• 参考(具体的问卷建议使用以前积累的模版):
  • @大史 2016福州大学软件工程实践期末调查问卷报告
  • @北航罗杰老师 2018年北航软件工程师资培训总结

C. 千帆尽发图

• 千帆竞发图的制作

D. 领骑黄衫与Peak Experience：

• “在一些事情上做到最好，用这样的体验来鼓励自己” ，在该页面搜索“Peak Experiences”

E. 检查点:

• 你平常使用问卷调查分析数据么？
• 你注意分析数据的变化么？
• 你体验过Peek Experience么？

0x08 为什么要每周汇报进度 | 20英里行进法则

[1] 完全解读．柯林斯经典着作《Great by Choice》
[2] 逆境中勝出，非關運氣，關乎選擇《Great by Choice》
[3] wiki:罗尔德·阿蒙森

案例摘要，来自 @SoftwareTeacher 的群推荐记录：

1911年10月，來自挪威和英國的兩支隊伍，同時展開南極的探險旅程。他們都是5人隊伍、裝備齊全，都希望自己能率先抵達終點，成為人類史上第一群站上南極點(南緯90度)的紀錄開創者。 兩個月過去，挪威隊依照原訂計畫，踏入這塊前人未達的處女地，達成目標並全身而退、風光返國。英國隊，卻只能在落後一個月後，懊悔地看著南極點上的陌生旗幟興嘆；更可惜的是，他們不僅壯志未酬，回程的一場暴風雪更吞噬了他們的性命，全軍覆沒。這兩隊之間的差距，不只是成功與失敗，更是生存與死亡的差別。英國隊隊長在最後的遺言裡，吐露出他的心聲：「我們的運氣不好。」 但事實上，兩支隊伍在同一時間裡，都經歷了同樣的暴風雪、同樣的-20度低溫、同樣的險峻地形。更重要的是，兩隊的成員都未曾到過南極，沒有誰比對方更熟悉環境，也沒有誰對這趟探險更有把握。換句話說，面對逆境和危險，他們擁有同樣的運氣，那麼，為什麼挪威隊得以成功歸來，英國隊卻只能賠上性命、甚至被歷史遺忘？這正是吉姆‧柯林斯(Jim Collins)和在《選擇卓越》(Great By Choice)中要回答的問題。當然，他要探究的不只是100年前的南極探險事件，更是商場中普遍存在的現象與疑問：同樣面對社會、經濟、產業條件的劇烈變化，為什麼有的企業就是能夠屹立不搖、甚至益加壯大？狂熱的紀律(Fanatic Discipline)
時序拉回100年前的那場南極探險競賽。挪威隊在出發前，隊長亞孟森(Amundsen)定下了一個嚴格的行進規則：無論是晴是雨，每天一定要前進20英哩，不准多、也不許少，更不得利用任何藉口逃避。 於是，儘管在旅程中實際遇上15天的暴風雪，挪威隊依然無畏惡劣天候的阻撓，將每天的行進速度上推至13英哩。更難得的是，即使是在風和日麗的日子裡，亞孟森也決不貪多，仍舊堅持不得前進超過20英哩，讓挪威隊的平均行進速率保持在15.5英哩左右。反觀英國隊，在遇上暴風雪時，卻選擇連續6天休息，按兵不動。亞孟森的堅持，讓挪威隊的行進速度，整整領先英國隊一個月，率先到達終點，而這份**「20英哩的行進法則」(20 Mile March)**，也成為書中藉以比喻10倍數領導者堅持紀律的最佳例證。 柯林斯這樣形容他筆下的這群高效執行長：「每個領導者，都具備某種程度的自律精神；但是10倍數領導者對原則的堅持，已經到了『狂熱』的地步。」無論是堅持不隨股價波動而隨意對外放話、透露公司營收的Progressive Insurance執行長彼得．路易斯(Peter Lewis)，或是為貫徹熱情、有趣的企業文化「戰士精神」，總以奇裝異服面對媒體的西南航空前執行長賀伯‧凱勒赫(Herb Kelleher)，都展現出紀律的精髓──言行一致。 也正是這份從一而終的堅持，讓領導者在面對外界的變動和壓力時，擁有更強大的心智與行為自主權；讓他們能夠秉持自律，不輕易妥協、不過分貪求，始終在同一條軌道上穩定前進，更不會因為受到狂風暴雨的侵襲而停下腳步。