SE_FZU目录：1 2 3 4 5 6 7 8 9 10 11 12 13
本次构建之法-SE助教工作，和福州大学张老师协作，福大学生基本发挥出了一定水平，在此做个小结。
教师
张老师本身的SE教学经验足够丰富，对教学工作中的教师、助教、学生的角色定位清晰，整体节奏和安排合理，同时在题目细节、时间和进度上能接受我的建议，采用更紧凑的风格，加上FZU学生的整体有效配合（一群认真想要学好SE的大学生），所以整体进度还不错。在时间上，张老师能根据学生的具体情况做适当调整；实践项目上，张老师坚持在主线上以个人项目、结对项目、团队项目循序渐进迭代，并且在项目内容上保持增量式，同时辅以练习、案例分析、增补作业等做为补充，保持学生练手的节奏；在评分规则上，我和张老师的协商都挺有效率，一旦协商确定就不再改动。整体上和张老师的协作是有效率的，主线是：充分协商->各自严格执行（课堂内，网络上）。张老师也坚持让学生们在做每个环节的时候都使用工具，学生们在整个SE过程中，练习和使用了相对多的工具，这点在他们的SE期末总结上也体现出来，我觉的这是一个好的要素，工程上的过程是多阶段的，分工是多角色的，每个阶段，每个角色都能充分利用甚至制造工具去提高效率，则有章法。
针对张老师，我重点谈下题目设计和教学进度控制两点。
题目设计上，如果全部推给助教，实际上助教并不能一上来就设计出良好的循序渐进的SE题目，我在这点上亦一开始还是有所担忧，不过这学期，张老师主动承担了大部分的题目设计，他根据自己学校学生的特点，针对性的设计了适合他们的增量题目，我觉的整体上有利于教学的循序渐进展开。我在这个点上做的是review题目的活，主要还是review：
- 时序问题。
- 开始的时间是否过于靠后，越后面的时间点，临近期末会越不好展开。
- 截止日期问题，给的时间不能太长。
- 作业次序问题，例如不能连续一个月都是文档性的作业，这个点上保证有编程项目的频率。
- CheckList
- 题目的要求必须明确，尽量少用含糊的概词，多用具体的量词。
- 题目要求的检查点尽量可量化，利于评分
教学进度控制上，主要也在时序和内容上。例如尽量在学期开始有效把个人作业迭代起来。把本来张老师计划安排在11月份才开始的alpha，提前到10月份中旬，避免10月份都没有编程任务。内容上，张老师认为学校里的敏捷并不容易搞起来，我的建议是教学内容和步骤可以是瀑布的，但项目的迭代进度还是以alpha+beata的scrum冲刺的形式进行。这点上坚持下来了。后面还行。
学生
接着说福大的学生。
FZU的学生基本没有抄袭的，这点很好，就可以直接关注在具体的练习的内容质量上。FZU的学生还是有部分会反馈，这点实际上不能强求，助教能做的就是坚持陈述句+提问的方式做好每次点评，如有反馈算是收益。
FZU的学生群，有匿名吐槽，不过其实他们只是说说而已，完了该做还是会做，而且在夹带吐槽的过程中，也实际上会对SE的相关内容进行交互，算是一种增强SE知识点的过程。学生群里引入了北航的个别优秀学生进来，也使得学生群的交流氛围有互相学习的效果，当然这要适当，不可强求。我觉的这算是一种自然有思辨的课堂环境，张老师做的挺好，松以讨论，严以规则，适当引导。学生群里也偶尔对单次作业做问卷调查，由于群的氛围还可以，所以FZU的学生大部分都乐意填写群里发起的问卷，以及期中的教学质量匿名问卷和期末的匿名自评问卷，这些调查的统计性结果反馈给张老师，利于本次课堂以及下一次课堂的改进。
FZU的学生项目实践，这学期也在git的使用，以及github上花费了一定的时间，以源代码版本管理为线，在个人项目上练习基本的源码版本管理、在结对、团队项目上练习了多人协作以及issue管理，同时辅以燃尽图对项目进度有整体控制。有部分学生对git和github的使用和理解已经比较熟练，可以说比很多已经工作了的程序员都掌握的好。虽然因为网络问题，大家比较折腾了一点。也有老师在说是否可以用国内的git仓库。但我个人是坚持认为应该用github，我的理由是：
- github是目前全世界程序员最主流的源码仓库，连microsoft、google、facebook等知名IT公司都在上面有自己的开源项目主页，我不知道这能持续多少年（以前svn时代是sf.net）,但目前它是，所以我坚持认为既然要用git的某个仓库，就应该用它，而非国内的某个git仓库中心。
- 我希望学生们以后的自己其他项目也都能用github，能直接在一流的源码仓库上干活，就不必退而求其次，好的开放社区，长期效果是更好的。当然这两点只是我个人的看法。
助教
最后说下我自己。我觉的最大的收获是，把自己能做的基本工作做到位即可。我想SE教学当然不可能一次就能解决所有问题，但在一次的过程中，我是抱着把自己能做的基本工作做到位的想法去的。本来有三个点：出题、点评、评分。不过出题上，张老师承担较多，我就退化为Review即可，点评这点，做到最核心的要求：保证所有博客都能有及时点评，这点到后面已经习以为常，并没什么压力，手机上利用碎片时间刷刷也能点评完，反正一般人每天刷微博刷朋友圈也都浪费很多时间，刷博客点评其实只是切换了这个时间片，点评的内容可以是：
- 无论他做了什么，既然做了，就应该给予简单肯定。不过明显太水的就算了。
- 博客本身的bug，例如少了链接、没了照片...等等看似无关紧要的细节，这点也是从邹老师的一些点评中学习，细节上既然说了，或者要求了，如果没做到，就可以点评出来。
- 给出进一步迭代的建议。
- 针对性给出提问，例如某一点在SE上的现成的做法，提问+建议，推动实施。
- 紧扣基本点（多看书多看书）不厌其烦指出了，例如alpha+beta，基本都是那些点，学生是“洗耳恭听，坚决不改”的，如有能及时接收建议反馈改进的就算是收益，退一步“就是不改，但是做完”也算有成。我觉的这些就是需要在每篇博客下“重复”点评，而不是在助教自己博客上给个总结式点评。当然，我想肯定有有人觉的我好烦，那没办法，这是一个课程，课程结束我就不会去烦他了。
- 适当的外部链接，我也不知道有多少人会去点击看。
- 去github上fork、star、clone学生的项目代码，review他们的代码，例如：编码规范、模块划分、单元测试、功能等，能跑的就跑起来体验。这些都会用在点评和评分上。
- 以上的目标都是为了促进学生能迭代，培养他们对迭代的感觉，如果有效迭代就会看到迭代的力量，进而能自我迭代，达到自举学习的目标。
- 和老师协商好deadline和要求后，就一定要严格执行，没有严格执行就像你的单元测试程序放水一样，最终会导致整个项目的质量出问题，bug难寻。那么当然有些人会错过1，2次作业，怎么办？靠做额外的作业弥补！所以逻辑就是：一次作业发布的规则和deadline就要严格执行，错过了靠增加新的作业和练习补救。既能保证教学项目的迭代，又能增加学生的练习次数。
最后，是评分。这个点上，我基本能做到按时评分，我觉的评分算是教学项目里的单元测试，及时Test，出分，每个角色：教师、学生、助教、其他人，都能看到一个环节的质量和进度，这算是一个教学本身的scrum冲刺。我在这个过程中，认识到无论是学生的SE学习，还是教学本身，保持节奏是一件重要的事情：在一个milestone里，保持连续、均匀、细节到位的迭代。这点也是我希望所有的SE学生们都能意识到（通过已经过去的实践项目），并且在以后的职业生涯中（无论你干什么）去再次体会，实践的事情。另外一点是，我认为在每个milestone，都应该对时间是敏感的，充分意识到时间只会越来越少，所以能打提前量的就打提前量，不必每个milestone都到最后才去冲刺，如果不是课堂项目，你提前完成一个milestone，实际上可以利用多余的时间，立刻投入到下一个milestone的前置工作。
评分的内容上（参考：http://www.cnblogs.com/math/p/5066939.html）：
- 迭代完善给出动态的评分机制。毕竟每个老师都不一样，需要和他们随时协调。例如alpha和beta，我需要跟张老师协调过程和验收的比例。例如作业和练习分数的分开。加分的特例等。我采用的是动态的改进评分的表格，并且逐步细化计算的公式。公式展示的是计算的细节，说明我们并不是泛泛给分，而是严格考察每个checkitem。不过我也想要是企业里的HR这样给我们算KPI，我会好烦，太严格太细致是令人窒息的，不过这是个人感慨，并不影响我的助教工作。
- 每次给出两个排行榜：柱状图和累积表格。表格的项目，也逐步给出缩写表头，我当然喜欢全英文的表头，以显“Professional”,不过也会根据情况看是否利于阅读和排版。这里强调一点就是不给学生的名字，只给学号后3位和博客id，这点我觉的以后的助教都可以参考，反正一锤子解决部分老师对学生隐私的顾虑。然后，坚持表格里有可点击的超链接，当然我觉的理想情况是每个分数项都是对应单篇博客的超链接，不过偷懒的话，就只要在博客Id那一列给学生的博客主页即可。
- alpha和beta阶段可以把团队的具体评分过程也dump出来。alpha和beta的1/3和1/2，3/4的时间点可以私下对那些进度落后的team给个warning，不过我并没做，主要是自己也忙，而且怕被当作spam。不过评分的时候，可以把过程分的计算给出。这是一个子表，子表的内容也是遵循：累加积分项+映射到单次总分的规则。不多说，用Excel，1/3公式活，1/3编辑体力活，1/3用脚本和工具批处理，我觉的自己以前用Excel并不多，这个过程中反而进一步熟练了。
还有一些其他的细节，也会有利于干活，例如：
- 博客园上我关注班级的老师、学生的所有博客，这样我只要在博客园个人页面上的博客那一栏即可看到每天谁更新了博客，保证及时点评。
- 博客园上设置别人的回复信息会提示（我不喜欢它发送的邮件，邮件毕竟会漏看，不如自己主动去刷博客园查看信息提示），这样能及时收到学生的反馈并进一步跟踪。
- github上可以适当star学生的项目，利于跟踪。
- 使用脚本（我用的是LinqPad写C#脚本，处理日常的统计，批量处理Word、Excel等，我以前买过它的代码自动完成，.NET又是全功能类库，方便），我觉的每个程序员都应该掌握1个自己熟练的脚本语言，正则表达式，做日常批处理。
大概这样，我觉的这些工作，除去点评部分需要经验的地方，也许并不需要多么资深的业界工程师才能做到，如果助教(无论是校内还是校外)能把这些严格做到位，可以完成同样质量。即使是经验的部分，我之前也并未有系统的SE学习，反而是在构建之法的SE助教过程中才系统学习，当然如果一个SE班级在基本点上都没问题，那么会进入进一步比拼SE的知识点上，如果SE的基本知识点上又都没问题，那么就进入比拼产品了，毕竟产品和用户才是最终考验点，从这点来说，我也觉得是需要该课程进一步迭代的地方。我觉的我在基本的要求上做了一些，但是其实如果同样的过程，换一个学校，一个老师，一些学生，情况又会大不一样，可能不同情况下所需要的“基本工作”会不一样。但一旦找到需要的基本点，严格执行，应该是一个重要的事情。