由中央高智能部门协调和控制软件的大批量发布经常会失败，其原因是由于数学NP问题以及人类之间的弱相互影响。 大多数公司以某种命令和控制方法开始软件版本发布，这是一种中央智能组织推动和控制工作流程，批量大小为N的发布策略是问题所在。 首先是数学上行不通，像很多问题一样，我们可以使用N（在我们的案例中为故事总数，依赖项数量，受影响的模块数量，“合并冲突”的数量之和）作为这个问题的输入数量的粗略指标。随着N的增加，大多数问题都变得更难解决。 我们可以使用采用N的某种表达式来表达他们要付出多少努力。如果该表达式是多项式，则称为P问题。如果不是，则称为NP问题。 这个问题就变成了计算机中复杂性的问题：NP Complete问题（NP完全问题），就是说即使N的增加很少，也会使难度增加到惊人的大。 直觉是，可靠地交付批次大小为N的发行版的问题是NP complete（完全问题），这是一种软件的包装，是确切的。 人与机器始终以小N来解决NP完全问题的特定情况。关键：并不是每次实例都是不可解决的。确切地说，N的微小增加会迅速导致此类问题“在宇宙热死之前无法可靠地解决”。 “可靠地”这个词很重要。您会看到，在解决NP完全问题时，可以通过生成候选解决方案并进行尝试来实现。如果问题有解决方案，那么您可能会在第一次尝试时就找到它。 这使我想到了第二个令人着迷的方面：团队可以花很长时间*经历*这个问题的NP完全问题，而没有意识到它。在这场比赛中，我们成功了一段时间，也许十分之一。但是我们失败了十分之九。但是我们更容易记住成功：“我们*几乎*做到了！” 几个小小的发行问题并不难解决，但是我们花了几个小时疯狂地奔波，急于捆绑新发现的遗漏的API端点，重建我们的应用程序，然后重新部署它。或者，在糟糕的日子里，我们沮丧地流着泪回去。 我们每个回合都会遇到一个或两个问题？他们每次都是不同的小问题：例如忘记了此链接、没有打开功能标志、不知道该功能依赖于我们删除的字段，每次碰到的问题都是小的狗屎，但是不同的狗屎。 我们没有在问题中看到模式，因为它不是模式，而是元模式：由于组合函数抛出了太多细节供我们考虑，因此出现了问题。我们的N开始启动使我们的问题无法可靠地解决。 第三个令人着迷的方面：软件发布还经常运转顺利。这些偶然的胜利彻底使水变得浑浊，因为它们确实只是组合运气。但是他们使我们相信，*每次*都有可能幸运。 可以肯定的是，人们可以采取措施改善自己的运气。在游戏中，这称为作弊。在计算机科学中，这确实是非常聪明。但是你不能消除运气。它内置于我们解决NP完整问题的性质中。 内卷化 因此，当我们失败时，我们会做两件事：
- 1）指责我们缺乏努力和意志，
- 2）增加更多规则，门槛和检查。
- 1）pull & swarm：程序员拉取一个版本的源码，以该源码为中心，作为一个整体进行“交付”。我们使用整体编程，或成对，甚至只是坐在一起。一次一个故事，一路走过去。
- 2）测试驱动的开发：在编写代码之前进行测试比在编写代码之后进行测试更快，更便宜。但事实是，它只有在测试代码编写完成后才更“有效”。这是我们自以为是的基本一线安全网。
- 3）基于主干的开发：我们不使用复杂的源分支策略来驱动N。相反，我们从主干拉取代码，推向主干，从主干测试，从主干交付。
- 4）注重路径的故事和代码设计：我们对故事和代码的设计不仅要着眼于最终的工作，还必须着重于它们可以被发布，而又仍然小到可以容纳它们的路径，这将涉及根本的风格变化。
- 5）稳定且值得信赖的自动化：希望该过程的每个环节都能实现自动化。自动化需要坚如磐石，甚至比应用程序本身更坚固。必须对其进行维护并将其扩展到我们的最高水平。