建站
咨詢
售后
建站咨詢
新聞中心
Steve Freeman 寫了一篇 blog 擁抱極限編程(Do do XP) 來反駁我的這篇文章。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比汪清網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式汪清網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋汪清地區(qū)。費(fèi)用合理售后完善，十載實(shí)體公司更值得信賴。
我開始厭倦了和那些堅(jiān)持認(rèn)為Scrum離開了極限編程就不再有價值的人的無休止的論戰(zhàn)。 Scrum 很好用 — 但前提是實(shí)施者必須從基礎(chǔ)上理解它的價值所在和實(shí)施原則。 你應(yīng)用Scrum所處的環(huán)境條件決定了你在實(shí)施過程中應(yīng)該采取哪些措施。 比如，在教堂里實(shí)施Scrum和在軟件開發(fā)中實(shí)施Scrum有著不同的一套實(shí)施策略。而這兩種情況下的實(shí)施措施又和傳統(tǒng)的Scrum有不同之處。
極限編程的擁護(hù)者動不動就抱怨在軟件工業(yè)中Scrum沒有提供很好的開發(fā)原則。 但就目前極限編程被業(yè)界采納的緩慢進(jìn)度來看，真正應(yīng)該受責(zé)備應(yīng)是XP的缺少實(shí)踐措施的問題，XP應(yīng)該為這種狀況負(fù)責(zé)。
從八十年代到九十年代，隨著開發(fā)語言的進(jìn)步和更適合于軟件設(shè)計(jì)，人們開發(fā)和測試的方式發(fā)生 了改變。 在廣大的面向?qū)ο笕后w中，有些概念正在緩慢的、但廣泛的被人們所接受。例如持續(xù)反省、限制責(zé)任、測試代碼優(yōu)先（TDD）、持續(xù)集成、推遲設(shè)計(jì)、編碼規(guī)范、 以及結(jié)對編程等。 所謂的極限編程 (Kent Beck和他的一些同事所做的) 也就是將所有的這些好的實(shí)踐方法集中到一起打成一個包，再加上Jeff Sutherland 1993年在Easel公司實(shí)踐出的Scrum模式。 某種意義上說，這也就有抽象Scrum概念的***次具體的實(shí)現(xiàn)。
這些都很成功。 然而他們的這些實(shí)踐經(jīng)驗(yàn)的推廣和采納并沒有像他們想象的那樣進(jìn)行。 也許就是因?yàn)槿×藗€極限編程的錯誤名稱； 也許是因?yàn)橹饕?、嗓門***的擁護(hù)者非要說這是唯一真理的原因； 也許是因?yàn)楣芾碚呖謶诌@個新出現(xiàn)的異類，暗中作梗反對它； 也許是因?yàn)?，說到底，XP也不過是另一種開發(fā)方法。 我不知道。 我只知道，只有很少的開發(fā)團(tuán)隊(duì)宣稱和承認(rèn)采用了XP。
然而與此同時，Scrum正在獲得強(qiáng)大的發(fā)展動力。 并不需要多少華麗的理由，實(shí)際情況卻是Scrum正在被為數(shù)不少的團(tuán)隊(duì)接受，正在用它來改進(jìn)我們軟件的開發(fā)過程。 反而是XP現(xiàn)在想來分一杯羹。 他們確實(shí)很饑餓。
首先，讓我把問題說明白。 我十分贊同軟件開發(fā)團(tuán)隊(duì)采用一些已知的實(shí)踐指導(dǎo)來提高代碼質(zhì)量、生產(chǎn)更高水平的軟件作品。 但為什么這么多人不愿意這么做？ 我不太喜歡把十幾個任務(wù)打個包直接丟給團(tuán)隊(duì)，也不喜歡事先指定一種開發(fā)方法讓他們必須遵守。 那樣做很顯然違反了“people over process”和自我管理原則。 在好的Scrum實(shí)施里，團(tuán)隊(duì)成員應(yīng)根據(jù)自身情況找到適合自身的實(shí)施策略，這樣的Scrum應(yīng)用過程才是與實(shí)際相結(jié)合、才有意義。 這才是我追求的進(jìn)步。 有些Scrum團(tuán)隊(duì)一直沒有找到很滿意的開發(fā)方法，這說明Scrum實(shí)施方式需要改進(jìn)，而不是去告訴團(tuán)隊(duì)成員強(qiáng)制實(shí)施。
我有一個問題思考：如果XP從來沒誕生過，有多少團(tuán)隊(duì)愿意完全接受所有XP所推薦的方法？ 我相信會有很多。 我相信這些寶貴的開發(fā)經(jīng)驗(yàn)會自然而然的被程序員和團(tuán)隊(duì)們采用，對我來說，關(guān)心的是經(jīng)驗(yàn)本身，而不是他們出現(xiàn)的形式。 我從來沒有“done XP“，但我顯然可以寫出高質(zhì)量的軟件。 XP的錯誤就在于堅(jiān)持要求全盤接受。 這并不是XP的創(chuàng)始人的初衷，可現(xiàn)在卻搞成這樣。 很可能就是XP導(dǎo)致了這些好的實(shí)踐經(jīng)驗(yàn)不被人接受。 很諷刺，不是嗎？
另一個大問題是，XP論述寫于12年之前，于此至今已有40多種新的語言誕生。 XP倡導(dǎo)者在向人們推薦12年前的、現(xiàn)在可能過時的經(jīng)驗(yàn) — 12年相當(dāng)于整個軟件工業(yè)年齡的四分之一。 驚人吧。 讓人們?nèi)グl(fā)現(xiàn)適合自己的開發(fā)方法，他們將會總結(jié)出最有效的開發(fā)經(jīng)驗(yàn)，這遠(yuǎn)不是幾個腦瓜好用的人在上個世紀(jì)末能創(chuàng)造的。
我強(qiáng)烈要求Scrum倡導(dǎo)者停止與XP的爭吵，我們討論的應(yīng)該是軟件藝術(shù)。 這才是我們在這個領(lǐng)域里急切需要的最終目標(biāo)。 幸運(yùn)的是，現(xiàn)在有一個有著自己的manifesto的軟件藝術(shù)運(yùn)動正在逐步為人們所關(guān)注。 最終，我們可以通過好的軟件藝術(shù)實(shí)踐運(yùn)動重新改革我們這個領(lǐng)域，而不是使用那些修修補(bǔ)補(bǔ)的策略。
開發(fā)者們：Don’t do XP。 我們要實(shí)現(xiàn)一個通常意義上的指導(dǎo)框架，解決多年來的困擾，構(gòu)建以人為本的核心基礎(chǔ)。讓我們重新為藝術(shù)而工作?；蛘邚拇穗x開這個行業(yè)。
英文原文：Don’t do XP
譯文出自：http://www.vaikan.com/
分享題目：遠(yuǎn)離極限編程(Don’tdoXP)
文章起源：http://www.5511xx.com/article/dpcpeds.html
