Je bent bekend met programmeren, maar Extreme Programming (afgekort XP) is voor jou nog een beetje een raadsel.
Laat je niet afschrikken door de naam, je loopt het risico nuttige informatie te missen.
In dit artikel gaan we alles behandelen wat u moet weten over extreem programmeren, zodat u het in uw voordeel kunt gebruiken.
Extreme programmering is een methodologie voor softwareontwikkeling die deel uitmaakt van wat gezamenlijk bekend staat als agile-methodologieën. XP is gebouwd op waarden, principes en praktijken, en het doel is om kleine en middelgrote teams in staat te stellen hoogwaardige software te produceren en zich aan te passen aan steeds veranderende en evoluerende vereisten.
Wat XP onderscheidt van andere agile methodologieën, is dat XP de nadruk legt op de technische aspecten van softwareontwikkeling. Extreme programmering is nauwkeurig over hoe ingenieurs werken, aangezien het volgen van technische praktijken teams in staat stelt om code van hoge kwaliteit in een duurzaam tempo te leveren.
Extreem programmeren is, in een notendop, tot het uiterste doorgevoerde good practices. Omdat paarprogrammering goed is, laten we het de hele tijd doen. Omdat vooraf testen goed is, testen we voordat er zelfs maar productiecode is geschreven.
XP is, in tegenstelling tot andere methodologieën, gebaseerd op waarden en principes die belangrijk en relevant zijn in termen van technische praktijken.
Waarden geven teams een doel. Ze fungeren als een "noordster" om uw beslissingen op hoog niveau te begeleiden. De waarden zijn echter abstract en te vaag voor specifieke richtlijnen. Bijvoorbeeld: Zeggen dat je communicatie waardeert, kan tot veel verschillende resultaten leiden.
Praktijken zijn in zekere zin het tegenovergestelde van waarden. Ze zijn concreet en nuchter, defispecificeren wat er moet gebeuren. Praktijken helpen teams zichzelf verantwoordelijk te houden voor waarden. Zo bevordert de praktijk van informatiewerkplekken transparante en eenvoudige communicatie.
Principes zijn domeinspecifieke richtlijnen die de kloof tussen praktijken en waarden overbruggen.
XP-waarden: communicatie, eenvoud, feedback, moed en respect. Laten we ze allemaal in meer detail bekijken.
Het opstellen BlogInnovazione.het van het beeld alexsoft. com
Comunicazione: Gebrek aan communicatie verhindert dat kennis binnen een team stroomt. Als er een probleem is, weet iemand vaak al hoe het moet worden opgelost. Maar een gebrek aan communicatie verhindert hen om meer te weten te komen over het probleem of bij te dragen aan de oplossing ervan. Zo wordt het probleem uiteindelijk twee keer opgelost, waardoor afval ontstaat.
eenvoud: Eenvoud zegt dat je er altijd naar streeft om het eenvoudigste te doen dat werkt. Het wordt vaak verkeerd begrepen en als het eenvoudigste beschouwd, punt uit, waarbij het 'dat werkt'-gedeelte wordt genegeerd.
Het is ook essentieel om te onthouden dat eenvoud zeer contextueel is. Wat voor het ene team simpel is, is voor het andere complex en hangt volledig af van de vaardigheden, ervaring en kennis van elk team.
Feedback: Feedback in meer traditionele, trapsgewijze softwareontwikkelingsmethodologieën is vaak "too little, too late".
XP omarmt echter verandering en XP-teams streven naar tijdige en constante feedback. Als koerscorrectie nodig is, willen XPers dat zo snel mogelijk weten.
Het opstellen BlogInnovazione.het van het beeld alexsoft. com
Feedback is er in vele soorten en maten. Als je samen programmeert, zijn opmerkingen van je collega essentiële feedback. Dat geldt ook voor de mening van andere teamleden over een idee, inclusief de klant die, idealiter, lid is van het team.
Tests zijn een andere bron van waardevolle feedback die verder gaat dan testresultaten. Of het schrijven van toetsen nu makkelijk of moeilijk is, feedback ook. Als je problemen hebt met het schrijven van toetsen, is je project waarschijnlijk te complex. Luister naar feedback en stroomlijn je ontwerp.
Iets dat klinkt als een geweldig idee, werkt in de praktijk misschien niet zo goed. Daarom is voltooide code ook een bron van feedback, net als een gedistribueerd product.
Houd er ten slotte rekening mee dat er te veel feedback is. Als een team meer feedback genereert dan het aankan, kan belangrijke feedback van de radar verdwijnen. Het is dus essentieel om te vertragen en erachter te komen wat de overtollige feedback veroorzaakt en dit op te lossen.
opvrolijken: Ken Beck defimoed komt naar voren als "effectieve actie in het aangezicht van angst". Als software engineer heb je veel te vrezen en dus volop kansen om lef te tonen.
Er is moed voor nodig om de waarheid te vertellen, vooral de onaangename, zoals eerlijke schattingen. Feedback geven en ontvangen vergt ook moed. En er is moed voor nodig om niet te vervallen in de denkfout van de verzonken kosten en een falende oplossing die substantiële investeringen heeft opgeleverd, terzijde te schuiven.
vergeleken: Een fundamenteel uitgangspunt van XP is dat iedereen om zijn werk geeft. Geen enkele hoeveelheid technische uitmuntendheid kan een project redden als er geen zorg en respect is.
Elke persoon verdient waardigheid en respect, en dat geldt natuurlijk ook voor de mensen die betrokken zijn bij een softwareontwikkelingsproject. Als jij en je teamleden respect hebben voor en zorg dragen voor elkaar, de klant, het project en zijn toekomstige gebruikers, profiteert iedereen
Principes bieden meer specifieke richtlijnen dan waarden. Het zijn richtlijnen die de waarden verhelderen en explicieter en minder dubbelzinnig maken.
Het opstellen BlogInnovazione.het van het beeld alexsoft. com
Alleen al op basis van de waarde van moed zou je bijvoorbeeld kunnen concluderen dat het raadzaam is om meteen een grote verandering in je schema door te voeren. Het Baby Steps-principe vertelt ons echter dat grote veranderingen riskant zijn. Geef dus de voorkeur aan de kleintjes.
Umanita: Mensen maken software voor mensen, een feit dat vaak over het hoofd wordt gezien. Maar rekening houdend met menselijke basisbehoeften, sterke en zwakke punten, ontstaan producten die mensen willen gebruiken. En een werkomgeving die je de mogelijkheid biedt tot voldoening en groei, het gevoel erbij te horen en basisveiligheid, is een plek waar je gemakkelijker rekening houdt met de behoeften van anderen.
economie: In XP besteden teams altijd aandacht aan de economische realiteit van softwareontwikkeling en evalueren ze voortdurend de economische risico's en projectbehoeften.
Ze zouden bijvoorbeeld gebruikersverhalen implementeren op basis van hun zakelijke waarde in plaats van technische zorgen.
Wederzijds voordeel: Na XP vermijd je oplossingen waar de ene partij van profiteert ten koste van de andere. Uitgebreide specificaties kunnen bijvoorbeeld iemand anders helpen het te begrijpen, maar het leidt u af van de implementatie ervan en vertraagt het voor uw gebruikers.
Een wederzijds voordelige oplossing is het gebruik van geautomatiseerde acceptatietesten. Krijg direct feedback over uw implementatie, uw collega's krijgen nauwkeurige specificaties in code en gebruikers krijgen eerst hun functies. Bovendien hebben jullie allemaal een vangnet tegen regressies.
Voordeel (wederzijds voordeel): Als een bepaalde oplossing op een bepaald niveau werkt, kan deze ook op een hoger of lager niveau werken. Het krijgen van vroege en constante feedback staat bijvoorbeeld in verschillende mate op het spel in XP.
verbetering: Volgens het verbeterprincipe streven teams niet naar perfectie in een eerste implementatie, maar naar een implementatie die goed genoeg is, en leren en verbeteren deze vervolgens continu met feedback van echte gebruikers.
Diversiteit: Jij en je collega's profiteren van een diversiteit aan perspectieven, vaardigheden en attitudes. Dergelijke diversiteit leidt vaak tot conflicten, maar dat is oké.
Conflicten en onenigheid zijn kansen voor het ontstaan van betere ideeën wanneer iedereen zich houdt aan de waarden van moed en respect. Moed om tegengestelde standpunten te uiten, respect om ze op een beschaafde en empathische manier te uiten. En dit alles is een effectieve communicatieoefening.
reflection: Geweldige teams reflecteren op hun werk en analyseren hoe ze beter kunnen worden. XP biedt hiervoor veel mogelijkheden. Niet alleen in de wekelijkse en driemaandelijkse cycli, maar in elke praktijk die het promoot.
Gevoelens zijn belangrijk om naast logische analyse te overwegen. Je gevoel kan je informeren voordat je ergens over kunt redeneren. En dus kan hij praten met niet-technische mensen, zij kunnen vragen stellen die geheel nieuwe mogelijkheden openen.
Stromen: Traditionele softwareontwikkelingsmethodologieën hebben verschillende fasen, die lang duren en weinig gelegenheid bieden voor feedback en koerscorrectie. In plaats daarvan vindt softwareontwikkeling in XP plaats in activiteiten die continu plaatsvinden, in een consistente "stroom" van waarde.
kansen: Problemen zijn onvermijdelijk bij softwareontwikkeling. Elk probleem is echter een kans voor verbetering. Leer ze op deze manier te bekijken en je komt veel eerder met creatieve en doelgerichte oplossingen die er ook toe dienen om herhaling te voorkomen.
Ontslag: Het principe van redundantie zegt dat als een bepaald probleem kritiek is, je veel tactieken moet gebruiken om het tegen te gaan.
Neem de gebreken. Er is geen enkele tactiek die kan voorkomen dat alle defecten aan de productie ontsnappen.
De oplossing van XP is dus om een reeks kwaliteitsmetingen op elkaar te stapelen. Paarprogrammering, testen, continue integratie. Elk een enkele verdedigingslinie, samen een vrijwel ondoordringbare muur.
mislukking: falen is geen verspilling als het zich vertaalt in kennis. Actie ondernemen en snel leren wat niet werkt, is veel productiever dan inactiviteit veroorzaakt door besluiteloosheid bij het kiezen uit vele opties.
Kwaliteit: Mensen denken vaak dat er een dilemma is tussen kwaliteit en snelheid.
Het is andersom: pushen om de kwaliteit te verbeteren, zorgt ervoor dat je sneller gaat.
Refactoring – de structuur van code veranderen zonder het gedrag ervan te veranderen – is bijvoorbeeld een praktijk die het gemakkelijker maakt om code te begrijpen en te veranderen. Als gevolg hiervan is de kans kleiner dat u codedefecten introduceert, waardoor u eerst meer waarde kunt leveren door geen bugs te hoeven repareren.
Kleine stapjes: Grote veranderingen zijn riskant. XP verkleint dat risico door veranderingen in kleine stappen door te voeren, op elk niveau.
Programmeurs schrijven code in kleine stappen met behulp van testgestuurde ontwikkeling. Ze integreren hun code meerdere keren per dag in de hoofdlijn, in plaats van slechts om de paar weken of zelfs maanden. Het project zelf vindt plaats in korte cycli in plaats van langdurige fasen.
Verantwoordelijkheid geaccepteerd: In XP moet verantwoordelijkheid worden geaccepteerd, nooit toegewezen.
Verantwoording moet gepaard gaan met de bevoegdheid om beslissingen te nemen over waarvoor u verantwoordelijk bent. Het tegenovergestelde is ook waar. Je wilt niet dat mensen beslissingen nemen als ze niet met de gevolgen ervan hoeven te leven.
Extreme programmering, die een agile methodologie is, kan worden geaccepteerd en kan worden overgenomen zonder rigide plannen te volgen. Dit is een iteratief ontwerp in plaats van een groot initieel project.
XP verschilt aanzienlijk van traditionele methodologieën, d.w.z. cascadering, waarbij langdurige fasen worden vermeden.
Hoe verschilt XP van andere agile methodieken?
Extreem programmeren heeft van nature veel gemeen met andere agile-methodologieën, maar is ook uniek onder hen.
De meeste andere ontwikkelingsmethodologieën zeggen niet veel of niets over hoe de klus moet worden geklaard. XP daarentegen is erg eigenwijs als het erop aankomt en legt grote nadruk op software-engineeringpraktijken.
Scrum is een raamwerk om teams te helpen complexe projecten op een adaptieve manier te ontwikkelen. Scrum schrijft niet voor hoe ontwikkelaars hun werk doen. XP legt, zoals gezegd, veel nadruk op goede programmeerpraktijken.
Het opstellen BlogInnovazione.nl Afbeelding netto oplossingen
XP gaat natuurlijk ook over programmeren. Scrum daarentegen kan worden toegepast op elk project dat baat heeft bij een iteratieve aanpak.
XP accepteert wijzigingen in de componenten. Teams worden gemachtigd en zelfs aangemoedigd om praktijken aan te passen op basis van hun specifieke behoeften. De Scrum Guide daarentegen is stellig: "Hoewel slechts delen van Scrum kunnen worden geïmplementeerd, is het resultaat geen Scrum."
Scrum is ook een raamwerk dat moet worden aangevuld met methodologieën en praktijken om de klus te klaren.
Dit betekent dat werken in extreem programmeren en Scrum sterk wordt aanbevolen.
Volgens Kent Beck moet een volwassen XP-team geen starre rollen toewijzen, maar erkennen dat rollen nuttig kunnen zijn voor beginnende teams totdat ze langzamer gaan werken of samenwerking bemoeilijken.
Laten we eens kijken naar enkele sleutelrollen:
Dit zijn de praktijken die in XP zijn aangenomen. Ze zijn onderverdeeld in drie hoofdgroepen: software engineering, werkplek- en projectmanagement.
Paar programmeren: In XP schrijf je code in paren zittend op een machine. U en uw koppel praten met elkaar terwijl u de functie waaraan u werkt analyseert, implementeert en test. Pair-programmering is vooral goed in het produceren van code met minder bugs terwijl het nog steeds boeiend, leuk en vermoeiend is.
Limiet van tien minuten: Vereist Geeft 10 minuten de tijd om het hele project te bouwen, inclusief het uitvoeren van alle geautomatiseerde tests, in maximaal tien minuten. Deze limiet is om testen gestroomlijnd en effectief te houden.
Tests voor het programmeren: implementeer functies met behulp van de test-first-benadering, ook wel genoemd testgestuurde ontwikkeling (TDD). TDD bestaat uit ontwikkeling met behulp van een eenvoudige iteratieve procedure:
TDD brengt verschillende voordelen met zich mee.
Eerst feedback. Als het moeilijk is om een test te schrijven, is het ontwerp waarnaar je op zoek bent of dat je hebt geërfd waarschijnlijk te complex en moet je het vereenvoudigen.
Ten tweede stelt TDD programmeurs in staat om de code die ze schrijven te vertrouwen en creëert het een mooi looping-ritme waarbij de volgende stap altijd duidelijk is.
Last but not least zorgt het gebruik van TDD vanaf het begin voor 100% codedekking. De testsuite wordt dan echt een vangnet voor toekomstige veranderingen, moedigt code-refactoring aan en creëert een positieve cirkel van kwaliteit.
Incrementeel ontwerp: De praktijk van incrementeel ontwerp betekent dat u elke dag moet investeren in uw applicatieontwerp, op zoek naar mogelijkheden om duplicatie te verwijderen en kleine verbeteringen aan te brengen om het best mogelijke ontwerp te bereiken voor wat uw systeem vandaag nodig heeft.
Integratie continua: In XP integreert u uw werk meerdere keren per dag in de belangrijkste gedeelde repository, waardoor het volledige systeem automatisch wordt opgebouwd. Door zo vroeg en zo vaak mogelijk te integreren, worden de integratiekosten aanzienlijk verlaagd, omdat het samenvoegen en logische conflicten minder waarschijnlijk wordt. Het legt ook milieu- en verslavingsproblemen bloot.
Gedeelde code (collectief eigendom): XP promoot gedeelde code of collectief eigendom: elke ontwikkelaar is verantwoordelijk voor alle code. Het stimuleert informatie-uitwisseling, vermindert de teambusfactor en verhoogt de algehele kwaliteit van elke module als we rekening houden met het diversiteitsprincipe.
Enkele CodeBase: Single codebase wordt ook wel "trunk-based development" genoemd. Het betekent dat er maar één bron van waarheid is. Dus in plaats van je gedurende lange tijd geïsoleerd te ontwikkelen, voeg je je bijdragen vroeg en vaak samen in één enkele stream. Functievlaggen helpen uw gebruik van functies te beperken totdat ze voltooid zijn.
Dagelijkse distributie: implementatie in productie minstens één keer per dag is een logisch gevolg van continue integratie:. Tegenwoordig gaan veel teams zelfs nog verder en oefenen ze continue implementatie uit. Dat wil zeggen, wanneer iemand zich aansluit bij de hoofdlijn, wordt de applicatie ingezet voor productie.
Coderen en testen: Deze praktijk betekent dat de broncode, inclusief tests, het enige permanente artefact van een softwareproject is. Betrokkenheid bij het genereren van andere soorten artefacten, inclusief documentatie, is vaak verspillend omdat het geen echte waarde voor de klant genereert.
Als je andere artefacten of documenten nodig hebt, probeer ze dan te genereren op basis van productiecode en tests.
Oorzaak analyse: Als een defect in productie gaat, corrigeer het defect dan niet zomaar. Zorg ervoor dat je erachter komt wat de oorzaak was, waarom jij en je teamgenoten de slip niet konden voorkomen. Onderneem vervolgens stappen om ervoor te zorgen dat het niet nog een keer gebeurt.
Bij elkaar zitten: In XP werken teams het liefst samen in een open ruimte. Deze praktijk bevordert de communicatie en het gevoel bij een team te horen.
Het hele team: Iedereen die nodig is voor het slagen van het project maakt deel uit van het XP-team. Dit is zeer contextueel – voor elk team verschillend – en dynamisch, het kan binnen een team veranderen.
Informatie werkruimten: Een informatiewerkruimte gebruikt de fysieke ruimte van het team om informatie weer te geven waarmee iedereen in één oogopslag de voortgang van het project kan zien. Hoe dit wordt gedaan, kan variëren, van fysieke notities en grafieken tot screenshots met Kanban-borden en dashboards van projectmanagementsoftware.
Energiek werken: In XP werk je alleen zolang je energetisch werk kunt doen. De arbeidsduur moet worden beperkt tot maximaal 40 uur per week.
Analisi- Schrijf gebruikersvereisten in een formaat dat bekend staat als gebruikersanalyse. Een gebruikersanalyse heeft een korte, beschrijvende naam en daarnaast een korte omschrijving van wat er uitgevoerd moet worden.
Slack: Voeg bij het plannen van een cyclus kleine taken toe die het team kan laten vallen als dat nodig is. Er kunnen altijd meer verhalen worden toegevoegd als het team te veel levert.
Cycli (maandelijks en wekelijks): Ontwikkeling in XP vindt plaats in twee hoofdcycli: de wekelijkse cyclus en de maandelijkse cyclus.
Vergaderingen, cycli, geplande releases: Ontwikkeling in XP werkt in twee hoofdcycli: de wekelijkse cyclus en de driemaandelijkse cyclus. Aanvankelijk adviseerde Kent Beck een cyclus van twee weken, maar veranderde dat in de tweede editie van zijn boek.
Wekelijkse cyclus: de wekelijkse cyclus is de "puls" van een XP-project. De cyclus begint met een bijeenkomst waarin de opdrachtgever kiest welke verhalen hij gedurende de week wil creëren. Daarnaast beoordeelt het team hun werk, inclusief de voortgang van vorige week, en denkt na over manieren om hun proces te verbeteren.
Maandelijkse cyclus: Elke maand reflecteert en identificeert het team verbetermogelijkheden in hun proces. De opdrachtgever kiest één of meerdere thema's voor die maand, samen met de analyses in deze thema's.
Hoe te beginnen met extreem programmeren?
Technische vaardigheden en XP-gewoonten kunnen moeilijk te leren zijn. Sommige praktijken lijken misschien vreemd voor programmeurs die er niet aan gewend zijn.
Ercole Palmeri
Afgelopen maandag maakte de Financial Times een deal met OpenAI bekend. FT geeft licenties voor haar journalistiek van wereldklasse...
Miljoenen mensen betalen voor streamingdiensten en betalen maandelijkse abonnementskosten. De algemene mening is dat je…
Coveware by Veeam zal responsdiensten op het gebied van cyberafpersingsincidenten blijven leveren. Coveware zal forensische en herstelmogelijkheden bieden...
Voorspellend onderhoud zorgt voor een revolutie in de olie- en gassector, met een innovatieve en proactieve benadering van fabrieksbeheer.…
