敏捷开发思想谈 敏捷的原则 敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先，请大家有这么个概念： 敏捷开发绝对不是一套一成不变的标准化流程。而更多的是一种自适应，自我优化的流程优化理念。
并没有一定的流程，而是需要大家有对任何自己觉得不对的，不正确的，效率低下的事情的警觉性，和将之提出来并进一步改正的行动力。 其次，敏捷之于游戏开发，则更要体现人对游戏本身品质的把握，而非对各种文档的审核，这就是和传统软件开发区别最大的地方。 所以，没有最好的流程，只要是合适并且能够持续优化的流程就是好的。
所以： l 不一样的项目经理会有不一样的流程 l 一样的项目经理，不一样的团队，也会有不一样的流程 l 一样的项目经理，一样的团队，每隔一段时间，都还会有不一样的流程。
为什么我们要迭代？ 进行游戏开发，首先请大家对此铭记于心： l 我们的设计不一定是我们真正想要的 l 文档内容在我们想象中和实际体验版本时的感受不相等 l 我们没法100%的思考到所有需要思考的角落 同样，要理解为什么要使用迭代，我们需要明白迭代开发从何而来。最初，软件开发行业中，一般都由需求方提需求，开发方拿到需求开始分析设计，一次性开发成型交付。随着行业的发展，软件复杂度的增大，需求变化的增加，大家发现一次成型的版本往往无法满足需求方的需要，于是返工。当这样的情况多了之后，返工就成了一种标准化的流程，系统化的返工其实就是我们所谓的迭代了。当然这是一种比较民间的解释，但是在游戏产业中，这也说明了： l 迭代的目的是为了应付需求的变化。 这里的需求变化需要我们的额外注意： l 游戏产业中的需求变化，并非只是指策划或需求方在中途站出来说自己的想法有变。更多的时候，是自己在进行游戏开发的过程中，出于对开发的游戏的认知的加深产生的需求设计的变化。一般来说游戏的需求来源于设计，但是我们的设计却往往并不是我们真实的需求。或者说，我们的设计往往不能满足我们真实的需求。
例如，我们需要一个激烈爽快的单体攻击技能，那么我们的设计可能会涉及到，这个技能的功能，伤害，消耗，动画播放等。这个设计还会涉及到表现：比如技能的动作如何，特效如何，播放速度如何，镜头如何。当我们看到这些设计，我们是否就能确定这些设计能够满足我们的需求？进一步，就算我们看到设计之后，认为能够满足了我们的需求了，但是否在游戏版本中我们实际体验的时候，实际效果能100%符合我们的预期？ 当我们清醒地认识到： l 无论我们在设计上花多少时间，我们都无法完全消除设计的实际效果和预期的差距。甚至在超过某种程度之后，我们花在设计上的时间将会形成浪费（这就是所谓的OVER-DESIGN）。 我们就应该开始考虑，什么时候设计应该停止，什么时候我们就应该开始先做，然后预留足够的时间，把那些可能出现的，和必然出现的问题，留给我们后续的迭代来发现和解决。而不是把这些问题试图在一开始全部解决掉，第一，不现实，第二，不科学。
什么是迭代 那么，迭代究竟是什么？ 首先要申明一点是，其实我们现在谈论的迭代并不是纯粹的迭代，而是迭代加增量开发。纯粹的迭代是指没有新需求的加入，第一个版本实现的内容就已经完整，之后的版本只是之前内容的优化。而增量，则指下一个版本是在上一个版本基础上增加内容的开发形式。 那么，迭代加增量开发的意思就显而易见了，而我们需要的开发模式就是这种： l 在不断以版本为基础的增量功能开发的基础上，不断对已经有的功能进行完善和优化。这就是狭义的迭代 进一步来讲，广义的迭代，则不仅限于我们的功能开发。而且还要对于我们本身的流程，工具，工作方式，方法，习惯等等所有可以改变，可以优化的地方进行优化，进行修改。最终的目的就是通过一个个版本迭代开发，不只功能品质在变好，团队效率，团队流程等各个方面都会变得越来越好。最终形成一个真的具有战斗力的团队。 周期总结会议，以及一系列的问题改正，优化提高事项，以及平时提倡的交流，对于变化的拥抱等等，都是为了这个目标而发生的。所以， l 敏捷开发是一种精神，而不是一种固定的形式。我们需要有一切都是可以改变的心态和准备，并且真的可以着手去改变任何我们觉得有问题的东西，这样才能真正发挥敏捷迭代开发的优势。
如何迭代 迭代的漩涡 首先，我们抽象一下，以便大家能简单的明白迭代的形式。迭代就像是一个漩涡，从漩涡中心开始旋转，越转越大。而处于迭代最中心，所有的东西都围绕它来转动的那个核心，就是我们的产品订单（故事清单）。 而那条旋转的线，就是我们的版本。版本永远围绕着我们的故事清单来开发，（故事清单，抽取于我们的游戏的设计），版本总是由故事清单里寻找需要完成的功能，再将根据实际版本得到的反馈，并更新故事清单。于是功能清单的功能越发的有价值，而版本本身也会越来越有价值。 迭代的步骤 那么，我们的版本该如何围绕我们的功能清单来画这个漩涡？ 首先，漩涡是一个环绕的圈，所以我们先确定圈的长度： l 一个迭代的长度 在这段固定长度中，它其实是一条单向封闭线性的线段，有始有终。有始有终的过程才能被量化和计划。在线段开始时我们从产品清单中取得信息，在结尾会释放一个版本并向产品订单反馈信息。 再进一步深入： 在这线段的开头，我们要从产品订单中取得什么？故事。什么样的故事？价值（优先级）总和最大，且大小（故事点）不超过我们一个周期工作量的故事。仅仅如此么？当然不是，首先，有一个重要的概念：
l 系统 也许有几个故事隶属于同一个系统下，它们共同组成了这个系统，它们全部完成，或者至少关键部分完成。这个系统才是完整的。当系统不完整的时候，这些功能的乐趣根本无法体现。 那么，有可能当我们选择这个周期开发某个高价值功能时，没有开发相应的属于一个系统的其他低价值功能。于是周期末的版本我们发现，由于系统的不完整，这个功能乐趣甚微。如果对这种涉及系统的问题没有认识，那么我们很可能就会对这个高价值功能有错误的认识。 （关于系统理论的知识，请参见WIKI系统学一词） 如何避免这个问题？这个时候人的作用就体现出来了。当然我们可以在故事列表上增加一列系统属性，提醒我们。但根本的方法还是一个或者多个对整个故事列表有着足够把握能力的人来进行掌控。 我们需要有人能够全面的了解设计意图，并且对我们的故事列表进行把关，对我们周期开始的需求选取进行主导。有一点大家应该明白，规则和标准都是人制定的，那么我们究竟是依靠标准和规则来更好的控制结果，还是依靠人本身？是完善更好的标准，还是培养出更能把握质量的人？ 接下来，线段中的开发过程，本质上其实就是分析需求，制定计划，开始开发。或许会周期内分为更细小的周期进行迭代。但是这些小迭代其实依然是瀑布式开发，这点毫无疑问。区别只是在于，这样的小周期内，我们开发的思想和方针是以敏捷开发的思想为指导的，我们更注重版本，更注重交流，更注重结果。而不是预定义式的开发流程（pre-defined)。 在线段的结尾，一个周期结束了，我们需要做两件事情，第一是将我们体验版本之后的反馈，反馈回故事清单中。或许我们体验某个功能之后会觉得加上另一个功能会更好玩，于是我们提升这个功能的优先级。或许我们会觉得这个功能很无聊，于是我们把同类型的功能优先级都降低。再或者我们添加，甚至删除一些全新的故事（不推荐）。
迭代的节奏 在迭代中，我们还需要注意我们迭代的节奏，什么时候该松，什么时候该紧。什么时候我们允许大家的发散和更多的思考。什么时候我们应该专注于我们的目标并且忽略其他的一切以得到我们最终的版本。这些都是有所讲究的。 这节奏包括各个方面。那么究竟这样的节奏应该如何来走呢？ 在一个迭代之内，我们的节奏应该是先松后紧。当然不是说迭代开始时我们的效率可以放缓。这里的先松，是指在一开始时我们可以有更多的想法和思路，更多的探讨和研究。本来我们的迭代工作就是从粗到细，从模糊到精确的进行。在迭代中，我们也如此一步步明确我们的工作。
一旦目标明确，那么迭代周期SPRINT的名称的含义就出来了：我们向着我们的目标冲刺而去。到了这个阶段，我们需要收缩我们的讨论和想象，一切以最后的版本和质量为前提。以尽可能快的速度来开发我们的功能，提高我们游戏的质量，得到我们需要的结果。至于具体的迭代方式，各有不同，我的方式大家可以参加之前发出的那个VISIO图表。某些细节接下来还会讲到。
为什么需要版本 验证乐趣 我们的设计在我们的脑海里，很可能和在别人脑海里得到的认识是不一样的。 或许大家都能有幸得到统一的认识，但是做出来实际体验的时候又不一定能够符合我们的预期。 就算符合了我们的预期，也许我们玩的时候会发现一些新的点子可以很容易的加入到游戏，并且大幅度的提高游戏性。 所以，多个迭代版本的目的，首先就是为了：验证我们的功能是否符合我们的设计预期。因为: l 没有实际玩到之前，永远不要相信自己的设计是OK的。 我想强调的是，这里的设计预期不仅仅涉及到我们的功能，事实上作为游戏开发，功能开发永远只占其中的一小部分，还有大部分的时间我们需要用来调整，优化，修改，以达到我们的真实预期。 换一种说法，这里的预期除了功能以外，还有我们对它的感受，也就是这个功能到底好不好玩。而我们关注的重点，也是在好不好玩上。如果只是关注于功能是否完善，那么我们的版本就还离成品有一大段路要走。 所以迭代版本应该是计划功能均可玩，并且没有会阻止我们体验所有需要体验内容的BUG的游戏版本。它是我们评判一切的依据，因为一切功能，一切资源，一切玩法，在进入版本可以被我们体验之前，都存在不确定性，只有最后经过版本的体验，这一切的不确定性才能消除。
持续集成 其次，敏捷开发的要求是快速迭代。但是这里的快速迭代其实远比大家想象的还要快速。或许大家觉得正确的快速迭代就是每一个周期，或2周，或一个月就需要一个版本出来。迭代速度比起传统开发确实快了许多，版本也多了许多。但是事实上的快速迭代远比一个周期要短的多。理想的快速迭代，应该是： l 每个功能，每个改动完成之后都有一个版本能够立即对功能进行验证，进行体验。 让我们对游戏的改变把握得更直接和高效。让大部分对游戏方向的修正都发生在开发当中而不仅仅发生在周期的开头或者末尾。原因就如我所说，每一个功能从完成，到有乐趣，都需要有一个打磨的过程。在打磨之前，很有可能这个功能根本没有乐趣。所以实际上，我们一周要开发一个功能，很可能我们前4天就需要把功能开发完毕，周四出一个版本进行体验。然后周五针对周四的反馈进行一些BUG修正和反馈修改。之后乐趣才出的来。 是的，如果是理想情况的话，每一个功能无论大小都应该是这样的一个流程。哪怕是一个只有半天开发周期的功能，我们在3个小时开发后也需要出一个版本对功能进行验证，并提出反馈改进（如果有的话）。之后优化到大家觉得这个功能合格或者有存在的价值之后，我们才会继续下一个功能。 这样的过程当然过于理想化，每一个功能我们都可以几乎无限的优化下去。所以我们也需要对优化的程度进行取舍。这样取舍的标准还是最终会基于我们开发者自己的个人能力和标准上。更重要的是，我们需要建立每一个功能和变动都需要一个版本进行验证的意识。进而才能追求我们的版本质量和效率。
效率 敏捷开发绝对不是牺牲效率追求品质的开发模式。 相反，在每一个迭代当中： l 效率才是需要追求的第一位。 唯有在尽可能快地发布版本之后，我们才能根据版本的反馈，进行修正。进而得到更好的版本质量。大部分时候，我们需要的仅仅是以最快的速度得到我们需要的原型。验证我们的设计。 为此我们需要尽可能的追求效率。 那么，如何得到我们需要的效率？ 范围 首先，永远不要做多余的事情。一旦目标明确，那么我们的目标就是所有我们要做的，在目标范围内的质量优化，必要的代码改善，必要的体验优化，都是可以做的。但是离开了我们目标范围的事情，一件都不要做。 这里的范围，则是一个度量。而这个度量的划分，则又一次，需要依据我们这些人来判断。它需要我们深刻的理解到，我们制定这些目标的意义，我们要实现的究竟是什么，我们应该优化到什么程度？ 我们有多少时间，那么我们就只能设计到什么程度，做到什么程度。而更多的次要的需求，我们有时间再考虑，更多的兼容性想法我们可以想，前提是我们这个版本还有时间。我们需要画一条基准线，在有限的时间里，我们能做多少内容，该做哪些内容？一切行动都需要以我们的目标为准则。当然，我们还需要考虑量产和下个阶段的准备工作等等（然则，这些其实如果规划的好，应该可以算作这个周期内的目标之一）。但这些都需要服从于当前版本的开发。全力开发我们需要的内容。 因此我们需要避免过度设计，过度开发，以及过度优化。我们需要将效率作为我们开发的准则。 人员 永远只涉及必要的人。为什么我们要进行小组化开发？因为人员牵扯一旦扩大，唯一的结果就是效率降低。各种意见难以统一，管理变得困难，计划难以统筹，任务分配变得困难等等。所以最佳的小组规模应该在7人前后。 仅仅如此么？当然不是，我们不但要确定小组规模并且将小组开发与外界的干扰屏蔽开。我们还要确定我们项目开发的流程中，每一个步骤所要参与的人员，哪些是真正必须的，哪些是不必参加的。确定人员的职责范围，首先他们需要专心于负责的部分，之后才涉及力所能及的部分。 在这里，需要解释的一点就是，敏捷开发并不是所有的决定和步骤都要大家来参与，以增进组员责任心和归属感的。为了最大化效率，我们永远只让必要的人来做必要的事情。比如故事分解为任务，只需要小组成员，和相应的主程主美主策。比如故事本身的优先级划分，只需要核心组成员（更加通常的情况是只有PO）参与即可，小组成员没有必要参与。再来，版本体验会，我们需要的是真正的指导性的意见和重要的人的声音，如果需要专门组织一个会来听小组成员对版本的反馈，我觉得那小组成员平时就不知道是干什么去了。我们需要在组织每一场会议的时候都考虑到，是不是每一个到会议的人都是必须到的，因为我们找他来开会的时间，都本来应该是他开发和工作的时间，而那才是我们的重点。 高效会议 最后，我们需要有一个清醒的认识，过多的会议永远都是高效率的开发的大敌。一个会议10个人，一小时，意味着我们会损失10个人时的工作时间。而实际上一周的工作中，我们一个人时都是损失不起的。当然，这并不是意味着我们不要开会。而是我们需要意识到我们的会议究竟是否有必要，如果有，那么会议效率是否足够？我们是否有足够的会议准备和计划，能够保证我们会议的效率？还有我们是否有相应的会议章程，会议时限？这些都是我们需要考虑的，用以高效化会议，减少时间浪费的重要方法。 所以，当我们思考效率的时候，不妨真的来看看我们现在的开发，分析一下一周的工作中，究竟开发的时间有多少？其他的时间又有多少。看看到底是什么在影响着我们的开发，是否有方法，或者措施，能减弱这些影响。最终进一步加快我们的开发？ 开发的脉络 交流 非正式沟通 交流，在敏捷开发中，是永远都谈不够的东西。也是永远会存在问题的地方。在敏捷开发中，我们会重视交流而轻文档。原因？只是因为交流永远比文档更高效。 并非我们就此放弃文档，文档最终会变成记录我们讨论交流结果的工具，便于未来查阅。高效的原因是，在交流的过程中，我们就可以共同修正分歧，修正个人的错误，并且将信息传达给对方。当然，一切都还仅仅是基础的东西。 进一步的是，究竟如何能让我们的交流高效？首先，必须明确一点，会议并非是高效率交流的良好方式。更好的交流，应该更多来自于更频繁的，更多的非正式的沟通。把所有人拉到一起，强迫他们发言，或者收听，并非能很好的传递信息或者进行讨论。而鼓励他们进行自发的讨论、交流、在每天，在所有的闲暇，都可以进行一些思想，一些想法的发散、讨论。这才是最好的情况。 我们当然也可以就此进行推动。更多的不是人为的设置一些刚性讨论需求，而是制造一种推崇各自讨论的氛围。 邮件 其次，是我们交流的方法。我们有没有真正考虑过，哪些内容我们应该放到正规会议上进行宣讲？哪些内容我们只需要发一封邮件，并收集回信的反馈？哪些内容，我们只需要找到相关的人，非正式地谈论一下就可以得到解决？这些分类一旦清晰，能够为我们的团队节约多少时间？ 从另一方面来说，有多少内容我们甚至连邮件都没有发出，完全变成了个人的地下行为？在这里，我想强调一下关于邮件的作用，在原来的公司，我们被要求尽量少使用邮件，因为某个时期，员工们甚至把所有需要面谈的内容都用邮件来代替了。距离5米的两个人甚至一周几百封邮件却没有一次谈话。 而在现在的环境中，邮件却变得相对冷落，很多应该有邮件作为记录，或者应该由邮件发出的内容都借由其他的方式或者没有以任何方式发出。比如现在很多的策划文档，每一次更新，只有一定几率会有邮件通知到大家。比如会议纪要，当然这都还是表现的比较好了。再比如不太重要的设计文档，这些都可以借由邮件发送来让需要知道的人了解，并且相比专门的宣讲会，节约很多的时间。大家只需要看完之后，把反馈意见用邮件发回就可以了。所以，我们可以考虑是否完善我们对于邮件的使用？更重要的是，是否我们可以进一步提高我们对于邮件使用的意识？我相信，这会是一个很漫长的过程，但是必然能够极大提高我们办公的效率。 其实终究，还是我们考虑问题的方式，我们是否能够意识到我们现在的交流方面的不足，是否能够开始改进？这将是我们是否能够继续成长的关键。 项目的基石 人 谈到人，其实就是谈到整个流程和过程中最关键的地方，最关键的元素，也是决定一切事情成败的根本。无论多好的制度，流程，如果没有相应的，合格的人来执行，也只会是失败的结局。那么，在敏捷开发中，或者说在游戏业的敏捷开发中，我们需要什么样的人，我们需要什么样的素质和要求，才能更好的运作这个模式，更好的做，并且做出更好的游戏呢？ 迭代的意识 首先，是改进的意识。永远记住，没有完美的东西。我们需要保持清醒的认识，认识到我们的项目；我们的流程；我们的文档；我们的游戏等等，都还有可以改进的地方，都还有很多可以改进的地方。改进是没有终点的，我们需要能够找到这些可以改进的地方，我们还需要可以找到改进的方法，并且切实的推行下去。这样，我们才能在一次次迭代中，得到更好的项目，更好的版本，更好的团队，等等。意识到我们有问题，我们才能够改正这些问题。从某种意义上来说，其实这也是迭代的意识。 效率的意识 其次，我们需要效率的意识，我们要明白，最终，我们是在开发商品。我们是在进行商业运作，所以效率是我们需要真正关心的。而效率的重点并不是每天在公司里花了超过8小时，而是我们的时间是否都真正被有效利用起来了。我们是不是真的在需要的时间内，给出了需要的成品。是否这些成品能够合格。每天做的事情是否有意义，是否能够给予我们的工作和项目帮助？我们是否能够抓住我们工作的重点？而不是浪费在无关痛痒的地方。我们需要考虑我们的工作是否是向着目标前进的，是否足够，是否有效率。要做到效率，我们就需要首先明确我们的目标，其次清醒的意识到我们在做的事情，最后再反省是否有无效或者被浪费的地方。是否我们能做的都做了，是否我们把不需要做的也做了？ 理解游戏 再次，我们需要有对游戏的把握。毕竟，我们做的是游戏，如果做的人都不知道什么是游戏，那么如何能保证我们做出来的游戏能被人喜爱？甚至，我们如何能保证我们做出来的游戏，是游戏， 而不仅仅是一个选择播放的技能地图预览器？所以，首先，我们大家都需要了解游戏，了解什么是游戏，游戏包含了什么；游戏性是什么；核心玩法是什么；主要模式是什么；画面表现是什么；音效是什么；故事是什么，它们是如何结合的，是如何组合成一个游戏的。不同的游戏类型里，这些要素又以什么比例组合，哪一个更加重要。这些都是游戏开发者所需要了解的基本。进而，开发者才能明白，我们现在的游戏已经有了哪些元素，还差哪些元素，已经有的元素是否足够，是否还有所欠缺。这时，合格的游戏开发者们，才有能力说出，我们的开发方向在哪里，应该补充什么元素，有什么欠缺的地方。这样，我们才有能力，做出一个至少完整的游戏。 开发者的野心 进一步，我们如果还有野心，并非只是做一个完整的，良好的游戏，我们还想要有创新，想要做一款让人眼前一亮的游戏。那么我们就不只要了解什么是游戏，我们还需要对游戏有自己的理解和想法，我们需要有自己对这个游戏的未来的想象，并且时常将之拿出来讨论，碰撞，最后留下那些可行的，优秀的方案来实现。我们每个人都需要对我们的游戏有所希望，并且这些希望都是需要时常在我们的大脑里酝酿的。这才是游戏开发最有趣的地方，我们总是可以实现我们脑海中大胆的想法，我们总是可以把我们有趣的意见，点子说出来，如果能够得到大家的赞同，就可以实现到游戏里去。做游戏应该是有趣的，而不是每天重复枯燥无聊的劳动。所以，我们需要思考，并且说出我们的想法。 快乐地制造快乐 用心制造快乐，是不够的，还需快乐地制造快乐。让我们并不仅仅是麻木的工作着，而是真的有趣的去做有趣的事。这才是做游戏的本意，这才是大部分人最早加入游戏公司制作游戏的本意。如果我们做的东西连我们自己都无法说服自己，“那是有趣的。”那做出来的真的能有趣么？我们在做游戏，之后才是工作。如果整个游戏，都没有一点自己的心思在里面，那我们就真的只是在勤劳的上下班了。 而且也只有相互间的思想，想法在碰撞，才会做出有意思的游戏。游戏的设计并不仅仅是策划的事情，游戏的需求也不仅仅是由策划提出。只有大家每个人都可以针对游戏的缺陷，乐趣，玩法能有自己的见解，每天争的面红耳赤，那才是真正做好游戏的取胜之道。在游戏性的讨论上，根本没有策划美术程序之分。 对游戏工业化开发的把握 最后，我们还需要有对游戏开发的把握，对整体的把握。我们是否知道我们现在处于游戏开发的哪个阶段？这个阶段应该重视那些东西？应该注意那些东西？这个阶段我们应该完成那些东西？对于这些我们是否有清醒的认识，清醒的计划？ 我们是否有对我们项目的整体规划？知道我们现在要做什么，知道我们下一步还要做什么，这才能让我们明白我们现在做的是否有意义，是否有效率，是否正确。我们的目的，绝对不是过GR1，2,3,4,5.这一点大家应该明白，我们始终都是在做游戏，如果我们的方法正确，计划正确，那么这些评审对我们产生不了任何影响，那么既然我们每次都需要针对这些评审改变我们的流程计划，那么是不是也意味着我们本身的计划也存在一些问题？这个问题大家也许可以思考一下。不要让问题找到我们，而是我们去寻找问题。
为什么要使用故事？ 我们为什么要使用故事？要理解这个问题，首先要理解故事的作用。那么故事的作用是什么？ 消除理解误差。 早期软件开发的需求方往往不懂任何技术，开发者的功能清单却往往难以让需求方有直观的对最后成品的认识。比如，或许一个功能描述是，“战斗场景分为5层可以根据摄像机的移动而相对运动”，但对于非专业人士来说，他们可能无法理解这样的描述意味着什么。于是故事开始发挥了它的作用：以一种大家都认可的方式让所有人对我们要做的功能目标有清楚的认识。 所以： l 只要能够让全体人充分意识到我们功能开发的目标以及内容，那么它就是一个很好的故事。 对我们来说，这样的共识需要在策划，美术，程序等人员之间达成，所以我们的故事也需要以一种大家都能理解的方式来表达。而更重要的，不是故事的方式，而是确实所有人都能够完全理解。具体怎么写，其实真的怎么写方便都可以。 整体统筹估计和管理。 由于故事是从系统和结构的层面，以一定的高度来描述我们整个项目的框架功能，所以我们可以以较快的速度全面了解我们的功能点，而对于这些功能点，我们还可以进一步快速的给出粗略的估算。进而得出整个项目的大概工期或者每个迭代我们可以完成的故事数量。这里的估算往往是由不准确慢慢到准确的。 l 每一个周期，每一个项目的历史数据都可以让我们之后的估计更加精确。 而且这样划分的工作，可以更好的交付给不同的小组完成。小组内部进一步自行组织计划，使得我们的管理工作可以分散到小组，降低管理难度。 创意管理 本质上，游戏就是已有的同类游戏的完整功能点，加上我们独特的创意。完备的前者能让我们的游戏成为一款合格的游戏，而后者的加入则让我们的游戏变得独特。引入故事后，我们可以总是在一个层面，对功能开发和创意尝试的投入进行平衡，相互以取舍。我们可以总是以功能和创意的价值来判断真正对我们有价值的开发顺序。 故事在讲什么？ 什么是故事? 首先，故事本质上依然是功能点，依然是从需求中抽取出的一个个系统功能。只是以一种所有人都能理解的形式进行描述。所以，为了能够让所有人能够理解，故事仅仅只从实现功能的目的来描述这个功能： l 故事是对功能的目的的描述 同时，故事是在讲述这个功能究竟是发挥什么样的作用。所以它本身价值只是简单描述和给予一定参考。 l 它不是，不能也不需要详细的描述这个功能的所有细节和玩家对此的感受。 因为前者有相应的策划文档，后者难以文档化以标准衡量。 所以，当我们要验收某个故事的时候，并不是我们比照着一个个故事，来体验游戏。看一个个故事是否在游戏中完整的实现了。 正确的故事验收，应该是在这个故事在组内达成统一之，所有人就应该知道要做成什么样子之后。将单个功能的验收在周期内 就实时完成。而在最后版本发布之时，对功能进行检验，检测这个功能的最终效果是好还是坏。 我们的目的不只是要看是不是功能A,B,C,D已经完成了，我们应该再深入一步： l 关注于功能是否得到了很好的效果，符合了我们的预期 l 在游戏开发中，则是，是否有了乐趣 l 是否有其他想法，能够让这个游戏更有趣 因为仅仅是功能的集合，并不能成为合格的游戏。 因此，我们也需要改变我们对于设计目的的定义： l 我们的目的并非仅仅是完成某个功能，而是功能能否达到我们需要的乐趣。 带着这样的思路，我们才能真正的在版本回顾的时候，给予能够指导我们开发方向的反馈，而非仅仅是针对我们功能开发的完整与否，发表意见。 作为核心组成员，或者，作为整个游戏项目的一员： l 我们不应该仅仅关心于完成情况，各种细小的错误。我们应该看得更远，思考的更远，给予我们的开发真正能提升最终质量的帮助。 最后，故事包含对它大小的估计，我们可以使用这个估计来对将来的工作和计划进行评估；对它本身价值的估计，让我们在选择他们时可以参考。简单的来说，就是另一些附加的功能。
如何使用故事 故事的来源 第一，从已有的游戏设计文档或者框架中抽取的，比如，我们已经知道我们要做的是一个回合制战斗的游戏，那么我们就可以抽取出，基础战斗指令，回合制战斗流程之类的故事。 第二，新出现的创意性质的内容，比如，今天我突然想到在回合制战斗中加入行动顺序条或许是个很有趣的点子，我告诉大家，大家也觉得这个东西很好，于是我把它加入到清单中。 第三，当我玩到某个游戏的版本的时候，发现，某个功能给我的反馈不是很好，或者我觉得可以如何改进，能够让这功能变得更好，那么也可以放进到故事清单中。 故事的使用 首先，我们有一个用来维护故事的列表，术语叫做产品订单，里面罗列了所有我们已经完成或者没有完成，重要的或者不重要的故事。我们可以在里面清楚的看到： l 故事的描述 l 故事点（大小） l 优先级（价值） l 当前状态 于是，在每个迭代开始的时候，我们都将故事从大到小排列起来，依据上个版本我们能完成的故事量（以故事点来衡量）来选取我们这个版本需要完成的故事内容。 故事选取完成后，下一步，则是让整个小组对故事的内容达成统一。也可能只是统一目标，而某些细节在完成的过程中确定。这过程的形式，依然并不固定。 当大家对故事的内容都有所了解之后，我们可以开始对故事进行分解。得到相应的详细的任务。任务又成了计划，在对计划进行评估和检验之后，每个周期的工作内容就如此确定。 故事的作用就基本到此结束，剩下的内容是当单个故事完成的时候，对版本中功能进行体验，如果通过，则这个故事就此完成，最后进行归档之类的收尾工作。 当然，在故事的具体使用中还有一些细微操作，比如如果一个故事在一个周期中制作时发现比估计的大很多要放到两个周期来做才能完成。那么我们还需要对故事进行拆分之类的操作。这些细微操作还是需要在针对不同的情况进行不同的处理。 版本体验会 当我们一个周期的开发内容完成，每个版本功能都已经在周期内得到了验证，并且已经有了一定的优化。为什么我们还要有一个版本体验会呢？ 首先，我们每个人负责的领域不同，我们有的人对于美术质量很关注，有的人对于代码质量很关注，有的人对于设计文档很关注。也许我们中的一些人参与了一些功能的开发，但是我们并不能对于这个周期的所有功能，所有的改动有所了解。就算对此有所了解，我们也许也不明白每一个功能的设计用意。最后，为了让所有人对最终结果达成统一的认识，我们需要一个正式的展示会议，向核心组或者高层进行我们这个阶段的成果展示。在展示我们的版本新增功能和内容的同时，核心组也会对这个版本的各个细节和内容进行考察和审核，确定这样的改变是否符合对于游戏性和乐趣的追求，是否符合我们对我们游戏的希望，这样的发展方向是否是正确的。 而在这样的会议中，最重要的是，我们需要得到来自各个方面的反馈。作为开发者，这可能本身就局限了我们对于我们的版本的认知和看法。我们对于我们的版本过于熟悉，有可能自动的忽略掉了一些很重要的问题，或者会错误的认为一些难以被接受的游戏性具有很大的乐趣。而这样的会议，则是指正我们类似问题的恰当时机。针对这些反馈，我们可以更好的修正我们的工作思路和计划。给予我们下一个阶段更好的目标。 所以，在这里，核心组需要给出的，更多，更重要的，还是对于我们游戏的方向性的，涉及到我们目前开发功能的游戏性和表现上的改进意见或者反馈和一些指导性的意见。因此，我们需要要求我们核心组本身更了解 游戏，更明白游戏性，并且自己对于我们要开发什么样的游戏，有清醒的认识和思考。 周期总结会 自适应，自我优化的流程，需要有两个要素才能真正的进行自我改进。首先最重要的是其中的人要有对流程中的问题，需要优化的地方，甚至是对优化本身有清醒的认识和意愿。其次，就是这样的人推动的一个优化行动。而周期总结会，就是SCRUM中设立的一种针对流程自身优化而进行的一种行为。 项目总结是游戏业的一个普遍工作习惯，在每一个游戏项目结束的时候，会进行一次全项目级别的总结会议，对于整个项目过程当中，做的好，有典范价值的事物，或者在过程当中发生的有范例价值的问题，甚至是还没有解决的问题进行系统的总结和提炼。之后将之发表，可以成为团队，甚至其他团队将来工作时的依据和帮助。 而每一个周期一次的周期总结，则是将这一行为加快，频率加高，在项目进行中不断反复。以此达到更快速的寻找总结目前我们的优缺点，针对我们目前的缺点问题寻找 解决的办法，并且开始行动。总的来说，就是以更快的频率不只是迭代我们的版本，将我们的版本改进的更好。同时也是迭代我们的行为，优化和让我们自己更加的进步。 其实设立一个这样的会议并不难，每一个周期我们都会有这样的总结会。而会议也总会有这样那样的缺陷和需要优化修改的结果。难的是我们需要切实的推行那些问题的修正措施，难的是我们需要能够直面我们的不足，并且将其提出。我们要能对或许难以开口的问题更直白。鲁迅先生有云，真正的猛士，敢于直面惨淡的死生。我们必须承认我们的工作都是不完善的，都是需要优化的。但是这些问题都不是阻止我们开始修正和改革的借口。敏捷开发的意义也就在于，知道一开始的我们不足以成功，甚至肯定会出现问题，会有失误。但是正是在一次次快速迭代中，我们快速的磨合，快速的修正，最后在一次次的改正与进步中，我们才会得到一个完善的团队，一个良好的流程以及一系列适合我们的方法。 这也才是周期开发的意义所在。所以，敏捷开发，并不是一个需要在一开始就有完全的准备的过程，并不是一个需要完整规划，好好考虑的过程。我们只需要有一定的东西可以开个头，哪怕还不算成熟，但是我们依然可以在接下来的过程中，对我们的目标愈发的清醒，越发的明确，并且我们本身也会越发的成熟，最终共同达到目标。 一开始，游戏功能不明确？没问题，我们可以先从知道一定会做的开始做，然后开始探讨我们最后要做的目标，再根据每一个迭代的版本反馈修正我们的目标。 一开始，我们开发团队磨合不够？没问题，我们可以先让他们从开发简单的底层功能做起，并且同时进行磨合，将磨合过程中需要解决的问题一一提出并改正，最终优化得到一个完善的团队。 一开始，我们的工具不够？没问题，我们可以先用最快的方式开发原型，同时分析原型制作的方式和需求，进行工具制作。并且在工具可以使用之后，再根据使用者的反馈和项目的进展进一步的优化和改进。 ... ... 我们可以做的东西很多，而那些还没有做的，也同样不能成为我们开始做的障碍。 |
