如何交付一场内部培训

回成都后，银大伟看到我发的《如何交付一场企业内训 - 某客户 OO BootCamp 总结》 ，希望我和 Suncorp Health 团队 Tech Lead 尤青松一起，完成对其团队的培训。 最近在学习课程开发，借博客大赛，总结分享给大家。

FAST 课程开发

上图是 FAST 课程开发方法流程，FAST 是四句话的首字母缩写:

  • Focus on problems
  • Aggregate Methods
  • Select Instructions
  • Transfigure outcomes

Focus on problems - 聚焦问题

培训课程必须与企业业务紧密结合，解决绩效问题，不然业务部门就会觉得培训浪费时间，指派一些初级员工去走个过场，而培训团队也会觉得自己这么辛苦业务部门居然不配合。

在收集问题的过程中，可能会说一些很感性的描述，比如没有 Sense，这时需要问问题挖掘背后的原因。

Aggregate Methods - 整合方法

人的精力是有限的，培训师很难同时成为技术和培训的专家，那就需要和技术专家一起来开发课程。 我采取萃取经验的方法，邀请团队的 Tech Lead 青松每堂课前列出主要的知识点，并一起讨论整合到课程中。

Select Instructions - 精选教法

培训的内容需要通过培训手法传递到学员身上，培训内容以培训师为中心，但培训手法应以学员为中心，以提高转化率。 提到分享，我们熟知的有 Session 和 Workshop 两种形式。而培训手法则丰富得多，大致可分为以下十类:

  • 阅读材料
  • 听讲和观看
  • 提问和发言
  • 大组讨论
  • 小组讨论
  • 案例分析
  • 角色扮演
  • 自我评测
  • 学员练习
  • 情景模拟

有这么多教学方法，我们应该如何选择呢？ 首先要知道，每一种教学方法，学员的参与度是不一样的。 我们要设计「课程心电图」，各种手法搭配使用，让学员体验过山车一样的跌宕起伏。

Transfigure outcomes - 优化成果

虽然提前有设计，但培训过程中总有意料之外的事情，比如第二天突然加入了 QA 正荷，为了形象的解释什么是 Stub 和 Mock，我们采用了角色扮演的方式。在重构的 Coding Dojo 中，QA 的参与感较弱，我邀请她帮我做引导，问操作电脑的 Pair两个问题:

  • 你发现了什么 Smell？
  • 你准备用什么手法来消除它？

经过这次培训，我从 OO Bootcamp 中提取出了 TDD Bootcamp(将持续优化)。

柯氏四级培训评估模式

培训的效果评估是个难题，柯氏四级培训评估模式(Kirkpatrick Model)给了个大的方向，它由国际著名学者威斯康辛大学（Wisconsin University）教授唐纳德.L.柯克帕特里克（Donald.L.Kirkpatrick）于1959年提出，是世界上应用最广泛的培训评估工具，在培训评估领域具有难以撼动的地位。 四级分别为:

  • 反应
  • 效果
  • 行为
  • 成果

反应 - 评估被培训者的满意程度

改进建议

内容和形式都非常不错。TDD那部分，也许可以加个录制好的视频（就像重构的那个视频一样）。时间安排很合理。
非常好，非常好，是我参加过最有干货的培训
时间安排希望可以有间隔，这样可以有更多的时间去消化巩固所学的东西 :)
连续的培训，中间虽然有homework，但是因为上班，所以自我实践得时间不太够，如果能够中间间隔一天，或者前2天后中间过了几天在来，让我们在工作中实践一下然后回来课堂印证应该不错
[内容]：可能时间不充裕，内容不够详细，但内容很完整，很连贯，课程间的逻辑也很清晰，
[形式]：以实践为主的形式使氛围非常活跃，学得很快乐。
[时间安排]：很好
形式：讲课过程中，有好几次讲着讲着就暂停了，感觉是进入了自己的思考，其实有任何新的想法可以说出来大家一起讨论，也会让大家get到讲师的思考
形式：也许可以再开放一点，更加激情一些，可以带动学员的积极性
内容：布置了作业，需要大家一起code review，不然学员写了作业没有提升，不知道自己写的怎么样（可以总结下大家的公共问题，然后一起解决，这次可能也有很多人没做作业，以后的培训如果大家都做了作业可以这样run一次）

