为不同学习项目选择最佳开发模式

　　近来，听闻了多方有关最佳教学设计方法的激情辩论，我也应中国《培训》杂志之邀，对时下最受欢迎的一些方法提出自己的见解。ADDIE，这一经过时间考验的、学术化的方法本来已经较为大众接受，但最近需要面对新的挑战——有人认为一些推陈出新的方法似乎可以比ADDIE更好地应用到工作中。过去，人们成长于导师指导的培训背景之下，更青睐已有的成熟的经验;如今，年轻人建立了e-Learning，更希望获得最新的知识。

　　和大多数辩论的走向差不多，这一辩题的真相是“没有哪一种教学设计方法是完美的”。它们在应用时都会遇到难题，即便是趋于完美的方法，也不可能担保组织中的绩效一定会通过培训而改变。

　　直到e-Learning变得流行之后，培训领域才开始关注迭代原型开发(iterative prototyping)和敏捷(Agile)方法。目前，在学习和发展领域，开发人员基本都处于对ADDIE、SAM和Agile这三种方法的选择和辩论当中。接下来，我将谈一谈这三种教学设计方法在应用时的优缺点。你可以参考其优势与局限性，选择最适合眼前学习项目的开发模式。

　　ADDIE：自上而下的开发策略

　　假设你想买一辆新车。这是一个有始有终的“过程”，有着清晰可测的目标——找到既符合你的生活方式又能满足预算的新车，这为你的选择建立了标准。

　　在这个故事中，你过去曾经买过车，所以对于接下来如何去做以及自己的喜好都非常清楚。在设计阶段，需要阐明真正需求的细节。分析之后，你将有关车的基本需求列出来：

　　·5人座

　　·四门

　　·可以放下大袋杂物的后备箱

　　·黑色或深灰色

　　·有天窗

　　·自动换挡

　　·耗油每加仑能跑30英里

　　带上这一份设计清单，你开始寻找最佳汽车，逐步开拓符合需求的可选项。之后，挑选好了汽车，你将其开回家，成功地执行了这一任务。随着对新车的了解越多，你会发现它越来越多的优缺点，可能不得不对其进行调整，让自己使用得更顺手。在这一阶段中，你会评估自己是否做出了最佳选择，或许将通过此次反思，学到更有效地购买新车的方法。

　　分析、设计、开发、实施、评估，这是数千年来人们使用的充满逻辑且符合自然规律的问题解决步骤。我们讨论的三种方法都存在这五大步骤，但开展每一个步骤时的具体做法完全不同。例如，每一种方法都要求在初始之时就对需求进行分析，而自上而下式(Top Down)的方法会要求在最早的阶段进行分析。分析得太迟会产生一些难以忽略的问题，导致在解决这些问题时需要付出高昂的代价。

　　ADDIE模型这种自上而下的方法也被称为瀑布法，这个称呼体现了在应用时面对的最大挑战——每个阶段只能进行一个步骤，完成该步骤后不会再循环回来，就像瀑布一样。例如，当分析完成时，你已经创造了一个需求文档，但如果你的需求一直改变，就会造成昂贵的返工，而变化通常时时刻刻都在发生。

　　在教学设计与课程开发过程中，事物变化的基本原因主要有两点：

　　·整个开发过程用时过长，外界早已千变万化。

　　·业务相关的主题内容专家未能全程参与，所以信息很不完整。

　　因此，别想着和“变化”做抗争或试图去控制“变化”，你需要根据ADDIE本身的优缺点，来判断是否选择这一方法(见图表1、2)。

　　SAM：循环反复的原型测试

　　让我们来看另一个故事。你正在寻找从家到工作地点的最佳交通方式，两地相距约5英里，较有环保意识的你决定选择电动车或自行车为交通工具。这也可以被视作一个有始有终的项目，通过清晰可测量的目标，找到既符合生活方式又满足预算的新自行车。你会做些什么来启动这一项目?

　　·做调研，找出可用的自行车类型，列出其特征和价格

　　·参考网页或者杂志上的相关评论与比较文章

　　·查看你的银行账户，确认预算是多少

　　·向已经买过新自行车的朋友取经

　　这将帮助你对之前从未做过的事情有新的认识，进而找到最适合你的自行车。每天都会有新型号的自行车被生产出来，你将会找到一些以前从不知道的可选项。例如，可以折叠放入轻便的袋子中的自行车。

　　当需求和技术都不够明确并且很可能发生变动时，SAM是更好的学习设计方法。在SAM方法中，首先让关键的利益相关者和课程开发者会面，列出一份高级需求清单，这被称为“SAVVY start”(认知启动)。所有参与其中的人都知道这份清单是学习解决方案的高级草图，而开发者和客户之间的协作对SAM的成功而言至关重要。由于需求不够明确，分析过程会短很多，更多的时间会花费在构建原型(prototyping)和设计方案上。某种意义上说，分析会在与设计的相互作用下产生。

　　通过和一群朋友交谈而完成了“新自行车项目”的分析阶段之后，你将根据对之前所有可选项的调研做出判定：

　　·理想中的自行车应当足够小巧，可以很方便地摆放在工作地点和家中

　　·自行车必须有一个装东西的篮子

　　·为了可持续问题，你决定不用电力产品

　　然而，目前的信息还很少，不足以让你决定购买哪辆自行车。下一步，是要试骑符合这些标准的自行车。每试过一辆不同的自行车之后，你就可以发现这辆车的优缺点，然后据此信息挑选下一辆试骑的自行车。通常而言，试过三辆之后，你的选择范围可缩小至某一个品牌，不过其各个型号之间也会有细微的差异，例如重量、颜色、价格等。

