xp是一種輕量（敏捷）、高效、低風險、柔性、可**、科學而且充滿樂趣的軟體開發方式。在以前的開發過程中，很多規則已經難於遵循，很多流程複雜而難於理解，很多專案中文件的製作過程正在失去控制。人們試圖提出更全面更好的一攬子方案，或者寄希望於更複雜的、功能更強大的輔助開發工具（casetools），但總是不能成功，而且開發規範和流程變得越來越複雜和難以實施。xp就是在這樣的情況下誕生的，它是靈巧的輕量級軟體開發方法，它跳出複雜的流程和文件，而是以輕量的框架和極限的思想為核心進行開發。
xp方**認為，如果小組成員之間無法做到持續的、無間斷的交流，那麼協作就無從談起，從這個角度能夠發現，通過文件、報表等人工製品進行交流面臨巨大的侷限性。因此，xp組合了諸如對程式設計這樣的最佳實踐，鼓勵大家進行口頭交流，通過交流解決問題，提高效率。
xp方**提倡在工作中秉承「夠用就好」的思路，也就是盡量地簡單化，只要今天夠用就行，不考慮明天會發現的新問題。這一點看上去十分容易，但是要真正做到保持簡單的工作其實很難的。因為在傳統的開發方法中，都要求大家對未來做一些預先規劃，以便對今後可能發生的變化預留一些擴充套件的空間。
反饋在團隊合作中是非常重要的，不僅是客戶與專案負責人之間的反饋，還應該包括開發人員在內，做到專案所有相關人自覺的反饋，讓他人知道專案進度，每個開發人員任務完成情況，做到人人都能及時知道專案的情況，人員的情況。這樣所有人都能心裡有數，才能做到相互配合，有效的溝通。
要知道，xp是提倡擁抱變化的，那麼要積極響應變化就需要相關相關人員，特別是開發人員有勇氣來面對快速開發，重新開發，**重構等情況，快速開發需要勇於面對更多h3ug，將一些h3ug留到下一版，重新開發要敢於廢棄之前的努力，不要因為已經開發出來了即使沒有什麼用處也要使用，重構則是要勇於改變現狀，讓**脫胎換骨。
及時地、快速地獲取反饋，並將所學到的知識盡快地投入到系統中去。也就是指開發人員應該通過較短的反饋迴圈，迅速地了解現在的產品是否滿足了客戶的需求。也就是需要我們持續交付，調整功能，這也是對反饋這一價值觀的進一步補充。快速反饋同樣適用於開發人員之間，團隊人員之間，及時反饋，有效溝通。
類似地，簡單性假設原則是對簡單這一價值觀的進一步補充。這一原則要求開發人員將每個問題都看得十分容易解決，也就是說只為本次迭代考慮，不去想未來可能需要什麼，相信具有將來必要時增加系統複雜性的能力，也就是號召大家出色地完成今天的任務。這點下文還會繼續說明。
就像開車打方向盤一樣，不要一次做出很大的改變，那樣將會使得可控性變差，更適合的方法是進行微調。而在軟體開發中，這樣的道理同樣適用，任何問題都應該通過一系列能夠帶來差異的微小改動來解決。
在軟體開發過程中，在解決最重要問題時，盡量為下一次修改做好準備。開發不息，h3ug不斷，我們都要打從心裡明白，h3ug是不可能有完全修改完的一天的，所以需要不斷進行更改，也不要守著最初的方案，不敢做任何變動，要為隨時可能到來的改動做好心裡準備。
在實踐中，經常看到許多開發人員喜歡將一些細小的問題留待後面解決。例如，介面的按鈕有一些不平整，由於不影響使用就先不管；某一兩個成員函式暫時沒用就不先寫等。這就是一種工作拖泥帶水的現象，這樣的壞習慣一旦養成，必然使得**質量大打折扣。而在xp方**中，貫徹的是「小步快走」的開發原則，因此工作質量決不可打折扣，通常採用測試先行的編碼方式來提供支援。
優質工作這點是個人自覺問題，特別體現開發人員的個人素質，拖泥帶水這個問題經常出現在進度比較趕的情況下，但pm或者leader也不能在這點上面妥協，而且一般這種問題也不會消耗很多開發時間，都是一兩句**的事，有時只是開發人員懶得去修改而已。一旦妥協，以後這種情況必然反覆出現。逐步修改這點除了開發人員實現，同時還需pm來配合，在迭代中進行微調，將更改控制在可控範圍，不會造成太大影響。
計畫遊戲的主要思想就是先快速地制定乙份概要的計畫，然後隨著專案細節的不斷清晰，再逐步完善這份計畫。計畫遊戲產生的結果是一套使用者故事及後續的一兩次迭代的概要計畫。
編寫故事：由客戶或者pm談論系統應該完成什麼功能，確定需求。
進行估算：開發人員對每個使用者故事進行估算，先從高優先順序開始估算。如果在估算的時候，感到有一些故事太大，不容易進行估算，或者是估算的結果超過2人/周，那麼就應該對其進行分解，拆成2個或者多個小故事。
迭代週期：接下來就是確定本次迭代的時間週期，這可以根據實際的情況進行確定，不過最佳的迭代週期是2~3周。
xp方**秉承的是「持續整合，小步快走」的哲學，也就是說每一次發布的版本應該盡可能的小，當然前提條件是每個版本有足夠的商業價值，值得發布。
創造心照不宣的詞彙和列子，更形象有趣的溝通。比喻有時候更能讓人更快更好的理解你的意思，而不是一堆晦澀專業術語。
簡單設計這個實現是乙個很容易讓人誤解，也讓許多批評者詬病的一條實現，因為它秉承「夠用就好」的思路，盡量地簡單化，只要今天夠用就行，不考慮明天會發現的新問題，明明是擁抱變化，怎麼又不考慮明天的問題了呢。而在傳統的開發中，需要我們考慮後期可能的需求，讓**做到高可擴充套件性，要求我們經常考慮後期需求。這樣看起來，傳統開發在這個方面似乎比xp更貼近擁抱變化的思想，我們再仔細看看。
這裡的簡單設計提出沒有重複**，盡量少的類和方法，使用迪公尺特法則等，只是針對今天而言，不要因為後期可能會用到，就新增了乙個現在不用的類或者方法，而不是不做可擴充套件性，這兩者並不衝突。即使因為沒有考慮很多，而可拓展性沒有做到很好，xp提倡重構也能將擴充套件性提高乙個檔次，而且更精確更符合現在的需求。而傳統的方式將一切考慮到位也不見得擴充套件性就完美，畢竟變化是不可**的，現在考慮的擴充套件性在幾個月後可能也用不上了，到時必然也是要重構。
簡單設計從本質上來說擴充套件性就很強，就像一張白紙，要怎麼畫都行，就看你能不能體會到其中的深度了。
工匠一代表的就是測試驅動開發的方法，當然為了有效的實現它，需要我們借助一些自動化測試工具。
如果你已經保持了簡單的設計，那麼編寫測試**根本不難。
如果你在結對程式設計，那麼如果你想出乙個好的測試**，那麼你的夥伴一定行。
當所有的測試都通過的時候，你再也不會擔心所寫的**今後會「暗箭傷人」，那種感覺是相當棒的。
當你的客戶看到所有的測試都通過的時候，會對程式充滿前所未有的信心。
當你需要進行重構時，測試**會給你帶來更大的勇氣，因為你要測試是否重構成功只需要乙個按鈕。
這樣的嘗試還是需要勇氣的，這也是xp的核心價值，不真正去使用去理解，一般人都會覺得天馬行空。
重構時一種對**進行改進而不影響功能實現的技術，xp需要開發人員在聞到**的壞味道時，有重構**的勇氣。重構的目的是降低變化引發的風險，使得**優化更加容易。重構有時並不是需要做很大的修改，不用談虎色變，對於xp來說，它只是乙個常規操作。
簡單來說就是兩個人坐在一起寫程式，結對程式設計也是乙個飽受質疑的舉措，一般認為它過於耗費人力資源，自尊心較強的開發人員也比較排斥結對程式設計。
當然結對程式設計也有結對程式設計的好處：
所有的設計決策確保不是由乙個人做出的。
系統的任何乙個部分都肯定至少有2個人以上熟悉。
幾乎不可能有2個人都忽略的測試項或者其他任務
結對組合的動態性，是乙個企業知識管理的好途徑。
**總是能夠保證被評審過。
而且xp方**整合的其他最佳實踐也能夠使得結對程式設計更加容易進行：
編碼標準可以消除一些無謂的分歧。
隱喻可以幫助結對夥伴更好地溝通。
簡單設計可以使得結對夥伴更了解他們所從事的工作。
結對程式設計還是要視情況使用，並不是有理論支援的就一定適用，如果覺得使用結對效率不高，還可以通過leader審核**來替代。
由於xp方**鼓勵團隊進行結對程式設計，而且認為結對程式設計的組合應該動態地搭配，根據任務的不同、專業技能的不同進行最優組合。由於每個人都肯定會遇到不同的**，所以**的所有制就不再適合於私有，因為那樣會給修改工作帶來巨大的不便。
也就是說，團隊中的每個成員都擁有對**進行改進的權利，每個人都擁有全部**，也都需要對全部**負責。同時，xp強調**是誰破壞的（也就是修改後發生問題），就應該由誰來修復。
由於在xp專案中，整合工作是一件經常性得工作，因此當有人修改**而帶來了整合的問題，會在很快的時間內被發現。
由於每乙個類都會有乙個測試**，因此不論誰修改了**，都需要執行這個測試**，這樣偶然性的破壞發生的概率將很小。
由於每乙個**的修改就是通過了結對的兩個程式設計師共同思考，因此通常做出的修改都是對系統有益的。
由於大家都堅持了相同的編碼標準，因此**的可讀性、可修改性都會比較好，而且還能夠避免由於命名法、縮排等小問題引發經常性得**修改。
持續整合是指團隊每天盡可能多次的進行**整合，保證團隊獲取的**都是近期統一過的**，避免太多不一致造成衝突。而上文說的小型發布則是更多的發布測試版本，中間版本，讓客戶或者pm審核，確認功能開發沒有錯誤。需要我們引入**管理工具，版本控制工具。
簡單來說，就是反對加班，將進度控制在合理的範圍，讓開發人員保持乙個健康高效的狀態。
做到讓開發人員享受開發，而不是讓他們感受到了煎熬。
為了保證開發出來的結果與客戶的預想接近，xp方**認為最重要的需要將客戶請到開發現場。就像計畫遊戲中提到過的，在xp專案中，應該時刻保證客戶負責業務決策，開發團隊負責技術決策。因此，在專案中有客戶在現場明確使用者故事，並做出相應的業務決策，對於xp專案而言有著十分重要的意義。特別是在發布中間版本後，需要客戶進行體驗，確保業務功能正確。
如果你的團隊已經擁有編碼標準，就可以直接使用它，並在過程中進行完善。如果還沒有，那麼大家可以先進行編碼，然後在過程中逐步總結出編碼規則，邊做邊形成。當然除了這種文字規範以外，還可以採用一些如自動格式化**工具之類的方法進行**規範。事實上，你只需要很好地貫徹執行其他的實踐並且進行通，編碼標準會很容易地浮現出來。
有句經典名言「1+1>2」最適合表達xp的觀點，kent h3eck認為xp方**的最大價值在於在專案中融會貫通地運用12個最佳實踐，而非單獨地使用。你當然可以使用其中的一些實踐，但這並不意味著你就運用了xp方**。xp方**真正能夠發揮其效能，就必須完整地運用12個實踐。你甚至可以跳出xp開發方法，和其他開發方法進行結合，只要是遵循敏捷宣言的方法，必定有它們共同之處，也有能夠相互配合，更加完善的地方。
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...