学习效果 - 测定被培训者的学习获得程度

在课程开始时，收集了大家关于 TDD 的问题，如下: 课程结束时，邀请大家尝试回答以上问题， 以测试大家的知识获取程度。 并邀请大家在金数据填写自己的感想:

第一天的Tasking：知道了做任务拆分时可以遵循的一些原则，如MECE。以前都是凭直觉在拆分任务。最令我感受最深的还是用画图的形式将问题域和解决方案域可视化出来，这样既可以作为pair之前或团队内部的沟通工具，同时又可以避免让自己陷入深度优先的思考方式从而减少遗漏。同时，启发式的互动教学是我在以后的培训过程当中可以练习。
第二天的单元测试：虽然写单元测试知道测什么怎么测，也能熟练运用。但是却不能一句话概括单元测试，以及单元测试原则，这是自己应该要思考的地方。通过这堂课加深了对单元测试的理解，以及First原则和Right-BICEP原则，这样以后给新人讲解单元测试的时候可以用上。感受最深的就是最后关于Mock和Stub的角色扮演，十分恰当的例子，让大家对这两种测试替身有了更深的理解。
第三天重构：对我来说，以前记住的那些坏味道名字和重构手法已经快忘记了。。主要还是因为平时没有怎么用到，即便是用到的时候也不会去管这个手法叫什么名字，或者说消除的是什么坏味道，总是凭直觉觉得就该这么重构。通过这堂课以后觉得自己平时的练习比较少难免会有生疏。另外，codedojo的形式可以很好的暴露每个人的编程习惯，pair或团队的默契程度，以及如何让团队达成一致等等问题。
第四天TDD：我之前给别人做TDD培训的时候基本上是自己的灌输TDD，缺少对受众进行启发式引导，互动性不强，所以效果可能没那么好，通过这几次的课程让我深刻体会了这种方式的好处。通过对codedojo过程中发现的各种问题及时进行针对性解答，既解答了大家在实践TDD过程中的一些困惑，同时也让大家知道应该怎么做才算是好的TDD实践。
最后的juggling ball的例子太完美了。服。。
对我个人而言，以前觉得TDD会让开发变慢，在工作中有时候会采用，但是如果是自己的业余项目的话，可能就根本不会，也感受到后期时候代码的难以维护性，以后应该会主动去使用TDD，在自己的业余项目中也是
1，只重构代码可读性差，然后需求变动快的代码
2，不重构代码丑，但是完全没bug的代码
3，不重构代码丑，但是完全没用到的代码
4，重构过程是同先解决命名，明确代码逻辑；其次解决代码重复的问题；以此为基础才逐渐抽象出设计模式
5，重构不一定全部都要套设计模式，觉得代码思路清晰即可
6，适当重构，只解决当前需要的重构，也就是说如果很多类型确定了一定不会再变了，就不需要增加类型扩展等功能（其他模式同样适用）
7，一定记住，从最简单的开始做，不要一开就动大手脚重构
8，TDD依赖tasking，UT，implement，refactor：
首先tasking要把需求明确，通过穷举输入输出，确定功能的边界；还要穷举所有的处理过程，确定实现思路；要满足不重不漏的原则MEMC
其次开始单元测试代码，测试用例来自于tasking中的输入输出，并且以输入输出驱动出处理过程；测试需要满足FIRST, Right-BICEP原则
再次实现具体的逻辑，使测试通过；遵循baby step（fake it，obvious impl，triangle）
最后进行重构，需要多使用快捷键，看懂code smell，并用对应的tech skill消除code smell（问题的关键，否则重构就是在乱重构）
9，TDD时，直接针对tasking分解出的最外层需求开始做，逐步驱动出自己的解决方案（避免从最里层做产生的多余测试）
10，遇到不知道如何实现时，从最外层抽象的解决方法开始逐步细化到具体的实现中
11，每个tasking在实现时一定要有抽象层次，每层只做每层的事情，逐步细化
12，重构的时候，一定要小步，确保重构的小步（不能改变测试，同时需要保证测试在每个步骤后是通过的）
13，TDD过程中，时刻保持代码的语义明确
14，测试代码和实现代码的重复也是code smell
收获和感受：以前只是听过TDD的大名， 并没有从心底认可它，这次参加了小波老师的培训，收获颇丰，从理论到实践，完全体会了TDD的好处，比如：通过Tasking加深对需求的理解，在编码前分析画图；分离关注点，减小实现的压力；得到更迅速的反馈，一切尽在把握之中；测试驱动开发，反推实现逻辑，从Red到Green；有单元测试反馈，再也不担心重构代码会引起各种未知结果。
[收获]：这次完整的学习和实践了一遍TDD，更新了我对于写代码的认识，更深刻地理解了TDD的好处以及如何实践TDD。也帮我看到了更多思考问题的方法，比如：复杂问题拆解成更小的问题，从特殊到一般的归纳推理等。还有看到idea快捷键在重构方面的强大
[感受]：感觉收获挺大的，但也担心回到工作中，又会回到自己习惯的开发方法。
感觉自己进步很大，自己的编程习惯和编程思维受到了应该说有点颠覆影响，非常高兴公司和波哥能给提供我这样的机会

