Afbeeldingsbron: pixabay.com

Extreem programmeren

Stel u dit eens voor: een softwareontwikkelingsproject voor een nieuw product, gebaseerd op first-to-market-voordeel, is zojuist op de radar van uw bedrijf gezien. Traditionele methoden voor extreem programmeren, waarbij de klant "precies" weet wat hij wil, zijn uit. Uw team is klein en bestaat uit jonge professionals die waarschijnlijk goed zullen reageren op een radicaal projectmanagementmodel. Welke opties heb je?

Je zult waarschijnlijk zeggen: Agile Project Management, natuurlijk! Maar welke methodiek wilt u gebruiken? Er zijn verschillende opties: ten eerste is er de enorm populaire Scrum: die bestaat uit het maken van korte "sprints" op basis van de achterstand van taken bij de klant. En dan is er Kanban, dat werkt aan het optimaliseren van de pijplijn van werk. Er is ook Extreme Programming, vaak afgekort tot XP, dat zich richt op het versterken van de positieve aspecten van traditionele programmeermodellen zodat ze optimaal kunnen werken.

Extreme programmering is een enorm populaire (hoewel niet zo populaire als Scrum) -methode gericht op het voldoen aan veranderende klantvereisten. Het eerste Extreme Programming-project werd gestart in maart 1996 door Kent Beck in Chrysler. In zijn boek 1999, Extreme Programming Explained: Embrace Change, lichtte hij de aspecten voor softwareontwikkeling toe.

Kent Beck was ook de pionier van testgestuurde ontwikkeling, die use-case testing op de radar plaatste als een verbetering van de manier waarop dingen toen werden gedaan: regels en coderegels schrijven en vervolgens testen. Hij was ook een van de oorspronkelijke ondertekenaars van het Agile Manifesto en hielp het manifest vorm te geven om de manier te veranderen waarop extreme programmeringssoftware werd geschreven.

De vijf waarden van Extreme Programming op basis van Explained zijn:

Communicatie

Extreme programmering is niet afhankelijk van uitgebreide documentatie. In feite wordt extreme programmadocumentatie alleen voorgesteld als dat nodig is. Dus de methodologie is sterk afhankelijk van communicatie tussen teamleden en ook met de gebruikers.

Eenvoud

Dit vormt de kern van Extreme Programming. De methodologie geeft de voorkeur aan eenvoudige ontwerpen, niet te ver vooruit denken in de toekomst, maar focussen op de eisen van vandaag, terwijl het programma zelf robuust genoeg wordt gemaakt om de eisen toe te voegen die de toekomst stelt.

terugkoppeling

Deze essentiële loop van heen en weer onderscheidt Agile-systemen in het algemeen en Extreme Programming in het bijzonder van andere softwareprojectmanagementmethodieken. De continue feedback kan op verschillende manieren werken, maar ze werken er allemaal aan om het systeem sterker en betrouwbaarder te maken.

Feedback kan verschillende smaken hebben:

  • Vanuit het programma zelf: Code wordt tijdens de hele projectontwikkelingscyclus krachtig getest, zodat wijzigingen door de ontwikkelaars kunnen worden doorgevoerd.
  • Van de klant: dit is een essentieel onderdeel van de meeste Agile-systemen. Klanten schrijven de acceptatietests waarop de ontwikkeling is gebaseerd en dit vormt de ruggengraat van het ontwikkelingsproces. Alle iteraties worden ook geleverd aan de klant, voor een periodieke feedback.
  • Van het team: Zodra een nieuwe use case / verhaal is gecreëerd, keert het team onmiddellijk terug met kostenberekening en tijdlijnschatting, waarbij eisen worden versterkt zodra deze zich voordoen. In Extreme Programming “bezit” niemand een code, en daarom wordt binnen extreme programmeerteams feedback op elkaars code aangemoedigd.

Moed

Dit lijkt misschien een vreemde waarde in extreme programmering voor softwareontwikkeling, meer geschikt voor zoiets als het leger of de mariniers! Denk er echter over na: softwareprojecten zijn al lange tijd vastgelopen door traditionele, extreme programmeermethoden; veilig in het comfort van uitgebreide documentatie en hiërarchie die geen innovatie toestaat. Deze waarde is een voorbeeld van de kern van Extreme Programming: wees klaar om te springen, zonder parachute als het erop aankomt! Bekijk deze andere stijl van projectmanagement, en wees klaar om verantwoordelijk te zijn, afstand te doen van de hiërarchie en verantwoordelijk te zijn en te werken zonder alles in het begin zelf te weten.

eerbied

Respect, de vijfde waarde, werd later toegevoegd en betekent respect voor anderen en het zelf. Het impliceert ook respect voor de code die wordt geschreven en voor de verwachtingen en behoeften van de klant. Deze waarde ligt ook ten grondslag aan de communicatie tussen verschillende stakeholders.

Activiteiten van een extreem programmeerproject