　　SAM就这样利用迭代设计环节来试用产品。规模较小的团队中，开发者和客户会经历三个迭代循环的步骤——设计、试用原型、评估。在最后，会产生一份“设计样本”(Design Proof)，即学习蓝图。

　　既然已经决定了自行车的品牌，接下来就需要登录网站，搜索颜色、重量和价格这三要素的最佳组合，并确定购买。

　　在SAM当中，“设计样本”得到认可之后，你将进入迭代开发阶段(Iterative Development Phase)。e-Learning的大致框架已经就绪，现在是时候来正式开发了。一般会开发三个测试版本：Alpha, Beta, Gold。Alpha是这一阶段中的第一个版本，也是开发者和客户做出大幅改动的最后机会，因此耗时最长，通常由项目组内部的专家或有限的相关客户进行测试;Beta版本会进行公测，由外部的拥有相关技能的人来测试;Gold版本即最后被批准可执行的版本。

　　值得注意的是，在这种方法里，评估在最后并不明晰。设计和开发过程中的每一次迭代循环完成之后，都会进行评估。课程的评估只能在学员上过课以及将所学用到工作中之后立即进行，而这些测评行为很可能会在原始版本推出数月之后才会发生。

　　SAM包括四个总步骤：分析、设计、开发和实施。在这整个过程当中，都有真正的客户参加迭代循环，以助于在不破坏任何设计的情况下对课程进行改动。这使教学的质量更高(见图表3、4)。

　　Agile：持续改进的处理次序

　　现在，你发现可以买一些装备来制造属于自己的自行车，这样可以省一大笔钱，还有一个在制造方面很有天赋的朋友答应帮忙。你会如何开始这个项目?

　　·与你的朋友会面，先预估如何实施，需要花费多长时间

　　·购买基础的自行车装备

　　·购买你制造自行车所需的其余材料

　　·和你朋友一起用三天周末的时间来制造自行车，期间无中断

　　假设你已经做过所有研究，经过分析已经知道自己想要什么样的自行车，也做好了制造的准备。在与朋友共进午餐之时，你俩定下了制造自行车需要的基本零件。你的朋友列出了组装每一部分所需的时间：

　　·脚踏组件——2小时

　　·车把手——1小时

　　·座椅——1小时

　　除了这些基本部件，你还想添加其他零件以增强功能。下面是你列出的清单以及你朋友认为组装每一部分所花的时间：

　　·载物车篓——1小时

　　·临时停车用的撑脚架——1小时

　　·在支撑架上涂写你的名字——3小时

　　你俩决定在第一天组装第一份清单中的三个基本部件(共耗时4小时);第一天结束时，需要确定第二天能够完成哪些增强功能的组装;第二天结束的时候(共耗时5小时)，需要决定第三天组装哪些部件。你们有可能需要更多时间，所以这个项目可能持续到下周末。

　　总而言之，你们在第一天开始工作。座椅安装得很快，但脚踏组件要经过多次调整才能到达正确的高度结果，你们低估了完成这项任务所需的时间，没法按计划开始组装车把手。当你们第二天进行回顾的时候，发现只有4个小时的工作时间，由于安装车把手还需要花1小时，所以第二天你们选择安装车篓和撑脚架，推迟涂写名字的计划。第二天一切进展顺利。车把手、车篓和撑脚架都在预计时间内安装完毕。你决定将涂写名字计划推迟到另一个时间段，并且认为整个自行车组装项目差不多已经完成。

　　注意，SAM和Agile有所区别。在SAM中，你反复进行原型测试和迭代构建;而在Agile中，你要让开发者和客户全程合作，先将大的需求分解为碎片化的特性，然后优先考虑开发每个特性所需花费的时间和预算。随着过程的推进，你对这一项目的复杂性了解越多，对某些开发工作的顺序安排也会像期望的那样变得更加实际。

　　托伦斯在线学习(Torrance Elearning)的梅根·托伦斯(Megan Torrance)，创建了一种方法叫作LLAMA(the Lot Like Agile Methods Approach)。在敏捷开发中，可以借此来为客户搭建e-Learning模块。实施LLAMA需要注意三大关键：

　　第一，开发者和客户之间的启动会议有时被称为“Scrum”，与SAVVY Start类似。以完成时间为拆分单位，需求被分解成了不同的特性。客户将自己要求的特性列出来(这只是根据他们当时所拥有的最佳信息而列出的要求，很有可能发生变化)，然后开发者来判断完成每一个要求所需花费的时间。

　　第二，客户会决定优先完成哪一种特性，在具体的时段中安排处理顺序。每一个平均时段(例如1天)被称为“Sprint”(短跑冲刺)。

　　第三，在每一个Sprint之后，下一个平均时段的工作时间量取决于上一个Sprint当中的运作情况。这被称为“Velocity”(速率)。

　　最后，直到客户看到产品拥有了他们想要的特性，项目才会结束。

　　对于该方法而言，还有两个关键的成功因素，但同时也具有挑战性：

　　·在构建过程中，客户最好全程亲自出席相关研讨，特别是开发者提出问题以及需要反馈的时候。在我们目前的多任务工作文化当中，要做到这一点很难。

　　·每一个Sprint当中创建的产品特性都应具体落实。与客户全程合作时，设计和构建可以很好地完成，每一个特性都会得到落实(经历分析、设计、开发、实施和评估五大步骤，每次针对一个特性)。

　　如果你为大型企业工作，该方式将增加一些小挑战：

　　·企业在做预算时，通常会要求你提前对所有的费用做出计划。

　　·同时将开发者和客户集中好几周，来完成某个项目，这并非大多数公司里的工作方式。

　　那么，关于这种敏捷开发方法，究竟适合应用于何种学习项目?你可以参考图表5与图表6当中的建议。