【翻譯】鐵三角（規模、時間和資源的限制）並不適用於軟件開發

當咱們開始偷工減料並倉促完成，就會開始犯小錯誤，而後堆積成大錯誤，而後花更多的時間（和開支）來查找並修復這些錯誤。

 

 The Iron Triangle Does Not Apply to Software Development 

by David Bernstein · May. 06, 16 · Agile Zone 

翻譯 KumaT  2016.5.18 （若有紕漏懇謝指正）（ 翻譯後的順序對比原文作了微調。）

 

There are three main constraints in manufacturing that are sometimes referred to as the 「iron triangle.」 These are scope, time, and resources. 

生產中的三個主要因素（又稱「鐵三角」）：規模、時間和資源。

Scope refers to the size of the project or the amount of work to be done.Time refers to when the project will be finished or how long it will take.The 「resources」 for developing software are people. 

規模是指項目的大小或要作的工做量。時間是指項目完成期限或工做將耗費的時長。「資源」在軟件開發中指的就是人。

In manufacturing they say, 「Pick two of these three things to flex, but one must remain fixed.」

在生產中經常是讓其中的兩個因素有彈性，但另外一個因素必須固定不變。

But this model does not apply to software development.

然而這種模式並不適用於軟件開發。

And because developing software requires a great deal of communication and coordination among people, when we add more people to a project it almost always has the short-term effect of slowing the project down. 

因爲開發軟件須要大量的溝通和協調，當咱們爲項目加更多人時幾乎總會使開發效率在短時間內降低。

Assembling software is not like assembling a car. In software development, resources are generally fixed because adding more people to a project doesn’t make it go faster.

組裝軟件不像組裝一臺車。在軟件開發中，資源通常狀況下是固定的，由於添加更多的人並不能使開發進展得更快。

On a Waterfall project, scope and time are also fixed, which often creates a nearly impossible situation.

在瀑布流項目上，規模和時間也被限制每每會形成一種不切實際的狀況。

 

If scope, time, and resources are all fixed then what’s left to flex? 

若是規模、時間和資源全都限制了，那還剩下什麼彈性呢？

Developers know the answer to this question because they often find themselves in this situation. 

開發者知道這個問題的答案，由於他們本身就經常陷入這種狀況中。

When all three sides of the iron triangle are fixed the only thing that can flex is the quality of their own work — and this is the one thing that developers must not compromise on.

當鐵三角中的三個角都被固定時，惟一能犧牲的就是他們的工做質量— 而這件事是開發者們絕對不該該妥協的。

 

As we start cutting corners and rushing we start making little mistakes that cluster into big mistakes that cost considerable time (and therefore money) to find and fix. 

當咱們開始偷工減料並倉促完成，就會開始犯小錯誤，而後堆積成大錯誤，而後花更多的時間（和開支）來查找並修復這些錯誤。

Teams very quickly get on a downward spiral that puts them in a reactive rather than proactive development environment.

團隊很快進入一個惡性循環，使得他們置身於一個被動而非主動的開發環境中。

A real and sincere effort toward quality software has been the hallmark of every highly productive team I’ve ever seen.

爲高質量軟件切實而純粹地努力是我所見的每個高效團隊共有的特性。

 

原文地址 by David Bernstein · May. 06, 16 · Agile Zone 翻譯 KumaT  2016.5.18（若有紕漏懇謝指正）