系統架構師---開發方法---敏捷開發

前言

極限編程

四大價值觀

溝通

簡單

反饋

勇氣

尊重：

十二個最佳實踐

計劃游戲

小型發布

隱喻

簡單設計

測試先行

重構

結對編程

集體代碼所所有制

持續集成

每周工作40小時

現場客戶

編碼標準

前言

2001年2月，在美國的猶他州，17位“無政府主義者”共同發表了《敏捷軟件開發宣言》，在宣言中指出：

盡早地、持續地向客戶交付有價值的軟件對軟件開發人員來說是最重要的。
擁抱變化，即使在開發的后期。敏捷過程能夠駕馭變化，保持客戶的競爭力。
經常交付可工作的軟件，從幾周到幾個月，時間范圍越小越好
在整個項目中，業務人員和開發者緊密合作
圍繞士氣高昂的團隊進行開發，為團隊成員提供適宜的環境，滿足他們的需要，并給予足夠的信任
在團隊中，最有效率的、也是效果最好的溝通方式是面對面地交流
可以工作的軟件是進度首要的度量方式
可持續地開發，投資人、開發團隊和用戶應該保持固定的節奏
不追求優秀的技術和良好的設計有助于提高敏捷性
要簡單，盡可能減少工作量。減少工作量的藝術是非常重要的
最好的架構、需求和設計都來自于一個自我組織的團隊
團隊要定期地總結如何能夠更有效率，然后相應的自我調整

極限編程

XP方法可以說是敏捷聯盟中最鮮艷的一面旗幟，也是相對來說最成熟的一種。XP方法的雛形最初形成于1996-1999年。

XP是一種輕量、敏捷、高效、低風險、柔性、可預測、可行而且充滿樂趣的軟件開發方式。與其他方法論相比，其最大的不同在于：

在更短的周期內，更早地提供具體、持續的反饋信息
迭代地進行計劃編制，首先在最開始迅速生成一個總體計劃，然后在整個項目開發過程中不斷地發展它。
依賴于自動測試程序來監控開發進度，并及早地捕獲缺陷
依賴于口頭交流，測試和源程序進行溝通
倡導持續的，演化式的設計
依賴于開發團隊內部的緊密協作
盡可能達到程序員短期利益和項目長期利益的平衡

XP由價值觀、原則、實踐和行為四個部分組成，他們彼此相互依賴，關聯，并通過行為貫穿整個生命周期

四大價值觀

XP的核心是其總結的溝通、簡單、反饋、勇氣四大價值觀，它們是XP的基礎，也是XP的靈魂。

溝通

通常，程序員給人留下的印象就是內向、不善言辭，項目中的許多問題就出在這些缺乏溝通的開發人員身上。由于某個程序員做出了一個設計決定，但是卻不能夠及時溝通團隊中的其他成員，結果使得團隊在協作與配合上出現很多麻煩。而在傳統的開發方法中，并不在意這種口頭溝通不暢的問題，而是希望借助于完善的流程和面面俱到的文檔、報表、計劃來替代，但是，這又引入了效率不高的新問題。

XP方法認為，如果小組成員之間無法做到持續的，無間斷的交流，那么協作就無從談起。從這個角度來看，通過文檔、報表等人工制品進行交流，具有很大的局限性。因此，XP組合了諸如結對編程這樣的最佳實踐，鼓勵大家進行口頭交流，通過交流解決問題，提供效率。

簡單

XP方法在工作中秉承“夠用即好”的思路，也就是盡量的簡單化，只要今天夠用就行，不考慮明天會出現的新問題。這一點看上去十分容易，但是要真正做到保持簡單的工作其實是很難的，因為在傳統的開發方法中，都要求開發人員對未來做一些預先規劃，以便對今后可能發生的變化預留一些擴展空間。

溝通和簡單之后還有一種相當微秒的互相支持的關系。一方面，團隊成員之間的溝通得越多，就越容易明白那些工作需要做，那些工作不需要做；另一方面，系統越簡單，需要溝通的內容也就越少，溝通也將更加全面。

反饋

是什么原因使得客戶、管理層這么不理解開發團隊？究其原因，就是開發的過程中缺乏必要的反饋。在很多項目中，當開發團隊經歷過需求分析之后，在一個相當長的時間段中，是沒有任何反饋信息的。整個開發過程對于客戶和管理層而言就像一個黑盒子，進度完全看不到。而且，在項目開發過程中，這樣的現象不僅出現在開發團隊與客戶、管理層之間，還包括在開發團隊內部。因此，開發團隊需要更加注重反饋。反饋對應任何軟件項目的成功都是至關重要的，而在XP方法論中則更進一步，通過持續、明確的反饋來暴露軟件狀態的問題。