Extreme Programming onderscheidt vier eenvoudige activiteiten van een project. Zij zijn:

  • Codering : Extreme programmering beschouwt dit als de belangrijkste activiteit. "Zonder code is er niets", zegt Kent Beck, de oprichter van Extreme Programming.
  • Testen : Code is precies dat, tenzij getest. Extreme programmering is obsessief over testen, met behulp van unit-tests om te bevestigen dat de code werkt en door de klant gegenereerde acceptatietests om te bevestigen dat de code test wat moet worden getest.
  • Luisteren: Luisteren, geïllustreerd door de kernwaarde van communicatie, is een activiteit waarbij de ontwikkelaars niet alleen de klanten horen, maar echt luisteren naar wat ze willen. Ontwikkelen en ondernemen zijn twee verschillende dingen en vaak begrijpen ontwikkelaars de business case van een bepaalde beslissing niet. De behoeften van de klant, evenals die van de ontwikkelaars, vormen de basis van de activiteit 'luisteren'.
  • Ontwerpen : het zal je misschien verbazen dat in een softwareontwikkelingsproject de ontwerpactiviteit, vaak zo belangrijk en primair, aan het einde komt. Dit komt omdat Extreme Programming opzettelijk mensen uit de "ontwerp en ontwikkeling" -geest wil halen die de industrie al vele jaren koestert. Het is niet om het belang van ontwerpen te beperken. Integendeel, goed en minimaal ontwerp is een van de kenmerken van een project.

Uit de waarden en activiteiten komen de 12 principes van Extreme Programming, zoals bedacht door de oprichter, naar voren in zijn boek, Extreme Programming Explained.

  • Planning Game
  • Paar programmeren
  • Test gedreven ontwikkeling
  • Hele team
  • Continue integratie
  • Ontwerp verbetering
  • Kleine releases
  • Coderingsnormen
  • Collectief code-eigendom
  • Simpel ontwerp
  • Systeem Metafoor
  • Duurzaam tempo

Een paar van deze extreme programmeermethoden, allemaal gekoppeld aan de best practices van software engineering, verschillen van generieke Agile-methoden. Enkele van de praktijken van extreme programmering worden hieronder uitgelegd:

  1. Planning Game

Dit is het planningsgedeelte van het project, ook wel het "planningsspel" genoemd. Het omvat de planning voor de volgende iteratie en release, in overleg met de gebruiker / klant, evenals een interne planning van de teams met betrekking tot de taken waaraan ze zullen werken.

  1. Paar programmeren

Dit houdt in dat twee mensen aan een stuk code werken. De ene persoon, het toetsenbord genoemd, typt de code in, terwijl de andere, de monitor genoemd, toezicht houdt op de code, deze becommentarieert en verfijnt, omdat dit nodig kan zijn. De twee mensen wisselen vaak hun rollen uit. Het is bewezen dat dit de efficiëntie van code aanzienlijk verbetert. Dit is mogelijk niet geschikt voor alle ontwikkelingsscenario's en dat is iets om te overwegen voordat u zich aanmeldt voor Extreme Programming.

  1. Test gedreven ontwikkeling

Alle code die wordt geschreven, wordt per eenheid beoordeeld, dat wil zeggen dat elk stuk code dat iets kan doen eerst wordt getest. Extreme programmering legt veel nadruk op testen. Dit helpt bevestigen dat de code werkt en dat deze dan kan worden overwogen voor opname in het extreme programmeerproject zelf. Het is analoog aan unit-testen op school: kleine stukjes informatie getest, zodat de leraar / student cursuscorrecties kan aanbrengen en niet bot tijdens de jaarlijkse examens!

  1. Ontwerpverbetering (refactoring)

XP-projecten willen op basis van de eenvoud de geschreven code voortdurend verbeteren. Dit betekent dat de hele code (en soms ook de database) altijd wordt verbeterd. Refactoring voegt geen functionaliteit toe; het verbetert alleen de bestaande code. Maakt het strakker en duidelijker. Het lijkt op het bewerken van een stuk schrijven, het polijsten en het verbeteren ervan.

  1. Simpel ontwerp

In Extreme Programming worden functies niet toegevoegd totdat ze specifiek vereist zijn. Zelfs als de code waaraan momenteel wordt gewerkt erg lijkt op wat in de toekomst nodig zou kunnen zijn, wordt deze niet overgenomen tenzij het is overeengekomen als een gebruikersverhaal.

  1. Systeem Metafoor

Dit omvat de standaardisatie van alle naamgevingsconventies zodat het doel en de functie ervan gemakkelijk kan worden ontcijferd. De operaties of kunnen bijvoorbeeld elke programmeur helpen zijn functionaliteit te begrijpen. Dit moet worden gedaan in het hele extreme programmeerproject, zodat het voor iedereen gemakkelijk is om naar de code te kijken en deze te wijzigen of te verbeteren, naargelang het geval.

Rollen binnen een Extreme Programming Project:

Net als Scrum heeft Extreme Programming een paar aangewezen rollen binnen elk project. Nu hoeven de rollen niet altijd door verschillende mensen te worden uitgevoerd en kan een persoon meer dan één rol op zich nemen.

De Extreme Programming-rollen zijn:

  • Klant : Spreekt voor zich. De reden voor het project. Ze beslist wat het project moet doen. Ze biedt de gebruikersverhalen.
  • Programmeur : dit is de persoon die:
    • Neemt de verhalen die de klant verzint
    • Maakt programmeertaken uit verhalen
    • Implementeert de gebruikersverhalen
    • Test de code per eenheid
  • Coach : de coach zorgt er in het algemeen voor dat het project op schema ligt en springt ook in om te helpen wanneer dat nodig is.
  • Tracker : de Tracker doet specifieke vragen aan programmeurs met een ingesteld interval. Doorgaans controleert hij de voortgang van programmeurs en biedt hij waar nodig hulp op verschillende manieren: mouwen oprollen en direct helpen met de code, de coach op de hoogte stellen of een ontmoeting met de klant opzetten, al naar gelang de behoefte.
  • Tester : voert functionele tests uit. De tester voert geen unit-tests uit, die door de programmeurs zelf worden uitgevoerd.
  • Doomsayer: Dit is, zoals de naam al doet vermoeden, verwant aan de Black Hat in het groepsdenken van Edward De Bono. Iedereen kan een Doomsayer zijn, die meestal potentiële problemen markeert en problemen helpt in het juiste perspectief te houden.
  • Manager : de manager in een project voor extreme programmering lijkt meer op een planner, zorgt ervoor dat de vergaderingen verlopen zoals gepland en zorgt ervoor dat de beslissingen die tijdens vergaderingen worden genomen, vaker aan de juiste persoon worden doorgegeven, de Tracker. De manager vertelt mensen echter niet wat ze moeten doen en wanneer. Dit wordt gedaan door de klant en / of de gebruikersverhalen zelf.
  • Gouden eigenaar : de gouden eigenaar is de persoon die het project financiert. Dit kan de klant zijn, maar dat hoeft niet zo te zijn.

Sommige van de extreme programmeerrollen, zoals hierboven beschreven, kunnen worden gecombineerd, maar sommige duidelijk niet.

De klant kan bijvoorbeeld niet ook de programmeur zijn. De programmeur en de tracker kunnen evenmin met succes dezelfde persoon zijn.

De extreme programmeerrollen zijn duidelijk genoeg gedefinieerd zodat er geen verwarring is en gecreëerd voor maximale flexibiliteit en efficiëntie.

Nadelen van extreme programmering:

Terwijl voorstanders van Extreme Programming een rooskleurig beeld schetsen, is het feit dat Extreme Programming, zoals de naam waarschijnlijk al suggereert, uiterst moeilijk te implementeren is. Facetten van extreme programmering kunnen met succes in projecten worden opgenomen dan XP volledig overnemen.

Enkele negatieve punten van Extreme Programming zijn:

  • Extreme programmering blijkt effectiever te zijn in kleinere groepen . De efficiëntie ervan in grotere groepen wordt betwist, en een betere optie is om extreme programmeerteams op te splitsen zodat groepen kleiner zijn.
  • Een van de belangrijkste kenmerken van Extreme Programmering, paarprogrammering werkt in veel gevallen niet goed . Complexe codering vereist mogelijk twee hoofden, maar niet alle taken kunnen twee mensen vereisen, waarbij de tweede persoon een dood gewicht is. In feite is paren programmeren, als een van de leden niet synchroon loopt met de andere, een van de belangrijkste redenen waarom Extreme Programmering in veel gevallen mislukt.
  • De afhankelijkheid van de klant, tot op het punt van het suggereren van een on-site resource van de kant van de klant, kan zeer verontrustend zijn. Het kan ook leiden tot interferentie, zowel reëel als ingebeeld, tijdens de ontwikkeling.
  • De focus van Extreme Programming op eenvoud kan het erg moeilijk maken om aan het huidige project toe te voegen, wat een hoger budget voor zelfs eenvoudige wijzigingen betekent, die niet meer eenvoudig blijven.
  • De platte hiërarchische structuur betekent dat het team altijd gefocust moet zijn, en bij afwezigheid van een manager om uiteenlopende soorten mensen bijeen te drijven, is een Extreme Programming-team volledig afhankelijk van de emotionele volwassenheid van alle teamleden, een factor die niet altijd betrouwbaar is .

Zelfs met deze factoren blijft Extreme Programmering een krachtig hulpmiddel om te gebruiken voor het juiste project, waarbij bedrijven na het toepassen van het extreme programmeerproces een veel grotere efficiëntie melden. Een ontwikkelaargestuurd systeem in tegenstelling tot Scrum, dat meer een procesgestuurd systeem is, Extreme Programming, of ten minste delen ervan, kan leiden tot een revolutie in de manier waarop we extreme programmeersoftware ontwikkelen.

Categorie:

Ondernemerschapsontwikkeling