【FF14】长草期电台·敏捷开发是把双刃剑|自制杂谈电台节目#001

我非常同意up想表达的主要观点:吉田7.0做的不好很大原因是因为被太多项目分散了精力，不适合的工作模式可能也进一步降低了他们的效率，最终导致了游戏质量的下滑。 但我想为敏捷开发发声，我已经在敏捷式开发的工作模式下工作好多年了，个人感觉进入敏捷式开发模式以后工作量并没有增加。你会感到劳累可能是因为你被安排了太多的工作。请不要被工作逼得太紧。 此外我个人感觉ff14使用的工作模式应该不是敏捷式开发的模式(不管吉田他们是如何声明的)。敏捷开发得足够敏捷，给他们定个小目标:两周一个小版本。

♥ 82 ↩ 4

根本原因是ffxiv这个项目组能获得的资源其实并不多，所以才不得不采取现在这套开发模式，同时这套开发模式也正是小吉的看家本领。 原因其实很好理解，先不提se本身被诟病多年的老日企做派和黑奴薪水，从企业管理的角度来看，ffxiv这个项目的其实已经达到可预期收益瓶颈，也就是说无论你再往里面投入多少新资源，营收的增长率也不会得到大的提高，不如拿着营收去赌下一个项目。 这是正常的企业管理心态，但从目前的情况来看，se其他项目并没有大爆，反而是持续薄死（不包括16，16的收益实际上是符合SE盈利预期，也就是赚了的）。加上7.0营收下滑严重，8.0应该是获得了一些新的资源倾斜，至少se内部不希望在找到下一个支柱项目前，这个项目就这么死了。

♥ 20

6.0的质量下滑以及7.0的整体拉跨，其实都和第三开发部分心去做FF16有着极大关联的，现在8.0的开发已经应该算是完全回到正轨了，SE社长也特地在粉丝节上声明会加大对FF14的支持力度（应该是对之前媒体披露质疑SE克扣FF14利润引起玩家不满的回应），所以我个人还是比较看好8.0的整体质量的（制作组甚至都在新CG里故意致敬5.0的CG了），希望小吉这次别再让大家失望了，铁粉玩家们经不起再一次倒退滑坡了，而且我觉得SE同样也禁不起FF14再一次倒退滑坡的...[呆]

♥ 20

还有一个我听来的很地狱的事，据说三开部从口罩时期开始大多数人居家办公并一直保持到7.3上线前，直到7.3还是7.4前整个三开部员工没有几天是所有人都在办公室的，终于吉田直树受不了了让所有人回办公室统一办公，7.4的质量才得以回升。不保真因为是我听来的[笑哭]

♥ 18 ↩ 4

我就是策划[吃瓜]我可以很明确告诉你，现在7.0不好玩的主因就是吉田（项目负责人）。ff14现在不好玩有很多原因，但最核心原因是每个人都在做自己的，没把力往一个方向使。每个人都做到了各自领域的本职和水平（不包含剧情），没能把这些有机结合，就是大方向不对，这个锅吉田是逃不了的。还有种情况是他们在改底层的东西，导致无法应付线上版本。如果这能在7.0改好，后面研发才会越来越好，这个只能看后续的了。 关于敏捷开发，敏捷开发本身是好的，能让项目对线上数据更敏感，更灵活的应对玩家需求。敏捷开发需要配套的是mvp设计模式，小吉这就没怎么实施过，导致新内容经常积重难返。敏捷开发也有自己的问题，敏捷开发最重要的环节是数据复盘和方向调整，这些都是很吃时间的内容。当前版本在推进，后续方向又要改动，经常会越干越累，身心俱疲。 最后一点是一个策划兼容战斗副本，这个是比较正常，是为了保证设计感官体验的一致性。他的开发周期是一年半，从研发时间角度来说是勉强够的，没有给过多的任务。如果是国内的厂子，一个人半年你就得搞定[吃瓜]如果能给他多分点人力肯定好，帮他处理执行的活，能更好的在设计上出力。

♥ 16 ↩ 1

我还是觉得ff14的开发上的困境在于资源的浪费。消耗了大量资源开发的地图、副本无法有效的利用，过了两年的“保质期”就成了占用存储空间的过气玩法

♥ 15

