我們必須靠許多次小調整來控制軟體開發，而不是靠少數幾次大調整——就像開車一樣。這意味著：我們需要回饋才知道自己偏了一點，需要許多修正的機會，而且必須能以合理的成本做出這些修正。
我們需要一個隱喻#
至此，問題的大致形狀已經清楚——風險的巨大代價，以及透過選擇權管理風險的機會；塑造解法所需的資源也已就位：在週期後段做變更而不顯著增加成本的自由。
現在該讓解法對焦了。而我們需要的第一件東西是一個隱喻（metaphor）：一個共享的故事，讓我們在壓力或抉擇時刻可以回頭依靠，幫助我們持續做對的事。
延伸：作者學開車的那一天
作者清楚記得第一次學開車那天。他和母親正沿著加州奇科（Chico）附近的五號州際公路行駛——那是一段筆直平坦、公路一路延伸到地平線的路。母親要他從副駕駛座伸手過去握住方向盤。
她先讓他體會方向盤的轉動如何影響車子的方向，然後告訴他：「開車就是這樣。把車子擺在車道正中間，直直對著地平線。」
他非常小心地瞇眼直視前方，把車子擺得不偏不倚，正對著路的中線。他做得很棒。然後心思稍微飄了一下……
車子壓上碎石路肩的瞬間，他猛然回神。母親（她的膽識如今讓作者驚嘆）輕輕把車子帶回路面上，然後才真正教了他開車：
開車不是把車子弄成朝正確方向前進。開車是持續保持注意，往這邊修一點、往那邊修一點。
沒有「筆直平穩」這回事#
這就是 XP 的典範。沒有筆直平穩這回事。 即使一切看似完美，你也不能把視線移開路面。變化是唯一的常數。 永遠準備好往這邊移一點、往那邊移一點；有時候你甚至得往完全不同的方向去。這就是程式設計師的人生。
軟體裡的一切都在變：需求會變、設計會變、業務會變、技術會變、團隊會變、團隊成員會變。
誰在開車#
軟體專案的駕駛是客戶。如果軟體沒做到他們想要的事，你就失敗了。當然，他們並不確切知道軟體該做什麼——這正是為什麼軟體開發像是轉方向盤，而不像是把車頭對準直路。
程式設計師的工作，是給客戶一個方向盤，並回饋給他們「我們現在究竟在路上的哪個位置」。
這個故事對 XP 流程本身的寓意#
開車的故事對 XP 流程本身也有寓意。下一章描述的四項價值——溝通、簡單、回饋、勇氣——告訴我們軟體開發感覺起來該是什麼樣子。然而，用來達成那種感覺的實踐，會因地、因時、因人而異。
在為你的開發流程掌舵時，你採用一組簡單的實踐，讓它產生你想要的感覺；隨著開發持續，你要時時察覺哪些實踐增進、哪些實踐減損你的目標。