反饋與溝通有著良好的配合，及時和良好的反饋有助于溝通。而簡單的系統，更有利于測試和反饋。

勇氣

在應用XP方法時，每時每刻都在應對變化；由于溝通良好，會有更多需求變更的機會；由于時刻保持系統的簡單，新的變化會帶來一些重新開發的需要；由于反饋及時，會有更多中間打斷思路的新需求。總之，這一切使得開發團隊處于變化之中，因此，這時就需要有勇氣來面對快速開發，面對可能的重新開發。勇氣可以來源與溝通，因為它使得高風險，高回報的試驗稱為可能；勇氣可以來源于簡單，因為面對簡單的系統，更容易鼓起勇氣；勇氣可以來源與反饋，因為可以及時獲得每一步前進的狀態（自動測試），會讓人更勇于重構代碼。

尊重：

在XP的四大價值之下，隱藏著一種更加深刻的東西，就是尊重。因為這一切的準則都建立在團隊成員之間相互關心，相互理解的基礎之上。

十二個最佳實踐

在XP中，集成了12個最佳實踐，大多數概念和編程一樣老。主要的創新點在于提供一種良好的思路將這些最佳實踐結合在一起，并且確保盡可能徹底地執行，使得他們能夠在最大程度上相互支持。

計劃游戲

計劃游戲的主要思想就是先快速地制定一份概要計劃，然后，隨著項目細節的不斷清晰，再逐步完善這份計劃。計劃游戲產生的結果是一套用戶故事及后續的一兩次迭代的概要計劃。

小型發布

XP方法秉承的是“持續集成，小步快走”的哲學思維，也就是說每一次發布的版本應該盡可能地小，當然前提條件是每個版本有足夠的商業價值，值得發布。由于小型發布可以使的集成更頻繁，客戶獲得的中間結果越頻繁，反饋也就越頻繁，客戶就能夠實時地了解項目的進展情況，從而提出更多的意見，以便在下一次迭代中計劃進去，以實現更高的客戶滿意度。

隱喻

相對而言，隱喻比較令人費解。根據詞典中的解釋是，“一種語言的表達手段，它用來暗示字面意義不相似的事物之間的相似之處”。隱喻常用的四個方面，尋求共識，發明共享詞匯、創新的武器、描述架構。

簡單設計

強調簡單的價值觀，引出了簡單性的假設原則，落實實處就是“簡單設計”實踐。這個實踐看上哪去似乎很容易理解，但是卻又經常被誤解，許多批評者就指責XP忽略設計是不正確的。其實，XP的簡單設計實踐并不是要忽略設計，而是認為設計不應該在編碼之前一次性完成，因為那樣只能建立在“情況不會發生變化”或者，“我們可以預見所有的變化”之類的謊言的基礎上。

測試先行

對于有些團隊而言，有時候程序員會以“開發工作太緊張”為理由，繼而忽略測試工作。這樣，就導致了一個惡性循環，越是沒空編寫測試程序，代碼的效率與質量越差，花在找缺陷，解決缺陷的時間也就越來越多，實際產能大大降低。由于產能降低，因此時間更緊張，壓力就更大。

重構

重構是一種對代碼進行改進而不影響功能實現的技術，XP需要開發人員在“聞到代碼的壞味道”時，就有重構代碼的勇氣。重構的目的是降低變化引發的風險、使得代碼優化更加容易。

結對編程

從20世紀60年代開始，就有類似的實踐在進行，長年以來的研究結果給出的結論是，結對編程的效率反而比單獨編程更高。一開始雖然會犧牲一些速度，但是慢慢的，開發的速度會逐漸加快。究其原因，主要是結對編程大大降低了溝通的成本，提供了工作的質量。結對編程技術被譽為XP保證工作質量、強調人文主義的一個最典型的實踐，應用得當還能夠使開發團隊協作更加順暢、知識交流與共享更加頻繁、團隊穩定性也會更加牢固。

集體代碼所所有制

由于XP方法鼓勵團隊進行結對編程，而且認為結對編程的組合應該動態地搭配，根據任務的不同、專業技能的不同進行更優組合。因此，每一個人都會遇到不同的代碼，代碼的所有制就不再適合于私有，因為那樣會給修改工作帶來巨大的不便。所謂集體代碼所有制，就是團隊中每個成員都擁有對代碼進行改進的權利，每個人都擁有全部代碼，也都需要對全部代碼負責。同時，XP強調代碼是誰破壞的（修改后出現問題），就應該誰來進行修復處理。

集體代碼所所有制是XP與其他敏捷方法的一個較大的不同，也是從另一個側面體現了XP中蘊含的很深厚的編碼情節。