Wat is extreem programmeren? Een overzicht van XP regels en waarden

februari 16, 2021 admin 0 Comments

in de jaren negentig maakte de opkomst van het Internet een verandering in softwareontwikkeling noodzakelijk. Als het succes van een bedrijf afhankelijk was van de snelheid waarmee het bedrijf kon groeien en producten op de markt kon brengen, moesten bedrijven de levenscyclus van softwareontwikkeling drastisch verminderen.,het was in deze omgeving dat Kent Beck extreme programming (XP) creëerde, een agile Project management methodologie die frequente releases in korte ontwikkelingscycli ondersteunt om de softwarekwaliteit te verbeteren en ontwikkelaars in staat te stellen te reageren op veranderende eisen van de klant.

hoewel u sommige van deze praktijken en waarden van andere Project management methodologieën kunt herkennen, neemt XP deze praktijken naar “extreme” niveaus, zoals de naam van de methodologie al doet vermoeden., In een interview met Informit legt Kent uit:

“De eerste keer dat ik gevraagd werd om een team te leiden, vroeg ik hen om een beetje dingen te doen die ik verstandig vond, zoals testen en reviews. De tweede keer stond er veel meer op het spel. Ik vroeg het team om alle knoppen omhoog te zetten naar 10 op de dingen die ik essentieel vond en de rest weg te laten.”

Als u en uw team snel moeten vrijgeven en reageren op verzoeken van klanten, neem dan een kijkje op de waarden en regels van extreme programmering—het zou een perfecte pasvorm kunnen zijn.,

Extreme Programming (XP) Overview (klik op de afbeelding om online te wijzigen)

waarden van extreme programming methodology

XP is meer dan alleen een reeks stappen om projecten te beheren—het volgt een reeks waarden die uw team helpen sneller te werken en effectiever samen te werken.

eenvoud

Teams bereiken wat gevraagd is en niets meer. XP breekt elke stap van een groot proces in kleinere, haalbare doelen voor teamleden te bereiken.,

gestroomlijnde communicatie

Teams werken samen op elk onderdeel van het project, van het verzamelen van vereisten tot het implementeren van code, en nemen deel aan dagelijkse standup vergaderingen om alle teamleden op de hoogte te houden. Eventuele zorgen of problemen worden onmiddellijk aangepakt.

consistente, constructieve feedback

In XP passen teams hun proces aan op het project en de behoeften van de klant, niet andersom. Het team moet hun software vroeg en vaak demonstreren, zodat ze feedback van de klant kunnen verzamelen en de nodige wijzigingen kunnen aanbrengen.,

Respect

Extreme programmering moedigt een “alles voor één en een voor allen” mentaliteit aan. Elke persoon in het team, ongeacht de hiërarchie, wordt gerespecteerd voor hun bijdragen. Het team respecteert de meningen van de klanten en vice versa.

moed

teamleden passen zich aan veranderingen aan wanneer deze zich voordoen en nemen de verantwoordelijkheid voor hun werk. Ze vertellen de waarheid over hun vooruitgang—er zijn geen “witte leugens” of excuses voor het falen om mensen zich beter te laten voelen. Er is geen reden om bang te zijn omdat niemand ooit alleen werkt.,

regels van extreme programming methodology

Don Wells publiceerde de eerste XP-regels in 1999 om beweringen tegen te gaan dat extreme programming geen activiteiten ondersteunt die nodig zijn voor softwareontwikkeling, zoals planning, beheer en ontwerpen. Van planning tot het testen van de software, volg deze basisstappen voor elke iteratie.

Planning

in deze fase vindt de UX-magie plaats., In plaats van een lange vereisten document, de klant schrijft gebruiker verhalen, die de functionaliteit van de klant zou willen zien definiëren, samen met de zakelijke waarde en prioriteit van elk van deze functies. Gebruikersverhalen hoeven niet uitputtend of overdreven technisch te zijn—ze hoeven alleen genoeg details te geven om het team te helpen bepalen hoe lang het duurt om deze functies te implementeren.

met Lucidchart kunnen klanten een basisstroomdiagram maken en eenvoudig de gewenste functionaliteit opnemen en delen.,

