Hvad er ekstrem programmering? En oversigt over Rulesp-regler og værdier

Tilbage i 1990 ‘ erne krævede stigningen af internettet en ændring i Soft .areudvikling. Hvis en virksomheds succes afhang af den hastighed, hvormed virksomheden kunne vokse og bringe produkter på markedet, var virksomhederne nødt til dramatisk at reducere soft .areudviklingens livscyklus.,

Det var i dette miljø, at Kent Beck skabt extreme programming (XP), en ” agile project management metoder, der understøtter hyppige udgivelser i korte udviklingsforløb til at forbedre software-kvalitet og giver udviklere mulighed for at reagere på ændringer i kundernes krav.

selvom du måske genkender nogle af disse metoder og værdier fra andre projektstyringsmetoder, tagerpp disse metoder til “ekstreme” niveauer, som metodens navn antyder., I et intervie.med Informit forklarer Kent:

“første gang jeg blev bedt om at lede et hold, bad jeg dem om at gøre lidt af de ting, jeg troede var fornuftige, som test og anmeldelser. Anden gang var der meget mere på linjen. Jeg … bad holdet om at skrue alle drejeknapperne op til 10 på de ting, jeg troede var vigtige, og udelade alt andet.”

Hvis du og dit team har brug for hurtigt at frigive og svare på kundeanmodninger, skal du kigge på værdierne og reglerne for ekstrem programmering—det kan være en perfekt pasform.,

Værdier af extreme programming metoden

XP er mere end blot en række skridt til at styre projekter—det følger et sæt af værdier, der vil hjælpe dit team med at arbejde hurtigere og samarbejde mere effektivt.

enkelhed

hold udfører det, der er blevet bedt om, og intet mere. XP nedbryder hvert trin i en større proces i mindre, opnåelige mål for teammedlemmer at opnå.,

strømlinet kommunikation

Teams arbejder sammen på alle dele af projektet, fra indsamling af krav til implementering af kode og deltager i daglige standup-møder for at holde alle teammedlemmer opdaterede. Eventuelle bekymringer eller problemer behandles straks.

konsekvent, konstruktiv feedback

i inp tilpasser teams deres proces til projektet og kundernes behov, ikke omvendt. Holdet skal demonstrere deres soft .are tidligt og ofte, så de kan samle feedback fra kunden og foretage de nødvendige ændringer.,

respekt

ekstrem programmering tilskynder til en “alt for en og en for alle” mentalitet. Hver person på holdet, uanset hierarki, respekteres for deres bidrag. Holdet respekterer kundernes meninger og vice versa.

mod

teammedlemmer tilpasser sig ændringer, når de opstår, og tager ansvar for deres arbejde. De fortæller sandheden om deres fremskridt—der er ingen “hvide løgne” eller undskyldninger for manglende evne til at få folk til at føle sig bedre. Der er ingen grund til at frygte, fordi ingen nogensinde arbejder alene.,

Regler af extreme programming metoden

Don Wells offentliggjort den første XP regler i 1999 for at imødegå påstande om, at extreme programming ikke støtte til aktiviteter, som er nødvendige til udvikling af software, såsom planlægning, styring og design. Fra planlægning til test af Soft .aren skal du følge disse grundlæggende trin for hver iteration.

Planlægning

Denne fase er, hvor UX magien sker., I stedet for et langvarigt kravsdokument skriver kunden brugerhistorier, der definerer den funktionalitet, kunden gerne vil se, sammen med forretningsværdien og prioriteringen af hver af disse funktioner. Brugerhistorier behøver ikke at være udtømmende eller alt for tekniske—de behøver kun at give nok detaljer til at hjælpe teamet med at bestemme, hvor lang tid det vil tage at implementere disse funktioner.

med Lucidchart kan kunderne oprette et grundlæggende Flo .chart og nemt registrere og dele den ønskede funktionalitet.,

derfra opretter holdet en udgivelsesplan og opdeler projektet i iterationer (en til tre uger lang). Projektledere vil måske oprette en tidslinje eller et forenklet Gantt-diagram for at dele tidsplanen med teamet.

håndtering af

på dette tidspunkt vil projektlederen indstille teamet til at lykkes med denne metode. Alle har brug for at arbejde sammen og kommunikere effektivt for at undgå slipups. Dette trin indebærer:

• oprettelse af et åbent arbejdsområde for dit team
• Indstilling af et bæredygtigt tempo (dvs ., at bestemme den rigtige længde for iterationer)
• at Planlægge en daglig standup møde
• Måling af projektet velocity (den mængde arbejde, der bliver gjort på dit projekt)
• Omfordeling af arbejde for at undgå flaskehalse eller viden tab
• at Ændre reglerne, hvis XP ikke fungerer perfekt for holdet

Design

Denne regel går tilbage til værdien af enkelhed: Starte med de simpleste design, fordi det vil tage mindre tid at gennemføre end den komplekse løsning. Tilføj ikke funktionalitet tidligt. Refactor ofte for at holde din kode ren og kortfattet., Opret spike-løsninger for at udforske løsninger på potentielle problemer, før de sætter dit team bag.

Kent Beck og Wardard Cunningham oprettede også CRC-kort (class-responsibility-collaboration) til brug som en del af methodologyp-metoden. Disse kort giver hele projektteamet mulighed for at designe systemet og se, hvordan objekter interagerer. Hvis du gerne vil prøve dette brainstorming værktøj til dig selv, komme i gang med vores Lucidchart skabelon.,

Kodning

Så er tiden endelig kommer til at implementere koden. Collectivep praktiserer kollektiv kode ejerskab: alle gennemgår kode, og enhver udvikler kan tilføje funktionalitet, rette fejl eller refactor. For at kollektiv kode ejerskab skal arbejde, skal teamet:

• vælge en systemmetafor (standardiseret navneskema).
• Øv par programmering., Teammedlemmer arbejder parvis på en enkelt computer for at oprette kode og sende den til produktion. Kun et par integrerer kode ad gangen.
• Integrer og commit kode i arkivet hvert par timer.

kunden skal være tilgængelig, helst på stedet, under hele denne proces, så de kan besvare spørgsmål og etablere krav.

test

holdet udfører enhedstest og retter fejl, før koden kan frigives. De kører også accept test ofte.,

Hvornår skal du bruge e ?treme programming

er du stadig usikker på, om ?p passer til dit teams behov, selv efter at have læst dets regler og værdier? Ekstrem programmering kan fungere godt for teams, der:

• forventer, at deres systems funktionalitet ændres hvert par måneder.
• Oplev konstant skiftende krav eller arbejde med kunder, der ikke er sikre på, hvad de vil have systemet til at gøre.
• ønsker at afbøde projektets risiko, især omkring stramme frister.
• omfatter et lille antal programmører (mellem 2 og 12 er at foretrække).
• er i stand til at arbejde tæt sammen med kunderne.,
• er i stand til at skabe automatiserede enhed og funktionelle tests.

Hvis samarbejde og kontinuerlig udvikling er prioriteter for dit team, kan ekstrem programmering være et forsøg værd. Fordi denne meget tilpasningsdygtige model kræver løbende feedback fra kunder, forudser fejl undervejs og kræver, at udviklere samarbejder, sikrer .p ikke kun en sundhedsproduktfrigivelse, men har også utilsigtet forbedret produktiviteten for udviklingshold overalt.,

Hvis du beslutter dig for at bruge .p, kan du prøve at dokumentere dine brugerhistorier, udgivelsesplaner, CRC-kort og systemdokumentation visuelt i Lucidchart. Tilmeld dig din gratis konto i dag.

---