When I used to work as a project management consultant, I would hear brilliant leaders around me say: “Speed, quality, cost. Pick two.” In other words: if you want a higher quality product, you have to sacrifice speed, cost, or both. In this frustratingly pervasive “iron triangle” decision-making philosophy, true improvement is not possible. We are doomed to do only as well as we are doing now; our only options are to choose which priorities will be sacrificed to others.
过去，我在咨询公司做项目管理的时候，我睿智的领导跟我说：“速度，质量，选择两个。”换句话说，如果你想要一个高质量的产品，你就需要以牺牲速度或成本或两者都失去为代价。在这弥漫着沮丧的“铁三角”决策哲学里，真正的改善是不可能的。我们注定只能像我们现在所做的一样。我们唯一的选择就是可以决定优先牺牲哪一个。
Iron Triangle thinking in software development
软件开发中铁三角的思考
In software development, this same trade-off-only mindset—an implicit belief in this Iron Triangle—still exists. Iron Triangle thinking means that engineers often feel stuck between prioritizing quality of code, speed (time to market), and cost. Of course, we will always have choices that we can make between speed, quality, and cost. But the fallacy of Iron Triangle thinking is believing that the parameters of these choices are fixed, limiting our potential for innovation.
在软件开发中，这种类似的铁三角交易思维方式仍然存在。铁三角思维意味着工程师们经常在优先选择优质代码，时间或者市场上追求速度和成本之间犹豫不决。当然了，在速度，质量和成本之间我们总是能够做出选择。但是铁三角思维的谬论认为，这些选择的决定因素是固定的，所以限制我们的潜在创造力的。
The pervasiveness of Iron Triangle thinking means that many engineering leaders see only a hard trade-off between the cost and speed benefits of continuous development and the quality benefits of deploying slower and testing more. As a result, many development teams who want to improve cost and speed are hesitant to make the move toward continuous development because they’re afraid of impacting code quality. They feel forced to choose between developing in two-week sprints—with a massive test suite that is expensive and slow, but assures quality at the end of the sprint—and moving to a Continuous Integration/Continuous Delivery (CI/CD) mode that is faster and cheaper, but sacrifices quality with less testing.
铁三角思维的普遍性意味着，很多工程师领队在成本和速度对持续发展的优势和缓慢部署，多做测试对质量的效益之间做艰难的权衡。结果，很多想要改善成本和速度的开发团队在向可持续发展进发的时候就会感到犹豫，因为他们担心会影响代码质量。他们感觉在两周之内配合大量的测试套件做开发昂贵而且缓慢，但是在短暂的开发结束的时候能保证质量并且在转向持续集成和持续和连续部署的模式的时候更快更，便宜，但是只损失了少量的质量测试。
Quality: The “agile” approach
质量：“敏捷”方法
In traditional end-to-end (E2E) testing processes, there is no pressure not to add tests because you want a minimal chance that any bugs will make it to production. Typically, in the sprint-based (“agile”) development approach, quality is optimized at the price of cost and speed.
在传统的端到端测试过程中，不增加测试也没什么压力，因为你希望bug产生的情况是极少的。在短周期（即敏捷）开发方式中，以成本和速度花费换取质量最优。
Most leaders are accustomed to running E2E testing at the end of a sprint, so the test suite can run as long as it needs to. Once E2E test suites grow to a certain size, you have to run them less frequently, as they can take several hours and simply can’t be run every time developers check in code. This means that there’s a feedback lag: developers discover bugs in their code days or weeks after they’re written. At that point, it’s impossible to pinpoint which deployment even caused the bug, so you can’t toss the buggy code back to the developer who wrote it. Often, leaders assign these bugs to more junior developers who are forced to mine the code to understand the intent of the original developer. In all, these bugs require a significant amount of time and resources to fix.
绝大部分的领导习惯于在短周期结束的时候执行端到端的测试，所以测试套件可以根据需要来运行。一旦端到端的测试套件增加到一定的规模，你就需要减少运行的频次，因为他们需要花费几个小时并且无法每次都被开发人员执行。这意味着会产生一个反馈延迟：开发人员在他们写完代码之后几天或者几周后才能发现代码中的bug。从这个点来看，查明哪个部署导致了bug是不可能的，所以你不能把有bug的代码给到写代码的人。通常，领队把这些bug分配给一些初级开发师，他们被迫理解原开发人员的代码意思。总之，这些bug需要很多重要的事件和资源来修复它。
Speed and cost: The continuous approach
速度和成本：持续的方法
In a CI/CD environment, a team supports continuous development with continuous testing: every deployment is tested individually before it is staged or shipped to production. With fewer tests, the test suite runs in a matter of minutes, feedback lag is minimal, and buggy code returns directly to the engineer who wrote it. With this approach, developers are more fresh on what they just wrote so that when bugs do get caught, they’re able to pinpoint exactly where the problem is and resolve it in minutes, rather than hours or days. Thus, with the continuous approach, the KPIs that the engineering leaders maximize are developer velocity (faster deployments) and cost (fewer tests to maintain).
在持续集成/持续部署的环境中，一个支持持续开发的团队中配合持续测试：每一个部署在被交付或者上演之前都要经过独立测试。当测试少的时候，测试套件运行只需几分钟，反馈延迟也极少，有bug的代码直接返回给写代码的工程师。用这种方法，开发人员面对对他们刚刚写的代码更清晰。当找到bug的时候，他们能够准确的查明问题究竟在哪并且在几分钟内解决它，而不需要几个小时或者几天。因此，在持续的方式中，工程领队最大化开发人员的KPI，开发速度更快，较少的测试维持使成本更少。
The drawback to having fewer tests, of course, is that you’re ensuring less quality before your code goes out the door. Fewer tests simply means fewer opportunities to catch bugs before they hit production, sacrificing quality in favor of speed.
当然，更少测试的缺点就是在你的代码开始发布前比较不能保证质量。较少的测试也以意味着跟少的机会在他们投产前能找到bug，在偏向速度中牺牲了质量。
A new approach: Agile and continuous
一个新的方法：敏捷和持续
As engineering leaders, as long as we continue to subscribe to Iron Triangle thinking, we will never be provoked to ask ourselves if we can actually improve a process without making a trade-off. When we break Iron Triangle thinking, we can find an option that is not some form of compromise between competing priorities. In software development, breaking Iron Triangle thinking requires that we do the harder thing and choose a smarter, more strategic approach to deployment design.
作为一个工程师领队，只要我们继续讨论铁三角思维，永远也不会激起我们通过不做权衡取舍来对改善流程得思考。当我们打破铁三角思维，我们就会发现一个不是由一些相互竞争的优先选择组成得一个方案。在软件开发中，打破铁三角思维需要我们完成更难得和选择更聪明更有战略性得方式来部署计划。
One such way to break the Iron Triangle is to simply choose the best parts of testing from both agile development and continuous deployment. One possible design change to your deployment structure is to implement continuous testing early in your SDLC with the quality benefits of the end-of-sprint testing that occurs in agile development practice.
这种打破铁三角思维的方式就是从敏捷开发和持续部署中选择最佳的部分测试。一个对你的部署架构的可能的设计上的改变是在你的系统生命周期早期完善持续测试，与发生在在敏捷开发实践中的冲刺测试的质量效益。
In this structure, you preserve the benefits of continuous development: your developers can still contribute small chunks of code and run tests continuously for rapid feedback. In addition, you can run a larger test suite in a staging environment against a number of builds to catch bugs that the continuous test suite missed. This approach means many of your bugs are caught sooner and fixed faster. Anything missed here is caught by the larger test suite later, giving your developers the speed advantages of continuously developing and testing, and your application gets the quality benefit of running a larger test suite—all without costs beyond maintaining the larger suite that would’ve been written for an agile team anyway.
在这个结构中，你保持了持续开发的优势：你的开发人员仍然能贡献一小段代码并且持续运行测试快速得到反馈。除此之外，你能在一个演示的环境下运行一个更大的测试套以抓取大量持续性测试错过的bug。这个方法意味着你的很多bug会被快速找到，给你的开发人员在持续开发和测试中速度优势，并且你的运用能让你在运行一个更大的测试套件使质量收益，所有这些没有成本，除了维持敏捷开发团队写的更大的套件。
Moving Forward: A practical application
前行：一个实际用例
As engineering leaders and teams, you can break the Iron Triangle of project management by structuring your improvement cycle not around trade-offs, but on continuous improvement. A great engineering leader will use the momentum and mindset shift gained from their first Triangle-breaking win to push their team to challenge the assumptions that have held them back from improving all parts of their engineering practice.
一个工程领队和团队，你们能通过不围绕权衡取舍来建立和改善你的周期的方式打破铁项目管理的三角思维，一个出色的工程领导会借助他们第一次成功打破三角关系的势头和思维方式推动他们的团队去挑战那些阻碍他们在工程实践中进步的所有的假设。
龙测科技，您身边的自动化测试专家。
作者： Erik Fogg
来源softwarenews