同行业从业者，感觉传统行业某些领导层对什么是敏捷开发都没法理解，更别提用好这套架构了。他们认为的敏捷开发可能就是需求来了加班做就完事了。

♥ 11 ↩ 1

现在许多地方已经变成降本增 笑 的新衣了[笑哭]

♥ 10

【长期招募对聊天电台节目录制感兴趣的FF14玩家】 如您想参与到每周FF14主题电台节目录制请私信我，或联系Q649799422

♥ 10

我还以为是开发敏捷系职业

♥ 8

我认知里的敏捷开发一个很重要的特点就是灵活的release schedule，而这个表象是由项目内部任务的解耦和模块化达成的，配合快速无感的交付系统，以此持续不断地进行微迭代和无感更新，碎片化地、积少成多地进行更新和维护。ff14这种固定的、长周期的、内容模板化成组发布的死板schedule，感觉很难算得上是敏捷开发。而且mmo的内容消费模式就不太适配敏捷开发的短周期微迭代。

♥ 7

敏捷这种真的看行业，我是做传统制造业相关软件的开发，当时新的部门领导从外空降，也是大刀阔斧的搞了差不多3个月的敏捷开发，真把人搞得鸡飞狗跳，因为我们行业太多功能天然有极高的耦合性，很多功能的开发任务根本没法拆，然后又有大量的前后依赖，结果代码没写太多，时间用在开对齐会了，还不如瀑布效率高。 另外，游戏行业敏捷开发基本上做不了的，之前朋友公司过去帮忙写过一些游戏的代码，游戏行业的整体耦合性比我们还强，用敏捷开发应该也会遇到跟我们相同的问题，很多功能的任务根本没法拆，所以游戏做敏捷感觉可能性不太大

♥ 5

敏捷牺牲了效率，光从团队组织架构上做动作，比如把团队规模减小，服务化等很难完全把这部分损耗找回来。要不断地为更好的工具投资，来对抗复杂度，提高效率。好的工具通常是对问题进行了抽象之后，让关键的信息流动的同时，让关键的步骤被自动化，这其实解决的就是复杂度问题

♥ 4 ↩ 1

我30岁老登都觉得这电台太有班味儿了……

♥ 3

[打call]喜欢这个节目！接触到了不太了解的角度很新鲜（？）（没做过这方面工作ry）

♥ 3

看弹幕有不少说快睡着和班味的，但我觉得这个还挺有趣的。对其他行业从业者的看法很感兴趣

♥ 2

不是任务拆分和多任务并行就叫敏捷开发，敏捷开发是拥抱变更，快速研发、持续迭代，请不要以偏概全。而且FF14 的项目组也不能说是敏捷开发的团队，他们只是在项目管理中用到了敏捷开发的方法，项目管理的方式方法本身是可以灵活自由组合的。7.0 没做好就是产能不足 + 制作人没有专注在这，别怪敏捷开发。任务多是任务多，不是敏捷开发的锅好吗。

♥ 2

不知道理解的对不对，敏捷开发模式非常吃资源，资源有一点没跟上就会崩，7.0就是因为在被抽调去ff16+疫情的情况下仍然维持原本敏捷模式导致崩盘的产物。(我原本以为6.0就被影响了，大结局收尾过于赶以及6.x后种种迹象，但当时还以为原来即使人员被抽走了疫情了还能做成这样那还算可以了。) 虽然8.0还没玩到，但肉眼可见的工作量多，根据种种迹象来看他们还是没有取回被抽走的资源，所以8.0是仍然在崩盘的敏捷开发模式下做出来的？？全靠超人员工核心过载燃烧自己吗

♥ 2 ↩ 1

敏捷开发本身命名就是一种误解，这套模式既不敏捷也不是一种直接硬套的开发模式，充其量算是一种理想情况下的团队资源管理的成功案例，团队的开发能力、领导决策能力、项目开发周期、客户的需求全都不一样，举例现实最直观的例子就是胖东来。 说会狒狒，只从玩家角度体验项目产出，完全看不到任何敏捷开发的效果，甚至可以作为一种项目资源管理的反面案例搬上来

♥ 2

程序员看到这个标题还挺惊讶的，没想到是这样的内容形式233…… 但是听得很开心，祝越做越好。 顺道祝up主工作能正常一点……

♥ 2