本周小孩送回姥爷姥姥家，终于有时间更新一下自己的微博了，三年没更新了，我真TMD懒惰！我错了。。。。这次努力更新一些东西
有些人问我，为啥不去一些大点的微博站写这些内容。我觉得没有必要啊，反正早晚都会被搜索引擎爬到，哪里都一样。
本文纯理论，是一个思想指导，你完全照搬，你就输了。。。。尽可能写的雅俗共赏一些，一起研究学习进步！
正文开始。。。。。（哪那么多废话。。。果然人老了）
首先，我们要明确两个概念
瀑布式开发：瀑布式，顾名思义，自上而下，连绵不绝，稳步推进。瀑布式开发，是一个我们最常规的开发方式，他应用于各行各业。在做之前，我们先安排一个缜密的工作计划，环环相扣，有前置条件，有最那天开始的工作。然后稳步推进，最终见到结果。
敏捷式开发：这是一个前5年开始流行的一个开发模式，流派很多，这里说的敏捷是Scrum。敏捷开发有点像一个没有地图的人周游世界，你一直在前进，一直在变化自己的路线，当然这个比喻也想有点不恰当。
还是不明白的，请参考各种维基
好，那我们说回来，网络游戏项目，也是一种负责的IT项目工程。虽然他的参与职能超级多，周期也不短，那自然要套用一些开发的指导思想
首先，我们要假设几个前提（为啥？具体问题具体分析）
1.我们这个项目，全新的，没有任何基础（可以是新平台，也可以是游戏类型全新创造，反正就是没有积累，或者有积累，但只能瞻仰）
2.我们项目，要调优，要做换皮、要做升级、要做资料片、要移植平台（反正不管怎么说，不是全新创造，继承已有事实，做同类型产品）
3.我要拿我们RPG的3D引擎，做×××游戏，或者其他啥的跟RPG没关系的（借用现有资源或第三方资源，做一个你没有积累的事情）
这是两个在项目初期遇到的比较明显的问题，好，具体来分析一下
1.首先如果你是一个全新项目，面临一穷二白的尴尬境地，你敏捷啥？敏捷不是强调持续的交付，持续的拥抱变化么，而且敏捷的最大的问题在于，并么有长远目标规划，不适合这种动辄1-2年的持久开发期。
在一穷二白阶段，瀑布式开发，是你最好的选择，你要努力的搭建出你的产品概念原形，或者，稳步的构建你的基础引擎（服务器+客户端）
在瀑布式模型中，你有一个非常明确的目标，并且划分出明确的阶段性、里程碑。这些基础内容，一般不会出现什么方向性错误（当然，如果你的策划很扯淡，上来要做的事就定错了，那就SB了，啥开发模型都解决不了这个问题。当然，有一个东西可以帮到你，请参考我后续博客中，关于 标准网游开发模型 立项篇）
那么我们只要按照我们的开发模型，来进行项目的前期规划，就可以得到一个可执行性很高的工作计划，他的目标非常明确清晰，里面有大量的实验，还有要实现很复杂的架构设计，反正总的来说，做了好多，就是在做基础，游戏根本还没影子呢。
好，经过我们半年的努力，我们的基础平台终于搭建完毕（服务器与客户端的引擎，非业务逻辑部分，也非业务支撑引擎），马上就要开始我们的产品原型制作。我们要用我们这些半成品的工具来进行原型开发，努力按照代码驱动，把我们的花架子，搭建出来。结果搭建出来，老板也很满意，那么就会进入到实际的开发阶段
实际的开发阶段不用于前面这个阶段，他是真刀***的，代码驱动，面向过程的做法，不可以了，要不然后面你会死！现在需要转向数据驱动，整个从新打一个真架子，走完这个阶段，我认为，该考虑转变开发方式了！
为什么呢？因为一旦游戏真正的开发原型搭建完毕，完成核心系统开发，就要面临一个严肃的问题，你的游戏，好玩吗？（不好玩？那赶紧砍掉项目，开饭馆去吧，不是说失败的IT人，最终命运都是开饭馆去吗？）好玩吗，这个问题，超级严肃。这关系到你的游戏设计，最终能否经得起用户和市场的考验。这个阶段，我相信你的项目管理压力，会上一个档次，所以合理的开发方式，将会缓解这些问题发生时的压力。
中途插一句，瀑布式开发网游的最大问题的实例，就是，有些人，总说，我们游戏还不完整，还没有体现出我们真正的设计，反正核心思想是，做到最后，他就成神了！就一定能成功。我觉得这纯属扯淡，扯各种蛋。当你中途已经偏离最终方向（高品质，好体验的游戏产品）的时候，后面那些事，做越多，错越多，当然游戏项目类型不同，有些的确需要核心玩法完整性才能真正体现游戏乐趣，如休闲竞技类游戏。
好，当你产品原型具备，核心玩法开发完毕，这个时候，我建议转向敏捷的开发方式。具体讨论，请看一下个问题分解。
2.针对第二个问题，就是针对已有的产品基础，进行完善、升级、再包装。我推荐，这种项目一开始，即采用敏捷开发方式。
敏捷开发的优势在于，不断修正前路，以便到达无限远的终点（虽然谁都不知道终点在哪里）
简单回顾一下该怎么做，假定接着问题1继续展开
首先，我们要形成一个可以进行敏捷开发的组织结构，具体的可以维基
接下来，我们要开始形成我们的，工作任务备选单（Backlogs）既然是备选单，一定特别特别多
再接下来，这么多任务，不可能一口气干掉，那我们来评估一下关键路径，划分一下优先级和工作量人时
那么，一个很棒的Backlogs形成了，我们还要，根据自身项目的时间安排，来安排阶段开发计划（sprint）注意工时的分解颗粒度与饱满度
好，一切就绪，开始干活，每个人都领到了自己的任务，那么大家狂加班。。。。。
加了4天后，到了周五，我们做整合工作，整合完毕，交付测试，交付验收（也可以根据项目进展，考虑是否采用持续集成）
好，经过这么1个月的折腾，我们做了4个版本，并且最终合并为X月测试版，交付内外部客户评测
对比瀑布式开发，交付的周期被大大缩短，瀑布式开发中，很多时候要看里程碑，但是两个里程碑之间间隔，有时候超过3个月甚至更多，这对项目对市场或者运营的快速反应，影响巨大
所以，敏捷开发，在游戏项目中，比较适合后期，完成核心玩法功能开发后，进行铺量和调优。又或者 扒皮、平台移植、资料片等
3.第三个问题，挺有意思的，我相信使用第三方引擎的人，会有面临这个问题，你说你有积累吧。。。的确有，但是跟你要做的事不搭嘎，这的确挺悲催的。那好，也来分析一下，我认为对的方式方法
对于这种情况，一定是敏捷和瀑布杂糅一起使用，怎么弄？
首先，引擎成型，很多基础工作你省了，恭喜。
然后，你需要有个敏捷阶段，确定如何改造引擎来适合新产品（肯定得改改吧，或者根据需求，确定你新的制作方案）
再来，你还是需要做一个瀑布式开发，做你的产品原型，有了工具，只是简化了你做工具的时间，并没简化这块
再来，当产品原型通过后，你还是需要进行开发，这块瀑布也是可以的
当你的开发结束后，你又要走敏捷的路线，调整产品
好，看完了这些，有人会问，有没有一种新型的开发模式，统一起他们俩？这个当然有的，可以参考一下FDD 需求驱动开发 ，但是我认为，有点难，难在，他需要有个非常有效的开发模型作为指导方向（这解决了，敏捷开发没有中长期精准目标的问题），但是开发模型这个玩意，也就是大公司有时间总结归纳，一般小公司小团队，都是经验致胜。
游戏的用户体验是唯心的，项目管理可以约束过程，但搞不定结果，所以当你体验不行时，再好的项目管理也白搭。相反，当你体验很棒，但是时间成本质量的平衡把握不住，哪也许就会毁灭一个伟大的项目。
请记住仔细阅读下面句话
这3种问题的类型，我描述的条件太少，实际工作中，遇到的问题太多，还是那句，具体问题具体分析。不管黑猫白猫，做了赚钱产品的就是好猫，不要纠结与开发模式上，其实只要项目管理者习惯，并且能管好，那种都行。
原创文章，作者：kepupublish，如若转载，请注明出处：https://blog.ytso.com/192199.html