https://simtarkus.wordpress.com/2022/03/24/the-nam-team-agile-like-development-paradigm-post-nam-37-how-it-works
2022 年 3 月 24 日 1 条评论
最近关注 Network Addon Mod (NAM) 发展的人可能已经注意到，在过去的 18 个月中，新版本的发布速度急剧增加。事实上，在 NAM 37 历时近 3 年之后，终于在 2020 年 7 月正式公开发布，在略多于一半的时间里，我们又发布了 7 个版本，包括新的 NAM 44 版本。我们还大幅增加了开发团队的规模，从只有 3 名活跃开发人员的骨干团队发展为拥有 30 多名成员以各种能力做出贡献的团队，接近 10 年来从未有过的规模。
自 2004 年以来一直在开发的电脑游戏模组（2003 年发布的游戏）在近 20 年后发生了如此多的事情，这一事实可能会让许多人感到惊讶。事实上，这对我来说也是一个惊喜，作为一个截至今年二月已经参与了 15 年的人，这是一个非常愉快的经历。我想我会分享我在过去 2 年中发生的变化的经验，以使 NAM 的这种突然滚雪球般的活动成为可能。
那些在过去 5 年中关注 NAM 项目的人至少知道臭名昭著的 NAM 37 的一些故事，其中一些我在 SimTarkus 上分享过。长话短说，整个开发周期都被诅咒了。在 NAM 36 于 2017 年 9 月发布之前，针对 NAM 37 的内容开发已经开始。但是，我们开始的许多项目都遇到了重大障碍（包括阻碍 RealExpressway 的“潮汐流”问题，RealExpressway 是最初计划的旗舰项目循环），导致它们被搁置并不断迫使我们回到绘图板上。我们非常小的开发团队，即使进行了一些轻微的扩张（包括我们的桥梁部门负责人 Kitsune 和 SC4 文艺复兴时期的人 Tyberius06 的关键增加），也经常被现实生活 (RL) 的沉重案例所困扰。
一旦我们终于让事情再次走上正轨，为这个周期组装了第一个完整的内部构建，恰当地命名为 NAM 37 Alpha Build 01（简称 NAM 37 A01，此后也被称为“核神器”），我们的安装程序系统——使用 NAM 36 已经变得有点不稳定——在接缝处完全炸裂，这是试图将可选组件之间日益密集的交联阵列围起来的产物，以及它与 NAM 控制器编译器实用程序交互的复杂性。它通常会完全跳过 NAM 控制器的编译，以及安装完整的预编译控制器的故障保护——鉴于 NAM 控制器包含在游戏中构建 NAM 网络添加所需的所有 RUL 代码，这是一个致命的问题。
NAM 37 Alpha Build 01 安装程序的屏幕截图——臭名昭著的“核神器”
这种情况导致了长达一年的时间尝试完全重新设计 mod 的文件架构，以降低内部复杂性，并允许它与不同的安装程序系统兼容。鉴于 Eggman121 和我自己都在“基本”行业工作，这种流行病并没有真正减慢我们的 RL 速度。整个周期是 NAM 为生存而进行的一场漫长的斗争——不知何故，我们确实生存了下来。但为了继续生存，很明显我们需要做一些不同的事情。NAM 37 的发展地狱不会再发生。
4 月 18 日，距离我们最终发布 NAM 37 的公开候选版本（在 2020 年 7 月正式发布之前）不到一周，我在 SC4 Devotion 的私人开发委员会发表了一篇冗长而坦率的帖子，题为“指导关于 NAM 开发和构建周期 – NAM 38 及以后”，或者可以开玩笑地称为“NAMifesto”。NAMifesto 基本上解决了房间里一些长期存在的大象问题（可以说自从 Tropod 于 2005 年底作为团队负责人退休后就一直存在），并制定了一个计划，以防止 NAM 37 再次发生，我们'从那时起已成功实施。我的同事 Lucario Boricua 整理了我们的 GitHub 代码提交图的注释版本，这说明了自 NAM 的“单体时代”开始以来的情况（从 2013 年开始，随着臭名昭著的 NAM 31 的发布——我们的 GitHub 存储库在该版本首次亮相前不久就开始了）。如您所见，与 NAM 37 发布后我们的活动相对应的“敏捷时代”部分具有一致的活动，其峰值比之前的“单体时代”任何时候都高得多
2013 年 2 月 24 日至 2022 年 3 月 22 日对 Network-Addon-Mod GitHub 存储库的提交图
NAM 开发的一个奇怪的事情是，在我在团队工作的 15 年中始终如一，那就是它在很大程度上是随心所欲的努力，而且本质上是即兴的，尤其是在发布周期的早期阶段。没有预谋的、集中的发布或功能集规划，开发人员通常不知道该做什么。相反，他们倾向于从事他们感兴趣的项目，通常与 NAM 发展方向的一种相互商定的路线图一致，无论是单独还是与其他开发人员合作，并且有一种共同的责任感事情通过一个可释放的状态。让具有共同目标感的开发人员能够获得这种程度的自主权确实是我们的开发流程和工作环境得以运转的关键。
然而，我们经常面临的结构性问题之一是，随着 NAM 的发展，项目的规模和难度增加，并且由于 RL 在整个发布周期中对开发人员产生不同的影响，这有时可能会导致已经很长的周期还要进一步延长。我们一直在工作，直到我们觉得给定的功能集“足够完整”，无论花了多长时间，而且这通常会陷入开发地狱，因为开发人员已经习惯了漫长的周期，并且会屈服于制作更多东西的诱惑。我们会在粗略的目标日期上写下，并且经常不断地超过它们——例如，NAM 28 最初在团队中被讨论为 2009 年 11 月的版本。它最终于 2010 年 5 月发布——尽管它也与期待已久的 Network Widening Mod (NWM, which was then a “separate-download plugin”), had a number of really ugly bugs that made it one of the worst releases the NAM Team ever made.
早期的 NAM 发布通常是快速的事情——事实上，在 NAM 的头两年，2004 年和 2005 年，发布周期的平均长度约为 3 周。但在 Tropod 退休后，随着 2005 年末 NAM 19 的发布，平均长度激增至 9 个月，并趋向于超过一年的周期，从 2011 年的 NAM 30 开始，最后一个“模块化时代”发布。开发周期的长度也没有带来更好的产品，因为开发人员和测试人员变得无聊和沮丧（包括我自己），并且失去了注意力。开发人员的想法是“如果我不把它放到下一个 NAM 中，我将不得不再等一年，也许更久。”
NAMIfesto 的目标是制止这种情况。解决方案是最终回到更类似于 Tropod-Era NAM 的东西——当时该团队仍被称为“Modd Squad Transport”。我提议：
发布周期长度的硬性上限，并执行该上限。
避免在 2010 年代在 NAM 开发中无处不在的各种重大重新规范项目，除非对它们有非常明显的好处。
不要害怕削减无法及时准备好满足硬上限的内容。
将大型项目重新定义为可以跨越多个版本的事物（通过分为多个阶段或在后台开发），同时提请注意在这种范式下“三个版本”仍然是比旧方式下的“下一个版本”更快。
团队的其他成员，在经历了 NAM 37 循环的无趣体验后，也有同样的挫败感，愿意试一试，并委托我作为官方团队负责人帮助制定这个计划（我们第一次自从 smoncrie 在 2005-2006 年担任团队负责人后，在 RL 强迫他结束了两年的中断之前，他确实有过一次。）在许多方面，我们最终构建的是一个“类似敏捷”的开发过程。虽然软件社区中的一些人可能会对“a-word”感到愤怒，并在脑海中勾勒出快速但漏洞百出的版本，以及要求不断更新状态的严厉项目经理，但 NAM 团队特殊的“类似敏捷”的方法避免建立正式的 scrums、sprint 等官僚作风。相反，它一直是关于取得成果, doing so through a sustainable, repeatable process, and maintaining the “chaotic good” that characterizes NAM development at its best.
虽然 NAM 团队的政策长期以来一直是避免与公众讨论发布日期和时间表（我们做过的一次是灾难性的 NAM 31 周期），但值得注意的是，自那以后，我们在每个发布周期都成功达到了“上限” ，Agile-Era NAM 版本的平均开发周期长度为 3 个月。
NAM 版本 1-44 的周期长度（版本 1 周期长度在技术上未知）
越来越多的关注使我们能够更快地处理错误报告和技术问题，并继续专注于我们的开发任务，从而产生更具凝聚力的版本，这些版本通常以比我们之前的马拉松周期更大的功能集而告终，并且与关于敏捷开发的刻板印象（以及周期更长的前敏捷 NAM 版本），更少的错误。如果一个功能还没有准备好，我们会简单地删减它，并在不久的将来的发布周期中重新访问它，从而让它达到一个稳定、成熟的状态，当它最终推出时可以供公众使用。缩短的发布节奏极大地帮助抑制了旧的做事方式强加给我们的开发人员的有问题的、人为的紧迫感。
这些变化重振了 NAM 开发工作的方式也使相当多的 NAM 新成员有兴趣学习一些必要的技能来做出贡献。我们很容易在各种开发任务中提高新团队成员的技能，从而进一步提高我们的吞吐量。根据 Lucario Boricua 对我们 GitHub 活动的计算，当前“敏捷时代”的 NAM 团队的生产力是之前“单体时代”的 4.4 倍（从 2013 年的 NAM 31 到 2020 年最终发布的 NAM 37） 。
我们也非常谨慎地努力发展团队，引进那些能力、个性和成熟度水平非常适合 NAM 生态系统的人。过去的一些人格冲突问题几乎使整个 NAM 工作脱轨（由于 2015 年 NAM 33 周期中发生的一个问题，我们失去了大部分开发团队），因此我们改进了我们的招聘方法（仍然是邀请-仅）的目标是引进能够与其他 NAMite 相互尊重的人。事实上，我们更倾向于关注这方面，因为 NAMites 可以通过多种方式为整体工作做出有意义的贡献。
在这些最近的发布周期中出现的另一个重大差异是使用私人 Discord 频道作为交流工具，而不是专注于论坛（我们仍然以某种身份使用）。Discord 的活跃、活跃的特性帮助创建了一个更具协作性、响应性更强的团队环境，这加速了开发并有助于促进团队团结。虽然我们可能没有适当的“敏捷”开发团队可能拥有的正式的 scrums 和站立会议，但这确实让我们能够定期、自然地进行沟通，无需任何技巧。
我们仍然在一些领域改进流程，但总而言之，NAMfesto 带来的变化可能产生了我参与该项目 15 年以来所见过的最富有成效和最和谐的 NAM 团队迭代. 这是希望我们可以继续进行更多。
-Tarkus
2022 年 3 月 24 日 1 条评论
最近关注 Network Addon Mod (NAM) 发展的人可能已经注意到，在过去的 18 个月中，新版本的发布速度急剧增加。事实上，在 NAM 37 历时近 3 年之后，终于在 2020 年 7 月正式公开发布，在略多于一半的时间里，我们又发布了 7 个版本，包括新的 NAM 44 版本。我们还大幅增加了开发团队的规模，从只有 3 名活跃开发人员的骨干团队发展为拥有 30 多名成员以各种能力做出贡献的团队，接近 10 年来从未有过的规模。
自 2004 年以来一直在开发的电脑游戏模组（2003 年发布的游戏）在近 20 年后发生了如此多的事情，这一事实可能会让许多人感到惊讶。事实上，这对我来说也是一个惊喜，作为一个截至今年二月已经参与了 15 年的人，这是一个非常愉快的经历。我想我会分享我在过去 2 年中发生的变化的经验，以使 NAM 的这种突然滚雪球般的活动成为可能。
那些在过去 5 年中关注 NAM 项目的人至少知道臭名昭著的 NAM 37 的一些故事，其中一些我在 SimTarkus 上分享过。长话短说，整个开发周期都被诅咒了。在 NAM 36 于 2017 年 9 月发布之前，针对 NAM 37 的内容开发已经开始。但是，我们开始的许多项目都遇到了重大障碍（包括阻碍 RealExpressway 的“潮汐流”问题，RealExpressway 是最初计划的旗舰项目循环），导致它们被搁置并不断迫使我们回到绘图板上。我们非常小的开发团队，即使进行了一些轻微的扩张（包括我们的桥梁部门负责人 Kitsune 和 SC4 文艺复兴时期的人 Tyberius06 的关键增加），也经常被现实生活 (RL) 的沉重案例所困扰。
一旦我们终于让事情再次走上正轨，为这个周期组装了第一个完整的内部构建，恰当地命名为 NAM 37 Alpha Build 01（简称 NAM 37 A01，此后也被称为“核神器”），我们的安装程序系统——使用 NAM 36 已经变得有点不稳定——在接缝处完全炸裂，这是试图将可选组件之间日益密集的交联阵列围起来的产物，以及它与 NAM 控制器编译器实用程序交互的复杂性。它通常会完全跳过 NAM 控制器的编译，以及安装完整的预编译控制器的故障保护——鉴于 NAM 控制器包含在游戏中构建 NAM 网络添加所需的所有 RUL 代码，这是一个致命的问题。
NAM 37 Alpha Build 01 安装程序的屏幕截图——臭名昭著的“核神器”
这种情况导致了长达一年的时间尝试完全重新设计 mod 的文件架构，以降低内部复杂性，并允许它与不同的安装程序系统兼容。鉴于 Eggman121 和我自己都在“基本”行业工作，这种流行病并没有真正减慢我们的 RL 速度。整个周期是 NAM 为生存而进行的一场漫长的斗争——不知何故，我们确实生存了下来。但为了继续生存，很明显我们需要做一些不同的事情。NAM 37 的发展地狱不会再发生。
4 月 18 日，距离我们最终发布 NAM 37 的公开候选版本（在 2020 年 7 月正式发布之前）不到一周，我在 SC4 Devotion 的私人开发委员会发表了一篇冗长而坦率的帖子，题为“指导关于 NAM 开发和构建周期 – NAM 38 及以后”，或者可以开玩笑地称为“NAMifesto”。NAMifesto 基本上解决了房间里一些长期存在的大象问题（可以说自从 Tropod 于 2005 年底作为团队负责人退休后就一直存在），并制定了一个计划，以防止 NAM 37 再次发生，我们'从那时起已成功实施。我的同事 Lucario Boricua 整理了我们的 GitHub 代码提交图的注释版本，这说明了自 NAM 的“单体时代”开始以来的情况（从 2013 年开始，随着臭名昭著的 NAM 31 的发布——我们的 GitHub 存储库在该版本首次亮相前不久就开始了）。如您所见，与 NAM 37 发布后我们的活动相对应的“敏捷时代”部分具有一致的活动，其峰值比之前的“单体时代”任何时候都高得多
2013 年 2 月 24 日至 2022 年 3 月 22 日对 Network-Addon-Mod GitHub 存储库的提交图
NAM 开发的一个奇怪的事情是，在我在团队工作的 15 年中始终如一，那就是它在很大程度上是随心所欲的努力，而且本质上是即兴的，尤其是在发布周期的早期阶段。没有预谋的、集中的发布或功能集规划，开发人员通常不知道该做什么。相反，他们倾向于从事他们感兴趣的项目，通常与 NAM 发展方向的一种相互商定的路线图一致，无论是单独还是与其他开发人员合作，并且有一种共同的责任感事情通过一个可释放的状态。让具有共同目标感的开发人员能够获得这种程度的自主权确实是我们的开发流程和工作环境得以运转的关键。
然而，我们经常面临的结构性问题之一是，随着 NAM 的发展，项目的规模和难度增加，并且由于 RL 在整个发布周期中对开发人员产生不同的影响，这有时可能会导致已经很长的周期还要进一步延长。我们一直在工作，直到我们觉得给定的功能集“足够完整”，无论花了多长时间，而且这通常会陷入开发地狱，因为开发人员已经习惯了漫长的周期，并且会屈服于制作更多东西的诱惑。我们会在粗略的目标日期上写下，并且经常不断地超过它们——例如，NAM 28 最初在团队中被讨论为 2009 年 11 月的版本。它最终于 2010 年 5 月发布——尽管它也与期待已久的 Network Widening Mod (NWM, which was then a “separate-download plugin”), had a number of really ugly bugs that made it one of the worst releases the NAM Team ever made.
早期的 NAM 发布通常是快速的事情——事实上，在 NAM 的头两年，2004 年和 2005 年，发布周期的平均长度约为 3 周。但在 Tropod 退休后，随着 2005 年末 NAM 19 的发布，平均长度激增至 9 个月，并趋向于超过一年的周期，从 2011 年的 NAM 30 开始，最后一个“模块化时代”发布。开发周期的长度也没有带来更好的产品，因为开发人员和测试人员变得无聊和沮丧（包括我自己），并且失去了注意力。开发人员的想法是“如果我不把它放到下一个 NAM 中，我将不得不再等一年，也许更久。”
NAMIfesto 的目标是制止这种情况。解决方案是最终回到更类似于 Tropod-Era NAM 的东西——当时该团队仍被称为“Modd Squad Transport”。我提议：
发布周期长度的硬性上限，并执行该上限。
避免在 2010 年代在 NAM 开发中无处不在的各种重大重新规范项目，除非对它们有非常明显的好处。
不要害怕削减无法及时准备好满足硬上限的内容。
将大型项目重新定义为可以跨越多个版本的事物（通过分为多个阶段或在后台开发），同时提请注意在这种范式下“三个版本”仍然是比旧方式下的“下一个版本”更快。
团队的其他成员，在经历了 NAM 37 循环的无趣体验后，也有同样的挫败感，愿意试一试，并委托我作为官方团队负责人帮助制定这个计划（我们第一次自从 smoncrie 在 2005-2006 年担任团队负责人后，在 RL 强迫他结束了两年的中断之前，他确实有过一次。）在许多方面，我们最终构建的是一个“类似敏捷”的开发过程。虽然软件社区中的一些人可能会对“a-word”感到愤怒，并在脑海中勾勒出快速但漏洞百出的版本，以及要求不断更新状态的严厉项目经理，但 NAM 团队特殊的“类似敏捷”的方法避免建立正式的 scrums、sprint 等官僚作风。相反，它一直是关于取得成果, doing so through a sustainable, repeatable process, and maintaining the “chaotic good” that characterizes NAM development at its best.
虽然 NAM 团队的政策长期以来一直是避免与公众讨论发布日期和时间表（我们做过的一次是灾难性的 NAM 31 周期），但值得注意的是，自那以后，我们在每个发布周期都成功达到了“上限” ，Agile-Era NAM 版本的平均开发周期长度为 3 个月。
NAM 版本 1-44 的周期长度（版本 1 周期长度在技术上未知）
越来越多的关注使我们能够更快地处理错误报告和技术问题，并继续专注于我们的开发任务，从而产生更具凝聚力的版本，这些版本通常以比我们之前的马拉松周期更大的功能集而告终，并且与关于敏捷开发的刻板印象（以及周期更长的前敏捷 NAM 版本），更少的错误。如果一个功能还没有准备好，我们会简单地删减它，并在不久的将来的发布周期中重新访问它，从而让它达到一个稳定、成熟的状态，当它最终推出时可以供公众使用。缩短的发布节奏极大地帮助抑制了旧的做事方式强加给我们的开发人员的有问题的、人为的紧迫感。
这些变化重振了 NAM 开发工作的方式也使相当多的 NAM 新成员有兴趣学习一些必要的技能来做出贡献。我们很容易在各种开发任务中提高新团队成员的技能，从而进一步提高我们的吞吐量。根据 Lucario Boricua 对我们 GitHub 活动的计算，当前“敏捷时代”的 NAM 团队的生产力是之前“单体时代”的 4.4 倍（从 2013 年的 NAM 31 到 2020 年最终发布的 NAM 37） 。
我们也非常谨慎地努力发展团队，引进那些能力、个性和成熟度水平非常适合 NAM 生态系统的人。过去的一些人格冲突问题几乎使整个 NAM 工作脱轨（由于 2015 年 NAM 33 周期中发生的一个问题，我们失去了大部分开发团队），因此我们改进了我们的招聘方法（仍然是邀请-仅）的目标是引进能够与其他 NAMite 相互尊重的人。事实上，我们更倾向于关注这方面，因为 NAMites 可以通过多种方式为整体工作做出有意义的贡献。
在这些最近的发布周期中出现的另一个重大差异是使用私人 Discord 频道作为交流工具，而不是专注于论坛（我们仍然以某种身份使用）。Discord 的活跃、活跃的特性帮助创建了一个更具协作性、响应性更强的团队环境，这加速了开发并有助于促进团队团结。虽然我们可能没有适当的“敏捷”开发团队可能拥有的正式的 scrums 和站立会议，但这确实让我们能够定期、自然地进行沟通，无需任何技巧。
我们仍然在一些领域改进流程，但总而言之，NAMfesto 带来的变化可能产生了我参与该项目 15 年以来所见过的最富有成效和最和谐的 NAM 团队迭代. 这是希望我们可以继续进行更多。
-Tarkus
