在“铁三角”模型中，有 3 个约束条件：
- 资源Resource：有多少人投入
- 范围Scope：需要完成多少工作
- 时间Time：完成工作的时间
它们形成了一个三角形，三角形的面积代表质量。
如果您曾经听过人们谈论“遗留代码”、“技术债务”等，那么您现在可能已经发现这个模型在起作用！质量和速度的关系没那么简单！不是简单认为：质量越高，速度越快，这是一种二分法的极端概念，高质量不代表高效高速，如果我们在短期内牺牲质量，就会损害速度？
平衡质量和速度并非易事 如果我们花大量时间寻求质量，一切都需要更长的时间，我们会失去速度；但是如果我们不主动尝试保持高质量，那么复杂性就会接管，一切又需要更长的时间，我们又失去速度。
同时，我们正在企业中构建软件。这意味着时间和金钱很重要！软件进展缓慢对企业来说是毁灭性的，显然需要紧急解决！
添加资源既昂贵又困难；此外，我们知道布鲁克斯的定律：“在一个迟到的项目中增加更多的人会使其晚一些”——所以这可能不是一个选择。
大多数企业自以为自己“掌握”“需求”，因此将范围缩小排除在质量与速度之间。。。这就造成复杂性的原因！
当然，对于短期的速度提升，我们可以在质量上偷工减料……但这会很快导致更多的复杂性、错误、返工和其他坏事，这会损害速度。
如果事情变得非常糟糕，最可能的答案是“重新编写”……让我们重新开始，不要犯同样的错误……这次我们将真正专注于质量！所以新项目开始了，每个人都非常乐观。让我们引入尽可能多的质量工具！单元测试、集成测试、TDD、BDD、没有空值的外来新语言……当然还有行业标准，Pull Requests - 一切为了质量！
需要明确的是，其中许多都是提高质量的好工具，一个能够及早快速检测问题的良好测试套件非常有价值。你可能应该确保你有很好的测试！但问题是，拥有所有这些东西会让你慢下来......
如果你进展缓慢，在一个时间和金钱都很重要的企业中，那是行不通的……如果你进展缓慢，管理者必须参与，不参与是不负责任的。我们又回到了质量与速度的较量——你需要走得更快……
显然，我们需要在不损害速度的情况下尽可能提高质量，同时在不损害质量的情况下尽可能提高速度。
这意味着批判性地看待每个工具，并诚实地了解它带来的好处以及这些好处的成本。一些工具——例如自动化测试——非常强大，但非常昂贵，所以也许我们会谨慎使用它们（想想“测试金字塔”）
Pull Requests拉取请求
最无法通过平衡测试的工具是 Pull Requests拉取请求。这有很多原因，即“物理定律”的东西，同时又是 PR 设计的内在因素，因此是不可避免的。
拉取请求的“作用机制”是让多人看到每个更改，以捕获并解决Bug。
拉取请求客观地产生很多额外开销：
- - 增加中断和上下文切换
- - 引入阻塞、瓶颈、争用和等待
- - 增加在制品和批量大小
- - 延迟缺陷检测并增加返工
这些都是导致损害速度的最明显的问题。拉取请求被提升为帮助提升质量的工具。但是，拉取请求会损害速度。当速度受损时，团队会面临时间压力。当有时间压力时，人们更可能匆忙，质量受到损害。
Pull Requests 的好处是：多个人在做同一件事——协作。然而，Pull Requests 是一种非常间接的协作形式！如果您重视 Pull Requests 的好处，您可能想看看有没有其他其他协作机制！
将“范围”作为常量的问题
传统观点是：铁三角中范围（需要完成多少工作）几乎总是更像是一个常数，是团队的上文，而不是团队可以对其产生任何影响的变量，是一个前提假设，但是挑战这个假设为我带来了巨大的突破。
到目前为止，我看到的最常见的对付"范围"方法是团队有一组“ticket票”，并且一次只做一些，或者更有可能同时做几张票。它们被视为原子，无论是“完成”还是“未完成”，而游戏就是尽可能多地“做”。
计划通常是通过“估计”每个原子票需要多长时间来完成的，可能是抽象的形式，例如故事点，但票的内容同样被视为固定的。
问题在于，这种“估计”是建立在理论之上的，然后再受制于往往残酷的现实世界。有时会出现不可预见的问题，这意味着完成一项任务需要更长的时间。
我们还需要注意帕金森定律——“工作会扩大，以填补完成它的可用时间”——这意味着虽然有时事情会比预期的要长得多，但事情花费的时间却少得多。 . 这是一个偏态分布！
让我们也了解一下 侯世达（Hofstadter）定律：“做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。” 如果您希望添加“缓冲区”可以拯救您，对不起...
范围作为变量
那么，我们如何才能可靠地交付进展？会有很多解决方案，但以下是对我有用的方法...
- 不要以完成为目标，以更好为目标
不要问多长时间，设定固定时间预算并寻找最佳花费方式
也就是说，使用“范围”作为变量，
您可以向需要看到可预测进展的企业承诺，您将分享自上次以来取得的进展的确切时间。你可以对事情的进展完全透明，如果遇到问题，你可以一起做出选择。
现在不再是“尝试做很多工作”，而是“尝试从固定的工作量中做出最大的改变”。这意味着使用帕累托（80:20 规则），并寻找最具影响力的改进！
在实践中会发生的情况是，一开始，您将能够做出重大改进，然后会出现收益递减的情况。这时问题应该是“我们下一步应该改进什么”？
在每个固定的时间周期内，您决定要改进什么，并尝试做出最大的改进。有时它会很顺利，有时不会那么顺利。您可以从中吸取教训，并将反馈包含在下次的决策中。
能够快速改变方向......我们有一个词.：敏捷
总结
所以，总结一下： - 质量与速度是一场失败的游戏
- - 不要玩！
- - 平衡是关键
- - 关键，寻找成本/收益
- - 请记住，在业务中，时间和金钱很重要（！），并且往往会在冲突中获胜
- - 进展很重要
- - 专注于稳定改进，尽早交付