案例背景

eFusion Inc. 是位於 Portland 的電子商務公司，開發 PushToTalk™，利用網路語音技術（VoIP）讓線上購物者不必離開網站即可與客服人員通話。產品建立在成熟的 EAG 技術上，營運長 Luis Machuca 視其為公司的代表性產品。

早期團隊受到「Intel 開發文化」與過度工程化設計影響，再配合僵化、近似瀑布式的方法，造成延遲與資源成本，難以回應快速變動的市場；產品過度複雜，原先目標市場甚至完全流失。管理階層因此導入極限程式設計（Extreme Programming, XP）。

問題／衝突

公司一方面要快速找回市場動能，一方面面臨成本削減、裁員、品質保證人力縮減、組織搬遷、角色與管理階層反覆變動。專案中途又出現很低的使用率，使團隊必須在預算與時程壓力下快速調整產品與開發流程。

決策點／實施

XP 被當成提高敏捷性、簡化程度與反應速度的實驗。原書描述的做法包括：

• 把工作分解成小型使用者故事（user stories），再拆成通常不超過兩天的任務；產品經理決定故事優先順序與範疇，工程經理決定交付時間。
• 使用短週期、持續建置、持續整合、重構與結對程式設計。
• 採簡單設計、CRC 卡與探索性解法（spike solutions），只做當下真正需要的能力。
• 需求在故事進入開發前都可持續調整；產品管理依顧客與業務回饋重新排序。
• 先寫自動化測試，所有程式碼都有單元測試，測試全部通過後才能整合；若出現缺陷，就新增相應測試。
• 每日站立會議持續辨識風險，沒有獨立的前期風險分析階段；每天回報專案速度，作為預算與進度可視性的主要指標。
• 產品管理被開發團隊視為顧客並直接嵌入團隊中，持續釐清需求。

原書狀態／結果

XP 讓專案能吸收因低使用率而產生的產品調整，而不至於大幅破壞開發計畫，也減少對獨立品質保證與營運人員的依賴；但案例指出，這些產品變更只小幅改善使用率，真正原因更多來自根本商業因素，所以從純成本效益來看並不划算。

原書整體判斷是：相較過度耗時的舊方法，XP 式做法在短期呈現較好的成果，也更適合此解決方案的反覆式特性。

原書討論問題

1. 分析極限程式設計用於非軟體開發流程的適用性。
2. 分析把傳統開發方法與極限程式設計混合的可行性。