Posted on 2008-12-31 00:52
mingj 閱讀(3545)
評(píng)論(1) 編輯 收藏 所屬分類:
agile 敏捷
前一段時(shí)間讀了Matt Stephens 與 Doug Rosenberg 合著的《Extreme Programming Refactored: The Case Against XP》(以下簡稱《Refactored》)。該書雖然是針對(duì) Kent Beck 的《Extreme Programming Explained: Embracing Changes》(以下簡稱《Explained》)第一版進(jìn)行闡發(fā),然后 Kent Beck 在《Explained》第二版里面也修正了一些 XP 的理念和態(tài)度,但是《Refactored》書中提到的一些見解和看法現(xiàn)在讀來還是挺有意思的。
比如作者一開始就講了個(gè)“皇帝的代碼”的故事新編,把皇帝比喻成迷信開發(fā)方法的客戶,然后 XP 者就是兩個(gè)騙子,利用不具體的過程標(biāo)準(zhǔn)來欺騙現(xiàn)場(chǎng)客戶以及審查的其他人,并贏得最后的release,卻最終被小孩子揭露出來的故事。不可否認(rèn)的是作者在其中做了過多的假設(shè)和有失偏頗的類比,最終使得故事顯得過于荒誕和不切實(shí)際,但 XP 在那個(gè)急于推廣自己的年代用一些過激的宣傳詞,從而引起這樣那樣的誤解,也是正常的。這也是 Kent Beck 在《Explained》第二版里面修正的主要方面,使得 XP 更具可操作性,概念不顯得那么的突兀而容易誤解了。
撇開這些不談,覺得特別有意思的是作者在書中把 XP 和馬克思主義來做對(duì)比,得出一些共同點(diǎn),也頗讓人若有所思。這里閑話不多講,直接貼上書中幾處 XP 和馬克思主義進(jìn)行對(duì)比的地方。
1. XP 里面的代碼共有與馬克思主義提倡的集體所有制
Just for fun, we did a little research on the subject of collectivism, outside of an XP context. It came from Marxist “power to the proletariat” sociopolitical theory (more on Marxism later). Here are a couple of interesting quotes that we found:
Karl Marx -- “Since the supreme aim of collectivism is the abolition of that capitalistic regime which enables one man or one corporation arbitrarily to exploit the labour and the necessities of many men, it obviously does not—in theory at least—imply equal compensation for all individuals, nor the destruction of individual initiative, nor the establishment of a bureaucratic despotism.”
然后引用 Robert C. Martin 的話就是:
“The only constraint that XP puts on you is that any production code has be [sic] written by a pair. Your preferences and comfort do not supercede the delivery of quality to the project, or your parcitipation [sic] in the team.”
2. XP 里面自組織團(tuán)隊(duì)與馬克思主義提倡的人民專政
Karl Mars -- Power to the Peeps
I was recently interviewing a programmer for a potential contract, and he happened to mention that he had worked on a project in which his team had attempted XP (but found it too difficult for various-reasons—in particular, that management wouldn’t buy in to the new way of working. Eventually they abandoned the “experiment” [which it quickly became known as], keeping unit tests but not much else).
I asked him what he most liked about XP, and he immediately perked up with, “It empowers the programmers! Puts us on an equal footing with the management. . . .”
可以看到的是,這里面有些確實(shí)是 XP 沒有解決好的問題,或者 XP 沒有明示的東西。萬幸的是,XP 不是一個(gè)固步自封的軟件開發(fā)方法學(xué),而是更注重它所強(qiáng)調(diào)的價(jià)值和原則,比如簡單、溝通、勇氣和反饋。所以,在實(shí)際開發(fā)過程中,不同的項(xiàng)目組在不同的項(xiàng)目環(huán)境下會(huì)裁剪出合適項(xiàng)目、合適組織的方法學(xué)。所以,前面兩個(gè)問題其實(shí)在 XP 的框架內(nèi)也都是可以解決的。
我們來看第一個(gè)問題:代碼共有導(dǎo)致個(gè)人失去成就感和幸福感。其實(shí)這個(gè)問題的更深層次是:
1. 敏捷團(tuán)隊(duì)如何評(píng)價(jià)個(gè)人performance?
2. 敏捷團(tuán)隊(duì)如何激勵(lì)個(gè)人創(chuàng)造?
其實(shí)這個(gè)問題也是我們?cè)谧雠嘤?xùn)的時(shí)候,學(xué)員們問得最多的問題。在傳統(tǒng)的文檔式開發(fā)過程中,開發(fā)人員的工作量被量化成代碼行數(shù)或者 bug 修正數(shù),雖然大家都知道這其實(shí)并不能反映真正的工作量,但畢竟可以作為他們衡量開發(fā)團(tuán)隊(duì)成員的 performance 的一個(gè)參考值。而 XP 一方面宣揚(yáng) pair programming 以及代碼共有,另一方面又宣揚(yáng)增進(jìn)設(shè)計(jì)和重構(gòu),這樣統(tǒng)計(jì)個(gè)人的代碼行數(shù)或者修改的 bug 數(shù)對(duì)于績效考核就沒有任何幫助。那么,在敏捷里面是怎么解決這個(gè)問題的呢?
我想,在檢查個(gè)人performance在項(xiàng)目組內(nèi)部通常都會(huì)有自己的辦法,符合公司文化和價(jià)值的評(píng)審方法。以我們公司為例,通常是由每個(gè)人找4-5個(gè)項(xiàng)目同事來給他寫 feedback,提供對(duì)這個(gè)人在項(xiàng)目里面表現(xiàn)的反饋。因?yàn)?XP 提倡勇氣和反饋,所以,每個(gè)人也是會(huì)基于一個(gè)比較客觀的態(tài)度來對(duì)同事進(jìn)行評(píng)價(jià)。這樣,從項(xiàng)目同事的反饋里面,就能得到比較全面的個(gè)人 performance 信息了。
如何激勵(lì)個(gè)人創(chuàng)造?對(duì),因?yàn)?XP 提倡簡單設(shè)計(jì),通過重構(gòu)來增進(jìn)設(shè)計(jì),所以在設(shè)計(jì)里面考慮更多的是設(shè)計(jì)是不是滿足當(dāng)前的業(yè)務(wù)需求,是不是容易讓項(xiàng)目組其他成員所理解。但是,這并不意味著敏捷就不允許引入新技術(shù),不允許進(jìn)行大范圍設(shè)計(jì)。這里不舉我們公司的實(shí)踐,在《透析敏捷編程》一書中提到了在項(xiàng)目組中使用“金卡”實(shí)踐來激勵(lì)個(gè)人創(chuàng)造,就是允許項(xiàng)目成員申請(qǐng)金卡來進(jìn)行新技術(shù)研究或者大范圍設(shè)計(jì)。因?yàn)?XP 提倡溝通和勇氣,所以只要開發(fā)人員有具體理由,并且項(xiàng)目組同意個(gè)人在某方面花費(fèi)時(shí)間精力,那就是應(yīng)該尊重和允許的。
所以,從上面來看,XP 并不會(huì)導(dǎo)致個(gè)人失去成就感,重點(diǎn)在于項(xiàng)目組是否足夠 XP,足夠敏捷來讓每個(gè)人都達(dá)到自己的幸福感和成就感。如果沒有,建議通過團(tuán)隊(duì) retropective 來找出有效的改進(jìn)方法。
我們?cè)賮砜吹诙€(gè)問題:在項(xiàng)目組內(nèi),程序人員地位不比項(xiàng)目管理人員差。其實(shí)這個(gè)問題的更深層次問題是:
1. 程序人員應(yīng)該聽從管理人員的指揮,怎么能提出異議呢?
2. 如果程序人員有自己的想法,那管理還能進(jìn)行下去么?
那么,我想大部分擁有這個(gè)疑慮的人應(yīng)該是傳統(tǒng)的項(xiàng)目經(jīng)理。但是自從在 javaeye 里面看了一篇把開發(fā)團(tuán)隊(duì)比喻成正規(guī)軍的比喻之后,我發(fā)現(xiàn)有些開發(fā)人員也傾向于接收管理人員的命令,而不是更積極主動(dòng)地提供自己的建議,去和管理人員進(jìn)行更有效的溝通。其實(shí),我們?cè)谧雠嘤?xùn)的時(shí)候,和一些項(xiàng)目經(jīng)理也談過這方面的問題。開發(fā)人員不善于與他們溝通,導(dǎo)致他們對(duì)開發(fā)團(tuán)隊(duì)的真實(shí)狀態(tài)不清楚,他們覺得非常不放心,于是反過來進(jìn)一步要求開發(fā)團(tuán)隊(duì)提交更多的文檔來反映他們的狀態(tài)。這樣,開發(fā)團(tuán)隊(duì)文檔任務(wù)增重了,怨聲載道,項(xiàng)目經(jīng)理就更得不到項(xiàng)目團(tuán)隊(duì)的真實(shí)狀態(tài)了。于是,惡性循環(huán)就形成了。
在開發(fā)過程中,隨時(shí)都有可能會(huì)發(fā)生影響項(xiàng)目交付的問題,比如原來估算的工作量有偏差、客戶對(duì)某一處需求提出了修改等等。很多事情項(xiàng)目經(jīng)理是不可能事無巨細(xì)都會(huì)察覺的。這些問題在傳統(tǒng)軟件方法學(xué)里面都是作為風(fēng)險(xiǎn)來管理的,于是項(xiàng)目經(jīng)理在預(yù)防各種各樣的風(fēng)險(xiǎn)中忙得焦頭爛額,“兵馬未動(dòng),糧草先行”,不到最后一刻不敢讓開發(fā)人員進(jìn)行開發(fā)。因?yàn)橐坏┻M(jìn)行開發(fā),而開發(fā)人員不積極主動(dòng)反饋項(xiàng)目狀態(tài)的話,項(xiàng)目經(jīng)理對(duì)于項(xiàng)目就是完全失控了。這是項(xiàng)目經(jīng)理無論如何不敢面對(duì)的??墒牵?#8220;防民之口,甚于防川”,項(xiàng)目開發(fā)過程的風(fēng)險(xiǎn),是能完全堵死的么?如果開發(fā)人員可以有機(jī)會(huì),也無風(fēng)險(xiǎn)地發(fā)表自己的看法,項(xiàng)目管理就可以是更輕松了的。而且,一個(gè)人的智慧總是有限的,當(dāng)客戶逼著你做決定的時(shí)候,你不希望項(xiàng)目團(tuán)隊(duì)的人能站出來,助你一臂之力么?把全部責(zé)任都一肩扛,只會(huì)對(duì)項(xiàng)目不利,而談不上有益。從另一個(gè)方面講,每個(gè)人都是希望有一個(gè)上升的職業(yè)生涯,希望能不斷提升自己。軟件組織也是希望能不斷涌現(xiàn)表現(xiàn)優(yōu)秀的員工,從而有利于組織的成長。那為什么要打壓開發(fā)人員積極參與管理的興趣和付出,最終影響組織的成長呢?
在培訓(xùn)中,大多數(shù)項(xiàng)目經(jīng)理也能認(rèn)識(shí)到項(xiàng)目團(tuán)隊(duì)溝通的重要性,但對(duì)怎么建設(shè)這樣的團(tuán)隊(duì)仍然顯得方法不多。XP 作為充分照顧了人性的方法學(xué),也是提出很多原則允許或者鼓勵(lì)開發(fā)人員積極溝通,表達(dá)自己的想法。所以,運(yùn)用 XP,建設(shè)好簡單、勇氣、溝通和反饋的良好氛圍的團(tuán)隊(duì),不僅對(duì)于每個(gè)團(tuán)隊(duì)成員,對(duì)于項(xiàng)目經(jīng)理,對(duì)于其他管理人員都是有百益而無一害的。為什么不嘗試一下呢?
馬克思主義說過“集體所有制”、“人民專政”,毛澤東思想也說過“實(shí)事求是”,鄧小平理論更是說“不管白貓黑貓,抓到耗子就是好貓”。在《Refactored》提到的一些誤解,其實(shí)都不能作為反對(duì)實(shí)施敏捷的理由。我想,如果果真是阻力重重,或者不知道如何開頭,或許可以考慮請(qǐng)求于一些專門提供敏捷咨詢的第三方組織了。