極限程式設計的“權利法案”

從前，當我和別人談及極限程式設計（Extreme Programming，XP）的時候，由於它還是全新的（概念），所以我通常不得不從最基本的零散知識開始。這樣的日子已經一去不復返了。現在當我演講的時候詢問聽眾是否已經聽說過XP，很多人都會舉手。從我的角度講，這是很好的，因為我希望有更多的人能夠知道XP是如何幫助他們以更高的效率來開發軟體的。但是越來越多的曝光率常常也會帶來它的邪惡胞兄——誤解。
軟體開發不是非黑即白無論它可能會有什麼其他性質，軟體開發極少是一片非黑即白的土地。它是一塊極具變數的土地，充斥著大量有不同需求的人，所以當兩個人看待同一片風景的時候，一個人看到的是美麗和雅緻，而另一個看到的卻是一片頭腦的沙漠。XP似乎就得到了這種評價，從名字上就可以看得出來。畢竟，為什麼要叫它“極限程式設計”呢？如果再有一個人問我，XP是不是和橡皮筋或者劃下垂直斜坡有關的東西，我可能會笑趴下。

我聽到過很多種對它的解釋：一個是，重點應該真正地放在“程式設計”上，因為XP的一箇中心觀點是程式設計活動主要責任在於商業價值的交付。另一個是，“極限”指的是一個團隊按照個人慣例的頻率。例如，任何團隊都可以在某些時候給程式配對，但是XP團隊會在所有的時候都給程式配對。

Kent Beck，極限程式設計之父和靈巧聯盟（Agile Alliance）的創立者之一，說過：團隊是用來傳達程式設計所能夠完成的強度的。“極限程式設計是一種感知和精力集中的活動——所有的刻度盤都被撥到了10——關注你需要關注的一切，而不會在無關緊要的事情上花費精力，”Beck如是說。儘管Beck說這不是他原來的意圖，但是我的經驗卻是，名稱的優勢之一是它能夠調動起情緒性的反應。Jim Highsmith，適應性軟體開發（Adaptive Software Development）方法的創立者兼靈巧聯盟的活躍作者和評論員，在《靈巧軟體開發生態系統（Agile Software Development Ecosystems）》一書裡表達了這樣一種情緒：“我不認為會有很多人對一本關於‘《穩健程式設計（Moderate Programming）》’的書感興趣。新的市場、新的技術、新的理念都不來自於這種穩健，而是來自於極限不同的觀點，以及敢於挑戰現狀的勇氣。”
極限程式設計：解決方案還是騙局？有的人會把XP當作是適用於所有軟體開發問題的解決方案，而有些人則會把它看作是個騙局，不適用於任何軟體開發的情形。當然，事實是介於兩者之間的，但是如果你去和XP的狂熱擁護者或者強烈反對者進行一番討論的話，你就很有可能曲解XP的真正含義。

在這裡，我沒有地方來講述我所碰到過的對XP的所有誤解，但是誤解幾乎都和XP根本的價值相矛盾。如果你瞭解這些價值，那麼就很容易找到誤解的所在。XP在很多方面都體現出了其價值，包括對不同參與者的權利的闡述。任何XP專案都應該包括這些權利。要注意，具體的時限可能會因專案的不同而改變。
客戶的權利

• 客戶有權利大規模地計劃成本和選擇。
• 客戶有權利安排每週的開發優先順序。
• 客戶有權利在第一週結束的時候以工作系統的形式檢視進度，並瞭解之後每週會做些什麼。
• 客戶有權利更新計劃安排、不論是好的還是壞的，只要有資訊都要更新。
• 客戶有權利改變他／她的主意而不需要付出太多的費用。

程式設計師的權力

• 程式設計師有權利對工作進行評估，其評估的結果應該受到團隊其他成員的尊重。
• 程式設計師有權利如實地報告進度。
• 程式設計師有權利在所有的時候都進行高質量的工作。
• 程式設計師有權利知道下一步要做的、以及最重要的是什麼。
• 程式設計師有權利詢問面向商業的問題，如果這些問題出現的話。

管理人員的權利

• 管理人員有權利對成本和結果進行全面的評估，確認實際情況將（和預計的）有所不同。
• 管理人員有權利在專案之間調動人員，而不需要支付過高的費用。
• 管理人員有權利每月更新進度，幫助客戶確定總體的優先順序。
• 管理人員有權利根據最新的投資情況取消專案，並保留工作系統。

任何拒絕這些權利的專案都不是一個真正的XP專案，而無論給它貼上的標籤是不是XP。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-578461/，如需轉載，請註明出處，否則將追究法律責任。