Bildkälla: pixabay.com

Extrem programmering

Föreställ dig det här: Ett mjukvaruutvecklingsprojekt för en ny produkt, baserat på först-till-marknadsfördel, har precis blivit upptäckt på ditt företags radar. Traditionella metoder för extrem programmering, där klienten vet "exakt" vad de vill ha, är ute. Ditt team är litet och består av unga yrkesverksamma som troligen kommer att svara bra på en radikal projektledningsmodell. Vilka är dina alternativ?

Du kommer förmodligen att säga, Agile Project Management, naturligtvis! Men vilken metod vill du använda? Det finns flera alternativ: för det första finns det den oerhört populära Scrum: det innebär att skapa korta "sprints" baserat på kundens orderstock av uppgifter. Och så finns det Kanban, som arbetar med att optimera rörledningen för arbete. Det finns också extrem programmering, ofta förkortad till XP, som fokuserar på att förstärka de positiva aspekterna av traditionella programmeringsmodeller så att de arbetar maximalt.

Extrem programmering är en oerhört populär (även om den inte är så populär som Scrum) metod med fokus på att möta förändrade kundkrav. Det första Extreme Programming-projektet startades i mars 1996 av Kent Beck på Chrysler. I sin bok från 1999, Extreme Programming Explained: Embrace Change, detaljerade han aspekterna för mjukvaruutveckling.

Kent Beck var också pionjären inom testdriven utveckling, som satte användningsfallstest på radaren som en förbättring av hur saker gjordes då: skriva rader och kodrader och sedan testa det. Han var också en av de ursprungliga undertecknarna av Agile Manifesto, och hjälpte till att forma manifestet för att förändra hur extrem programmeringsprogramvara skrevs.

De fem värdena för Extreme Programming baserat på Explained är:

Kommunikation

Extrem programmering beror inte på omfattande dokumentation. I själva verket föreslås extrem dokumentationsdokumentation endast vid behov. Så metoden förlitar sig starkt på kommunikation mellan teammedlemmar och även med användarna.

Enkelhet

Detta är kärnan i Extreme Programming. Metodiken gynnar enkla mönster, inte att tänka för långt framåt, men fokusera på dagens krav, samtidigt som programmet i sig är tillräckligt robust för att lägga till de krav som framtiden kastar upp.

Respons

Denna väsentliga slinga för att gå fram och tillbaka skiljer agila system i allmänhet och extrem programmering i synnerhet från andra mjukvaruprojekthanteringsmetoder. Den kontinuerliga feedbacken kan fungera på olika sätt, men alla arbetar för att göra systemet starkare och mer pålitligt.

Feedback kan komma i olika smaker:

  • Från själva programmet: Koden testas kraftigt under hela projektutvecklingscykeln, så att förändringar kan implementeras av utvecklarna.
  • Från klienten: Detta är en väsentlig del av de flesta Agile-system. Kunder skriver de acceptansprov som utvecklingen bygger på, och detta utgör ryggraden i utvecklingsprocessen. Alla iterationer levereras också till klienten för periodisk feedback.
  • Från teamet: När ett nytt användningsfall / berättelse har skapats, återgår teamet omedelbart med kostnadsberäkning och tidslinjeuppskattning, vilket förstärker kraven när de uppstår. I Extreme Programming "äger" ingen person någon kod, och därför, inom extrema programmeringsteam, uppmuntras feedback på varandras kod.

Mod

Detta kan verka som ett konstigt värde i extrem programmering för mjukvaruutveckling, mer lämpad för något som armén eller marinorna! Men tänk på det: Programvaruprojekt har sedan länge fastnat av traditionella extrema programmeringsmetoder för hantering; säkra i bekvämligheten med omfattande dokumentation och hierarki som inte tillåter innovation. Detta värde exemplifierar kärnan i extrem programmering: Var redo att hoppa, utan fallskärm om det kommer till det! Titta på denna olika typ av projektledning och var redo att vara ansvarig, att avstå från hierarkin och vara ansvarig och arbeta utan att veta allt i början.

Respekt

Respekt, det femte värdet, tillkom senare och betyder respekt för andra och jaget. Det innebär också respekt för koden som skrivs och för kundens förväntningar och behov. Detta värde ligger till grund för kommunikationen mellan olika intressenter också.

Aktiviteter i ett extremt programmeringsprojekt

