Info
以下摘要自《無瑕的程式碼 敏捷篇》P.33 管理鐵十字
管理鐵十字 (Iron Cross)：好、快速、便宜、完成。
有了專案所產生的數據，現在是時候讓該專案的管理人員決定「專案應該要多好」、「應該要多快」、「應該要多便宜」、「應該完成到什麼樣的程度」。管理人員將透過更改範圍、時程表、人員與品質來達成這一點。
更改時程表
讓我們問問利益相關者，我們是否可以將專案從 11 月 1 日延遲到 3 月 1 日。這些對話通常不會進行得很順利。日期的選擇往往是依據對業務有益的考量，這些業務因素可能沒有改變。因此「延遲」通常代表該業務將遭受某些重大的衝擊。
增加人手
一般情況下，企業根本不願意更改時程表。因此，讓我們嘗試增加人手吧。每個人都知道，透過加倍的人力，速度就可以變成兩倍。
事實上，情況恰好相反。Brooks’ Law 指出：「在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。」
實際情況是，團隊在新進人員加入時會有一段時間的生產力下降，等到新進人員步上軌道後(希望)，團隊生產力會上升。管理人員的賭注是，我們有「足夠的時間」和「足夠的提升」來彌補最初的損失。另一個因素是，增加人員的成本是昂貴的（招募成本與維持成本）。通常預算根本不能容許雇用新人。
降低品質
每個人都知道，產生垃圾程式碼可以讓速度變得更快。
相信你知道我要告訴你什麼，這樣做是沒用的。產生垃圾程式碼並不會讓你走得更快，反而會使你走的更慢。這就是你成為一位程式設計師之後，累積二三十年會得到的教訓。There is no such thing as quick and dirty. Anything dirty is slow.
快速前進的唯一方法，就是選擇好的品質。
(The only way to go fast, is to go well.)
剛開始我會以為，降低外層程式碼的品質，像是純 UI 頁面或元素這種幾乎沒有相依其它物件的小型組件，出錯的風險算小，可以快快處理。
但其實，以正常的產品來說，按鈕的規則需要特別設計，圖示物件的讀取需要特別設計，為了支援多語言連文字也需要特別設計。這些東西不在專案規模變大前設計完，到最後才做通常會死得很難看。如果軟體人員有跟產品負責人好好規劃這些事，把功能設計的好用，可以省下很多開發和設置時間。
改變範圍
也許，只是也許啦，有些功能不一定要在 11 月 1 日之前完成。讓我們問問利益相關者吧！
「長官好，如果您需要所有的功能，那麼交付日期只能是 3 月。如果您堅決在 11 月之前要我們交付一點東西出來，那麼您必須刪除一些功能。」
『我們什麼也不會刪。我們要所有的功能！而且我們必須在 11 月 1 日之前就拿到！』
「您可能不了解情況。如果您需要全部的功能，那我們得工作到 3 月才能完成。」
『我們全部都要，11 月就要！』
這場小小的爭論會持續一段時間，因為沒有人願意讓步。儘管利益相關者在這場爭論中擁有道德制高點，但程式設計師擁有數據。在任何理性的組織中，數據都將獲勝。
如果組織是理性的，那麼利益相關者最終會低頭、接受，並開始仔細審查計畫。他們會逐一指出他們在 11 月之前「非絕對必要」的功能。這件事很痛苦，但理性組織能有什麼實質上的選擇呢？因此，計畫進行了調整，有一些功能被延後了。
當然，在你能夠拿出預估的日期之前，你得要有團隊的執行數據，才能夠進行討論。