开发流程：ADDIE与Scrum

开发游戏化的产品有两个主流方法。对学习与发展方面的专家，ADDIE模型是大家耳熟能详的。这是一个线性的瀑布式方法，包含相对独立的步骤：分析、设计、开发、实施和评估。实际中，流程并不是那么顺序执行。与之相对的是基于迭代的Scrum流程。

ADDIE

ADDIE过程模型是为教学而创立的五个单一却半独立的步骤。这五个步骤是分析、设计、开发、实施和评估。它也时而被引用为MADDIE模型，即把项目管理纳入其中。ADDIE经常与课堂教学课本和电子化学习模块的开发相关，被众多教学设计及电子化学习产品研制的公司采用。

在分析阶段，问题的类型会被解析，确认问题着实是缺少知识、期待教学，而不是诸如设计糟糕的流程之类的问题。分析阶段还考虑学习内容的类型，比如确定是陈述性知识，还是问题解决的知识。分析也要关注学员，他们的必备知识和学习倾向；此外还考量可行的学习技术，着眼学习方案的交付。

一旦分析完毕，设计接棒。在这个阶段，教学目标会落实到字面，特别是使用行为可测量性的语言（比如，“学员能够识别……”）。教学策略会被遴选出来，比如用正例还是反例。与行为目标对应的评测条目也会出炉。这一过程的典型产出就是优质充实的开发文档，还配有内容大纲、教学策略细节、内置性的和总结性的测试条目清单，以及故事剧本。客户通常要在设计文档上签字，开发人员才着手落实设计方案，而不必担心不测的变动。

开发阶段就是编写程序和教材制作。其间涉及增加必要连接，为教学创建界面单元，或使用现有模板。还包括制作和加载图像和声音文件以配合教学活动。在贯穿开发阶段的各个节点上，构成型评估流程在进行，学员和相关方代表参加评估、检查教材。如果需要变化，流程返回到设计阶段，或改变就地生效。

当开发结束，实施登场。这实际上就是教材向学员的推送过程。它主要保证教材能运行于任何必要的电脑，或教师知道如何使用教材。

评估实际上贯穿于模型的始终，有两种类型：构成性评估和教学终极评估。通过设计和开发时期的构成性评估，教材内容会被审核，反馈提交给开发团队，必要的改变会发生。教学终极评估会发生在使用教材后的测评完成以后。

管理或项目管理有时也被列模型之中。这特指一个项目经理监管由教学设计者、图形美术师、程序员或文档开发人员，以及提供内容的业务资深人士组成的团队。

Scrum

Scrum是一种敏捷开发的使用迭代策略的方法论，用于复杂和不可预测的项目。它与大规模软件开发相关，被许多开发大型多人在线游戏的公司用来更新和维护自己的产品。Scrum不是缩略语；它来自橄榄球运动，指球队在运动场移动时橄榄球从一个人传到另一个人。

一个利益相关人、一个产品经理或一个程序员收到一条未来的洞见、一个新产品的想法或一单更新，Scrum流程就开始了。产品经理为用户发声，所以代表业务或客户。

从洞见或想法开始，需求清单应运而生，专业上称作产品代办列表。由于在项目生命周期内层出不穷的新需求，产品代办列表是不完整的。与ADDIE试图把所有可能的需求事先放入设计文档的做法不同，Scrum照顾新需求，允许它们在任意迭代周期进入项目，每一个迭代周期称为一个冲刺。产品经理负责产品代办列表中表项的优先排序。根据Scrum产品开发团队对开发时长的估计，产品经理决定列表表项被认领的顺序。

图9-1说明了Scrum团队概念。团队是跨职能的，尽管教学游戏开发需要各种专业技能，比如：编程、教学设计、艺术加工、动画制作，甚至音乐编排，但组成人员都非专职，这着实为跨职能团队建设增加了点难度。大多数Scrum团队由7人组成，但也可以根据情况上下浮动。理想的情况是团队自治，但有的团队配备项目经理。

图9-1　形象化描绘现实的Scrum

资料来源：Image reprinted with permission of the artist，Kristin Bittner.

团队与产品经理会面，从产品代办列表中挑选项目放入冲刺代办列表中，这样项目就启动了。团队只做冲刺列表中的活，冲刺周期从2周到5周不等，甚至更长，但短期为佳。每个冲刺周期第一天用于作计划，最后一天用于作检查。每个冲刺的目标是开发完备的功能，且可供项目经理和局外的利益代表们核查。在冲刺周期内，不能对冲刺代办列表进行任何修改。

完成了本轮冲刺检查后，通常情况下，局外利益代表和产品经理会提供反馈，通常还会引入额外的急迫需求，这些需求就进入到产品代办列表重新排序。流程中这段时间是允许修改和变化的；只要优先权够高，可以对下一个冲刺进行修改。这个流程着眼于快速开发，及便利导入变化，它有利于改善最终产品的质量、降低风险、提高投资回报。在Scrum中，优化产品代办列表及后面的冲刺代办列报的一条原则是以投资回报为纲。

为确保团队专注于冲刺，每天的要安排例会，例会就叫Scrum。每天例会全组出席，每个人回答三个问题，力争Scrum会议短小高效。问题是：

·自从上次以来我做了什么？

