Steve Freeman 寫了一篇 blog 擁抱極限程式設計(Do do XP) 來反駁我的這篇文章。
我開始厭倦了和那些堅持認為Scrum離開了極限程式設計就不再有價值的人的無休止的論戰。 Scrum 很好用 — 但前提是實施者必須從基礎上理解它的價值所在和實施原則。 你應用Scrum所處的環境條件決定了你在實施過程中應該採取哪些措施。 比如，在教堂裡實施Scrum和在軟體開發中實施Scrum有著不同的一套實施策略。而這兩種情況下的實施措施又和傳統的Scrum有不同之處。
極限程式設計的擁護者動不動就抱怨在軟體工業中Scrum沒有提供很好的開發原則。 但就目前極限程式設計被業界採納的緩慢進度來看，真正應該受責備應是XP的缺少實踐措施的問題，XP應該為這種狀況負責。
從八十年代到九十年代，隨著開發語言的進步和更適合於軟體設計，人們開發和測試的方式發生了改變。 在廣大的物件導向群體中，有些概念正在緩慢的、但廣泛的被人們所接受。例如持續反省、限制責任、測試程式碼優先（TDD）、持續整合、推遲設計、編碼規範、以及結對程式設計等。 所謂的極限程式設計 (Kent Beck和他的一些同事所做的) 也就是將所有的這些好的實踐方法集中到一起打成一個包，再加上Jeff Sutherland 1993年在Easel公司實踐出的Scrum模式。 某種意義上說，這也就有抽象Scrum概念的第一次具體的實現。
這些都很成功。 然而他們的這些實踐經驗的推廣和採納並沒有像他們想象的那樣進行。 也許就是因為取了個極限程式設計的錯誤名稱； 也許是因為主要的、嗓門最大的擁護者非要說這是唯一真理的原因； 也許是因為管理者恐懼這個新出現的異類，暗中作梗反對它； 也許是因為，說到底，XP也不過是另一種開發方法。 我不知道。 我只知道，只有很少的開發團隊宣稱和承認採用了XP。
然而與此同時，Scrum正在獲得強大的發展動力。 並不需要多少華麗的理由，實際情況卻是Scrum正在被為數不少的團隊接受，正在用它來改進我們軟體的開發過程。 反而是XP現在想來分一杯羹。 他們確實很飢餓。
首先，讓我把問題說明白。 我十分贊同軟體開發團隊採用一些已知的實踐指導來提高程式碼質量、生產更高水平的軟體作品。 但為什麼這麼多人不願意這麼做？ 我不太喜歡把十幾個任務打個包直接丟給團隊，也不喜歡事先指定一種開發方法讓他們必須遵守。 那樣做很顯然違反了“people over process”和自我管理原則。 在好的Scrum實施裡，團隊成員應根據自身情況找到適合自身的實施策略，這樣的Scrum應用過程才是與實際相結合、才有意義。 這才是我追求的進步。 有些Scrum團隊一直沒有找到很滿意的開發方法，這說明Scrum實施方式需要改進，而不是去告訴團隊成員強制實施。
我有一個問題思考：如果XP從來沒誕生過，有多少團隊願意完全接受所有XP所推薦的方法？ 我相信會有很多。 我相信這些寶貴的開發經驗會自然而然的被程式設計師和團隊們採用，對我來說，關心的是經驗本身，而不是他們出現的形式。 我從來沒有“done XP“，但我顯然可以寫出高質量的軟體。 XP的錯誤就在於堅持要求全盤接受。 這並不是XP的創始人的初衷，可現在卻搞成這樣。 很可能就是XP導致了這些好的實踐經驗不被人接受。 很諷刺，不是嗎？
另一個大問題是，XP論述寫於12年之前，於此至今已有40多種新的語言誕生。 XP倡導者在向人們推薦12年前的、現在可能過時的經驗 — 12年相當於整個軟體工業年齡的四分之一。 驚人吧。 讓人們去發現適合自己的開發方法，他們將會總結出最有效的開發經驗，這遠不是幾個腦瓜好用的人在上個世紀末能創造的。
我強烈要求Scrum倡導者停止與XP的爭吵，我們討論的應該是軟體藝術。 這才是我們在這個領域裡急切需要的最終目標。 幸運的是，現在有一個有著自己的manifesto的軟體藝術運動正在逐步為人們所關注。 最終，我們可以通過好的軟體藝術實踐運動重新改革我們這個領域，而不是使用那些修修補補的策略。
開發者們：Don’t do XP。 我們要實現一個通常意義上的指導框架，解決多年來的困擾，構建以人為本的核心基礎。讓我們重新為藝術而工作。或者從此離開這個行業。