Ekstrem programmering
Forestil dig dette: Et softwareudviklingsprojekt til et nyt produkt, der er baseret på en første-til-markedsfordel, er netop blevet fundet på din virksomheds radar. Traditionelle metoder til ekstrem programmering, hvor klienten ved "nøjagtigt", hvad de ønsker, er ude. Dit team er lille og sammensat af unge fagfolk, der sandsynligvis reagerer godt på en radikal projektstyringsmodel. Hvad er dine muligheder?
Du vil sandsynligvis sige, Agile Project Management, selvfølgelig! Men hvilken metode vil du gerne bruge? Der er flere muligheder: for det ene er der den enormt populære Scrum: der involverer at skabe korte "sprints" baseret på kundens efterslæb med opgaver. Og så er der Kanban, der arbejder på at optimere rørledningen til arbejde. Der er også ekstrem programmering, ofte forkortet til XP, der fokuserer på at forstærke de positive aspekter ved traditionelle programmeringsmodeller, så de arbejder maksimalt.
Ekstrem programmering er en meget populær (skønt ikke så populær som Scrum) metodik, der fokuserer på at imødekomme ændrede klientkrav. Det første Extreme Programming-projekt blev startet i marts 1996 af Kent Beck i Chrysler. I sin bog fra 1999, Extreme Programming Explained: Embrace Change, detaljerede han aspekterne for softwareudvikling.
Kent Beck var også pioneren inden for testdrevet udvikling, der satte brug-case-test på radaren som en forbedring i forhold til, hvordan tingene blev gjort derefter: at skrive linjer og kodelinjer og derefter teste den. Han var også en af de originale underskrivere af Agile Manifesto, som hjalp med at forme manifestet til at ændre den måde, ekstrem programmeringssoftware blev skrevet på.
De fem værdier for ekstrem programmering baseret på forklaret er:
Meddelelse
Ekstrem programmering er ikke afhængig af omfattende dokumentation. Faktisk foreslås ekstrem programmeringsdokumentation kun, når det er nødvendigt. Så metoden er meget afhængig af kommunikation mellem teammedlemmer og også med brugerne.
Enkelhed
Dette er kernen i ekstrem programmering. Metodikken favoriserer enkle design, ikke ved at tænke for langt fremad, men fokusere på kravene i dag, samtidig med at programmet i sig selv er robust nok til at tilføje de krav, fremtiden kaster op.
Feedback
Denne essentielle loop af at gå frem og tilbage adskiller agile systemer generelt og ekstrem programmering i særdeleshed fra andre softwareprojekthåndteringsmetoder. Den kontinuerlige feedback kan arbejde på forskellige måder, men de arbejder alle på at gøre systemet stærkere og mere pålideligt.
Feedback kan komme i forskellige varianter:
- Fra selve programmet: Kode testes kraftigt i hele projektudviklingscyklussen, så ændringer kan implementeres af udviklerne.
- Fra klienten: Dette er en væsentlig del af de fleste Agile-systemer. Kunder skriver de acceptstest, som udviklingen er baseret på, og dette udgør rygraden i udviklingsprocessen. Alle iterationer leveres også til klienten for periodisk feedback.
- Fra teamet: Når en ny brugssag / -historie er oprettet, vender teamet straks tilbage med omkostningsberegning og tidslinjeestimering, hvilket styrker kravene, når de opstår. I ekstrem programmering “ejer” ingen personer nogen kode, og derfor inden for ekstreme programmeringshold opmuntres feedback til hinandens kode.
Mod
Dette kan virke som en mærkelig værdi i ekstrem programmering til softwareudvikling, der er mere velegnet til noget som hæren eller marinesoldaterne! Men tænk over det: Softwareprojekter er længe blevet forkælet af traditionelle ekstreme programmeringsmetoder til styring; sikre komforten ved omfattende dokumentation og hierarki, der ikke tillader innovation. Denne værdi illustrerer kernen i ekstrem programmering: Vær klar til at hoppe uden faldskærm, hvis det kommer til det! Se på denne forskellige stil af projektstyring, og vær klar til at være ansvarlig, at give afkald på hierarki og være ansvarlig og arbejde uden at vide alt i starten.
respekt
Respekt, den femte værdi, blev tilføjet senere og betyder respekt for andre og jeget. Det indebærer også respekt for koden, der skrives, og kundens forventninger og behov. Denne værdi ligger bagved kommunikationen mellem forskellige interessenter.
Aktiviteter i et ekstrem programmeringsprojekt
Ekstrem programmering adskiller fire enkle aktiviteter i et projekt. De er:
- Kodning : Ekstrem programmering betragter dette som den vigtigste aktivitet. ”Uden kode er der intet, ” siger Kent Beck, grundlæggeren af Extreme Programming.
- Testning : Kode er netop det, medmindre det testes. Ekstrem programmering er besat af testning, ved hjælp af enhedstest for at bekræfte, at koden fungerer, og klientgenererede acceptstest for at bekræfte, at koden tester, hvad der skal testes.
- Lytning: Lytning, eksemplificeret ved kerneværdien af kommunikation, er en aktivitet, der kræver, at udviklerne ikke blot hører klienterne, men virkelig lytter til, hvad de vil. Udvikling og forretning er to forskellige ting, og ofte kan udviklere ikke forstå forretningssagen om en bestemt beslutning. Kundens behov såvel som udviklerne danner grundlaget for aktiviteten ”lytter”.
- Design : Det kan overraske dig, at i et softwareudviklingsprojekt placeres designaktiviteten, ofte så vigtig og primær, i slutningen. Dette skyldes, at ekstrem programmering bevidst ønsker at få folk ud af den ”design og udvikle” tankegang, som branchen har plejet i mange år. Det er ikke for at begrænse vigtigheden af at designe. Tværtimod er et godt og minimalt design et af kendetegnene for et projekt.
Fra værdierne og aktiviteterne kommer de 12 principper for ekstrem programmering, som de er udtænkt af dens grundlægger, i sin bog Extreme Programming Explained.
- Planlægning af spil
- Parprogrammering
- Testdrevet udvikling
- Hele hold
- Kontinuerlig integration
- Designforbedring
- Små udgivelser
- Kodningsstandarder
- Ejerskab af kollektiv kode
- Enkelt design
- Systemmetafor
- Bæredygtigt tempo
Et par af disse ekstreme programmeringspraksis, alle kortlagt til software engineering's bedste praksis, er forskellige fra generiske Agile-metodologier. Nogle af fremgangsmåderne ved ekstrem programmering er forklaret nedenfor:
-
Planlægning af spil
Dette er planlægningsdelen af projektet, kaldet ”Planlægningsspil”. Det inkluderer planlægning for næste iteration og frigivelse i samråd med brugeren / klienten samt en intern planlægning af holdene med hensyn til de opgaver, de vil arbejde på.
-
Parprogrammering
Dette involverer to personer, der arbejder på et stykke kode. Én person, kaldet tastaturet, indtaster koden, mens den anden, kaldet skærmen, fører tilsyn med koden, kommenterer og raffinerer den, alt efter behov kan opstå. De to mennesker udveksler ofte deres roller. Dette har vist sig at forbedre kodens effektivitet markant. Dette er muligvis ikke egnet til alle udviklingsscenarier, og det er noget, du skal overveje, før du tilmelder dig Extreme Programming.
-
Testdrevet udvikling
Al kode, der er skrevet, gennemgås enhedsmæssigt, dvs. hvert kodestykke, der kan gøre noget, testes først. Ekstrem programmering lægger meget vægt på test. Dette hjælper med at bekræfte, at koden fungerer, og så den derefter kan overvejes til optagelse i selve det ekstreme programmeringsprojekt. Det er analogt med enhedsprøver i skolen: små oplysninger, der er testet, så læreren / eleven kan foretage kursuskorrektioner og ikke flødre under de årlige prøver!
-
Designforbedring (refactoring)
XP-projekter, der er baseret på dens funktion af enkelhed, har til formål løbende at forbedre den kode, der er skrevet. Dette betyder, at hele koden (og nogle gange også databasen) altid forbedres. Refactoring tilføjer ingen funktionalitet; det forbedrer blot den eksisterende kode. Gør det strammere og klarere. Det svarer til at redigere et stykke skrivning, polere det og gøre det bedre.
-
Enkelt design
I ekstrem programmering tilføjes funktioner først når det kræves specifikt. Selv hvis koden, der arbejdes på i øjeblikket, ligner meget, hvad der muligvis kræves i fremtiden, tages den ikke op, medmindre den er aftalt som en brugerhistorie.
-
Systemmetafor
Dette inkluderer standardisering af alle navnekonventioner, så dens formål og funktion let afkrypteres. F.eks. Kan operationerne eller operationerne hjælpe enhver programmør med at forstå deres funktionalitet. Dette skal laves på tværs af hele det ekstreme programmeringsprojekt, så det er let for enhver at se på koden og ændre eller bedre den, som det måtte være tilfældet.
Roller inden for et ekstremt programmeringsprojekt:
Ligesom Scrum har Extreme Programming et par udpegede roller inden for hvert projekt. Nu behøver rollerne ikke altid at udføres af forskellige mennesker, og en person kan påtage sig mere end en rolle.
Rollerne for ekstrem programmering er:
- Kunde : Selvforklarende. Årsagen til projektet. Hun beslutter, hvad projektet skal gøre. Hun leverer brugerhistorier.
- Programmerer : Dette er den person, der:
- Tager historierne, som kunden kommer frem til
- Opretter programmeringsopgaver ud af historier
- Implementerer brugerhistorier
- Tester koden efter enhed
- Coach : Coach sørger generelt for, at projektet er i rute, og springer også ind for at hjælpe, når det er nødvendigt.
- Tracker : Trackeren fremsætter specifikke forespørgsler til programmerere med et bestemt interval. Typisk går han rundt og kontrollerer programmernes fremskridt, tilbyder hjælp, hvor det er nødvendigt på flere måder: at rulle ærmer op og hjælpe direkte med koden, fortælle Coach eller oprette et møde med kunden, alt efter behov.
- Tester : Kører funktionelle tests. Testeren kører ikke enhedsforsøg, der køres af programmererne selv.
- Doomsayer: Dette, som navnet antyder, svarer til Black Hat i Edward De Bonos system for gruppetænkning. Enhver kan være en Doomsayer, der typisk markerer potentielle problemer og hjælper med at holde problemer i det rigtige perspektiv.
- Manager : Manageren i et ekstremprogrammeringsprojekt ligner mere en planlægger, der sikrer, at møderne forekommer som planlagt, og sikrer, at de beslutninger, der tages under møder, videresendes til den rette person, oftere end ikke, Tracker. Manageren fortæller imidlertid ikke folk, hvad de skal gøre, og hvornår de skal gøre det. Dette gøres af kunden og / eller brugerhistorierne selv.
- Guldsejer : Guldsejeren er den person, der finansierer projektet. Dette kan være kunden, men ikke nødvendigvis det.
Nogle af de ekstreme programmeringsroller, som beskrevet ovenfor, kan kombineres, men andre kan det klart ikke.
Kunden kan for eksempel ikke være programmereren. Programmeringen og Tracker kan på lignende måde ikke være den samme person.
De ekstreme programmeringsroller defineres klart nok, så der ikke er nogen forvirring, og skabes for maksimal fleksibilitet og effektivitet.
Ulemper ved ekstrem programmering:
Mens tilhængere af ekstrem programmering maler et rosenrødt billede, er kendsgerningen, at ekstrem programmering, som navnet sandsynligvis antyder, er ekstremt vanskeligt at gennemføre. Facetter af ekstrem programmering kan integreres i projekter mere vellykket end ved at vedtage XP fuldstændigt.
Nogle af negativerne ved ekstrem programmering er:
- Ekstreme programmeringer viser sig at være mere effektive i mindre grupper . Dets effektivitet i større grupper bestrides, og en bedre mulighed er at opdele ekstreme programmeringsteam, så grupper er mindre.
- En af nøglefunktionerne i ekstrem programmering, parprogrammering fungerer ikke godt i mange tilfælde . Kompleks kodning kræver muligvis to hoveder, men ikke alle opgaver kræver muligvis to personer, hvor den anden person er en død vægt. Faktisk er parprogrammering, hvis et af medlemmene ikke er synkroniseret med det andet, en af hovedårsagerne til, at ekstrem programmering mislykkes i mange tilfælde.
- Afhængigheden af kunden, til det punkt at foreslå en ressource på stedet fra kundens side, kan være dybt nervøs. Det kan også føre til interferens, både reel og forestillet, under udvikling.
- Ekstreme programmerings fokus på enkelhed kan gøre det meget vanskeligt at tilføje det aktuelle projekt, hvilket betyder et højere budget for endda enkle ændringer, som ikke forbliver enkle mere.
- Den flade hierarkiske struktur betyder, at teamet altid skal være fokuseret, og i mangel af en manager til at korralere forskellige mennesker, er et ekstremt programmeringshold helt afhængigt af den følelsesmæssige modenhed hos alle teammedlemmer, en faktor, der ikke altid er pålidelig .
Selv med disse faktorer forbliver ekstrem programmering et kraftfuldt værktøj, der skal bruges til det rigtige projekt, hvor virksomheder rapporterer om en mangfoldig stigning i deres effektivitet efter vedtagelsen af den ekstreme programmeringsproces. Et udviklerdrevet system i modsætning til Scrum, der mere er et procesdrevet system, ekstrem programmering eller i det mindste dele af det, kan føre til en revolution i den måde, vi udvikler ekstrem programmeringssoftware på.