布鲁克斯

2. 人月神话

  • 提前预留足够的测试时间
  • 开发并推行称产率图表、缺陷率、估算规则
    • pingcode的速率图、燃尽图
    • 缺陷率。总结归纳作为前车之鉴
  • 缺乏合理的时间进度，是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大
  • 围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
  • 想进度落后的项目中增加人手，会是进度更加落后(任务重新分配、沟通成本、培训成本、原有任务中断)

4. 系统设计

  • 为了获得概念完整性，设计必须有一个人或者具有共识的小型团队来完成。

5. 画蛇添足

  • 这部分内容对应PMP中的范围，即：做且仅做。防止范围蔓延而带来的额外成本。
  • 范围蔓延在游戏项目中应该属于最常见的事情，游戏功能、玩法经常改动

6. 贯彻执行

  • 手册/文档
    在游戏项目中，最应该做这部分的应该是一些中台技术(SDK、游戏后台数据上报、CI/CD)及引擎优化建议；因为游戏类型不一样(MMO\FPS\MOBA)除了上述一些通用接入类型的事情，很难总结出一些有用内容，以及没有那么多时间来写项目手册；换皮版本基本也还是原版人马接着做。所以基于项目的手册 在游戏行业基本不受重视。
  • 会议
    会议目的是为了及时发现问题，提前规避及解决风险及信息共享。常规而言都是周会、月会进行跟进。在敏捷开发中会议更为频繁，但目的是一样的。但敏捷开发的每日站会很容易流于形式至消失。
    会议记录
    会议记录留痕在我看来是个很重要的东西，记录每个阶段的问题及改进方向，作为前车之鉴的知识储备。
    现在在线协作文档自带的会议模板基本就很好用了，如果没有内网限制不妨试一下(Confluance/PingCode的WIKi/语雀/腾讯文档/石墨)
  • 测试
    唉

7.为什么巴比伦塔会失败

  • 缺乏交流以及交流的结果-组织
  • 团队应该以尽可能多的方式进行相互之间的交流:非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手机以及电子邮件。

大团队 产品负责人主导

小团队 产品负责人打杂

12.干将莫邪

12.1 目标机器

这部分可以理解为手游开发中的最低适配机型，确定好最低需要适配的机型后尽力保证在最低要求手机上流畅运行。

12.3 高级语言和交互式编程

  • *高级语言: 高级语言的主要原因是生产率和调试速度。
    就目前的Unity而言，使用lua的项目占比依然很大。目前而言，从招人、培训、社区等方面而言 lua的确有优势，但随着游戏要求越来越高 lua在效率、调试、代码质量上面的问题也会随之加剧。在出现新解决方案,例如HybridCLR我的个人建议是积极适配(起码目前我们项目是使用了)

13.整体部分

13.1 剔除bug的设计

  • 防范bug的定义
  • 测试规格说明
  • 自顶向下的设计
    其中关于自顶向下的设计这一则，对策划也尤为重要。一套自洽的产出、玩法等能很大程度的避免项目中后期因为体验不好进而带来的返工。

14.祸起萧墙

14.1 有效的里程碑

里程碑的选择只有一个原则，那就是:里程碑必须是具体的、特定的、可度量的事件，能够清晰定义。
  • 里程碑有明显边界和没有歧义，比它容易被老板核实更为重要
  • 好的里程碑对团队来说实际上是一项服务，可以用来向项目经理提出合理要求的一项 服务，而不确切的里程碑是难以处理的负担。
  • 慢性进度偏离同样也是士气杀手

14.2 关键路径(PERT)

14.2.1 三时估算:

$t_i = (a_i + b_i + 4c_i) / 6$
公式中：
$t_i$:工作i的平均持续时间
$a_i$:乐观估计时间
$b_i$:悲观估计时间
$c_i$:正常估计时间
扩充: 方差公式$σ_i^2 = [(b_i – a_i) / 6]^2$

14.2.2主要作用:

  1. 标识出项目的关键路径，以明确项目活动的重点，便于优化对项目活动的资源分配
  2. 当管理者想计划缩短项目完成时间，节省成本时，就要把考虑的重点放在关键路径上
  3. 在资源分配发生矛盾时，可适当调动非关键路径上活动的资源去支持关键路径上的活动，以最有效地保证项目的完成进度
  4. 采用 PERT 网络分析法所获结果的质量很大程度上取决于事先对活动事件的预测，若能对各项活动的先后次序和完成时间都能有较为准确的预测，则通过 PERT 网络的分析法可大大缩短项目完成的时间

14.3 地毯下面

周进度评估、月进度评估。
无论如何，提交真实的状态评估
老板-监督小组-项目经理

15. 另一面

  • 流程图: 用于教学和解释，而不是程序前期设计。
  • 程序文档
    • 标签、声明语句
    • 提高阅读可读性：尽可能的使用空格和一致的格式表现丛书和嵌套关系
    • 以段落注释的形式，向程序中插入必要的记叙性文字

16. 没有银弹

  • 自行的进行市场调研，避免开发已上市的产品
  • 在获取和制定软件需求时，将快速原型开发作为迭代计划的一部分
  • 有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能
  • 不断挑选和培养杰出的概念设计人员

解决复杂性的一些方法：

  • 层次化，通过分层的模块或者对象
  • 增量化，从而系统可以持续的运行