Du är bekant med programmering, men Extreme Programming (XP förkortas) är fortfarande lite av ett mysterium för dig.
Låt inte namnet avskräcka dig, du riskerar att gå miste om användbar information.
I den här artikeln kommer vi att täcka allt du behöver veta om extrem programmering så att du kan använda det till din fördel.
Extrem programmering är en mjukvaruutvecklingsmetodik som är en del av vad som gemensamt kallas agila metoder. XP bygger på värderingar, principer och metoder och dess mål är att göra det möjligt för små och medelstora team att producera högkvalitativ programvara och anpassa sig till ständigt föränderliga och föränderliga krav.
Det som skiljer XP från andra agila metoder är att XP betonar de tekniska aspekterna av mjukvaruutveckling. Extrem programmering handlar exakt om hur ingenjörer arbetar eftersom att följa ingenjörspraxis gör att team kan leverera högkvalitativ kod i en hållbar takt.
Extrem programmering är, i ett nötskal, god praxis som tagits till en extrem. Eftersom parprogrammering är bra, låt oss göra det hela tiden. Eftersom det är bra att testa i förväg testar vi innan produktionskoden ens är skriven.
XP, till skillnad från andra metoder, är baserad på värderingar och principer som är viktiga och relevanta när det gäller ingenjörspraxis.
Värderingar ger ett syfte till team. De fungerar som en "nordstjärna" för att vägleda dina beslut på hög nivå. Värdena är dock abstrakta och för luddiga för specifik vägledning. Till exempel: Att säga att du värdesätter kommunikation kan leda till många olika resultat.
Praxis är på sätt och vis motsatsen till värderingar. De är konkreta och jordnära, defiställa in detaljerna för vad som ska göras. Praxis hjälper team att hålla sig ansvariga för värderingar. Till exempel främjar utövandet av informationsarbetsytor öppen och enkel kommunikation.
Principer är domänspecifika riktlinjer som överbryggar klyftan mellan praxis och värderingar.
XP-värden: kommunikation, enkelhet, feedback, mod och respekt. Låt oss titta på var och en av dem mer i detalj.
Utformningen BlogInnovazione.det av bilden alexsoft.com
Comunicazione: Brist på kommunikation hindrar kunskap från att flöda inom ett team. Ofta, när det finns ett problem, vet någon redan hur man åtgärdar det. Men brist på kommunikation hindrar dem från att lära sig om problemet eller bidra till att lösa det. Således slutar problemet med att lösas två gånger, vilket genererar avfall.
enkelhet: Enkelheten säger att du alltid strävar efter att göra det enklaste som fungerar. Det missförstås ofta och tas som det enklaste, punkt, och ignorerar "som fungerar"-delen.
Det är också viktigt att komma ihåg att enkelhet är mycket kontextuell. Vad som är enkelt för ett lag är komplext för ett annat och beror helt på kompetensen, erfarenheten och kunskaperna hos varje team.
Återkoppling: Feedback i mer traditionella, överlappande metoder för mjukvaruutveckling är ofta "för lite, för sent".
XP omfamnar dock förändring och XP-team strävar efter snabb och konstant feedback. Om kurskorrigering behövs vill XPers veta så snart som möjligt.
Utformningen BlogInnovazione.det av bilden alexsoft.com
Feedback kommer i många former och storlekar. När du samarbetar med programmering är kommentarer från din kollega viktig feedback. Så är andra teammedlemmars åsikter om en idé, inklusive kunden som helst är medlem i teamet.
Tester är en annan källa till värdefull feedback som går utöver testresultat. Oavsett om det är lätt eller svårt att skriva prov, så är feedback också. Om du har problem med att skriva tester är ditt projekt förmodligen för komplicerat. Lyssna på feedback och effektivisera din design.
Något som låter som en bra idé kanske inte fungerar så bra i praktiken. Därför är färdig kod också en källa till feedback, liksom en distribuerad produkt.
Slutligen, kom ihåg att det finns för mycket feedback. Om ett team genererar mer feedback än vad det kan hantera kan viktig feedback falla av radarn. Så det är viktigt att sakta ner och ta reda på vad som orsakar överflödig feedback och åtgärda det.
Mod: Kent Beck defimod framstår som "effektivt agerande inför rädsla". Som mjukvaruingenjör har du mycket att frukta och därför gott om möjligheter att visa mod.
Det krävs mod att berätta sanningen, särskilt de obehagliga, som ärliga uppskattningar. Att ge och ta emot feedback kräver också mod. Och det krävs mod för att undvika att hamna i felkostnadsfelet och kassera en misslyckad lösning som har fått betydande investeringar.
rispetto: En grundläggande förutsättning för XP är att alla bryr sig om sitt arbete. Ingen mängd teknisk excellens kan rädda ett projekt om det inte finns någon omsorg och respekt.
Varje person är värd värdighet och respekt, och det inkluderar naturligtvis de personer som är involverade i ett programvaruutvecklingsprojekt. När du och dina teammedlemmar respekterar och bryr sig om varandra, kunden, projektet och dess framtida användare, gynnas alla
Principer ger mer specifik vägledning än värderingar. De är riktlinjer som belyser värderingarna och gör dem mer explicita och mindre tvetydiga.
Utformningen BlogInnovazione.det av bilden alexsoft.com
Till exempel, baserat på värdet av mod enbart, kan du dra slutsatsen att det är lämpligt att göra en stor förändring i ditt schema omedelbart. Men Baby Steps-principen säger oss att stora förändringar är riskabla. Så, föredrar de små istället.
Mänskligheten: Människor skapar mjukvara för människor, ett faktum som ofta förbises. Men att ta hänsyn till grundläggande mänskliga behov, styrkor och svagheter skapar produkter som människor vill använda. Och en arbetsmiljö som ger dig möjlighet till tillfredsställelse och tillväxt, känslan av tillhörighet och grundläggande trygghet, är en plats där du lättare tar hänsyn till andras behov.
Ekonomi: I XP uppmärksammar team alltid de ekonomiska realiteterna för mjukvaruutveckling, utvärderar ständigt ekonomiska risker och projektbehov.
Till exempel skulle de implementera användarberättelser baserat på deras affärsvärde snarare än tekniska problem.
Ömsesidig förmån: Efter XP slipper du lösningar som gynnar en part på bekostnad av en annan. Till exempel kan utökade specifikationer hjälpa någon annan att förstå det, men det distraherar dig från att implementera det och försenar det för dina användare.
En ömsesidigt fördelaktig lösning är att använda automatiserade acceptanstest. Få omedelbar feedback om din implementering, dina kamrater får exakta specifikationer i koden och användarna får sina funktioner först. Dessutom kommer ni alla att ha ett skyddsnät mot regressioner.
Förmån (ömsesidig nytta): Om en given lösning fungerar på en nivå kan den också fungera på en högre eller lägre nivå. Till exempel, att få tidig och konstant feedback står på spel i olika grad i XP.
Förbättring: Enligt förbättringsprincipen siktar teamen inte på perfektion i en initial implementering, utan på en implementering som är tillräckligt bra, för att sedan kontinuerligt lära sig och förbättra den med feedback från riktiga användare.
Mångfald: Du och dina kollegor drar nytta av en mångfald av perspektiv, färdigheter och attityder. Sådan mångfald leder ofta till konflikter, men det är okej.
Konflikter och oenighet är möjligheter för bättre idéer att dyka upp när alla spelar efter värdena mod och respekt. Mod att uttrycka motsatta synpunkter, respekt genom att uttrycka dem på ett civilt och empatiskt sätt. Och allt detta är en effektiv kommunikationsövning.
reflektion: Bra team reflekterar över sitt arbete och analyserar hur man kan bli bättre. XP erbjuder många möjligheter för detta. Inte bara i sina vecko- och kvartalscykler, utan i varje träning som det främjar.
Känslor är viktiga att ta hänsyn till förutom logisk analys. Din magkänsla kan informera dig innan du kan resonera om någonting. Och så kan han prata med icke-tekniska människor, de kan ställa frågor som öppnar helt nya möjligheter.
Flöde: Traditionella metoder för mjukvaruutveckling har distinkta faser, som varar länge och har små möjligheter till feedback och kurskorrigering. Istället sker mjukvaruutveckling i XP i aktiviteter som sker kontinuerligt, i en konsekvent "ström" av värde.
möjligheter: Problem är oundvikliga i mjukvaruutveckling. Men varje problem är en möjlighet till förbättring. Lär dig se på dem på det här sättet och du är mycket mer benägen att komma på kreativa och målinriktade lösningar som också tjänar till att förhindra att de händer igen.
Redundans: Principen om redundans säger att om ett givet problem är kritiskt måste du använda många taktiker för att motverka det.
Ta bristerna. Det finns ingen enskild taktik som kan förhindra att alla defekter undslipper produktionen.
Så XPs lösning är att stapla en uppsättning kvalitetsmått. Parprogrammering, testning, kontinuerlig integration. Var och en en enda försvarslinje, tillsammans en praktiskt taget ogenomtränglig mur.
Fel: misslyckande är inte ett slöseri när det omvandlas till kunskap. Att vidta åtgärder och snabbt lära sig vad som inte fungerar är mycket mer produktivt än passivitet orsakad av obeslutsamhet att välja bland många alternativ.
qualità: Folk tror ofta att det finns ett dilemma mellan kvalitet och snabbhet.
Det är tvärtom: att trycka på för att förbättra kvaliteten är det som får dig att gå snabbare.
Till exempel är refactoring – att ändra kodens struktur utan att ändra dess beteende – en praxis som gör kod lättare att förstå och ändra. Som ett resultat är det mindre sannolikt att du introducerar koddefekter, vilket gör att du kan leverera mer värde först genom att inte behöva fixa buggar.
Små steg: Stora förändringar är riskabla. XP minskar den risken genom att göra ändringar i små steg, på alla nivåer.
Programmerare skriver kod i små steg med hjälp av testdriven utveckling. De integrerar sin kod i huvudlinjen flera gånger om dagen, istället för bara med några veckors eller till och med månaders mellanrum. Själva projektet sker i korta cykler snarare än långvariga faser.
Ansvar accepterat: I XP bör ansvar accepteras, aldrig tilldelas.
Ansvar bör komma med befogenhet att fatta beslut om vad du är ansvarig för. Det motsatta är också sant. Man vill inte att folk fattar beslut om de inte behöver leva med sina konsekvenser.
Extrem programmering, som är en smidig metodik, kan accepteras och börja tillämpas utan att följa stela planer. Detta är en iterativ design snarare än ett stort initialt projekt.
XP skiljer sig avsevärt från traditionella metoder, d.v.s. kaskad, för att undvika långvariga faser.
Hur skiljer sig XP från andra agila metoder?
Extrem programmering har till sin natur mycket gemensamt med andra agila metoder men är också unik bland dem.
De flesta andra utvecklingsmetoder säger inte mycket, om något, om hur man får jobbet gjort. XP, å andra sidan, är väldigt opinionsbildande när det kommer till detta och lägger stor vikt vid mjukvaruteknik.
Scrum är ett ramverk för att hjälpa team att utveckla komplexa projekt på ett adaptivt sätt. Scrum dikterar inte hur utvecklare gör sitt arbete. XP, som nämnts, lägger stor vikt vid bra programmeringsmetoder.
Utformningen BlogInnovazione.sv Bild nätlösningar
Dessutom handlar XP uppenbarligen om programmering. Scrum, å andra sidan, kan tillämpas på alla projekt som drar nytta av ett iterativt tillvägagångssätt.
XP accepterar ändringar av dess komponenter. Teamen bemyndigas och till och med uppmuntras att ändra praxis baserat på deras specifika behov. Scrum-guiden, å andra sidan, är stenhård att "Även om bara delar av Scrum kan implementeras, är resultatet inte Scrum."
Scrum är också ett ramverk som måste kompletteras med metoder och praxis för att få jobbet gjort.
Detta innebär att arbete i extrem programmering och Scrum rekommenderas starkt.
Enligt Kent Beck bör ett moget XP-team inte tilldela stela roller, utan inse att roller kan vara användbara för nya team tills de börjar sakta ner eller försvåra samarbete.
Låt oss titta på några nyckelroller:
Detta är de metoder som används i XP. De är indelade i tre huvudgrupper: mjukvaruteknik, arbetsplats och projektledning.
Parprogrammering: I XP skriver du kod i par som sitter på en maskin. Du och ditt par pratar med varandra när ni analyserar, implementerar och testar funktionen ni arbetar med. Parprogrammering är särskilt bra på att producera kod med färre buggar samtidigt som det är engagerande, roligt och tröttsamt.
Tio minuters gräns: Obligatoriskt Ger 10 minuter att bygga hela projektet, inklusive att köra alla automatiserade tester, på högst tio minuter. Denna gräns är för att hålla testningen strömlinjeformad och effektiv.
Tester före programmering: implementera funktioner med test-först-metoden, även kallad testdriven utveckling (TDD). TDD består av utveckling med en enkel iterativ procedur:
TDD ger flera fördelar.
Först feedback. Om det är svårt att skriva ett test är designen du letar efter eller som du har ärvt förmodligen för komplex och du måste förenkla den.
För det andra tillåter TDD programmerare att lita på koden de skriver och skapar en trevlig loop-rytm där nästa steg alltid är tydligt.
Sist men inte minst, att använda TDD från början säkerställer 100 % kodtäckning. Testsviten blir då verkligen ett skyddsnät för framtida förändringar, uppmuntrar kodrefaktorering och skapar en god cirkel av kvalitet.
Inkrementell design: Övningen av inkrementell design innebär att du behöver investera i din applikationsdesign varje dag, leta efter möjligheter att ta bort dubbelarbete och göra små förbättringar för att uppnå bästa möjliga design för vad ditt system behöver idag.
Kontinuerlig integration: I XP integrerar du ditt arbete i det delade huvudförrådet flera gånger om dagen, vilket utlöser en automatisk uppbyggnad av hela systemet. Att integrera så tidigt och så ofta som möjligt minskar dramatiskt kostnaden för integration eftersom det minskar sannolikheten för sammanslagningar och logiska konflikter. Det exponerar även miljö- och missbruksfrågor.
Delad kod (kollektivt ägande): XP främjar delad kod, eller kollektivt ägande: varje utvecklare är ansvarig för all kod. Det uppmuntrar informationsutbyte, minskar teambussfaktorn och ökar den övergripande kvaliteten på varje modul om vi tar hänsyn till principen om mångfald.
Enskild kodbas: Enskild kodbas är också känd som "trunk-baserad utveckling". Det betyder att det bara finns en källa till sanning. Så istället för att utvecklas isolerat under långa perioder, slå samman dina bidrag till en enda ström tidigt och ofta. Funktionsflaggor hjälper dig att begränsa din användning av funktioner tills de är färdiga.
Daglig utdelning: driftsättning i produktionen minst en gång om dagen är en logisk konsekvens av kontinuerlig integration:. Faktum är att idag går många team ännu längre och övar på kontinuerlig implementering. Det vill säga, när någon ansluter sig till huvudlinjen, distribueras applikationen till produktion.
Kod och tester: Denna praxis innebär att källkoden, inklusive tester, är den enda permanenta artefakten i ett programvaruprojekt. Att engagera sig i genereringen av andra typer av artefakter, inklusive dokumentation, är ofta slösaktigt eftersom det inte genererar verkligt värde för kunden.
Om du behöver andra artefakter eller dokument, gör ett försök att generera dem från produktionskod och tester.
Grundorsaksanalys: Närhelst en defekt går i produktion, korrigera inte bara defekten. Se till att du tar reda på vad som orsakade det i första hand, varför du och dina lagkamrater misslyckades med att förhindra sladden. Vidta sedan åtgärder för att se till att det inte händer igen.
Sitt tillsammans: I XP föredrar team att arbeta tillsammans i ett öppet utrymme. Denna praxis främjar kommunikation och en känsla av att tillhöra ett team.
Hela laget: Alla som behövs för att projektet ska lyckas är en del av XP-teamet. Detta är mycket kontextuellt – olika för varje team – och dynamiskt, det kan förändras inom ett team.
Informationsarbetsytor: En informationsarbetsyta använder teamets fysiska utrymme för att visa information som gör det möjligt för vem som helst att med ett ögonkast veta hur projektet fortskrider. Hur detta görs kan variera, från fysiska anteckningar och grafer till skärmdumpar som visar Kanban-tavlor och instrumentpaneler från projektledningsprogram.
Energifyllt arbete: I XP arbetar du bara så länge du kan utföra energiskt arbete. Arbetstiden ska vara begränsad till max 40 per vecka.
Analisi- Skriv användarkrav i ett format som kallas användaranalys. En användaranalys har ett kort, beskrivande namn och även en kort beskrivning av vad som behöver implementeras.
Slak: När du planerar en cykel, lägg till mindre uppgifter som teamet kan överge om behovet uppstår. Fler berättelser kan alltid läggas till om teamet levererar för mycket.
Cykler (månatlig och veckovis): Utveckling i XP sker i två huvudcykler: veckocykeln och månadscykeln.
Möten, cykler, schemalagda releaser: Utveckling i XP fungerar i två huvudcykler: veckocykeln och kvartalscykeln. Inledningsvis rekommenderade Kent Beck en tvåveckorscykel, men ändrade det i den andra upplagan av sin bok.
Veckocykel: veckocykeln är "pulsen" i ett XP-projekt. Cykeln börjar med ett möte där klienten väljer vilka berättelser han vill skapa under veckan. Dessutom granskar teamet sitt arbete, inklusive förra veckans framsteg, och funderar på sätt att förbättra sin process.
Månadscykel: Varje månad reflekterar teamet och identifierar förbättringsmöjligheter i sin process. Kunden väljer ett eller flera teman för den månaden, tillsammans med analyserna i dessa teman.
Hur börjar man arbeta med extrem programmering?
Tekniska färdigheter och XP-vanor kan vara svåra att lära sig. Vissa av metoderna kan verka främmande för programmerare som inte är vana vid dem.
Ercole Palmeri
En oftalmoplastikoperation med Apple Vision Pro kommersiella tittare utfördes på Catania Polyclinic...
Att utveckla finmotorik genom färgläggning förbereder barn för mer komplexa färdigheter som att skriva. Att färglägga…
Marinesektorn är en sann global ekonomisk makt, som har navigerat mot en marknad på 150 miljarder...
I måndags tillkännagav Financial Times ett avtal med OpenAI. FT licensierar sin journalistik i världsklass...
