外资游戏企业的“中国式困境”
外资游戏企业的“中国式困境”
　　2007年3月《21世纪经济报道》的一篇报道披露，从去年10月起，EA拖欠合作伙伴广东天悦的各项运营费用，包括员工工资，导致双方的合作出现危机。广东天悦方面称：“我们已经发出最后通函，如果仍得不到回复，天悦将停止‘POGO中国’的运营。”
　　一年前，2006年4月，EA将其在中国大陆网络游戏业务的独家运营权交给广东天悦，由后者负责运营EA的休闲网游平台――POGO.然而不到一年，双方的合作就产生了严重的裂痕。这仅仅是因为EA中国高层的变动吗？如果是，新任总裁为何要改变EA的在华策略？当初EA又为何要承担起广东天悦的运营费用，甚至员工工资？
　　中国游戏业发轫之初，来自欧美、日本和港台地区的外资企业曾经占据重要地位，从育碧到EA，从智冠到大宇，从华彩到华义。2002年后，随着网络游戏在中国的高歌猛进，越来越多的国外游戏巨头开始关注中国这块市场。2002年，任天堂以美日对等方式注资成立神游科技有限公司，后者于2003年9月在中国大陆推出基于N64主机技术的神游机。2004年1月，索尼的PS2在上海和广州两地正式发售。2004年8月，世嘉携三款网游而来，吹响了进军中国的号角。两个月后，美国艺电（EA）也宣布成立中国工作室，目标直指网游市场。
　　然而奇怪的是，虽然汇聚中国的国外游戏公司越来越多，外资游戏企业在中国的影响力却日渐式微。从最初的高调进入到今天的默默无闻，它们仿佛一簇簇烟花，在短暂的绽放后便消失在了茫茫夜空中。仅仅是因为水土不服？或是过于自信？“泯然众人”背后是否还有其它原因？本刊记者采访了部分外资企业及相关协会的业内人士。
　　三个号，一个都不能少
　　陈朝勋的穿着朴素到不能再朴素，上身白衬衫，下身牛仔裤。在街上碰到他，你会把他当成一个发福的普通中年人。和他交谈，你更会觉得这就是一个地地道道的北京人，“忒”、“倍儿”、“哥几个”、“海了去了”……各种儿化音和俚语脱口而出，你不会想到他是史克威尔艾尼克斯中国（SEC）的总经理，更不会想到他在台湾生长了30年。“不管在哪儿，你都得照当地人的方式去办事。”他笑着说。
　　1998年2月，陈朝勋被台湾光谱资讯派驻到北京管理北京分公司，从蹬三轮给软件店送货的那段日子起，他就开始学习中国游戏业的形形色色的规则。对于外资游戏企业在中国的难处，他深有体会：“外商投资企业到底困难在哪儿？首先肯定是准入――怎么进来？怎么合法地进来？想进中国的往往是家大业大的上市公司，上市公司不可能作违法的事，它们必须先弄清中国的法律法规。可是，在对中国的法律环境作了深入调查后，这些国外公司会发现――它们根本进不来。”
　　在中国大陆运营一款网络游戏通常需要具备“三证”，在“广东天悦网络科技有限公司”网站首页的底部，我们可以看到这三个证号：“新出音管号”、“文网文号”和“ICP证号”。“ISBN及新出音管字号”是新闻出版总署颁发的电子出版物的书号和批准文号，“文网文号”是文化部颁发的《网络文化经营许可证》号，ICP证号即信息产业部颁发的《增值电信业务经营许可证》号。
　　为什么需要这些“证”？这是由网络游戏在中国的多重身份所决定的。首先，网络游戏及其网站的运营属于互联网内容服务，按照中国的法律法规，任何企业要从事互联网内容服务，必须申请ICP牌照。而ICP牌照对外资企业的发放是极为严格的，外商独资企业无法取得，合资企业要想申请ICP牌照，外资比例不得超过50%，即便如此，拿到ICP牌照的合资企业也是凤毛麟角。其次，网络游戏同单机游戏一样属于电子出版物，同时也是互联网出版物，要在中国大陆境内合法出版，就必须取得新闻出版主管部门的批准，而目前来看，主管部门对于境外游戏产品的引入是有总量控制的。另外，网络游戏及其网站还属于互联网文化产品，需要遵守《互联网文化管理暂行规定》的相关规定。2004年9月，上海育碧电脑软件有限公司因“非法提供游戏《无尽的任务》”而被文化部查处，即是因为《无尽的任务》虽然拿到了新闻出版总署的版号，却未持有文化部的《网络文化经营许可证》。
　　在中国大陆合法运营网络游戏，这三个证是必不可少的，而这三个证对于外资企业都有严格限制，怎么办？就此打道回府？且慢，为什么那些公司可以在中国运营网络游戏？
　　借壳上市
　　一位不愿透露姓名的业内人士对记者说：“请问，盛大是外商吗？是的。九城是外商吗？是的。网易是吗？是的。它们哪一个不是在纳斯达克上市的？哪一个不是对美国发行存托凭证？哪一个不拥有外国股东？统统都有。久游网也一样，背后是境外资本，可有谁把久游当外商来看？真正纯粹由国内资本经营的公司有没有？有，但非常少。”
　　我们所熟悉的“上海盛大网络发展有限公司”是一家内资企业，而纳斯达克上市的“盛大互动娱乐有限公司”是境外公司，它于2003年11月在开曼群岛注册成立，陈天桥家族通过英属维京群岛注册的地平线媒体有限公司持有其57%的股份，其余股份来自公众募集。正在酝酿海外上市的久游网也是如此，润星国际有限公司的注册地在开曼群岛，它的前三大股东分别为中科英华（香港）商贸有限公司、科润国际控股有限公司和润星海外控股有限公司，其余股份为美国凯雷集团等风险投资商所持有。
　　无论是海外上市的公司、有风险投资的公司，还是“纯粹”的国外公司，只要在境外注册，依照法律都属于境外公司，都不能在中国从事互联网内容的运营业务。既然盛大互动娱乐和润星国际是境外公司，为什么它们可以在中国大陆运营网络游戏？其实回顾一下以往中国内地许多互联网公司的海外上市历程，我们就会明白。为了满足政府对互联网业的监管条件，这些互联网公司在海外上市之前首先会剥离其国内的ICP业务，与ICP业务相关的资产、人员、域名、商标、经营权和用户关系等，以协议的方式有偿或无偿地转让给一家纯内资公司，然后再通过商业合作的方式，间接地将这家内资公司的收益转移过去。我们看到，盛大的网游运营实体是“上海盛大网络发展有限公司”，久游网的运营实体是“上海润星网络科技有限公司”，这两家公司都是内资企业。它们的大部分成本和收益，分别通过“盛趣信息技术（上海）有限公司”和“久之游信息技术（上海）有限公司”，被盛大互动娱乐和润星国际这两家境外企业所接纳。
　　盛大2005年度财务报告对“盛大网络”和“盛趣”之间的关系有着清晰的解释：“中华人民共和国的法律规章目前限定提供互联网内容服务，包括网络游戏运营，的外资企业的外资股权比例不得超过50%.而且，外商或外商投资企业目前无法申请在中华人民共和国境内运营网络游戏所需的牌照。盛大互动娱乐有限公司成立于开曼群岛，根据中华人民共和国法律，盛趣相应地被认为是一家外资企业。为了遵守对外资的限制，本集团通过盛大网络在中华人民共和国境内运营网络游戏。盛大网络由陈天桥和陈大年全资拥有，他们两人均为中华人民共和国公民。盛大网络持有运营网络游戏和在盛大网页销售网络广告所需的牌照和许可，盛趣拥有运营网络游戏所需的大部分实物资产。盛趣与盛大网络、南京盛大和杭州边锋签有一系列协议，根据协议，盛趣为盛大网络、南京盛大和杭州边锋提供服务、软件授权和设备，以此交换酬金。盛趣还为盛大网络、南京盛大和杭州边锋提供运营所需的财务支持。此外，盛趣与盛大网络及其股东签有协议，该协议保证盛趣对盛大网络享有实际控制能力。”
　　借壳落地
　　已在纳斯达克上市的盛大和九城，必须通过一家内资企业去持有运营网游所需的互联网内容服务许可、互联网文化经营许可以及互联网出版经营许可；正在酝酿海外上市的公司，如久游和天联世纪，也需要作类似的重组。
　　除了实现海外上市的目的外，这种“借壳”的模式也会被境外资本用于曲线进入受政策法律限制的网游市场，例如在中国物色一家纯内资企业与之合作，由后者申请运营网游所需的牌照，或是利用后者已有的牌照。去年5月，《第一财经日报》一篇题为“文化部紧急叫停网游《街头篮球》 天联连喊误会”的报道中提到：“在网络游戏行业，类似天联这样通过收购或者合作来取得运营资质的例子并不鲜见。……更有一些拥有各类证件的中国企业认为奇货可居，即便公司已经不再有游戏产品在运营，也不会宣布关门，而是静悄悄地等待外资企业出高价与之合作，或者将其收购。”
　　一位业内人士告诉记者，外资对于这类合作伙伴的考察一般有三个标准：“第一，要干净。从资本、人员结构到债务，都要很干净。第二，要听话。听话，牌照才好用，严苛点的会要求对方把营业执照和公章都交出来。第三，要小。越小越好，小了才干净，小了才听话。”达成合作后，表面上看，外资企业只是为这家内资企业提供技术支持；而实际运作中，内资企业的最大价值就是持有牌照，其资金来源和决策权往往控制在外资企业手中。这家内资企业甚至可以不雇用任何一名员工，而只是一个空壳。这就是所谓的“假内资”企业。
　　“假内资”企业在法律和经营管理上的风险显而易见。法律上，一旦被查出是“假内资”，营业执照就会面临被吊销的危险。经营管理上，由于外资企业的“真身”与内资企业这个“壳”之间的默契关系是不受法律保护的，因此，今后双方如果产生矛盾，例如“真身”被“壳”反咬一口，或是在“亲兄弟明算帐”时出现利益上的纠纷，或是某一方的高层战略发生变动，问题就会变得复杂化。毕竟，“真身”的所有业务都要通过持有牌照的“壳”来完成，而“真身”却并不拥有“壳”的任何实际股份。这中间存在着无法预估的灰色风险。
　　即便是为海外上市而“借壳”的公司，也存在着类似的风险。很多人对六年前的“王志东事件”仍然记忆犹新，“借壳”模式最早被公开揭示出来即源于此。2001年6月，《南方周末》一篇题为“新浪不是经营报”的文章在评论“王志东去职事件”时将这一模式及其风险解释得很清楚：“北京新浪互动广告公司和北京新浪互联网信息服务公司，王志东个人持有前者75%以及后者70%的股份。新浪广告是一家拥有国内广告经营执照的公司，在NASDAQ上市的新浪网的所有国内广告都必须通过它来完成；新浪信息是一家持有ICP执照的公司，新浪网国内部分的运营必须由它来进行。上市公司新浪网和这两家公司签定协议，通过协议，这两家公司的成本和收益都进入了新浪网。之所以让王志东个人持有这两家公司的股份并不是因为新浪网没钱了，需要王志东个人来投资，而是因为政策壁垒。……绕过中间的山山水水，我们看到，整个事件大致是这样的：外资的新浪网和中国籍的前CEO王志东合谋，由王志东个人出一个名义，要过来一个中国政府颁发的广告经营和ICP资格证，现在新浪网让王志东下课了，王就警告新浪道，别忘了，你之所以能在中国运营，是因为我的名义。”
　　回顾王志东与新浪之间的这段恩恩怨怨，我们很容易联想到EA与广东天悦之间正在进行着的这场风波。
　　八个法律规章
　　外经贸部商务部研究院研究员王志乐与何茂春撰写的《我国利用外资法律的修订及影响》一文对“假内资”企业做过总结，他们认为“假内资”企业的存在说明了三个问题：“一是有些限制措施也许本来就不必有；二是有些限制措施技术上很难限制；三是有些限制措施在执行过程中被腐化了。”
　　今年1月，美国市场咨询公司Niko Partners与权亚律师事务所（TransAsia Lawyers）共同发布了一份题为《中国游戏产业法规全景》（China's Videogame Industry Regulatory Landscape）的调查报告，该报告对单机游戏、网络游戏和电视游戏在中国所处的法律环境作了考察。Niko Partners执行董事丽莎。科斯马斯。汉森（Lisa Cosmas Hanson）认为：“复杂的法律环境是国外公司进入中国市场的主要壁垒，这主要是因为十个政府部门和机构都在为这个行业制定法律规章。”
　　在日举行的“国产游戏软件和网络游戏产业发展”研讨会上，网游行业的三个主要管理部门――信息产业部、新闻出版总署和文化部――的领导均到场并作了发言。新闻出版总署音像电子和网络出版管理司副司长寇晓伟在会上指出，游戏从业人员必须了解八个法律规章，他归纳为“一法、三条例、二决定、二规定”。“一法”即《著作权法》，“三条例”为《电信管理条例》、《互联网信息服务管理办法》和《出版管理条例》，“二规定”包括《电子出版物管理规定》和《互联网出版管理规定》，“二决定”指《国务院关于第三批取消和调整行政审批项目的决定》和《国务院关于第三批保留行政审批项目的决定》。除了这八个法律规章外，文化部的《互联网文化管理暂行规定》也是各游戏公司必须了解的。而就在这次研讨会召开的一年前，日，即《互联网文化管理暂行规定》正式实施的第二天，新华网曾刊登过一篇题为《行政法规重复交叉 互联网出版企业困惑尴尬》的文章，该文作者认为多头管理不仅会增加企业的运营成本，而且会贻误商机。
　　对于不熟悉中国法律环境和市场环境的国外游戏公司，如果它们只是想把自己的游戏引入中国，而没有更大的野心的话，最理想最稳妥的方式无疑还是传统的授权代理模式。不过近几年，即便是产品的引入也变得不那么容易。有人将四年多前《奇迹》（MU）的遭遇视为这一变化的重要分水岭，2002年9月，九城与Webzen成立合资公司，获得《奇迹》的中国大陆地区代理权；而直到五个月后，2003年2月，《奇迹》才正式收费，原因是版号迟迟没有拿到。从那一年起，政府开始对境外游戏产品，即“外版产品”，的进口总量实施控制。
　　然而，究竟什么是“外版”、什么是“内版”，并没有一个很准确的定义。目标软件作为一家外资企业，它的游戏产品属于内版还是外版？大宇开发的以中国传统文化为题材的游戏，属于内版还是外版？那些“借壳”的游戏公司，是否会利用“内资”的身份走捷径？两年前，台湾松岗科技线上游戏处总监陈居丰在接受本刊记者采访时即对内外版的标准提出过质疑。他说：“海外游戏的引进受到限制，目前内版是蛮受鼓励的。有人说只要在当地研发的游戏就算内版，有人说必须是要内资公司研发的才能算内版。有很多种说法，到底哪种说法才是可信的？审核的标准能不能更清楚一些？”
　　如果说ICP证、网络文化经营许可证的发放，影响的主要是网络游戏运营商的话，版号的问题影响的则是包括PC单机游戏、TV游戏和网络游戏在内的所有游戏产品。
　　以何种方式去适应中国游戏业的法律环境？在中国游戏业中应扮演怎样的角色？这两个问题，无论是关注中国市场的国外企业，还是立足本土的国内企业，都应该慎重思考。正如陈朝勋所说：“外资企业应该也必须遵循中国政府的所有法律法规，这是企业合法、永续经营的基础。不单单是外资企业，所有行业内的企业也都应该这么做。”
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&更多最新文章相关作者文章搜狗：感谢您阅读讨论：大家对游戏开发都存在哪些认知误区？ 本文版权归原作者所有，本文由网友投递产生，如有侵权请联系 ，会第一时间为您处理删除。提示：用户名只能修改一次，请慎重选择名字，大讲堂建议用户使用真实姓名作为用户名。
腾讯资深产品经理谈敏捷开发于游戏
&&& 敏捷开发思想谈&&&&&& 敏捷的原则
&&&&& 敏捷开发其实并没有标准型的流程。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.这一点大家应该明白，我们始终都是在做游戏，如果我们的方法正确，计划正确，那么这些评审对我们产生不了任何影响，那么既然我们每次都需要针对这些评审改变我们的流程计划，那么是不是也意味着我们本身的计划也存在一些问题？这个问题大家也许可以思考一下。不要让问题找到我们，而是我们去寻找问题。
&&&&&&& 故事WHY ME? WHY STORY?
&&&&&&& 为什么要使用故事？
&&&&&& 我们为什么要使用故事？要理解这个问题，首先要理解故事的作用。那么故事的作用是什么？
&&&&&&& 消除理解误差。
&&&&& 早期软件开发的需求方往往不懂任何技术，开发者的功能清单却往往难以让需求方有直观的对最后成品的认识。比如，或许一个功能描述是，“战斗场景分为5层可以根据摄像机的移动而相对运动”，但对于非专业人士来说，他们可能无法理解这样的描述意味着什么。于是故事开始发挥了它的作用：以一种大家都认可的方式让所有人对我们要做的功能目标有清楚的认识。
&&&&& 所以：
&&&&& l&&只要能够让全体人充分意识到我们功能开发的目标以及内容，那么它就是一个很好的故事。
&&&&& 对我们来说，这样的共识需要在策划，美术，程序等人员之间达成，所以我们的故事也需要以一种大家都能理解的方式来表达。而更重要的，不是故事的方式，而是确实所有人都能够完全理解。具体怎么写，其实真的怎么写方便都可以。
&&&&&&& 整体统筹估计和管理。
&&&&& 由于故事是从系统和结构的层面，以一定的高度来描述我们整个项目的框架功能，所以我们可以以较快的速度全面了解我们的功能点，而对于这些功能点，我们还可以进一步快速的给出粗略的估算。进而得出整个项目的大概工期或者每个迭代我们可以完成的故事数量。这里的估算往往是由不准确慢慢到准确的。
&&&&&&l&&每一个周期，每一个项目的历史数据都可以让我们之后的估计更加精确。
&&&&&&而且这样划分的工作，可以更好的交付给不同的小组完成。小组内部进一步自行组织计划，使得我们的管理工作可以分散到小组，降低管理难度。
&&&&&&&&创意管理
&&&&&本质上，游戏就是已有的同类游戏的完整功能点，加上我们独特的创意。完备的前者能让我们的游戏成为一款合格的游戏，而后者的加入则让我们的游戏变得独特。引入故事后，我们可以总是在一个层面，对功能开发和创意尝试的投入进行平衡，相互以取舍。我们可以总是以功能和创意的价值来判断真正对我们有价值的开发顺序。&&&&&&&故事在讲什么？
&&&&&&&什么是故事?
&&&&&&首先，故事本质上依然是功能点，依然是从需求中抽取出的一个个系统功能。只是以一种所有人都能理解的形式进行描述。所以，为了能够让所有人能够理解，故事仅仅只从实现功能的目的来描述这个功能：
&&&&&&l&&故事是对功能的目的的描述
&&&&&&同时，故事是在讲述这个功能究竟是发挥什么样的作用。所以它本身价值只是简单描述和给予一定参考。
&&&&&&l&&它不是，不能也不需要详细的描述这个功能的所有细节和玩家对此的感受。
&&&&&&因为前者有相应的策划文档，后者难以文档化以标准衡量。
&&&&&&所以，当我们要验收某个故事的时候，并不是我们比照着一个个故事，来体验游戏。看一个个故事是否在游戏中完整的实现了。
&&&&&&正确的故事验收，应该是在这个故事在组内达成统一之，所有人就应该知道要做成什么样子之后。将单个功能的验收在周期内
就实时完成。而在最后版本发布之时，对功能进行检验，检测这个功能的最终效果是好还是坏。
&&&&& 我们的目的不只是要看是不是功能A,B,C,D已经完成了，我们应该再深入一步：
&&&&& l&&关注于功能是否得到了很好的效果，符合了我们的预期
&&&&& l&&在游戏开发中，则是，是否有了乐趣
&&&&&&l&&是否有其他想法，能够让这个游戏更有趣
&&&&&& 因为仅仅是功能的集合，并不能成为合格的游戏。
&&&&& 因此，我们也需要改变我们对于设计目的的定义：
&&&&& l&&我们的目的并非仅仅是完成某个功能，而是功能能否达到我们需要的乐趣。
&&&&& 带着这样的思路，我们才能真正的在版本回顾的时候，给予能够指导我们开发方向的反馈，而非仅仅是针对我们功能开发的完整与否，发表意见。
&&&&& 作为核心组成员，或者，作为整个游戏项目的一员：
&&&&&& l&&我们不应该仅仅关心于完成情况，各种细小的错误。我们应该看得更远，思考的更远，给予我们的开发真正能提升最终质量的帮助。
&&&&& 最后，故事包含对它大小的估计，我们可以使用这个估计来对将来的工作和计划进行评估；对它本身价值的估计，让我们在选择他们时可以参考。简单的来说，就是另一些附加的功能。
&&&&&& 用好你的武器
&&&&&& 如何使用故事
&&&&& &故事的来源
&&&&& 第一，从已有的游戏设计文档或者框架中抽取的，比如，我们已经知道我们要做的是一个回合制战斗的游戏，那么我们就可以抽取出，基础战斗指令，回合制战斗流程之类的故事。
&&&&& 第二，新出现的创意性质的内容，比如，今天我突然想到在回合制战斗中加入行动顺序条或许是个很有趣的点子，我告诉大家，大家也觉得这个东西很好，于是我把它加入到清单中。
&&&&&&第三，当我玩到某个游戏的版本的时候，发现，某个功能给我的反馈不是很好，或者我觉得可以如何改进，能够让这功能变得更好，那么也可以放进到故事清单中。
&&&&&&& 故事的使用
&&&&&&首先，我们有一个用来维护故事的列表，术语叫做产品订单，里面罗列了所有我们已经完成或者没有完成，重要的或者不重要的故事。我们可以在里面清楚的看到：
&&&&& l&&故事的描述
&&&&& l&&故事点（大小）
&&&&& l&&优先级（价值）
&&&&&&l&&当前状态
&&&&&于是，在每个迭代开始的时候，我们都将故事从大到小排列起来，依据上个版本我们能完成的故事量（以故事点来衡量）来选取我们这个版本需要完成的故事内容。
&&&&&&故事选取完成后，下一步，则是让整个小组对故事的内容达成统一。也可能只是统一目标，而某些细节在完成的过程中确定。这过程的形式，依然并不固定。
&&&&&& 当大家对故事的内容都有所了解之后，我们可以开始对故事进行分解。得到相应的详细的任务。任务又成了计划，在对计划进行评估和检验之后，每个周期的工作内容就如此确定。
&&&&& 故事的作用就基本到此结束，剩下的内容是当单个故事完成的时候，对版本中功能进行体验，如果通过，则这个故事就此完成，最后进行归档之类的收尾工作。
&&&&& 当然，在故事的具体使用中还有一些细微操作，比如如果一个故事在一个周期中制作时发现比估计的大很多要放到两个周期来做才能完成。那么我们还需要对故事进行拆分之类的操作。这些细微操作还是需要在针对不同的情况进行不同的处理。 &&&&&& 版本体验会
&&&&&&当我们一个周期的开发内容完成，每个版本功能都已经在周期内得到了验证，并且已经有了一定的优化。为什么我们还要有一个版本体验会呢？
&&&&&&首先，我们每个人负责的领域不同，我们有的人对于美术质量很关注，有的人对于代码质量很关注，有的人对于设计文档很关注。也许我们中的一些人参与了一些功能的开发，但是我们并不能对于这个周期的所有功能，所有的改动有所了解。就算对此有所了解，我们也许也不明白每一个功能的设计用意。最后，为了让所有人对最终结果达成统一的认识，我们需要一个正式的展示会议，向核心组或者高层进行我们这个阶段的成果展示。在展示我们的版本新增功能和内容的同时，核心组也会对这个版本的各个细节和内容进行考察和审核，确定这样的改变是否符合对于游戏性和乐趣的追求，是否符合我们对我们游戏的希望，这样的发展方向是否是正确的。
&&&&& 而在这样的会议中，最重要的是，我们需要得到来自各个方面的反馈。作为开发者，这可能本身就局限了我们对于我们的版本的认知和看法。我们对于我们的版本过于熟悉，有可能自动的忽略掉了一些很重要的问题，或者会错误的认为一些难以被接受的游戏性具有很大的乐趣。而这样的会议，则是指正我们类似问题的恰当时机。针对这些反馈，我们可以更好的修正我们的工作思路和计划。给予我们下一个阶段更好的目标。
&&&&& 所以，在这里，核心组需要给出的，更多，更重要的，还是对于我们游戏的方向性的，涉及到我们目前开发功能的游戏性和表现上的改进意见或者反馈和一些指导性的意见。因此，我们需要要求我们核心组本身更了解 游戏，更明白游戏性，并且自己对于我们要开发什么样的游戏，有清醒的认识和思考。 &&&&&&& 周期总结会
&&&&& 自适应，自我优化的流程，需要有两个要素才能真正的进行自我改进。首先最重要的是其中的人要有对流程中的问题，需要优化的地方，甚至是对优化本身有清醒的认识和意愿。其次，就是这样的人推动的一个优化行动。而周期总结会，就是SCRUM中设立的一种针对流程自身优化而进行的一种行为。
&&&&&&项目总结是游戏业的一个普遍工作习惯，在每一个游戏项目结束的时候，会进行一次全项目级别的总结会议，对于整个项目过程当中，做的好，有典范价值的事物，或者在过程当中发生的有范例价值的问题，甚至是还没有解决的问题进行系统的总结和提炼。之后将之发表，可以成为团队，甚至其他团队将来工作时的依据和帮助。
&&&&&&而每一个周期一次的周期总结，则是将这一行为加快，频率加高，在项目进行中不断反复。以此达到更快速的寻找总结目前我们的优缺点，针对我们目前的缺点问题寻找 解决的办法，并且开始行动。总的来说，就是以更快的频率不只是迭代我们的版本，将我们的版本改进的更好。同时也是迭代我们的行为，优化和让我们自己更加的进步。
&&&&&&其实设立一个这样的会议并不难，每一个周期我们都会有这样的总结会。而会议也总会有这样那样的缺陷和需要优化修改的结果。难的是我们需要切实的推行那些问题的修正措施，难的是我们需要能够直面我们的不足，并且将其提出。我们要能对或许难以开口的问题更直白。鲁迅先生有云，真正的猛士，敢于直面惨淡的死生。我们必须承认我们的工作都是不完善的，都是需要优化的。但是这些问题都不是阻止我们开始修正和改革的借口。敏捷开发的意义也就在于，知道一开始的我们不足以成功，甚至肯定会出现问题，会有失误。但是正是在一次次快速迭代中，我们快速的磨合，快速的修正，最后在一次次的改正与进步中，我们才会得到一个完善的团队，一个良好的流程以及一系列适合我们的方法。
&&&&& 这也才是周期开发的意义所在。所以，敏捷开发，并不是一个需要在一开始就有完全的准备的过程，并不是一个需要完整规划，好好考虑的过程。我们只需要有一定的东西可以开个头，哪怕还不算成熟，但是我们依然可以在接下来的过程中，对我们的目标愈发的清醒，越发的明确，并且我们本身也会越发的成熟，最终共同达到目标。
&&&&&&一开始，游戏功能不明确？没问题，我们可以先从知道一定会做的开始做，然后开始探讨我们最后要做的目标，再根据每一个迭代的版本反馈修正我们的目标。
&&&&& 一开始，我们开发团队磨合不够？没问题，我们可以先让他们从开发简单的底层功能做起，并且同时进行磨合，将磨合过程中需要解决的问题一一提出并改正，最终优化得到一个完善的团队。
&&&&&&一开始，我们的工具不够？没问题，我们可以先用最快的方式开发原型，同时分析原型制作的方式和需求，进行工具制作。并且在工具可以使用之后，再根据使用者的反馈和项目的进展进一步的优化和改进。
&&&&&& ... ...
&&&&& 我们可以做的东西很多，而那些还没有做的，也同样不能成为我们开始做的障碍。
请选择禁言时间:
Copyright (C) 1998 - 2013 Tencent. All Rights Reserved.&&腾讯公司 版权所有