Extreme programmering skiljer fyra enkla aktiviteter i ett projekt. Dom är:

  • Kodning : Extrem programmering anser att detta är den viktigaste aktiviteten. "Utan kod finns det inget", säger Kent Beck, grundaren av Extreme Programming.
  • Testning : kod är bara det om inte testat. Extremprogrammering är obsessiv när det gäller testning, genom att använda enhetstester för att bekräfta att koden fungerar och klientgenererade godkännandetester för att bekräfta att koden testar vad som måste testas.
  • Lyssna: Lyssna, exemplifierad av kärnvärdet för kommunikation, är en aktivitet som kräver att utvecklarna inte bara hör klienterna utan verkligen lyssnar på vad de vill. Utveckling och affär är två olika saker och ofta misslyckas utvecklarna med att förstå affärssaken med ett visst beslut. Kundens behov, såväl som utvecklarna, utgör grunden för ”lyssnande” -aktiviteten.
  • Designing : Det kan överraska dig att i ett mjukvaruutvecklingsprojekt placeras designaktiviteten, ofta så viktig och primär, i slutet. Detta beror på att Extreme Programming medvetet vill få människor ur den ”design och utveckla” tankesätt som branschen har gett upp under många år. Det är inte för att begränsa vikten av att utforma. Snarare är bra och minimal design ett av kännetecknen för ett projekt.

Från värdena och aktiviteterna framgår de 12 principerna för Extreme Programming, som de har utformats av dess grundare, i sin bok Extreme Programming Explained.

  • Planera spelet
  • Parprogrammering
  • Testdriven utveckling
  • Hela laget
  • Fortsatt integration
  • Designförbättring
  • Små releaser
  • Kodningsstandarder
  • Äganderätt till kollektiv kod
  • Enkel design
  • Systemmetafor
  • Hållbart tempo

Några av dessa extrema programmeringsmetoder, alla kartlade till mjukvaruteknikens bästa praxis, skiljer sig från generiska Agile-metoder. Några av metoderna för extrem programmering förklaras nedan:

  1. Planera spelet

Detta är planeringsdelen av projektet, kallat ”Planeringsspel”. Det inkluderar planering för nästa iteration och frisläppande, i samråd med användaren / klienten, samt en intern planering av teamen, för de uppgifter de kommer att arbeta med.

  1. Parprogrammering

Det handlar om två personer som arbetar med en kod. En person, kallad tangentbordet, skriver in koden medan den andra, kallad bildskärmen, övervakar koden, kommenterar och förädlar den, eftersom behovet kan uppstå. De två personerna byter ofta sina roller. Detta har visat sig förbättra kodens effektivitet avsevärt. Detta kanske inte passar alla utvecklingsscenarier, och det är något du bör tänka på innan du registrerar dig för Extreme Programming.

  1. Testdriven utveckling

All kod som skrivs granskas enhetligt, dvs. varje kodkod som kan göra något testas först. Extrem programmering lägger stor vikt vid testning. Detta hjälper till att bekräfta att koden fungerar och så att den kan övervägas för att inkluderas i själva extrema programmeringsprojektet. Det är analogt med enhetstester i skolan: små uppgifter testade, så att läraren / eleven kan göra korrigeringar och inte flyter under de årliga tentamen!

  1. Designförbättring (refactoring)

XP-projekt, baserat på dess funktioner i enkelhet, syftar till att kontinuerligt förbättra den kod som skrivs. Detta innebär att hela koden (och ibland också databasen) alltid förbättras. Refactoring lägger inte till någon funktion; det förbättrar bara den befintliga koden. Gör det stramare och tydligare. Det är besläktat med att redigera ett skrivande, polera det och göra det bättre.

  1. Enkel design

I extrem programmering läggs inte till funktioner förrän det specifikt krävs. Även om koden som arbetas med för närvarande är mycket lik den som kan krävas i framtiden, tas den inte upp såvida den inte avtalas som en användarhistoria.

  1. Systemmetafor

Detta inkluderar standardisering av alla namnkonventioner så att dess syfte och funktion lätt kan avkodas. Till exempel kan operationerna eller operationerna hjälpa alla programmerare att förstå deras funktionalitet. Detta bör göras över hela det extrema programmeringsprojektet, så att det är lätt för alla att titta på koden och ändra eller bättre den, beroende på vad som är fallet.

Roller inom ett extremt programmeringsprojekt:

Liksom Scrum har Extreme Programming några specifika roller inom varje projekt. Nu behöver inte rollerna alltid utföras av distinkta människor, och en person kan ta mer än en roll.

Rollerna för extrem programmering är:

  • Kund : Självförklarande. Anledningen till projektet. Hon bestämmer vad projektet behöver göra. Hon ger användarnas berättelser.
  • Programmerare : Det här är personen som:
    • Tar de berättelser som kunden kommer på
    • Skapar programmeringsuppgifter ur berättelser
    • Implementerar användarhistorierna
    • Testar koden per enhet
  • Coach : Tränaren säkerställer generellt att projektet är på rätt spår och hoppar också in för att hjälpa när det behövs.
  • Tracker : Tracker gör specifika förfrågningar till programmerare med ett inställt intervall. Vanligtvis går han runt och kontrollerar utvecklarna hos programmerare, erbjuder hjälp vid behov på flera sätt: rulla upp ärmar och hjälper direkt med koden, berättar tränaren eller ställer in ett möte med kunden, efter behov.
  • Tester : Kör funktionella tester. Testaren kör inte enhetstester, som körs av programmerarna själva.
  • Doomsayer: Detta, som namnet antyder, liknar Black Hat i Edward De Bonos system för grupptänkande. Vem som helst kan vara en Doomsayer, som vanligtvis flaggar potentiella problem och hjälper till att hålla problem i rätt perspektiv.
  • Manager : Manageren i ett extremt programmeringsprojekt liknar en schemaläggare, säkerställer att mötena sker som planerat och ser till att besluten som tas under möten vidarebefordras till rätt person, ofta än inte, Tracker. Chefen säger emellertid inte vad de ska göra och när de ska göra det. Detta görs av kunden och / eller användarberättelserna själva.
  • Guldägare : Guldägaren är personen som finansierar projektet. Detta kan vara kunden, men inte nödvändigtvis så.

Vissa av de extrema programmeringsrollerna, som beskrivs ovan, kan kombineras, men andra kan helt klart inte.

Kunden kan till exempel inte vara programmeraren. Programmeraren och Tracker kan på liknande sätt inte framgångsrikt vara samma person.

De extrema programmeringsrollerna definieras tydligt nog så att det inte finns någon förvirring och skapas för maximal flexibilitet och effektivitet.

Nackdelar med extrem programmering:

Även om förespråkare för Extreme Programming målar en rosa bild, är faktumet att Extreme Programming, som namnet antagligen antyder, är extremt svårt att genomföra. Facetter av extrem programmering kan integreras i projekt mer framgångsrikt än att använda XP helt.

Några av negativerna till extrem programmering är:

  • Extreme programmering har visat sig vara effektivare i mindre grupper . Dess effektivitet i större grupper ifrågasätts, och ett bättre alternativ är att dela extrema programmeringsteam så att grupper blir mindre.
  • En av de viktigaste funktionerna i extrem programmering, parprogrammering fungerar inte bra i många fall . Komplex kodning kan kräva två huvuden, men inte alla uppgifter kan kräva två personer, med den andra personen en död vikt. I själva verket är parprogrammering, om en av medlemmarna inte är synkroniserad med den andra, en av de främsta orsakerna till att extrem programmering misslyckas i många fall.
  • Beroendet av kunden, till punkten att föreslå en resurs på plats från kundens sida, kan vara djupt irriterande. Det kan också leda till störningar, både verkliga och föreställda, under utvecklingen.
  • Extreme Programmerings fokus på enkelhet kan göra det mycket svårt att lägga till det nuvarande projektet, vilket innebär en högre budget för även enkla förändringar, som inte förblir enkla längre.
  • Den platta hierarkiska strukturen innebär att teamet alltid ska vara fokuserat, och i frånvaro av en chef för att korrigera olika människor är ett Extreme Programming-team helt beroende av den känslomässiga mognaden hos alla teammedlemmar, en faktor som inte alltid är tillförlitlig .

Även med dessa faktorer förblir Extreme Programming ett kraftfullt verktyg som ska användas för rätt projekt, där företag rapporterar en mångfaldig ökning av deras effektivitet efter att ha använt den extrema programmeringsprocessen. Ett utvecklarstyrt system i motsats till Scrum, som mer är ett processdrivet system, Extreme Programming, eller åtminstone delar av det, kan leda till en revolution i hur vi utvecklar extrem programmeringsprogramvara.