• 软工+C(9): 助教指南

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


    目录:

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

    0x00 Handshake

    0x01 点评

    A. 汉堡包模型

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

    B. 点评内容上的建议

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

    D. 点评的目标有:

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

    E. 检查点:

    0x02 评分

    A. 规则:

    B. 工具:

    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. 通读过去的教师／助教／学生的博客，学习所有的经验:

    D. 小节训练:

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

    E. 检查点:

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

    0x04 明确课程主线条

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

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

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

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

    D. 小节训练:

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

    E. 检查点:

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

    0x05 项目设计

    A. 协作工具

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

    B. 教师设计项目初稿

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

    C. 复审设计的题目:

    D. 发布

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

    E. 检查点:

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

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

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

    B. 时间／风险估计

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

    C. 版本管理

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

    D. git 工具:

    E. 燃尽图:

    F. 敏捷冲刺过程

    G. WBS怎样才有效？:

    H. 检查点:

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

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

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

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

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

    C. 千帆尽发图

    D. 领骑黄衫与Peak Experience：

    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），都展現出紀律的精髓──言行一致。 也正是這份從一而終的堅持，讓領導者在面對外界的變動和壓力時，擁有更強大的心智與行為自主權；讓他們能夠秉持自律，不輕易妥協、不過分貪求，始終在同一條軌道上穩定前進，更不會因為受到狂風暴雨的侵襲而停下腳步。
  • 相关阅读:
    gradle 使用本地maven 仓库 和 提交代码到maven
    eclipse 快捷键
    eclipse gradle 找不到依赖解决办法
    java web 简单的权限管理
    spring 配置properties 编码
    html 一些坑。。。
    js 的 一些操作。。。
    maven 过滤webapp下的文件
    django 模型
    vue系列之webstrom的设置
  • 原文地址：https://www.cnblogs.com/math/p/sec009.html
Copyright © 2020-2023  润新知