vanaf daar maakt het team een release schema en verdeelt het project in iteraties (een tot drie weken lang). Projectmanagers willen misschien een tijdlijn of een vereenvoudigd Gantt-diagram maken om het schema met het team te delen.

Managing

in dit stadium zal de projectmanager het team opzetten om deze methodologie te slagen. Iedereen moet samenwerken en effectief communiceren om eventuele fouten te voorkomen. Deze fase omvat:

het creëren van een open werkruimte voor uw team
het instellen van een duurzaam tempo (d.w.z., het bepalen van de juiste lengte voor iteraties)
een dagelijkse standup vergadering plannen
het meten van projectsnelheid (de hoeveelheid werk die aan uw project wordt gedaan)
werk opnieuw toewijzen om knelpunten of kennisverlies te voorkomen
de regels wijzigen als XP niet perfect werkt voor het team

ontwerpen

deze regel gaat terug naar de waarde van eenvoud: begin met het eenvoudigste ontwerp omdat het minder tijd kost om te voltooien dan de complexe oplossing. Voeg functionaliteit niet te vroeg toe. Refactor vaak om uw code schoon en beknopt te houden., Maak spike-oplossingen om oplossingen voor potentiële problemen te verkennen voordat ze uw team achter zich laten.

Kent Beck en Ward Cunningham creëerden ook class-responsibility-collaboration (CRC) kaarten om te gebruiken als onderdeel van de XP methodologie. Met deze kaarten kan het hele projectteam het systeem ontwerpen en zien hoe objecten interageren. Als u deze brainstormtool zelf wilt uitproberen, ga dan aan de slag met onze Lucidchart template.,

Class-Responsibility-Collaborator (CRC) Model (klik op de afbeelding om online te wijzigen)

codering

dan is het eindelijk tijd om code te implementeren. XP practices collectieve code eigendom: iedereen reviews code en elke ontwikkelaar kan functionaliteit toevoegen, fix bugs, of refactor. Om collectieve code-eigendom te laten werken, moet het team:

Een systeemmetafoor kiezen (gestandaardiseerd naamgevingsschema).
Oefenpaar programmeren., Teamleden werken in paren, op één computer, om code te maken en in productie te sturen. Slechts één paar integreert code tegelijk.
integreer en commit code om de paar uur in de repository.

de klant moet tijdens dit hele proces beschikbaar zijn, bij voorkeur ter plaatse, zodat hij vragen kan beantwoorden en eisen kan vaststellen.

testen

het team voert unit tests uit en repareert bugs voordat de code kan worden vrijgegeven. Ze voeren ook regelmatig acceptatietests uit.,

wanneer extreme programmering gebruiken

nog steeds niet zeker of XP zal voldoen aan de behoeften van uw team, zelfs na het lezen van de regels en waarden? Extreme programmering kan goed werken voor teams die:

verwachten dat de functionaliteit van hun systeem om de paar maanden verandert.
ervaar voortdurend veranderende eisen of werk met klanten die niet zeker weten wat ze willen dat het systeem doet.
wil projectrisico ‘ s beperken, met name rond krappe deadlines.
omvat een klein aantal programmeurs (tussen 2 en 12 verdient de voorkeur).
in staat zijn om nauw samen te werken met klanten.,
zijn in staat om geautomatiseerde unit-en functionele tests te maken.

Als samenwerking en continue ontwikkeling prioriteiten zijn voor uw team, kan extreme programmering het proberen waard zijn. Omdat dit zeer aanpasbare model voortdurende feedback van klanten vereist, fouten anticipeert en ontwikkelaars nodig heeft om samen te werken, zorgt XP niet alleen voor een gezondheidsproduct release, maar heeft het ook onbedoeld de productiviteit van ontwikkelingsteams overal verbeterd.,

Als u besluit XP te gebruiken, probeer dan uw gebruikersverhalen, vrijgaveschema ‘ s, CRC-kaarten en systeemdocumentatie visueel in Lucidchart te documenteren. Meld je vandaag nog aan voor je GRATIS account.