你熟悉編程，但極限編程（簡稱XP）對你來說還是有點神秘。
不要讓這個名字讓您失望，您可能會錯過有用的信息。
在本文中，我們將涵蓋您需要了解的有關極限編程的所有信息，以便您可以充分利用它。
極限編程是一種軟件開發方法，是統稱為敏捷方法的一部分。 XP 建立在價值觀、原則和實踐之上，其目標是使中小型團隊能夠生產高質量的軟件並適應不斷變化和不斷發展的需求。
XP 與其他敏捷方法的區別在於 XP 強調軟件開發的技術方面。 極限編程精確地描述了工程師的工作方式，因為遵循工程實踐允許團隊以可持續的速度交付高質量的代碼。
簡而言之，極限編程就是將好的實踐發揮到極致。 由於結對編程很好，所以我們一直這樣做吧。 由於提前測試很好，我們甚至在編寫生產代碼之前就進行了測試。
XP 與其他方法不同，它基於工程實踐方面重要且相關的價值觀和原則。
價值觀為團隊提供了目的。 他們充當“北極星”，在高層次上指導您的決策。 但是，這些值是抽象的，對於具體的指導來說過於模糊。 例如：說你重視溝通會導致許多不同的結果。
從某種意義上說，實踐與價值觀是對立的。 他們是具體的、腳踏實地的， defi設定要做什麼的細節。 實踐幫助團隊對價值觀負責。 例如，信息工作空間的實踐促進了透明和簡單的溝通。
原則是特定領域的指導方針，彌合了實踐和價值觀之間的差距。
XP價值觀：溝通、簡單、反饋、勇氣和尊重。 讓我們更詳細地看看它們中的每一個。
起草 BlogInnovazione.它的圖像 亞歷克斯軟件網
Comunicazione：缺乏溝通會阻止知識在團隊內流動。 通常，當出現問題時，有人已經知道如何解決它。 但是缺乏溝通會阻止他們了解問題或為解決問題做出貢獻。 因此，問題最終被解決了兩次，產生了浪費。
簡單的: 簡單意味著你總是努力做最簡單有效的事情。 它經常被誤解並被視為最簡單的事情，句號，忽略了“有效”的部分。
同樣重要的是要記住，簡單是高度相關的。 對一個團隊來說簡單的事情對另一個團隊來說很複雜，並且完全取決於每個團隊的技能、經驗和知識。
您的意見：在更傳統的級聯軟件開發方法中，反饋通常“太少，太晚”。
然而，XP 擁抱變化，XP 團隊努力爭取及時和持續的反饋。 如果需要更正路線，XPers 希望盡快知道。
起草 BlogInnovazione.它的圖像 亞歷克斯軟件網
反饋有多種形式和大小。 當您進行合作編程時，同事的評論是至關重要的反饋。 其他團隊成員對一個想法的意見也是如此，包括理想情況下是團隊成員的客戶。
測試是除了測試結果之外的另一個有價值的反饋來源。 無論編寫測試是容易還是困難，反饋也是如此。 如果您在編寫測試時遇到問題，您的項目可能太複雜了。 聽取反饋並簡化您的設計。
聽起來不錯的想法在實踐中可能效果不佳。 因此，完成的代碼也是反饋的來源，就像分佈式產品一樣。
最後，請記住反饋太多。 如果一個團隊產生的反饋多於它可以處理的數量，那麼重要的反饋可能會被忽視。 因此，必須放慢速度並找出導致過多反饋的原因並進行修復。
勇氣：肯特·貝克 defi勇氣表現為“面對恐懼的有效行動”。 作為一名軟件工程師，您有很多恐懼，因此有很多機會展現勇氣。
說實話需要勇氣，尤其是那些不愉快的，比如誠實的估計。 提供和接受反饋也需要勇氣。 避免陷入沉沒成本謬誤並放棄已獲得大量投資的失敗解決方案需要勇氣。
尊重：XP 的一個基本前提是每個人都關心他們的工作。 如果沒有關心和尊重，再多的技術卓越也無法挽救一個項目。
每個人都值得尊嚴和尊重，當然，這包括參與軟件開發項目的人。 當你和你的團隊成員相互尊重和關心對方、客戶、項目及其未來的用戶時，每個人都會受益
原則比價值觀提供更具體的指導。 它們是闡明價值觀並使價值觀更明確、更明確的指導方針。
起草 BlogInnovazione.它的圖像 亞歷克斯軟件網
例如，僅基於勇氣的價值，您可能會得出結論，建議立即對您的日程安排進行重大更改。 然而，Baby Steps 原則告訴我們，大的改變是有風險的。 所以，更喜歡小的。
烏曼尼塔：人類為人類創造軟件，這是一個經常被忽視的事實。 但考慮到人類的基本需求、優勢和劣勢，創造出人類想要使用的產品。 一個能為您提供成就感和成長機會、歸屬感和基本安全感的工作環境，是您更容易考慮他人需求的地方。
經濟：在 XP 中，團隊始終關注軟件開發的經濟現實，不斷評估經濟風險和項目需求。
例如，他們會根據業務價值而不是技術問題來實施用戶故事。
互惠互利：在 XP 之後，您會避免以犧牲另一方為代價使一方受益的解決方案。 例如，擴展規範可能會幫助其他人理解它，但它會分散您對實現它的注意力並延遲它對您的用戶的實現。
一個互惠互利的解決方案是使用自動驗收測試。 獲得關於您的實施的即時反饋，您的同行獲得精確的代碼規範，而用戶首先獲得他們的功能。 另外，你們所有人都會有一個防止倒退的安全網。
利益（互利）：如果給定的解決方案在一個級別上工作，它也可能在更高或更低的級別上工作。 例如，在 XP 中，獲得早期和持續的反饋在不同程度上處於危險之中。
改進：根據改進的原則，團隊的目標不是在最初的實施中完美，而是為了一個足夠好的實施，然後根據真實用戶的反饋不斷學習和改進。
多樣性：您和您的同事受益於多元化的觀點、技能和態度。 這種多樣性往往會導致衝突，但這沒關係。
當每個人都秉承勇氣和尊重的價值觀時，衝突和分歧是產生更好想法的機會。 敢於表達相反的觀點，以文明和同理心的方式表達尊重。 所有這些都是有效的溝通練習。
反射：偉大的團隊會反思他們的工作並分析如何做得更好。 XP 為此提供了許多機會。 不僅在每周和每季度的周期中，而且在它促進的每項實踐中。
除了邏輯分析之外，感覺也很重要。 在您推理任何事情之前，您的直覺會告訴您。 這樣他就可以與非技術人員交談，他們可以提出開闢全新可能性的問題。
弗魯索：傳統的軟件開發方法有不同的階段，持續很長時間並且很少有機會獲得反饋和過程修正。 相反，XP 中的軟件開發發生在持續發生的活動中，發生在一致的“價值流”中。
機會: 問題在軟件開發中是不可避免的。 然而，每一個問題都是改進的機會。 學會以這種方式看待它們，你就更有可能想出創造性的、以目標為導向的解決方案，這些解決方案也有助於防止它們再次發生。
冗餘：冗餘原則說，如果給定的問題很關鍵，則必須採用多種策略來應對它。
抓住缺點。 沒有一種策略可以防止所有缺陷從生產中逃脫。
所以 XP 的解決方案是疊加一套質量措施。 結對編程、測試、持續集成。 每一道防線，共同構成一道幾乎堅不可摧的牆。
失敗：當失敗轉化為知識時，失敗並不浪費。 採取行動並迅速了解什麼是行不通的，這比在眾多選項中做出選擇時優柔寡斷導致的不作為更有成效。
質量: 人們通常認為質量和速度之間存在兩難選擇。
恰恰相反：努力提高質量會讓你走得更快。
例如，重構——改變代碼結構而不改變其行為——是一種使代碼更易於理解和更改的實踐。 因此，您不太可能引入代碼缺陷，這讓您無需修復錯誤即可首先交付更多價值。
小步驟: 大的變化是有風險的。 XP 通過在每個級別進行小步更改來減輕這種風險。
程序員使用測試驅動開發以小步驟編寫代碼。 他們每天多次將代碼集成到主線中，而不是每隔幾週甚至幾個月一次。 該項目本身發生在較短的周期而不是長期的階段。
接受責任: 在 XP 中，責任應該被接受，而不是分配。
問責制應該伴隨著對你負責的事情做出決定的權力。 反之亦然。 你不希望人們在不必承擔後果的情況下做出決定。
極限編程作為一種敏捷的方法論，可以被接受並開始採用它，而無需遵循嚴格的計劃。 這是一個迭代設計，而不是一個大的初始項目。
XP 與傳統方法顯著不同，即級聯，避免持久階段。
XP 與其他敏捷方法有何不同？
極限編程，就其本質而言，與其他敏捷方法有很多共同點，但在它們之間也很獨特。
大多數其他開發方法並沒有過多地說明如何完成工作。 另一方面，XP 在這方面非常自以為是，非常強調軟件工程實踐。
Scrum 是一個幫助團隊以適應性方式開發複雜項目的框架。 Scrum 不規定開發人員如何工作。 如前所述，XP 非常重視良好的編程實踐。
起草 BlogInnovazione.en 圖片 網絡解決方案
另外，XP 顯然是關於編程的。 另一方面，Scrum 可以應用於任何受益於迭代方法的項目。
XP 接受對其組件的更改。 團隊被授權甚至鼓勵根據他們的特定需求修改實踐。 另一方面，Scrum 指南堅持認為“雖然只能實施 Scrum 的一部分，但結果不是 Scrum”。
此外，Scrum 是一個框架，需要輔以方法和實踐來完成工作。
這意味著強烈建議使用極限編程和 Scrum。
根據 Kent Beck 的說法，一個成熟的 XP 團隊不應該分配嚴格的角色，而是要認識到角色對剛起步的團隊是有用的，直到他們開始放慢速度或使協作變得困難。
讓我們看看一些關鍵角色：
這些是XP中採用的做法。 他們分為三個主要組：軟件工程、工作場所和項目管理。
結對編程: 在 XP 中，你在一台機器上成對地編寫代碼。 您和您的夫婦在分析、實施和測試您正在開發的功能時互相交談。 結對編程特別擅長生成錯誤更少的代碼，同時仍然具有吸引力、樂趣和累人。
十分鐘限制：必需 允許 10 分鐘構建整個項目，包括運行所有自動化測試，最多 XNUMX 分鐘。 這個限制是為了保持測試的精簡和有效。
編程前測試：使用測試優先方法實現功能，也稱為 測試驅動開發 (TDD). TDD 包括使用簡單迭代過程的開發：
TDD 帶來了幾個好處。
第一，反饋。 如果很難編寫測試，那麼您正在尋找的或繼承的設計可能太複雜，您需要對其進行簡化。
其次，TDD 允許程序員信任他們編寫的代碼並創建一個很好的循環節奏，下一步總是很清楚。
最後但同樣重要的是，從一開始就使用 TDD 可確保 100% 的代碼覆蓋率。 然後，測試套件真正成為未來更改的安全網，鼓勵代碼重構並創建質量的良性循環。
增量設計：增量設計的實踐意味著您每天都需要在應用程序設計上進行投資，尋找機會消除重複並進行小的改進，以實現當今系統所需的最佳設計。
持續集成: 在 XP 中，您每天多次將您的工作集成到主共享存儲庫中，觸發整個系統的自動構建。 儘早和盡可能頻繁地集成可顯著降低集成成本，因為它使合併和邏輯衝突不太可能發生。 它還暴露了環境和成癮問題。
共享代碼（集體所有）: XP提倡共享代碼，或集體所有權：每個開發人員對所有代碼負責。 如果我們考慮多樣性原則，它會鼓勵信息交流，降低團隊總線因素並提高每個模塊的整體質量。
單一代碼庫: 單一代碼庫也稱為“基於主幹的開發”。 這意味著只有一個真理來源。 因此，與其長時間孤立地開發，不如儘早並經常將您的貢獻合併到一個流中。 功能標誌有助於限制您對功能的使用，直到它們完成為止。
每日派送：每天至少在生產中部署一次是持續集成的合乎邏輯的結果：。 事實上，今天，許多團隊走得更遠，實踐持續實施。 也就是說，只要有人加入主線，應用程序就會部署到生產環境中。
代碼和測試：這種做法意味著源代碼（包括測試）是軟件項目的唯一永久工件。 參與其他類型的工件（包括文檔）的生成通常是一種浪費，因為它不會為客戶產生真正的價值。
如果您需要其他工件或文檔，請努力從生產代碼和測試中生成它們。
根本原因分析：每當將缺陷投入生產時，不要只是糾正缺陷。 確保首先弄清楚是什麼原因造成的，為什麼你和你的隊友未能阻止打滑。 然後，採取措施確保它不再發生。
坐在一起：在 XP 中，團隊更喜歡在開放空間中一起工作。 這種做法促進了溝通和團隊歸屬感。
整個團隊：項目成功所需的每個人都是 XP 團隊的成員。 這是高度相關的——每個團隊都不同——而且是動態的，它可以在團隊內部發生變化。
信息工作空間：信息工作空間利用團隊的物理空間來展示信息，讓任何人都能一目了然地了解項目的進展情況。 這是如何完成的，從物理筆記和圖表到顯示項目管理軟件的看板和儀表板的屏幕截圖。
充滿活力的工作: 在 XP 中，只要您能幹精力充沛的工作，您就可以工作。 工作時間必須限制在每週最多 40 小時。
Analisi- 以稱為用戶分析的格式編寫用戶需求。 用戶分析有一個簡短的描述性名稱，還有一個對需要實施的內容的簡短描述。
鬆弛：在規劃週期時，添加團隊可以在需要時放棄的次要任務。 如果團隊交付太多，總是可以添加更多故事。
週期（每月和每週）: XP 中的開發有兩個主要周期：每週週期和每月週期。
會議、週期、預定發布: XP 中的開發工作有兩個主要周期：每週週期和季度週期。 最初，肯特·貝克 (Kent Beck) 建議以兩週為周期，但在他的書的第二版中對此進行了更改。
每週循環：每週週期是 XP 項目的“脈搏”。 這個週期從一個會議開始，客戶在會上選擇他想在一周內創作的故事。 此外，團隊會回顧他們的工作，包括上週的進展，並思考改進流程的方法。
每月週期：每個月，團隊都會反映並確定流程中的改進機會。 客戶選擇當月的一個或多個主題，以及對這些主題的分析。
如何開始使用極限編程？
技術技能和 XP 習慣可能很難學習。 有些做法對於不習慣它們的程序員來說可能看起來很陌生。
Ercole Palmeri
Casaleggio Associati 發布了義大利電子商務年度報告。題為「人工智慧商務：人工智慧電子商務的前沿」的報告...
