steve freeman 寫了一篇 blog 擁抱極限程式設計(do do xp) 來反駁我的這篇文章。
我開始厭倦了和那些堅持認為scrum離開了極限程式設計就不再有價值的人的無休止的論戰。 scrum 很好用 — 但前提是實施者必須從基礎上理解它的價值所在和實施原則。 你應用scrum所處的環境條件決定了你在實施過程中應該採取哪些措施。 比如，在教堂裡實施scrum和在軟體開發中實施scrum有著不同的一套實施策略。而這兩種情況下的實施措施又和傳統的scrum有不同之處。
極限程式設計的擁護者動不動就抱怨在軟體工業中scrum沒有提供很好的開發原則。 但就目前極限程式設計被業界採納的緩慢進度來看，真正應該受責備應是xp的缺少實踐措施的問題，xp應該為這種狀況負責。
從八十年代到九十年代，隨著開發語言的進步和更適合於軟體設計，人們開發和測試的方式發生了改變。 在廣大的物件導向群體中，有些概念正在緩慢的、但廣泛的被人們所接受。例如持續反省、限制責任、測試**優先（tdd）、持續整合、推遲設計、編碼規範、以及結對程式設計等。 所謂的極限程式設計 (kent beck和他的一些同事所做的) 也就是將所有的這些好的實踐方法集中到一起打成乙個包，再加上jeff sutherland 2023年在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。 我們要實現乙個通常意義上的指導框架，解決多年來的困擾，構建以人為本的核心基礎。讓我們重新為藝術而工作。或者從此離開這個行業。
英文原文：don』t do xp
挑戰極限 極限程式設計中的「極限」
最近，一直在看robert martin的 敏捷軟體開發 原則 模式和實踐 該文中以極限程式設計 xp 來講述敏捷的實踐。看完有關於 xp實踐的部分，對 xp基本的主張和如何去實踐有了乙個大概的了解。但是，一直有個問題在我腦海中，那就是這種開發實踐方式為什麼會被稱為 極限程式設計 看完這部分之後，對...
極限程式設計下的極限測試
極限測試主要由兩部分測試組成 單元測試和驗收測試。單元測試是極限測試中主要採用的測試方法，它具有兩條簡單規則 所有 模組在編碼開始之前必須設計好單元測試用例。在產品發布之前需要通過單元測試。極限測試中的單元測試和普通的單元測試之間最大的區別是 極限測試中的單元測試必須在模組編碼之前就完成設計和生成。...
XP極限程式設計
結隊程式設計是xp極限程式設計的乙個關鍵實踐，如果把結隊程式設計放到整個xp裡面會更容易體現出它的價值，所以我覺得分析結隊程式設計的乙個整體思路是 1 適用場景 xp的適用性在 什麼樣的專案中適合採用xp，在這樣的專案中xp可以起到什麼作用。如果離開了適用場景，xp的適用性都要重新考慮，所以就更不用...