行为 - 考察被培训者的知识运用程度

根据影响力原则中的承诺与一致原则，我邀请大家在金数据填写接下来会采取的行动:

接下来的Actions：
1. 跟团队每个人过一下OO bootcamp的感受，跟踪大家的Action，同时评估下一步可能引入的培训
2. 本月内在团队内部再搞一次TDD的codedojo
3. 用6周时间复习6大类重构手法。每周一个大类。刻意练习小步重构
4. 将遇到的Story卡进行可视化的任务拆分。去影响团队所有人养成这种习惯
5. 希望有机会能和小波老师一起pair主持codedojo或code retreat等活动。锻炼自己同时给社区做贡献。
接下来（学习和练习计划）
首先会把Refactor网站上的code smell和tech skill 总结提炼一遍（目前正在做，每过一个都形成了一篇博文，就是一些简单的说明和总结，有点类似笔记）
其次会把Design pattern过一遍（目前也在做，通过强制自己使用设计模式练习设计模式，一遍理解什么问题可以用到设计模式，使用哪种设计模式）
最后会通过网上的kata练习所有TDD相关的知识点，把上述一点的内容窜起来，熟练掌握TDD的思想和做法，并应用到项目中去
在项目中会直接练习TDD，虽然现在是半桶水
[接下来的行动]：要拿出更多的时间练习TDD，让练习中不自觉的改变自己的习惯。趁热把收获到的东西用文学整理出来。
后面纠正自己的不良编程习惯和编程思维，再自己的项目中多多实践，不要将就，要先理清思路，再coding
接下来的行动：
通过这次培训深刻体会到了TDD的好处，以后要落实到工作中！
1. 写总结，加深对所学的理解；
2. 有意识的去加强锻炼重构快捷键度使用；
3. 运用TDD在工作中，增加实践；
4. 借鉴TDD中的模式(将大的、难的拆分成简单的、易实现的，分离关注点)，运用在新技术学习中；

并持续提醒大家执行:

成果 - 计算培训创造的经济效益

理论上可以对比培训前后迭代速率大概计算培训效益。 不过真实项目中可变因素太多，以我现在的能力和经验，还无法准确量化。

培训师 VS 讲师

一直搞不清楚培训师和讲师到底有啥区别，刚刚体会到一点：课程开发能力是讲师和培训师的主要区别。 讲师通常有现成的课程，甚至 PPT，只需根据 PPT 进行讲解，形式以讲为主。 培训师需要调研绩效问题、发现培训需求、开发培训课程、布置作业、定期检查成果、分阶段进行深化训练，根据员工情况量身打造所授内容和授课方法。

感谢 尤青松，杨倚，张鑫，林晨，杨岳彤，高诗意，余正荷!

换一篇 | 去首页