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。 我們要實現一個通常意義上的指導框架，解決多年來的困擾，構建以人為本的核心基礎。讓我們重新為藝術而工作。或者從此離開這個行業。

總結

以上是生活随笔為你收集整理的远离极限编程 (Don’t do XP)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。