·接下来我做什么？

·我碰到了哪些问题？

有时组织聘请一位Scrum船长，保证每天的例会顺利进行，帮助Scrum团队规避组织各种干扰，聚焦重心，以及监管Scrum项目。

Scrum船长并非团队领导；他像一个守门员保证团队无碍工作，并在整个流程中提供咨询和辅导。Scrum船长还帮助队员思索可能引起迟延的难题或争议。项目的进度用一个叫燃尽图的工具跟踪，它图示出多少工作还没做和剩下多少时间，燃尽图通常会张贴在可见区，所以每个人都可以看到。一般情况下，冲刺和项目都有各自的燃尽图。

混合模式

组织内部的绝大多数游戏化项目不会像大规模多人在线游戏（MMO）那样耗费太多时间和人力，甚至不如游戏《愤怒的小鸟》的投入。Scrum模型对于小项目来说大材小用了。然而ADDIE模型对于设计和开发过程中不可避免的变化缺乏关照。因此游戏化项目的大小直接影响项目复杂度、时长和在设计、开发和实施方面的投入。

开发一个单机版、可下载、学习词汇的15分钟游戏所花费的经历与一个网络版、跨越14个国家、学习领导技能的多用户角色扮演游戏所投入的精力，不能同日而语。

下面的流程是两种模型的混搭，而很可能因项目的规模、标的宽度和复杂程度进行调整。这里展示的游戏化产品制作流程实际上已经成功孵化了学习游戏。你很可能根据自己的项目需要做适当调整，下面讲述的是基本组成元素。

开发流程的第一步是确定学习的产出是什么。是情感的变化还是行为的改变？生产力会提高吗？一个成功的基于游戏的干预方案，其应用结果有何不同凡响？这些问题都要有答案后，有效地结果才会出现。这类似于ADDIE模型的分析阶段。

一旦有答案了，确定所讲内容的类型。内容经常跨越不同的学习领域，从概念学习到问题的解决。辨别内容的类型和领域，同时找到与每个内容类型对应的学习目标，这会帮助你分析出必要的游戏框架和要素。这一步还要确定大多数学员的动机是内生的还是外来的，因为它决定你如何创建奖励和积分制度。

然后要和业务资深人士、程序员、美术设计师、游戏设计师和教学设计师聚集一堂，群策群力。这一头脑风暴过程应该收获适量的游戏囊括的内容和流程知识，以及原型试制的思路、游戏中的施教时刻和从程序设计角度理解技术可行性。它还包括拟定粗线条的故事梗概，考虑积分和奖励制度。也涉及确定游戏里的活动，这些活动可以有效传授教学重点，这些教学重点由表9-1定义的框架认定的。

表9-1　把游戏内的活动与学习评估联系起来

集思广益也好，在游戏活动中传道授业上统一思想也罢，最终落脚点是游戏化设计文档。它负责说明游戏的设计，明确假设前提，描述内容传授的具体活动。它不是一个200页的详细文档，而是一个纲领性的说明，令人提纲挈领地理解待开发的游戏。从Scrum流程角度看它就是产品代办列表。

此刻，一个不赖的想法是在第一个冲刺期内建立纸上模型并尝试游戏。此时的模型无须精心雕琢，它只要能尽可能准确地传递出游戏的设想即可。如果纸上的模型玩起来枯燥、无趣，那电子版的也不会好到哪去。对于一个易用软件的开发，这一步实际会被有意省略。但这里不要忽略！尝试“纸上谈兵”版的教学游戏，验证想法的有效程度非同一般。这其中的洞察和领悟对设计和教学假设的价值无可取代，当然还将获得优质的构成性反馈。

另一个冲刺可同时进行，让美术设计师和教学设计师一道开发剧本和概念艺术。剧本和概念艺术能展示原型设计中游戏各个部分的互动和整体连贯。目的是把游戏活动的完整顺序在纸面上呈现。没有艺术的表现，人们很难对游戏进行视觉化，而制作剧本可以方便设计团队解释游戏过程。

特别是游戏化设计文档要帮助开发团队遵循游戏既有的观念和想法，不能偏离。而那些不能直接参与游戏化项目的人无法真正理解到底怎么回事，也就无法给出恰当的反馈，但当他们看到剧本和概念艺术后，一切就会好转。那时他们的反馈也就更深刻和更具参考价值。

一个完整的剧本和视觉艺术需要测试，即要先展示给焦点小组，小组能提供反馈并能解答设计团队提出的各种问题。如果焦点问题没有提出，反馈将变得零散，作用也大打折扣。问题应该围绕游戏化项目的预期效果展开，比如它多大程度上完成了教学目的？老师或培训师们脑海中的游戏是什么样，而预期的推广障碍是什么？

一旦获得反馈，它应该反映到必要的文档和剧本中，立竿见影。从这一点出发，启动开发冲刺。团队全力以赴开发出第一层的游戏功能，然后与利益相关代表会面，观摩成果，然后启动下一轮冲刺。游戏开发全程的每日例会很重要。每个冲刺后，尝试游戏并检验新开发出来的部分能否在可游戏性和教学性两者间左右逢源。

一旦游戏化项目最终完成开发，按照实施步骤发布并收集终极评估。照此办理，你的游戏化努力会结出正果。