Vad är extrem programmering? En översikt över XP Regler och värden

0 Comments

tillbaka på 1990-talet, ökningen av Internet krävde en förändring i mjukvaruutveckling. Om ett företags framgång berodde på den hastighet med vilken företaget kunde växa och föra produkter till marknaden, företag som behövs för att dramatiskt minska mjukvaruutveckling livscykel.,

det var i denna miljö som Kent Beck skapade extreme programming (XP), en smidig projektledningsmetod som stöder frekventa utgåvor i korta utvecklingscykler för att förbättra programvarukvaliteten och tillåta utvecklare att svara på förändrade kundkrav.

även om du kan känna igen några av dessa metoder och värden från andra projektledningsmetoder, tar XP dessa metoder till ”extrema” nivåer, som metodens namn antyder., I en intervju med Informit förklarar Kent:

” första gången jag blev ombedd att leda ett lag, bad jag dem att göra lite av de saker jag trodde var förnuftiga, som testning och recensioner. Andra gången var det mycket mer på linjen. Jag … bad teamet att vrida upp alla rattar till 10 på de saker jag trodde var nödvändiga och lämna ut allt annat.”

om du och ditt team snabbt behöver släppa och svara på kundförfrågningar, ta en titt på värdena och reglerna för extrem programmering—det kan vara en perfekt passform.,

översikt över Extreme Programming (XP) (Klicka på bilden för att ändra online)

värden för extreme programming methodology

XP är mer än bara en serie steg för att hantera projekt—det följer en uppsättning värden som hjälper ditt lagarbete snabbare och samarbeta mer effektivt.

enkelhet

lag åstadkomma vad som har efterfrågats och ingenting mer. XP bryter ner varje steg i en större process i mindre, uppnåbara mål för gruppmedlemmar att uppnå.,

strömlinjeformad kommunikation

team arbetar tillsammans på varje del av projektet, från att samla krav för att genomföra kod, och delta i dagliga standup möten för att hålla alla gruppmedlemmar uppdaterade. Eventuella problem eller problem behandlas omedelbart.

konsekvent, konstruktiv feedback

i XP anpassar teamen sin process till projektet och kundens behov, inte tvärtom. Teamet ska visa sin programvara tidigt och ofta så att de kan samla feedback från kunden och göra nödvändiga ändringar.,

respekt

extrem programmering uppmuntrar en ”allt för en och en för alla” mentalitet. Varje person i laget, oavsett hierarki, respekteras för sina bidrag. Teamet respekterar kundernas åsikter och vice versa.

Mod

gruppmedlemmar anpassar sig till förändringar när de uppstår och tar ansvar för sitt arbete. De berättar sanningen om deras framsteg-Det finns inga ”vita lögner” eller ursäkter för att inte få människor att må bättre. Det finns ingen anledning att frukta för att ingen arbetar ensam.,

Rules of extreme programming methodology

Don Wells publicerade de första XP-reglerna 1999 för att motverka påståenden om att extrem programmering inte stöder aktiviteter som är nödvändiga för mjukvaruutveckling, såsom planering, hantering och utformning. Från planering till testning av programvaran, följ dessa grundläggande steg för varje iteration.

Extreme Programming Feedback/Planning loopar (klicka på bilden för att ändra online)

planering

det här steget är där UX magic händer., I stället för en lång kravdokument, kunden skriver användarhistorier, som definierar funktionaliteten kunden skulle vilja se, tillsammans med affärsvärde och prioritet för var och en av dessa funktioner. Användarhistorier behöver inte vara uttömmande eller alltför tekniska—de behöver bara ge tillräckligt med detaljer för att hjälpa laget att avgöra hur lång tid det tar att genomföra dessa funktioner.

med Lucidchart kan kunderna skapa en grundläggande flödesschema och enkelt spela in och dela önskad funktionalitet.,

därifrån skapar teamet ett utgivningsschema och delar upp projektet i iterationer (en till tre veckor lång). Projektledare kanske vill skapa en tidslinje eller ett förenklat Gantt-diagram för att dela schemat med laget.

hantera

i detta skede kommer projektledaren att ställa in teamet för att lyckas med denna metod. Alla behöver arbeta tillsammans och effektivt kommunicera för att undvika slipups. Det här steget innebär:

  • att skapa en öppen arbetsyta för ditt team
  • att ställa in en hållbar takt (dvs., bestämma rätt längd för iterationer)
  • schemalägga ett dagligt standup-möte
  • mäta projekthastighet (mängden arbete som görs på ditt projekt)
  • omfördela arbete för att undvika flaskhalsar eller kunskapsförlust
  • ändra reglerna om XP inte fungerar perfekt för laget

designa

denna regel går tillbaka till värdet av enkelhet: börja med den enklaste designen eftersom det tar mindre tid att slutföra än komplex lösning. Lägg inte till funktionalitet tidigt. Refactor ofta för att hålla din kod ren och koncis., Skapa spike lösningar för att utforska lösningar på potentiella problem innan de sätter ditt team bakom.

Kent Beck och Ward Cunningham skapade också class-responsibility-collaboration (CRC) kort att använda som en del av XP-metoden. Dessa kort gör det möjligt för hela projektgruppen att utforma systemet och se hur objekt interagerar. Om du vill prova detta brainstorming verktyg för dig själv, komma igång med vår Lucidchart Mall.,

Modell Class-Responsibility-Collaborator (CRC) (klicka på bilden för att ändra online)

kodning

då är det dags att implementera koden. XP practices collective code ownership: alla recensioner kod och alla utvecklare kan lägga till funktionalitet, fixa buggar eller refactor. För att kollektiv kodägande ska fungera bör laget:

  • välja en systemmetafor (standardiserat namngivningssystem).
  • öva parprogrammering., Gruppmedlemmar arbetar i par, på en enda dator, för att skapa kod och skicka den till produktion. Endast ett par integrerar kod åt gången.
  • integrera och begå kod i arkivet några timmar.

kunden bör vara tillgänglig, helst på plats, under hela denna process så att de kan svara på frågor och fastställa krav.

testa

teamet utför enhetstester och åtgärdar fel innan koden kan släppas. De kör också acceptanstester ofta.,

när du ska använda extrem programmering

fortfarande osäker på om XP passar ditt lags behov, även efter att ha läst dess regler och värden? Extrem programmering kan fungera bra för lag som:

  • förväntar sig att systemets funktionalitet ändras några månader.
  • Upplev ständigt förändrade krav eller arbeta med kunder som inte är säkra på vad de vill att systemet ska göra.
  • vill minska projektrisken, särskilt kring snäva tidsfrister.
  • inkluderar ett litet antal programmerare (mellan 2 och 12 är att föredra).
  • kan arbeta nära kunderna.,
  • kan skapa automatiserade enheter och funktionstester.

om samarbete och kontinuerlig utveckling är prioriteringar för ditt team, kan extrem programmering vara värt ett försök. Eftersom denna mycket anpassningsbara modell kräver kontinuerlig feedback från kunder, förutser fel på vägen och kräver att utvecklare arbetar tillsammans, säkerställer XP inte bara en hälsoproduktfrisättning utan har också oavsiktligt förbättrad produktivitet för utvecklingsteam överallt.,

om du väljer att använda XP, försök dokumentera dina användarhistorier, släpp scheman, CRC-kort och systemdokumentation visuellt i Lucidchart. Registrera dig för ditt gratis konto idag.


Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *