- 项目管理 / 程序架构 / 软件开发模式 相关极简史

- 假定 “人性懒贪痴嗔” 会有一些让人不舒服的观点

- 说起来距离写下第一行代码差不多10年了。。。

假设前提：游戏 或 其他任何有一定难度x规模的大型软件项目，开发过程中存在【高技术人员/管理方/低技术人员】的3方博弈。

|利益相关者分析

高技术技术人员：能独立设计画风的美术工作者 / 能完成网络架构的程序员 等拥有不可替代性能力的人员。

回报 = 行业内曝光度/影响力 + 经济回报 - 脑力消耗

管理方：资方 / 出版方 / 甲方 / 偏商业化设计的游戏策划。不直接参与游戏/软件内容的生产。

回报 = 经济回报 - （减少脑力消耗+管理成本+社会资源消耗）+ 可能由项目出圈影响力带来的超额收益

低技术人员：对游戏/软件开发并无太大热情的普通打工人

回报 = 经济回报 - 脑体力消耗

|各个开发模式

90年代 - 相对来说技术主导

所谓各种【数据中心/开源库/开发套件】等概念还没有流行起来，相对来说软件开发人员的基础知识都比较扎实，同时由于程序员当时工资不高，并没有大量的对技术没有热情的人进入行业。

所以当时更多的是企业自己购买硬件，采用【Waterfall / 瀑布式开发】，即像传统工业产品设计一样，在开始开发前有一个具体的参数要求，然后根据现有技术设计，最后开发出来一步到位。

好处-对实际开发者友好，团队内部的各种损耗较小。

坏处-项目周期长，前置的投资/成本高昂。

2000年左右 - 相对来说3方势力平衡的时期 - 敏捷开发

将硬件初步托管给第3方，软件上也逐渐出现了一些后来会成为行业标准的软件库（可重复再利用的代码），但是如果像3A游戏/主机游戏等一些高性能软件，高技术开发人员还是很大的话语权和不可替代性。

这期间由于不同项目间确实有一些相似性，可以先从一个【MVP/Minimal Viable Part】的软件骨架上开始，然后逐渐添加各类功能，最后再调优成一个合格的软件产品。这样就不需要从一开始设计好整个软件，而是可以在开发过程中随时调整了。

好处-资方风险和实际开发者的劳力支出达到一个平衡

坏处-经验不足对项目预估出现大偏差时会有大量返工的情况 影响项目周期/成本/士气

2017年左右 - 管理方主导 - DevOps

由于已经有大量的通用开发套件，【低代码开发 Low-code / 可视化开发 Visual programming】等不需要代码相关知识的开发概念开始流行，由钻研技术带来的少量性能/用户体验 提升也很难带来额外利益，高技术开发者和低技术开发者对于管理方来说不存在本质区别。资方/商业化相关设计人员/管理人员 开始主导。

较之前来说 DevOps 和另外2种开发模式，因为DevOps更不强调区分不同实际开发者之间的分工，管理者对技术的理解需要得更少，管理方的管理成本更小。

*实际项目中几种开发模式混用是很常有的事情，就游戏来说 运营维护LiveService阶段后，从瀑布式转为敏捷式也十分常见。没有那么死板。

**如果管理难度大，通过自己出资/降低项目难度/只采用复合型高技术人才 等 都是可以将1方排出这个3方博弈，降低管理成本的方法。

|总结

其实这20年软件开发模式的变化也没什么出人意料的。经济好，需求旺盛，由于高技术者带来得2%~3%的性能提升就可能被市场放大成为数倍乃至数百倍的回报，所以管理方愿意负担高昂的前置成本去搏阿尔法收益。经济不好，需求不再增长了，管理方就降本增效，分摊/隔离风险，尽可能增加贝塔收益。就。。。还挺无趣。。。