理想的 XP 專案會經歷一段短暫的初始開發期，接著是數年的正式運行支援與精煉並行，最後在專案不再合理時優雅退場。
本章描繪的是一個理想化的流程。你到現在大概已經明白：沒有任何兩個 XP 專案會（或該）完全一樣。這裡希望傳達的，是一個專案的整體流動感。
探索期#
作者最近聽到一句話：「上線就是死亡。」XP 說的恰恰相反——不在正式環境，就是只花錢不賺錢。
不過在上線之前，你得相信自己上得了線：
- 你必須對工具有足夠的信心，相信自己能把程式做完
- 你必須相信程式碼一旦完成，就能日復一日地跑下去
- 你必須相信自己擁有（或學得會）所需的技能
- 團隊成員必須學會信任彼此
探索期就是這一切匯聚之處。
探索期該做什麼#
程式設計師方面：
- 用上未來正式系統要用的每一項技術
- 積極探索系統架構的各種可能——花一兩週建一套「與最終要建的類似」的系統，但用三、四種不同做法去做。可以讓不同的對嘗試不同做法後比較，也可以讓兩對用同一種做法、看看會浮現什麼差異
- 探測技術的效能極限——若可能，用正式環境的硬體與網路模擬真實負載。你不必等整個系統做完才寫負載模擬器：光是計算「網路每秒得支撐多少位元組」再跑個實驗看它能否提供必要頻寬，就能走很遠
- 實驗架構構想——例如「怎麼建一個支援多層復原（undo）的系統？」用三種不同方式各實作一天，看哪一種感覺最好。當使用者提出你完全不知道怎麼實作的故事時，這類小型架構探索最為重要
- 估算探索期中著手的每一項程式設計任務，任務完成後回報實際所需的日曆時間。估算的練習，會在真正要做出公開承諾時提升團隊對自身估算的信心
如果一週還不足以讓某項技術跑起來，作者會把那項技術歸類為風險。這不表示你不該用它，但你應該更謹慎地探索它，並考慮替代方案。
你或許會想在探索期引進技術專家，讓實驗不被「某個已經走過這條路的人可以輕鬆處理的蠢小事」拖累。
但要小心，別盲目接受關於「這技術最終該怎麼用」的建議。 專家有時養成的習慣，其背後的價值體系與極限程式設計並不完全合拍。團隊必須對自己選擇的實踐感到自在——當專案開始失控時，「專家說的」這個理由並不怎麼令人滿意。
客戶方面： 在團隊練習技術的同時，客戶練習寫故事。
別期待這件事完全順利——故事一開始不會是你需要的樣子。關鍵是讓客戶在最初幾個故事上得到大量快速回饋，好讓他們快速學會指定程式設計師需要的、不指定程式設計師不需要的。
關鍵問句是：「程式設計師能有信心地估算這個故事所需的工作量嗎？」有時候是故事需要換個寫法，有時候是程式設計師需要去實驗一下。
探索期該多長#
- 如果團隊已經熟悉他們的技術與彼此，探索期可短至數週
- 如果團隊對技術或領域完全陌生，可能得花上數個月
- 如果比這更久，作者會去找一個小而真實、團隊能輕鬆完成的專案，替流程注入緊迫感
規劃期#
規劃期的目的，是讓客戶與程式設計師有信心地議定一個日期，屆時「最小、最有價值的那組故事」將完成。（做法見〈規劃策略〉的規劃遊戲。）
如果你在探索期做足準備，規劃（產出承諾時程）應該只需一兩天。
- 比這更短，你大概解決不了任何顯著的業務問題（但如果你做得到，太好了！）
- 比幾個月更長，風險就太大了
邁向首發的各次迭代#
承諾時程被切分成一到四週的迭代。每次迭代都會為該次迭代排定的每個故事，產出一組功能測試案例。
- 第一次迭代把架構就位——挑那些會迫使你建出「整個系統」的故事，即使只是骨架形式
- 後續迭代的故事完全由客戶裁量——要問的問題是：「這次迭代我們該做的最有價值的事是什麼？」
一邊迭代，一邊看偏差#
在你一次次點過迭代的同時，你要尋找與計畫的偏差：
- 每件事都花了你預想的兩倍時間嗎？還是一半？
- 測試案例有準時完成嗎？
- 你們玩得開心嗎？
- 也許是計畫要改——增減故事，或改變它們的範圍
- 也許是流程要改——你找到了更好的技術運用方式，或更好的 XP 運作方式
理想上，每次迭代結束時，客戶已完成功能測試，而且全部通過。
嘿，你們剛剛準時交付了高品質的軟體。也許只有三週份量，但那仍然是一項成就，值得慶祝。
最後一次迭代結束時，你們就準備好上線了。
正式化期#
一次發布的終盤（正式化，productionizing）會看到回饋循環收緊：
- 從三週迭代改成一週迭代
- 也許改成每日站立會議，讓每個人都知道其他人在做什麼
- 通常會有某種認證軟體可上線的流程——準備好實作新的測試來證明上線適格性，平行測試常在此階段派上用場
效能調校的時機#
作者說本書談效能調校很少，因為他非常相信這句座右銘：「讓它能動、讓它正確、讓它快（Make it run, make it right, make it fast）。」
放慢演化，但別停止思考#
正式化期間，你會放慢演化軟體的步調。並不是軟體停止演化，而是「風險」在「這個變更值不值得進這次發布」的評估中變得更重要。
但要留意：你對一套系統的經驗越多，對它該如何設計的洞見就越深。
如果你開始發現大量「無法為這次發布正當化」的想法，就做一份可見的清單，讓每個人都看得到這次發布上線後你們要往哪裡去。
如果你同時不覺得有點害怕，那你就瘋了——但派對能幫你釋放一些必然累積起來的過剩張力。
維護期#
你必須同時：產出新功能、維持既有系統運行、把新人納入團隊，並向要離開的成員道別。
每一次發布都從一個探索期開始：你可以嘗試上次發布後期不敢做的大重構、試用打算在下次發布加入的新技術、遷移到既有技術的新版本、實驗新的架構構想；而客戶也可以試著寫些天馬行空的新故事，尋找業務上的大贏家。
上線後開發的不同之處#
- 你對自己所做的變更更加小心
- 你必須準備好中斷開發去反應正式環境的問題
- 你有活資料，改設計時必須小心遷移
如果上線前不是那麼危險，你會永遠不上線。
上線很可能改變你的開發速度。對新估算要保守。
探索的同時，度量正式運行支援對開發活動的影響。作者見過上線後「理想工程時間比日曆時間」的比值上升 50%（從每工程日 2 個日曆日變成 3 個）。別用猜的——去量。
團隊結構與新人#
- 準備好改變團隊結構以應付正式運行：可以輪流值「服務台」，讓大多數程式設計師大多數時候不必應付上線問題。
- 但務必讓所有程式設計師都輪過這個位子——有些東西只能從支援正式運行學到，別無他法。（另一方面，這確實不如開發好玩。）
- 邊做邊把新開發的軟體送上正式環境。即使你知道有些部分不會被執行，還是把它放進正式系統。作者參與過以日或以週為循環的專案；無論如何，別讓程式碼擱置超過一次迭代。時機取決於驗證與遷移的成本。
如果你讓正式程式碼庫與開發程式碼庫幾乎同步，你就會遠遠更早得到整合問題的警訊。
新成員加入時，給他們兩到三次迭代，工作內容是：問大量問題、擔任結對夥伴、讀大量測試與程式碼。等他們覺得準備好了，就能承擔幾項程式設計任務，但負載係數降低；當他們展現出交付能力後，才提高負載係數。
這比典型的「東西在這裡，這疊紙包含你需要的所有資訊」交接風險低得多。事實上，傳達專案周圍的文化，與傳達設計與實作的細節一樣重要——而前者只能透過人際接觸做到。
死亡#
如果客戶再也想不出任何新故事，那就是把系統封存的時候了。
好的死法與不好的死法#
- 好的理由——客戶對系統滿意，而且在可預見的未來想不出想加的東西。（作者說他從沒親身經歷過，但聽說過，所以列在這裡。）
- 不那麼好的理由——系統就是交付不了。客戶需要功能，而你就是無法經濟地加上去；缺陷率悄悄爬升到無法忍受的地步。
這正是你長久以來對抗的熵之死。
XP 不是魔法。熵最終也會追上 XP 專案——你只能希望它發生得晚一些，而不是早一些。
無論如何，一旦系統必須死，這件事應該在所有人睜著眼睛的情況下發生：團隊應該清楚處境的經濟現實；他們、客戶與管理者，應該能夠一致同意——這支團隊與這套系統，就是交付不了所需要的東西。
辦一場派對，邀請所有曾在這套系統上工作過的人回來回憶往事。趁這個機會試著標定出系統敗亡的種子，好讓你未來更知道該留意什麼；也和團隊一起想像：下次他們會怎麼把事情做得不一樣。