Stuur uw goede werk naar de kennisbank is eenvoudig. Gebruik onderstaand formulier

Studenten, promovendi en jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

Geplaatst op http://www.allbest.ru/

Inhoud

• Invoering
• 1. Wat is XP?
• 3.1 BasistechniekenXP
• 4. Voor- en nadelen
• 5. Gebruiksgeschiedenis
• Conclusie

Invoering

Extreme Programming, vaak afgekort tot XP, is een discipline van softwareontwikkeling en softwarebusiness die de inspanningen van beide partijen (programmeurs en zakenmensen) richt op gemeenschappelijke, haalbare doelen. Teams die XP gebruiken, produceren in een zeer snel tempo kwaliteitssoftware. De technieken waaruit de HR-discipline bestaat, zijn gekozen omdat ze gebaseerd zijn op menselijke creativiteit en de acceptatie dat mensen wispelturige en feilbare wezens zijn.

XP wordt vaak gepresenteerd als een reeks technieken, maar XP zelf is niet de eindstreep. Het is niet nodig om HR steeds beter te oefenen en te ontwikkelen om aan het einde van dit proces de langverwachte gouden ster te ontvangen. Integendeel, XP is de startlijn. XP stelt de vraag: "Hoe minimaal kunnen onze inspanningen zijn zodat we kwaliteitssoftware kunnen blijven produceren?"

Extreme Programming is een vereenvoudigde productiemethodologie voor kleine en middelgrote teams van specialisten die een softwareproduct ontwikkelen onder omstandigheden van onduidelijke of snel veranderende vereisten.

1. Wat is XP?

ExtreemMlinnenprogrammaMzwervend(Engels) Extreem Programmering, XP) is een van de flexibele softwareontwikkelingsmethoden. De auteurs van de methodologie zijn Kent Beck, Ward Cunningham, Martin Fowler en anderen.

XP is een vereenvoudigde, efficiënte, flexibele, voorspelbare, op wetenschap gebaseerde en zeer plezierige manier om software met weinig risico te ontwikkelen. HR verschilt op de volgende manieren van andere methoden:

Door extreem korte ontwikkelingscycli te gebruiken, biedt XP snelle, echte en voortdurende feedback.

XP maakt gebruik van incrementele planning, wat ertoe leidt dat er vrij snel een algemeen projectplan ontstaat, maar het is duidelijk dat dit plan gedurende de hele levensduur van het project evolueert.

XP hanteert een flexibel schema voor de implementatie van een of andere functionaliteit, waardoor beter kan worden ingespeeld op de veranderende aard van de bedrijfsvoering en de veranderende klantwensen die daarmee samenhangen.

XP is gebaseerd op geautomatiseerde tests die zijn ontwikkeld door zowel programmeurs als klanten. Dankzij deze tests is het mogelijk om het ontwikkelingsproces te monitoren, de correcte evolutie van het systeem te garanderen en eventuele defecten in het systeem onmiddellijk op te sporen.

XP is gebaseerd op mondelinge communicatie, tests en broncode. Deze drie tools worden gebruikt om informatie uit te wisselen over de structuur en het gedrag van een systeem.

XP is gebaseerd op een evoluerend ontwerpproces dat doorgaat zolang het systeem zelf bestaat.

XP is gebaseerd op nauwe interactie tussen programmeurs met de meest voorkomende vaardigheden en capaciteiten.

XP is gebaseerd op technieken die zowel de kortetermijninstincten van individuele programmeurs als de langetermijnbelangen van het hele project bevredigen.

XP is een softwareontwikkelingsdiscipline. Dit is een discipline omdat er binnen XP bepaalde dingen zijn die je moet doen als je XP gaat gebruiken. Je moet niet kiezen of je wel of niet tests schrijft, want als je dat niet doet, is de programmering die je doet niet extreem.

De XP-methodologie is ontworpen om te werken aan projecten waaraan twee tot tien programmeurs kunnen werken, die niet worden beperkt door de rigide grenzen van een bestaande computeromgeving, en waarin al het noodzakelijke testwerk binnen één dag kan worden voltooid.

2. Waar begint extreme programmering?

Waar begint extreme programmering? Vanuit het inzicht dat de typische positie van een binnenlandse softwareontwikkelaar verplicht om de ontwikkelingskosten zoveel mogelijk te verlagen. En hiervoor is het noodzakelijk om intensief met de klant samen te werken, zijn belangen te begrijpen en uiteindelijk precies te doen wat hij wil: niet meer en niet minder.

Extreme Programming is niet gebaseerd op specifieke technieken, zoals vaak wordt aangenomen, maar slechts op vier basisprincipes: communicatie, eenvoud, feedback en moed. Dit is waar je moet beginnen.

Extreme Programming biedt een kant-en-klare oplossing: houd alles zo eenvoudig mogelijk, houd de klant voor jezelf of blijf bij de klant, laat hem het ontwikkelproces actief monitoren, verwelkom verandering - en succes is vrijwel gegarandeerd.

In XP-teams wordt communicatie altijd aangemoedigd: de snelste manier om informatie en ervaringen te delen. Dit is erg belangrijk wanneer maximale ontwikkelsnelheid vereist is. Maar communicatie vereist, net als elke andere nuttige onderneming, constante ondersteuning. Daarom moet iemand uit het team de verantwoordelijkheid op zich nemen voor het monitoren van de communicatie, een zogenaamde diplomaat worden. Communicatie en de noodzaak om je handelingen aan andere teamleden uit te leggen, dwingt je om alles zo eenvoudig mogelijk te doen. Als het de eerste keer niet lukt, werken ze keer op keer aan vereenvoudiging totdat het hoofddoel is bereikt: maximale begrijpelijkheid van de code voor andere ontwikkelaars.

Wat we ook doen - een naald inrijgen of naar een feestje gaan - we streven er altijd naar een bepaald doel te bereiken. Als we merken dat we ervan afwijken, passen we ons handelen daarop aan. Stel je nu eens voor hoeveel moeilijker het is om een ​​naald in te rijgen met je ogen dicht of om je mooi te kleden zonder spiegel! Maar bij het ontwikkelen van programma's gebeurt dit vaak: we doen iets waarvan we het resultaat niet kunnen zien. Daarom is het bij extreme programmering een regel om het resultaat van je acties zo snel mogelijk te zien. Of, technisch gesproken, om zo snel mogelijk feedback te geven.

Extreme Programming vraagt ​​ons: waarom ontwikkelen we geen moed? Ze is immers heel belangrijk in haar werk. Is het zonder moed mogelijk om de verantwoordelijkheid te nemen voor het voltooien van een taak, en wel binnen een specifiek tijdsbestek? Is het zonder moed mogelijk om te beseffen dat je op een doodlopende weg bent beland, een stap terug te doen en op zoek te gaan naar een oplossing? En ten slotte: wat zal de ontwikkelaar in staat stellen zijn fout bij het beoordelen van de taak toe te geven en anderen er tijdig voor te waarschuwen, in plaats van hen pas voor een voldongen feit te stellen als alle deadlines zijn verstreken? De voordelen van moed liggen voor de hand, en elk succes, zelfs bij de kleinste taak, kan deze moed ontwikkelen.

3. XP-technieken

Extreme Programming (XP) is ontstaan ​​als een evolutionaire methode voor bottom-up softwareontwikkeling. Deze aanpak is een voorbeeld van de zogenaamde Agile Ontwikkelmethode. Tot de groep ‘live’ methoden behoren naast het extreme programmeren ook de methoden SCRUM, DSDM (Dynamic Systems Development Method, een methode voor het ontwikkelen van dynamische systemen), Feature-Driven Development (ontwikkeling gedreven door systeemfuncties), etc.

De basisprincipes van live softwareontwikkeling zijn vastgelegd in het live ontwikkelingsmanifest, dat in 2000 verscheen.

· De mensen die betrokken zijn bij een project en hun communicatie zijn belangrijker dan processen en hulpmiddelen.

· Een werkprogramma is belangrijker dan uitgebreide documentatie.

· Samenwerking met de klant is belangrijker dan het bespreken van de details van het contract.

· Het doorwerken van veranderingen is belangrijker dan vasthouden aan plannen.

‘Levende’ methoden verschenen als protest tegen de buitensporige bureaucratisering van softwareontwikkeling, de overvloed aan nevendocumenten die niet nodig zijn om het eindresultaat te verkrijgen, die moeten worden opgesteld bij de uitvoering van een project in overeenstemming met de meeste ‘zware’ processen , extra werkzaamheden ter ondersteuning van het vaste proces van de organisatie, zoals dit nodig is binnen bijvoorbeeld CMM. De meeste van dergelijke werkzaamheden en documenten houden niet direct verband met softwareontwikkeling en kwaliteitsborging, maar zijn bedoeld om te voldoen aan de formele clausules van ontwikkelingscontracten en om certificaten te verkrijgen en te bevestigen voor naleving van verschillende normen.

Met 'Live'-methoden kunnen ontwikkelaars het grootste deel van hun inspanningen richten op ontwikkelingstaken en het voldoen aan echte gebruikersbehoeften. Door het ontbreken van stapels documenten en de noodzaak om ze in samenhang te bewaren, kunt u sneller en efficiënter reageren op veranderingen in de vereisten en in de omgeving waarin het toekomstige programma zal moeten werken.

XP heeft echter zijn eigen ontwikkelingsprocesdiagram (hoewel over het algemeen het veelgebruikte begrip van het 'ontwikkelingsproces' als een tamelijk rigide actieschema in tegenspraak is met het idee van 'levendige' ontwikkeling), weergegeven in figuur 1 .

Volgens de auteurs van XP volgt deze techniek niet zozeer enkele algemene actiepatronen, maar maakt zij gebruik van een combinatie van de volgende technieken. Elke techniek is echter belangrijk, en zonder het gebruik ervan wordt ontwikkeling niet als XP beschouwd, aldus Kent Beck, een van de auteurs van deze aanpak, samen met Ward Cunningham en Ron Jeffries.

· Liveplanning (planningspel)

Zijn taak is om zo snel mogelijk te bepalen hoeveel werk er moet worden gedaan vóór de volgende softwareversie. De beslissing wordt ten eerste genomen op basis van de prioriteiten van de klant (d.w.z. zijn behoeften, wat hij nodig heeft van het systeem om zijn bedrijf succesvoller te runnen) en ten tweede op basis van technische beoordelingen (d.w.z. inschattingen van de complexiteit van ontwikkeling, compatibiliteit met andere elementen van het systeem, enz.). Plannen worden gewijzigd zodra deze afwijken van de werkelijkheid of de wensen van de klant.

Rijst.1 XP-workflowdiagram

· Veel voorkomendwijzigingVversies (kleinreleases)

De allereerste werkende versie zou zo snel mogelijk moeten verschijnen en onmiddellijk in gebruik moeten worden genomen. Daaropvolgende versies worden met vrij korte tussenpozen voorbereid (van enkele uren voor kleine wijzigingen in een klein programma tot een maand of twee voor een grote herwerking van een groot systeem). Versies (releases) van het product moeten zo vaak mogelijk in gebruik worden genomen. Het voltooien van elke versie zou zo min mogelijk tijd in beslag moeten nemen. Bovendien moet elke versie voldoende betekenisvol zijn in termen van bruikbaarheid voor het bedrijfsleven.

· Metafoor (metafoor) systemen

De metafoor moet, in een vrij eenvoudige en begrijpelijke vorm voor het team, het basismechanisme van het systeem beschrijven. Dit concept doet denken aan de architectuur, maar zou de essentie van de technische beslissingen veel eenvoudiger moeten beschrijven, in slechts een of twee zinnen.

Architectuur is een idee van de componenten van een systeem en hoe ze met elkaar verbonden zijn. Ontwikkelaars gebruiken architectuur om te begrijpen waar nieuwe functionaliteit aan het systeem wordt toegevoegd en waarmee een nieuwe component zal communiceren.

De systeemmetafoor is een analogie van wat in de meeste technieken architectuur wordt genoemd. De systeemmetafoor geeft het team een ​​idee van hoe het systeem momenteel functioneert, waar nieuwe componenten worden toegevoegd en welke vorm deze moeten aannemen.

· Eenvoudigontwerpoplossingen (eenvoudigontwerp)

Het systeem moet op elk moment zo eenvoudig mogelijk worden ontworpen. Het is niet nodig om vooraf functies toe te voegen - alleen na een expliciet verzoek daartoe. Alle onnodige complexiteit wordt verwijderd zodra deze wordt ontdekt.

XP komt voort uit het feit dat tijdens het werkproces de omstandigheden van het probleem herhaaldelijk kunnen veranderen, wat betekent dat het product dat wordt ontwikkeld niet van tevoren in zijn geheel moet worden ontworpen. Als je een systeem van begin tot eind in detail probeert te ontwerpen wanneer je voor het eerst begint, verspil je je tijd. XP gaat ervan uit dat ontwerp zo'n belangrijk proces is dat het gedurende het hele project continu moet worden uitgevoerd. Het ontwerp moet in kleine stappen worden uitgevoerd, waarbij rekening moet worden gehouden met voortdurend veranderende eisen. Op elk moment proberen we het eenvoudigste ontwerp te gebruiken dat geschikt is om het huidige probleem op te lossen. Tegelijkertijd veranderen we het naarmate de omstandigheden van het probleem veranderen.

· Ontwikkelingopbasistesten (test- geredenontwikkeling)

Ontwikkelaars schrijven eerst tests en proberen vervolgens hun modules zo te implementeren dat de tests werken. Klanten schrijven vooraf tests uit die de belangrijkste mogelijkheden van het systeem demonstreren, zodat ze kunnen zien dat het systeem echt werkt.

XP legt bijzondere nadruk op twee soorten testen:

ü testen van eenheden;

b acceptatietesten.

extreme programmeersoftware

Een ontwikkelaar kan pas zeker zijn van de juistheid van de code die hij heeft geschreven als absoluut alle tests van de modules van het systeem dat hij ontwikkelt, hebben gewerkt. Met unittests kunnen ontwikkelaars verifiëren of hun code correct werkt. Ze helpen andere ontwikkelaars ook te begrijpen waarom een ​​bepaald stuk code nodig is en hoe het functioneert. Met unittests kan de ontwikkelaar ook zonder zorgen refactoren.

Acceptatietests zorgen ervoor dat het systeem daadwerkelijk over de gestelde capaciteiten beschikt. Bovendien kunt u met acceptatietests de correcte werking van het te ontwikkelen product verifiëren.

Voor XP heeft een hogere prioriteit de aanpak die TDD (Test Driven Development) wordt genoemd. Eerst wordt een test geschreven die niet slaagt, vervolgens wordt de code zo geschreven dat de test slaagt, en pas dan wordt de code opnieuw bewerkt.

· Constanterecycling (refactoring)

Het is geen geheim dat de toevoeging van elke nieuwe functionaliteit en de groei van de code de ontwikkeling bemoeilijkt, fouten identificeert en daaropvolgende wijzigingen aanbrengt. Een van de trucs van Extreme Programming is het compenseren van toegevoegde functionaliteit met codeverbeteringen. Dit is codeverwerking of refactoring.

Programmeurs herwerken het systeem voortdurend om onnodige complexiteit te elimineren, de begrijpelijkheid van de code te vergroten, de flexibiliteit ervan te vergroten, maar zonder het gedrag ervan te veranderen, wat wordt geverifieerd door na elke herwerking van de tests uit te voeren. Tegelijkertijd wordt de voorkeur gegeven aan elegantere en flexibelere oplossingen, vergeleken met oplossingen die eenvoudigweg het gewenste resultaat opleveren. Niet-succesvol opnieuw ontworpen componenten moeten tijdens de testuitvoering worden geïdentificeerd en teruggezet naar de laatste intacte staat (samen met de componenten die ervan afhankelijk zijn).

Refactoring is een techniek om code te verbeteren zonder de functionaliteit ervan te veranderen. XP betekent dat zodra de code is geschreven, deze in de loop van een project vrijwel zeker meerdere keren zal worden herschreven. XP-ontwikkelaars herwerken meedogenloos eerder geschreven code om deze te verbeteren. Dit proces wordt refactoring genoemd. Het gebrek aan testdekking leidt tot een weigering om te refactoren vanwege de angst om het systeem te breken, wat leidt tot een geleidelijke degradatie van de code.

· Programmeringin paren (paarprogrammeren)

Ervaren ontwikkelaars hebben gemerkt dat het periodiek beoordelen van de code van anderen een positief effect heeft op de kwaliteit ervan. De meesters van Extreme Programming hebben deze aanpak ontwikkeld door code tijdens de ontwikkeling voortdurend te herzien via een techniek die pair programming wordt genoemd.

Het coderen wordt uitgevoerd door twee programmeurs op één computer. Het koppelen is willekeurig en varieert van taak tot taak. Degene in wiens handen het toetsenbord het huidige probleem op de beste manier probeert op te lossen. De tweede programmeur analyseert het werk van de eerste en geeft advies, overweegt de gevolgen van bepaalde beslissingen, nieuwe tests, minder directe maar flexibelere oplossingen. Indien nodig wordt het toetsenbord vrijelijk van de ene naar de andere overgedragen. Tijdens het werken aan een project staan ​​de paren niet vast: het wordt aanbevolen om ze door elkaar te halen, zodat elke programmeur in het team een ​​goed begrip heeft van het hele systeem. Op deze manier verbetert pair programming de samenwerking binnen het team.

· Collectiefbezitcode (collectiefeigendom)

Collectief bezit betekent dat elk teamlid verantwoordelijk is voor alle broncode. Iedereen heeft dus het recht om wijzigingen aan te brengen in elk onderdeel van het programma. Pair programming ondersteunt deze praktijk: door in verschillende paren te werken, raken alle programmeurs vertrouwd met alle delen van de systeemcode. Een belangrijk voordeel van gedeeld code-eigendom is dat het het ontwikkelingsproces versnelt, omdat als er een fout optreedt, elke programmeur deze kan repareren.

Door elke programmeur het recht te geven om de code te wijzigen, lopen we het risico dat er bugs worden geïntroduceerd door programmeurs die denken te weten wat ze doen, maar geen rekening houden met bepaalde afhankelijkheden. Goed gedefinieerde UNIT-tests lossen dit probleem op: als niet-onderzochte afhankelijkheden fouten genereren, zal de volgende reeks UNIT-tests mislukken.

· Constanteintegratie (continuintegratie)

Het systeem wordt geassembleerd en ondergaat zo vaak mogelijk een integratietest, meerdere keren per dag, telkens wanneer een paar programmeurs klaar zijn met het implementeren van de volgende functie.

Als u het systeem dat u ontwikkelt vaak genoeg integreert, kunt u de meeste problemen die ermee gepaard gaan, vermijden. Bij traditionele methoden wordt de integratie meestal helemaal aan het einde van het werk aan een product uitgevoerd, wanneer wordt aangenomen dat alle componenten van het systeem dat wordt ontwikkeld volledig klaar zijn. In XP wordt de code-integratie van het hele systeem meerdere keren per dag uitgevoerd, nadat de ontwikkelaars er zeker van zijn dat alle unit-tests correct verlopen.

Ondanks zijn eenvoud heeft deze techniek zijn eigen gebruiksregels, zoals het succes van de bestaande unit-tests voor de functionaliteit die wordt geïntegreerd, de aanwezigheid van functionele of acceptatietests en uiteraard de mogelijkheid om terug te keren naar een vorige staat. . Normaal gesproken worden de integratie en oplossing van de bijbehorende problemen op een aparte computer uitgevoerd door een aantal programmeurs. Hiermee minimaliseert u het risico op ongewenste gevolgen van de integratie.

· 40 uurwerkeneen week

Overuren maken wordt gezien als een teken van grotere problemen in het project. Overwerk gedurende 2 weken achter elkaar is niet toegestaan ​​- dit put programmeurs uit en maakt hun werk aanzienlijk minder productief.

Een mens, vooral als hij een programmeur is, is tot veel zaken in staat: tot laat op het werk blijven, in het weekend naar zijn werk gaan, vakanties opgeven, een aantal dagen wakker blijven terwijl hij achter het toetsenbord zit... Wat kunt u in het algemeen doen ter wille van uw favoriete bezigheid. Maar extreme programmering is categorisch tegen dergelijke zelfopoffering en schending van geaccepteerde arbeidswetten.

Dit wordt niet alleen gedicteerd door overwegingen van legaliteit en menselijkheid, maar in de eerste plaats door de noodzaak om de werkefficiëntie en een strikte organisatie te vergroten. Extreme programmering is immers een collectief spel, niet bedoeld voor individuen, maar voor de hele groep. En zoiets als bijvoorbeeld paarprogrammering is alleen mogelijk als de bioritmen van de deelnemers gesynchroniseerd zijn. En het is onmogelijk als de een om negen uur naar zijn werk komt, en de tweede om twaalf uur, of de een besluit dat het beter voor hem is om op zaterdag en zondag te werken, terwijl de ander ongemakkelijk is.

Maar het belangrijkste is dat iemand voldoende rust nodig heeft om zijn gezondheid en prestaties te behouden. De achturige werkdag en de vijfdaagse werkweek zijn juist ingesteld om redenen van maximale productiviteit. In veel westerse bedrijven wordt het laattijdig verlaten van het werk beschouwd als een onvermogen om goed te presteren of als een onvermogen om de werktijd goed te beheren. In de meeste gevallen is dit waar. En vanuit medisch oogpunt leiden vertragingen op het werk tot constante vermoeidheid, prikkelbaarheid en verminderde hersenactiviteit. Is dit effectief? Hoe kunnen we in zo’n team een ​​constante open communicatie tussen ontwikkelaars organiseren, en zal pair programming mogelijk zijn? Het antwoord is negatief. Normen zijn normen en moeten worden nageleefd.

· InclusieklantVteam (op- plaatsklant)

Het grootste probleem bij softwareontwikkeling is het gebrek aan kennis van programmeurs in het vakgebied dat wordt ontwikkeld. Extreme programmering heeft een uitweg uit deze situatie gevonden. Nee, dit is geen ontwikkelaarsstage bij de klant - dan wil hij niet programmeren. Integendeel, het is de participatie van de klant in het ontwikkelingsproces.

In het ontwikkelteam zit altijd een klantvertegenwoordiger die de hele werkdag bereikbaar is en alle vragen over het systeem kan beantwoorden. Zijn verantwoordelijkheid is het onmiddellijk beantwoorden van vragen van welke aard dan ook met betrekking tot de functies van het systeem, de interface ervan, de vereiste prestaties, de juiste werking van het systeem in moeilijke situaties, de noodzaak om de communicatie met andere applicaties te onderhouden, enz.

Velen twijfelen aan de mogelijkheid om de klant bij het ontwikkelingsproces te betrekken. Klanten zijn inderdaad verschillend. Mocht het niet lukken om de klant of diens vertegenwoordiger aan te trekken, dan is het soms raadzaam om tijdelijk een specialist in te huren op het vakgebied dat ontwikkeld wordt. Deze stap zal onduidelijkheden in het werk verminderen, de ontwikkelingssnelheid verhogen en het project dichter bij datgene brengen wat de klant wil ontvangen. Ook vanuit financieel oogpunt kan dit gunstig zijn: het salaris van een programmeur is immers soms aanzienlijk hoger dan het salaris van specialisten in andere branches.

· GebruikcodeHoefaciliteitencommunicatie

Code wordt gezien als het belangrijkste communicatiemiddel binnen een team. Duidelijkheid van de code is een van de belangrijkste prioriteiten. Het volgen van codeerstandaarden die deze duidelijkheid bieden, is absoluut noodzakelijk. Dergelijke standaarden moeten, naast de duidelijkheid van de code, zorgen voor minimaal taalgebruik (geen duplicatie van code en informatie) en moeten door alle teamleden worden geaccepteerd.

· Openwerkenruimte (openwerkruimte)

Het team is gehuisvest in een redelijk ruime ruimte om de communicatie te vergemakkelijken en groepsdiscussies mogelijk te maken bij het plannen en nemen van belangrijke technische beslissingen.

· WijzigingreglementDoornoodzaak (zojuistreglement)

Elk teamlid moet de genoemde regels accepteren, maar als dat nodig is, kan het team deze wijzigen als alle leden het met deze wijziging eens zijn.

Zoals uit de gebruikte technieken blijkt, is XP ontworpen voor gebruik binnen kleine teams (niet meer dan 10 programmeurs), wat wordt benadrukt door de auteurs van deze techniek. Een grotere teamgrootte vernietigt het communicatiegemak dat nodig is voor succes en maakt het onmogelijk om veel van de genoemde technieken te implementeren.

3.1 Basis XP-technieken

Twaalf basistechnieken van extreem programmeren (gebaseerd op de eerste editie van het boek Extreem programmeren uitgelegd) kan worden gecombineerd in vier groepen:

· Korte feedbackcyclus (fijne schaalfeedback)

o Testgedreven ontwikkeling

o Planningsspel

o De klant is altijd dichtbij (hele team, klant op locatie)

o Paarprogrammering

Continu proces in plaats van batchgewijs

o Continue integratie

o Refactoring (ontwerpverbetering, refactor)

o Frequente kleine releases

· Begrip gedeeld door iedereen

o Eenvoud (eenvoudig ontwerp)

o Systeemmetafoor

o Collectief code-eigendom of geselecteerde ontwerppatronen (collectief patrooneigendom)

o Codeerstandaard of codeerconventies

· Welzijn van programmeurs:

o 40-urige werkweek (Duurzaam tempo, veertigurige werkweek)

Een spelVplanning

Onze wereld is te veranderlijk en onvoorspelbaar om te vertrouwen op de constantheid van de situatie. Hetzelfde gebeurt bij de ontwikkeling van software: bij een zeldzaam systeem kun je zeggen dat de uiteindelijke vorm aan het begin van de ontwikkeling van tevoren tot in detail bekend was. Meestal komt de eetlust van de klant tijdens het eten: hij wil voortdurend iets veranderen, iets verbeteren of iets helemaal uit het systeem gooien. Dit is de variabiliteit van eisen waar iedereen zo bang voor is. Gelukkig krijgt iemand het vermogen om mogelijke opties te voorspellen en zo de situatie onder controle te houden.

Bij Extreme Programming is planning een integraal onderdeel van de ontwikkeling en wordt vanaf het begin rekening gehouden met het feit dat plannen kunnen veranderen. Het steunpunt, de techniek waarmee je de situatie kunt voorspellen en veranderingen pijnloos kunt verdragen, is het planningsspel. Tijdens een dergelijk spel kunnen bekende systeemvereisten snel worden verzameld, beoordeeld en op prioriteit worden gepland.

Net als elk ander spel heeft planning zijn deelnemers en zijn doel. De sleutelfiguur is uiteraard de klant. Hij is het die de behoefte aan deze of gene functionaliteit communiceert. Programmeurs geven een geschatte beoordeling van elke functionaliteit. De schoonheid van het planningsspel ligt in de eenheid van doel en solidariteit tussen de ontwikkelaar en de klant: bij overwinning wint iedereen, bij nederlaag verliest iedereen. Maar tegelijkertijd gaat elke deelnemer zijn eigen weg naar de overwinning: de klant selecteert de belangrijkste taken in overeenstemming met het budget, en de programmeur evalueert de taken in overeenstemming met zijn vermogen om ze te implementeren.

Bij extreem programmeren wordt ervan uitgegaan dat ontwikkelaars zelf kunnen beslissen hoe lang het duurt om hun taken te voltooien en wie van hen meer bereid is het ene probleem op te lossen en wie het andere.

In een ideale situatie zou het planningsspel tussen de klant en de programmeur elke 3-6 weken moeten worden gespeeld, totdat de volgende ontwikkelingsiteratie begint. Dit maakt het vrij eenvoudig om aanpassingen te maken op basis van de successen en mislukkingen van de vorige iteratie.

4. Voor- en nadelen

De voordelen van XP, als het geïmplementeerd kan worden, zijn een grotere flexibiliteit, de mogelijkheid om snel en nauwkeurig wijzigingen in de software aan te brengen als reactie op veranderende eisen en individuele klantwensen, de hoge kwaliteit van de resulterende code en de afwezigheid van de noodzaak om klanten overtuigen dat het resultaat aan hun verwachtingen voldoet.

De nadelen van deze aanpak zijn de onuitvoerbaarheid van voldoende grote en complexe projecten in deze stijl, het onvermogen om de timing en complexiteit van het project voor een voldoende lange termijn te plannen en de resultaten van een langetermijnproject duidelijk te voorspellen in termen van de verhouding van de kwaliteit van het resultaat en de kosten van tijd en middelen. Ook kan worden opgemerkt dat XP niet geschikt is voor die gevallen waarin mogelijke oplossingen niet direct worden gevonden op basis van eerder opgedane ervaringen, maar vooronderzoek vereisen.

5. Gebruiksgeschiedenis

XP als een reeks beschreven technieken werd voor het eerst gebruikt tijdens de werkzaamheden aan het C3-project (Chrysler Comprehensive Compensation System, ontwikkeling van een systeem voor de boekhouding van personeelsbeloningen bij Daimler Chrysler). Van de 20 deelnemers aan dit project publiceerden er 5 (inclusief de bovengenoemde 3 hoofdauteurs van XP) 3 boeken en een groot aantal artikelen gewijd aan XP tijdens het project zelf en daarna. De volgende gegevens illustreren de problemen met sommige XP-technieken wanneer ze worden toegepast op tamelijk complexe projecten.

Het project begon in januari 1995. Sinds maart 1996, na de opname van Kent Beck, wordt het uitgevoerd met XP. Tegen die tijd was het al verder gegaan dan het budget en de plannen voor een gefaseerde implementatie van functies. Het ontwikkelingsteam werd ontslagen, en ongeveer zes maanden daarna ontwikkelde het project zich behoorlijk succesvol. In augustus 1998 verscheen een prototype dat ongeveer 10.000 medewerkers zou kunnen bedienen. Oorspronkelijk werd verwacht dat het project medio 1999 zou worden voltooid en dat de resulterende software zou worden gebruikt om de voordelen voor de 87.000 werknemers van het bedrijf te beheren. Het werd in februari 2000 stopgezet na 4 jaar XP te hebben gebruikt, omdat het tijdschema en het budget niet werden gehaald. De ontwikkelde software is nooit gebruikt om met gegevens van meer dan 10.000 werknemers te werken, hoewel is aangetoond dat deze gegevens van 30.000 werknemers van het bedrijf kan verwerken. De persoon die de rol van klant speelde en deel uitmaakte van het projectteam stopte na een paar maanden van dergelijk werk, omdat hij de werkdruk niet aankon en tot het einde van het project nooit een adequate vervanger kreeg.

Conclusie

Alle bovenstaande methoden zijn niet toevallig samengebracht. Hun consistente combinatie kan het ontwikkelingsproces intellectueel weerklank geven, waardoor de kwaliteit van het product aanzienlijk wordt verhoogd en de releasetijd ervan wordt versneld. Het belangrijkste schoonheid van alle extreme programmering is de voorspelbaarheid en het minimaliseren van de ontwikkelingskosten; het aan de klant ter beschikking stellen van het product dat hij wenst te ontvangen op het moment van vrijgave; en natuurlijk communicatie en training van ontwikkelaars on-the-job.

De meningen over de voorgestelde methodologie kunnen variëren. Het is belangrijk om te begrijpen dat Extreme Programming niet tot doel heeft bestaande ontwikkelingstechnologieën te vervangen. Integendeel, XP kan een extra impuls geven aan teams die traditionele benaderingen gebruiken. Je moet hier niet naar antwoorden op al je vragen zoeken. Dit is geen programmeertechnologie, maar eerder een technologie voor het organiseren van werk, en in deze vorm heeft het recht op leven.

Geplaatst op Allbest.ru

Soortgelijke documenten

Analyse van de fasen en kenmerken van de ontwikkeling van een optimaal en functioneel ARIS-model - een softwareproduct van IDS Scheer voor het modelleren van de bedrijfsprocessen van het bedrijf. Studie van de basisconcepten, methodologieën en benaderingen van extreem programmeren.

test, toegevoegd op 06/04/2011


De belangrijkste fasen van softwareontwikkeling (softwarepakket), analyse van systeemvereisten. Werkwijze voor stapsgewijze detaillering. Programmeertalen op laag en hoog niveau (imperatief, objectgeoriënteerd, functioneel, logisch).

presentatie, toegevoegd op 13-10-2013


Ontwikkeltaal, implementatieomgeving, ontwikkeltools. Kenmerken van de virtuele omgeving voor programma-implementatie en hun overweging bij de ontwikkeling van een softwareproduct. Systeemmacro's en hun gebruik in ontwikkelingsteksten. Visuele programmeertools.

zelfstudie, toegevoegd op 26-10-2013


Het probleem van de betrouwbaarheid van software, de indicatoren en ondersteunende factoren. Methoden voor het monitoren van het ontwikkelingsproces van programma's en documentatie, foutpreventie. Fasen van het software-foutopsporingsproces, gestructureerde programmeertechnieken en het principe van modulariteit.

presentatie, toegevoegd op 30-04-2014


Machinecodes en assembler. De eerste programmeertalen op hoog niveau. FORTRAN-programmeertaal. Voor- en nadelen van ALGOL. Wetenschappelijke en boekhoudprogramma's. De basisprincipes die werden gevolgd bij het maken van de Basic-programmeertaal.

cursuswerk, toegevoegd op 21-06-2014


Het concept en het belangrijkste verschil van gedistribueerde softwareontwikkeling, de voor- en nadelen ervan. Conceptuele oplossing en keuze van het ontwikkelingstype. Kenmerken van open source-software. Het idee en de ontwikkeling van Open Source.

cursuswerk, toegevoegd op 14-12-2012


Het concept van de levenscyclus van software. Bij technische projecten worden twee soorten activiteiten onderscheiden: ontwerp en productie. De belangrijkste principes van het manifest van aanhangers van flexibele methodieken. Basisprincipes van extreem programmeren.

presentatie, toegevoegd op 14-08-2013


Internationale standaard voor de programmeertaal Pascal. Technieken van objectgeoriënteerd programmeren in Turbo Pascal. Symbolen van de taal, het alfabet. Stadia van programmaontwikkeling. Het concept van algoritmen en algoritmisering. Structuur van programma's in Pascal.

cursuswerk, toegevoegd op 28/02/2010


Moderne softwareontwikkelingstools voor besturingssystemen. Universele programmeertalen en hun vergelijking met SCADA-systemen. Softwareontwikkeling met behulp van meerkanaals meetomvormers Ш9327.

proefschrift, toegevoegd op 13-07-2011


Basistechnieken voor het werken in de Delphi-programmeeromgeving. Kenmerken van de technologie voor het maken van eenvoudige applicaties. Werken met componenten van de applicatieontwikkelomgeving. Invoer, bewerking, selectie en uitvoer van informatie. Aspecten van het gebruik van vertakkingsstructuren.

Extreme Programming of XP, eXtreme Programming is een flexibelee. Net als andere agile methodologieën heeft het specifieke tools, processen en rollen. Hoewel de auteur van XP niets nieuws heeft bedacht, maar de best practices van agile ontwikkeling heeft overgenomen en maximaal heeft versterkt. Daarom wordt programmeren extreem genoemd.

De auteur van de methode is de Amerikaanse ontwikkelaar Kent Beck. Eind jaren negentig leidde hij het Chrysler Comprehensive Compensation System-project en daar pionierde hij met de praktijk van extreem programmeren. Hij beschreef zijn ervaring en het concept dat hij creëerde in het boek Extreme Programming Exploreed, gepubliceerd in 1999. Het werd gevolgd door andere boeken waarin XP-praktijken werden beschreven. Ward Cunningham, Martin Fowler en anderen waren ook betrokken bij de ontwikkeling van de methodologie.

XP verschilt van andere agile methodieken doordat het van toepassing is alleen op het gebied van softwareontwikkeling. Het kan niet worden gebruikt in een ander bedrijf of in het dagelijks leven zoals scrum, kanban of lean.

Het doel van de XP-methodologie is om te kunnen omgaan met voortdurend veranderende eisen aan een softwareproduct en de kwaliteit van de ontwikkeling te verbeteren. Daarom is XP zeer geschikt voor complexe en onzekere projecten

De XP-methodologie is opgebouwd rond vier processen: coderen, testen, ontwerpen en luisteren. Bovendien heeft Extreme Programming de waarden eenvoud, communicatie, feedback, moed en respect.

1. Het hele team

Alle projectdeelnemers die XP gebruiken, werken als één team. Er moet een vertegenwoordiger van de klant in zitten; het is beter als dit een echte eindgebruiker van het product is die de business begrijpt. De klant stelt eisen aan het product en geeft prioriteit aan de implementatie van functionaliteit. Bedrijfsanalisten kunnen hem helpen. Aan de uitvoeringskant bestaat het team uit ontwikkelaars en testers, soms een coach die het team begeleidt, en een manager die het team van middelen voorziet.

2. Planningsspel

De planning in XP wordt in twee fasen uitgevoerd: releaseplanning en iteratieplanning.

Tijdens de releaseplanning komt het programmeerteam samen met de klant om erachter te komen welke functionaliteit hij wil hebben voor de volgende release, dat wil zeggen over 2-6 maanden. Omdat de eisen van de klant vaak vaag zijn, specificeren ontwikkelaars deze en splitsen ze op in delen, waarvan de implementatie niet meer dan een dag in beslag neemt. Het is belangrijk dat de klant de werkomgeving begrijpt waarin het product zal werken.

Taken worden op kaartjes genoteerd en de klant bepaalt de prioriteit ervan. Vervolgens schatten ontwikkelaars hoeveel tijd elke taak zal kosten. Wanneer de taken zijn beschreven en beoordeeld, beoordeelt de klant de documentatie en geeft hij toestemming om met de werkzaamheden te beginnen. Voor het succes van het project is het van cruciaal belang dat de klant en het programmeerteam op hetzelfde terrein spelen: de klant kiest de functionaliteit die echt nodig is binnen het budget, en de programmeurs vergelijken de eisen van de klant adequaat met hun mogelijkheden.

Als het team in XP geen tijd heeft om alle taken op de releasedatum te voltooien, wordt de release niet uitgesteld, maar wordt een deel van de functionaliteit die het minst belangrijk is voor de klant, geschrapt.

Er wordt een iteratieplanning uitgevoerd elke twee weken, soms meer of minder vaak. De klant is altijd aanwezig: hij bepaalt de functionaliteit voor de volgende iteratie en brengt wijzigingen aan in de producteisen.

3. Frequente versie-releases

In XP worden regelmatig versies uitgebracht, maar met weinig functionaliteit. Ten eerste is een kleine hoeveelheid functionaliteit eenvoudig te testen en te onderhouden voor de functionaliteit van het gehele systeem. Ten tweede ontvangt de klant bij elke iteratie een stukje functionaliteit dat bedrijfswaarde heeft.

4. Gebruikerstesten

De klant definieert zelf geautomatiseerde acceptatietests om de functionaliteit van de volgende producteigenschap te controleren. Het team schrijft deze tests en gebruikt ze om de voltooide code te testen.

5. Collectief code-eigendom

In XP kan elke ontwikkelaar elk stukje code bewerken, omdat... De code is niet toegewezen aan de auteur ervan. Het hele team is eigenaar van de code.

6. Continue code-integratie

Dit betekent dat nieuwe stukjes code onmiddellijk in het systeem worden ingebouwd: XP-teams uploaden om de paar uur of vaker een nieuwe build. Ten eerste kunt u direct zien welke gevolgen de laatste wijzigingen hebben voor het systeem. Als een nieuw stukje code iets kapot maakt, is het veel eenvoudiger om de fout te vinden en te herstellen dan een week later. Ten tweede werkt het team altijd met de nieuwste versie van het systeem.

7. Coderingsnormen

Wanneer iedereen eigenaar is van de code, is het belangrijk om consistente ontwerpnormen te hanteren, zodat de code eruitziet alsof deze door één professional is geschreven. U kunt uw eigen standaarden ontwikkelen of kant-en-klare standaarden overnemen.

8. Systeemmetafoor

Een systeemmetafoor is een vergelijking van het systeem met iets bekends om een ​​gedeelde visie binnen het team te creëren. Meestal wordt de systeemmetafoor bedacht door degene die de architectuur ontwerpt en het systeem als geheel voorstelt.

9. Stabiel tempo

XP-teams werken met maximale productiviteit en handhaven een gestaag tempo. Tegelijkertijd heeft extreme programmering een negatieve houding ten opzichte van overwerk en bevordert het een 40-urige werkweek.

10. Testgestuurde ontwikkeling

Een van de moeilijkste praktijken van de methodologie. In XP worden tests door de programmeurs zelf geschreven, VOORDAT de code wordt geschreven die moet worden getest. Met deze aanpak wordt elk stukje functionaliteit voor 100% afgedekt met tests. Wanneer een aantal programmeurs code naar de repository uploaden, worden er onmiddellijk unit-tests uitgevoerd. En ze zouden ALLEMAAL moeten werken. Dan weten de ontwikkelaars zeker dat ze de goede kant op gaan.

11. Programmering van paren

Stel je voor dat twee ontwikkelaars op één computer aan één productfunctionaliteit werken. Dit is pair programming, de meest controversiële XP-praktijk. Het oude gezegde ‘één hoofd is goed, twee zijn beter’ illustreert perfect de essentie van de aanpak. De beste wordt gekozen uit twee opties om een ​​probleem op te lossen, de code wordt onmiddellijk geoptimaliseerd en fouten worden onderschept voordat ze optreden. Het resultaat is dat we schone code hebben waar twee ontwikkelaars goed thuis in zijn.

12. Eenvoudig ontwerp

Eenvoudig ontwerp in XP betekent dat u alleen doet wat u nu nodig heeft, zonder toekomstige functionaliteit te raden. Eenvoudig ontwerp en continue refactoring hebben een synergetisch effect: als de code eenvoudig is, is deze gemakkelijk te optimaliseren.

13. Refactoring

Refactoring is het proces waarbij het ontwerp van een systeem voortdurend wordt verbeterd om aan nieuwe eisen te voldoen. Refactoring omvat het verwijderen van dubbele code, het vergroten van de cohesie en het verminderen van koppeling. XP omvat voortdurende refactorings, zodat het ontwerp van de code altijd eenvoudig blijft.

XP-voordelen en nadelen

De XP-methodologie veroorzaakt veel controverse en kritiek van degenen die deze nooit in hun team hebben kunnen implementeren.

De voordelen van Extreme Programming zijn zinvol als het team ten minste één van de XP-praktijken volledig benut. Dus, wat is het proberen waard:

• de klant krijgt precies het product dat hij nodig heeft, ook al kan hij zich aan het begin van de ontwikkeling zelf nog niet precies de uiteindelijke vorm ervan voorstellen
• het team brengt snel codewijzigingen door en voegt nieuwe functionaliteit toe door eenvoudig codeontwerp, frequente planning en releases
• de code werkt altijd dankzij voortdurend testen en continue integratie
• het team onderhoudt de code gemakkelijk, omdat het is geschreven volgens één enkele standaard en wordt voortdurend aangepast
• snel ontwikkelingstempo vanwege paarprogrammering, gebrek aan herwerk, aanwezigheid van de klant in het team
• hoge codekwaliteit
• de risico's die met de ontwikkeling gepaard gaan, worden verminderd, omdat de verantwoordelijkheid voor het project wordt gelijkmatig verdeeld en het vertrek/aankomst van een teamlid zal het proces niet verpesten
• De ontwikkelingskosten zijn lager omdat team is codegericht, niet documentatie en vergaderingen

Ondanks alle voordelen werkt XP niet altijd en kent het een aantal zwakke punten. Dus extreme programmering - nadelen:

• het succes van het project hangt af van de betrokkenheid van de klant, wat niet zo eenvoudig te realiseren is
• Het is moeilijk om de tijd die aan een project wordt besteed te voorspellen, omdat... in het begin kent niemand de volledige lijst met vereisten
• het succes van XP hangt sterk af van het niveau van programmeurs; de methodiek werkt alleen met senior specialisten
• Het management heeft een negatieve houding ten opzichte van pair programming en begrijpt niet waarom het voor twee programmeurs zou moeten betalen in plaats van voor één
• Regelmatige ontmoetingen met programmeurs zijn duur voor klanten
• vergt te veel cultuurverandering
• door gebrek aan structuur en documentatie niet geschikt voor grote projecten
• omdat Agile methodieken zijn functioneel georiënteerd, niet-functionele eisen aan productkwaliteit zijn lastig te beschrijven in de vorm van user stories.

XP-principes

In zijn eerste boek verwoordde Kent Beck de principes van Extreme Programming: eenvoud, communicatie, feedback en moed. In de nieuwe editie van het boek voegde hij een vijfde principe toe: respect.

1. Eenvoud

In XP begint de ontwikkeling met de eenvoudigste oplossing die voldoet aan de huidige behoefte aan functionaliteit. Teamleden houden alleen rekening met wat er nu moet gebeuren en stoppen geen functionaliteit in de code die morgen, over een maand of nooit nodig zal zijn.

2. Communicatie

In XP vindt de communicatie tussen ontwikkelaars niet plaats via documentatie, maar live. Het team communiceert actief met elkaar en met de klant.

3. Feedback

Feedback in XP wordt in drie richtingen tegelijk geïmplementeerd:

1. feedback van het systeem tijdens het voortdurend testen van modules
2. feedback van de klant, omdat hij maakt deel uit van het team en neemt deel aan het schrijven van acceptatietesten
3. feedback van het team tijdens de planning over de ontwikkeltijd.

4. Moed

Sommige extreme programmeertechnieken zijn zo ongebruikelijk dat ze moed en constante zelfbeheersing vereisen.

5. Respect

Bij Extreme Programming wordt respect gezien in termen van respect voor het team en zelfrespect. Teamleden mogen geen wijzigingen uploaden die de compilatie of unit-tests verstoren of het werk van collega's vertragen. Iedereen streeft naar code en design van de hoogste kwaliteit.

Algoritme voor het implementeren van de XP-methodiek en het werkproces

Beck Kent raadt aan om XP te implementeren om problemen in een project op te lossen. Het team kiest het meest urgente probleem en lost dit op met behulp van een van de Extreme Programming-praktijken. Ga dan verder met het volgende probleem met meer oefening. Met deze aanpak fungeren problemen als motivatie voor het gebruik van XP en krijgt het team geleidelijk alle tools van de methodologie onder de knie.

Om XP in een bestaand project te implementeren, moet u geleidelijk de technieken op de volgende gebieden onder de knie krijgen:

• testen
• ontwerp
• planning
• beheer
• ontwikkeling

Testen.

Het team maakt tests VOORDAT nieuwe code wordt geschreven en herwerkt geleidelijk oude code. Voor oude code worden tests geschreven als dat nodig is: wanneer u nieuwe functionaliteit moet toevoegen, een bug moet repareren of een deel van de oude code moet herwerken.

Ontwerp.

Het team reconstrueert geleidelijk oude code, meestal voordat nieuwe functionaliteit wordt toegevoegd. Net als bij testen wordt het refactoren van oude code alleen gedaan als dat nodig is. Tegelijkertijd moet het team langetermijndoelen formuleren voor het herwerken van de code en deze geleidelijk verwezenlijken.

Planning.

Het team moet overschakelen naar een nauwe interactie met de klant. In dit stadium is het belangrijk om hem de voordelen van het werken in hetzelfde team met ontwikkelaars over te brengen en hem in het team te integreren.

Beheer.

De rol van managers tijdens de overgang naar XP is ervoor te zorgen dat alle teamleden volgens de nieuwe regels werken. De projectmanager beslist wanneer hij afscheid neemt van een teamlid dat het werk in de nieuwe omgeving niet aankan, of wanneer hij een nieuwe zoekt en hem op de juiste manier in het werk integreert.

Ontwikkeling.

Transformaties in de ontwikkeling beginnen met de organisatie van werkstations voor het programmeren in paren. De volgende uitdaging is om meestal in paren te programmeren, hoe moeilijk het ook is voor ontwikkelaars.

Bij een project dat volgens de XP-methodiek werkt, is het proces als volgt opgebouwd:

Wie gebruikt XP

Volgens een onderzoek van Versionone uit 2016 gebruikt slechts 1% van de agile bedrijven extreme programmering in zijn pure vorm. Nog eens 10% werkt met een hybride scrum- en XP-methodiek.

Interessant is dat, hoewel XP verre van de meest gebruikelijke methodologie in zijn pure vorm is, de praktijken ervan worden gebruikt door de meerderheid van de bedrijven die aan agile methodologieën werken. Dit blijkt uit gegevens uit hetzelfde onderzoek:

Het is niet eenvoudig om informatie te vinden over teams die XP gebruiken, maar er zijn mensen die adverteren dat deze methodologie de reden is voor hun succes. Een voorbeeld van Extreme Programming is Pivotal Software, Inc.

Cruciale Software, Inc.

Een Amerikaans softwarebedrijf dat software ontwikkelt voor bedrijfsanalyses op basis van big data en adviesdiensten levert. Belangrijke producten worden gebruikt door Ford, Mercedes, BMW, GAP, Humana, grote banken, overheidsinstanties, verzekeringsmaatschappijen, enz.

Pivotal is een voorstander van agile methodologieën als de enige mogelijke in de moderne ontwikkeling. Van alle opties voor flexibele methodologieën koos het bedrijf voor XP als een win-winaanpak voor klanten en programmeerteams. Elke werkdag begint met een vergadering onderweg en eindigt precies om 18.00 uur - geen overuren. Pivotal maakt gebruik van gameplanning, pair-programmering, continu testen, continue integratie en andere XP-praktijken. Voor veel praktijken hebben zij eigen software.

Extreem programmeren,
Extreme programmering: planning,
Extreme programmering: testgestuurde ontwikkeling / Kent Beck

Over extreme programmering van de maker van de methodologie, Kent Beck. Begin met de eerste, die het XP-concept met voorbeelden beschrijft en de voordelen ervan rechtvaardigt. Later publiceerde de auteur nog een aantal boeken, waarin hij individuele XP-praktijken in detail beschreef.

Refactoring: bestaande code verbeteren / Martin Fowler

Extreme programmering: procesformulering. Van de eerste stappen tot het bittere einde / Ken Auer, Roy Miller

Omdat Extreme Programming streeft naar schone en gemakkelijk te onderhouden code, bevat de lijst met boeken alle publicaties die je leren hoe je beter kunt programmeren.

Aanvragen voor het implementeren van XP in een team

Teams die aan projecten werken met behulp van de XP-methodologie gebruiken taakmanagers en services voor agile projecten. Er zijn veel van dergelijke producten op de markt, we zullen een paar voorbeelden bekijken.

Gratis en open source taakbeheer. Belangrijkste functies: aan meerdere projecten tegelijk werken, flexibel taakbeheersysteem, Gantt-diagram, tijdcontrole, werken met documentatie, taken aanmaken via e-mail, etc.

Een eenvoudige, handige service voor het samenwerken aan projecten. Inclusief taakbeheer, message board, ingebouwde chat, bestandsopslag, kalender

Jira

Een krachtige service speciaal ontworpen voor ontwikkelaars van agile projecten. Combineert een bugtracker en een projectbeheerservice. Veel functies plus synchronisatie met andere diensten. Oplossingen voor teams van verschillende grootte.

Om aan projecten te werken. Hiermee kunt u taken instellen en het uitvoeringsproces controleren, met elkaar over een taak corresponderen, filters instellen, rekening houden met de besteding van tijd en financiën en met bestanden werken.

Uitspraak

Extreme Programming is een flexibele methodiek die zich richt op hoogwaardige, werkbare code met een eenvoudige architectuur. Het doel ervan is om de onzekerheid in projecten te verminderen en echt flexibel te reageren op veranderingen in productvereisten.

Deze methodiek is uitsluitend bedoeld voor het vakgebied software ontwikkeling en kan niet worden aangepast voor een ander bedrijf.

Dit is een van de moeilijkste methodologieën om te implementeren, omdat het maar liefst dertien praktijken omvat!

Er zijn maar weinig bedrijven die het risico lopen om met pure XP te werken, maar de ontwikkelingspraktijken ervan zijn het populairst in agile projecten. En dit is een sterk argument ten gunste van hun effectiviteit.

Niemand dwingt je om XP te implementeren op een alles-of-niets-basis. Uiteindelijk moeten agile methodologieën flexibel zijn in hun toepassing – afgestemd op de behoeften van een specifiek team en project.

Ontwikkeling (ontwikkeling gedreven door systeemfuncties), etc.

Volgens de auteurs van XP volgt deze techniek niet zozeer enkele algemene actiepatronen, maar maakt zij gebruik van een combinatie van de volgende technieken. Elke techniek is echter belangrijk, en zonder het gebruik ervan wordt ontwikkeling niet als XP beschouwd, aldus Kent Beck, een van de auteurs van deze aanpak, samen met Ward Cunningham en Ron Jeffries.

• Live planningsspel

  Zijn taak is om zo snel mogelijk te bepalen hoeveel werk er moet worden gedaan vóór de volgende softwareversie. De beslissing wordt ten eerste genomen op basis van de prioriteiten van de klant (d.w.z. zijn behoeften, wat hij nodig heeft van het systeem om zijn bedrijf succesvoller te runnen) en ten tweede op basis van technische beoordelingen (d.w.z. inschattingen van de complexiteit van ontwikkeling, compatibiliteit met andere elementen van het systeem, enz.). Plannen worden gewijzigd zodra deze afwijken van de werkelijkheid of de wensen van de klant.

• Frequente versiewijzigingen (kleine releases)

  De allereerste werkende versie zou zo snel mogelijk moeten verschijnen en onmiddellijk in gebruik moeten worden genomen. Daaropvolgende versies worden met vrij korte tussenpozen voorbereid (van enkele uren voor kleine wijzigingen in een klein programma tot een maand of twee voor een grote herwerking van een groot systeem).

• Metafoor van het systeem

  De metafoor moet, in een vrij eenvoudige en begrijpelijke vorm voor het team, het basismechanisme van het systeem beschrijven. Dit concept doet denken aan de architectuur, maar zou de essentie van de technische beslissingen veel eenvoudiger moeten beschrijven, in slechts een of twee zinnen.

• Eenvoudige ontwerpoplossingen

  Het systeem moet op elk moment zo eenvoudig mogelijk worden ontworpen. Het is niet nodig om vooraf functies toe te voegen - alleen na een expliciet verzoek daartoe. Alle onnodige complexiteit wordt verwijderd zodra deze wordt ontdekt.

• Test gedreven ontwikkeling

  Ontwikkelaars schrijven eerst tests en proberen vervolgens hun modules zo te implementeren dat de tests werken. Klanten schrijven vooraf tests uit die de belangrijkste mogelijkheden van het systeem demonstreren, zodat ze kunnen zien dat het systeem echt werkt.

• Continue refactoring

  Programmeurs herwerken het systeem voortdurend om onnodige complexiteit te elimineren, de begrijpelijkheid van de code te vergroten, de flexibiliteit ervan te vergroten, maar zonder het gedrag ervan te veranderen, wat wordt geverifieerd door na elke herwerking van de tests uit te voeren. Tegelijkertijd wordt de voorkeur gegeven aan elegantere en flexibelere oplossingen, vergeleken met oplossingen die eenvoudigweg het gewenste resultaat opleveren. Niet-succesvol opnieuw ontworpen componenten moeten tijdens de testuitvoering worden geïdentificeerd en teruggezet naar de laatste intacte staat (samen met de componenten die ervan afhankelijk zijn).

• Paar programmeren

  Het coderen wordt uitgevoerd door twee programmeurs op één computer. Het koppelen is willekeurig en varieert van taak tot taak. Degene in wiens handen het toetsenbord het huidige probleem op de beste manier probeert op te lossen. De tweede programmeur analyseert het werk van de eerste en geeft advies, overweegt de gevolgen van bepaalde beslissingen, nieuwe tests, minder directe maar flexibelere oplossingen.

• Collectief eigendom van code

  Elk teamlid kan op elk moment een deel van de code wijzigen. Niemand mag een eigen verantwoordelijkheidsgebied hebben; het hele team als geheel is verantwoordelijk voor alle code.

• Continue integratie

  Het systeem wordt geassembleerd en ondergaat zo vaak mogelijk een integratietest, meerdere keren per dag, telkens wanneer een paar programmeurs klaar zijn met het implementeren van de volgende functie.

• 40-urige werkweek

  Overuren maken wordt gezien als een teken van grotere problemen in het project. Overwerk gedurende 2 weken achter elkaar is niet toegestaan ​​- dit put programmeurs uit en maakt hun werk aanzienlijk minder productief.

• De klant opnemen in het team (klant op locatie)

  In het ontwikkelteam zit altijd een klantvertegenwoordiger die de hele werkdag bereikbaar is en alle vragen over het systeem kan beantwoorden. Zijn verantwoordelijkheid is het onmiddellijk beantwoorden van vragen van welke aard dan ook met betrekking tot de functies van het systeem, de interface ervan, de vereiste prestaties, de juiste werking van het systeem in moeilijke situaties, de noodzaak om de communicatie met andere applicaties te onderhouden, enz.

• Code gebruiken als communicatiemiddel

  Code wordt gezien als het belangrijkste communicatiemiddel binnen een team. Duidelijkheid van de code is een van de belangrijkste prioriteiten. Het volgen van codeerstandaarden die deze duidelijkheid bieden, is absoluut noodzakelijk. Dergelijke standaarden moeten, naast de duidelijkheid van de code, zorgen voor minimaal taalgebruik (geen duplicatie van code en informatie) en moeten door alle teamleden worden geaccepteerd.

• Open werkruimte

  Het team is gehuisvest in een redelijk ruime ruimte om de communicatie te vergemakkelijken en groepsdiscussies mogelijk te maken bij het plannen en nemen van belangrijke technische beslissingen.

• De regels indien nodig wijzigen (alleen regels)

  Elk teamlid moet de genoemde regels accepteren, maar als dat nodig is, kan het team deze wijzigen als alle leden het met deze wijziging eens zijn.

Zoals uit de gebruikte technieken blijkt, is XP ontworpen voor gebruik binnen kleine teams (niet meer dan 10 programmeurs), wat wordt benadrukt door de auteurs van deze techniek. Een grotere teamgrootte vernietigt het communicatiegemak dat nodig is voor succes en maakt het onmogelijk om veel van de genoemde technieken te implementeren.

De voordelen van XP, als het geïmplementeerd kan worden, zijn een grotere flexibiliteit, de mogelijkheid om snel en nauwkeurig wijzigingen in de software aan te brengen als reactie op veranderende eisen en individuele klantwensen, de hoge kwaliteit van de resulterende code en de afwezigheid van de noodzaak om klanten overtuigen dat het resultaat aan hun verwachtingen voldoet.

De nadelen van deze aanpak zijn de onuitvoerbaarheid van voldoende grote en complexe projecten in deze stijl, het onvermogen om de timing en complexiteit van het project voor een voldoende lange termijn te plannen en de resultaten van een langetermijnproject duidelijk te voorspellen in termen van de verhouding van de kwaliteit van het resultaat en de kosten van tijd en middelen. Ook kan worden opgemerkt dat XP niet geschikt is voor die gevallen waarin mogelijke oplossingen niet direct worden gevonden op basis van eerder opgedane ervaringen, maar vooronderzoek vereisen.

XP als een reeks beschreven technieken werd voor het eerst gebruikt tijdens de werkzaamheden aan het C3-project (Chrysler Comprehensive Compensation System, ontwikkeling van een systeem voor de boekhouding van personeelsbeloningen bij Daimler Chrysler). Van de 20 deelnemers aan dit project publiceerden er 5 (inclusief de bovengenoemde 3 hoofdauteurs van XP) 3 boeken en een groot aantal artikelen gewijd aan XP tijdens het project zelf en daarna. Dit project wordt in verschillende bronnen herhaaldelijk genoemd als voorbeeld van het gebruik van deze techniek. De volgende gegevens zijn samengesteld uit de genoemde artikelen, minus anekdotisch bewijs, en illustreren de problemen met sommige XP-technieken wanneer ze worden toegepast op tamelijk complexe projecten.

Het project begon in januari 1995. Sinds maart 1996, na de opname van Kent Beck, wordt het uitgevoerd met XP. Tegen die tijd was het al verder gegaan dan het budget en de plannen voor een gefaseerde implementatie van functies. Het ontwikkelingsteam werd ontslagen, en ongeveer zes maanden daarna ontwikkelde het project zich behoorlijk succesvol. In augustus 1998 verscheen een prototype dat ongeveer 10.000 medewerkers zou kunnen bedienen. Oorspronkelijk werd verwacht dat het project medio 1999 zou worden voltooid en dat de resulterende software zou worden gebruikt om de voordelen voor de 87.000 werknemers van het bedrijf te beheren. Het werd in februari 2000 stopgezet na 4 jaar XP te hebben gebruikt, omdat het tijdschema en het budget niet werden gehaald. De ontwikkelde software is nooit gebruikt om met gegevens van meer dan 10.000 werknemers te werken, hoewel is aangetoond dat deze gegevens van 30.000 werknemers van het bedrijf kan verwerken. De persoon die de rol van klant speelde en deel uitmaakte van het projectteam stopte na een paar maanden van dergelijk werk, omdat hij de werkdruk niet aankon en tot het einde van het project nooit een adequate vervanger kreeg.

Extreme Programming (XP) is een van de flexibele. De auteurs van de methodologie zijn Kent Beck, Ward Cunningham, Martin Fowler en anderen.

Planningsspel

Onze wereld is te veranderlijk en onvoorspelbaar om te vertrouwen op de constantheid van de situatie. Hetzelfde gebeurt bij de ontwikkeling van software: bij een zeldzaam systeem kun je zeggen dat de uiteindelijke vorm aan het begin van de ontwikkeling van tevoren tot in detail bekend was. Meestal komt de eetlust van de klant tijdens het eten: hij wil voortdurend iets veranderen, iets verbeteren of iets helemaal uit het systeem gooien. Dit is de variabiliteit van eisen waar iedereen zo bang voor is. Gelukkig krijgt iemand het vermogen om mogelijke opties te voorspellen en zo de situatie onder controle te houden.
Bij Extreme Programming is planning een integraal onderdeel van de ontwikkeling en wordt vanaf het begin rekening gehouden met het feit dat plannen kunnen veranderen. Het steunpunt, de techniek waarmee je de situatie kunt voorspellen en veranderingen pijnloos kunt verdragen, is het planningsspel. Tijdens een dergelijk spel kunnen bekende systeemvereisten snel worden verzameld, beoordeeld en op prioriteit worden gepland.
Net als elk ander spel heeft planning zijn deelnemers en zijn doel. De sleutelfiguur is uiteraard de klant. Hij is het die de behoefte aan deze of gene functionaliteit communiceert. Programmeurs geven een geschatte beoordeling van elke functionaliteit. De schoonheid van het planningsspel ligt in de eenheid van doel en solidariteit tussen de ontwikkelaar en de klant: bij overwinning wint iedereen, bij nederlaag verliest iedereen. Maar tegelijkertijd gaat elke deelnemer zijn eigen weg naar de overwinning: de klant selecteert de belangrijkste taken in overeenstemming met het budget, en de programmeur evalueert de taken in overeenstemming met zijn vermogen om ze te implementeren.
Bij extreem programmeren wordt ervan uitgegaan dat ontwikkelaars zelf kunnen beslissen hoe lang het duurt om hun taken te voltooien en wie van hen meer bereid is het ene probleem op te lossen en wie het andere.
In een ideale situatie zou het planningsspel tussen de klant en de programmeur elke 3-6 weken moeten worden gespeeld, totdat de volgende ontwikkelingsiteratie begint. Dit maakt het vrij eenvoudig om aanpassingen te maken op basis van de successen en mislukkingen van de vorige iteratie.

Releaseplan

Het releaseplan definieert de releasedatums en gebruikersverklaringen die in elk ervan zullen worden geïmplementeerd. Op basis hiervan kunt u formuleringen kiezen voor de volgende iteratie. Tijdens een iteratie worden acceptatietests geproduceerd en uitgevoerd binnen die iteratie en alle daaropvolgende iteraties om ervoor te zorgen dat het programma correct werkt. Het plan kan worden herzien als er aan het einde van een van de iteraties een aanzienlijke vertraging of voorsprong is.
Iteraties. Iteratie maakt het ontwikkelingsproces dynamisch. Het is niet nodig om uw softwaretaken lang van tevoren te plannen. In plaats daarvan is het beter om aan het begin van elke iteratie een planningsvergadering te houden. Het heeft geen zin om te proberen iets te implementeren dat niet gepland was. Je hebt nog tijd om deze ideeën te implementeren wanneer ze volgens het releaseplan worden vrijgegeven.
Door er een gewoonte van te maken om functionaliteit niet vooraf toe te voegen en vooruit te plannen, kunt u zich gemakkelijk aanpassen aan veranderende klantvereisten.

Iteratieplanning

Iteratieplanning begint met een bijeenkomst aan het begin van elke iteratie om een ​​stappenplan te ontwikkelen om softwareproblemen op te lossen. Elke iteratie zou één tot drie weken moeten duren. Formuleringen binnen een iteratie worden gesorteerd op volgorde van belang voor de klant. Daarnaast worden er taken toegevoegd die de acceptatietests niet konden doorstaan ​​en verder werk vereisen. Testverklaringen en resultaten worden vertaald naar softwareproblemen. Taken worden op kaarten genoteerd die een gedetailleerd iteratieplan vormen. Het duurt één tot drie dagen om elk probleem op te lossen. Taken die minder dan één dag vergen, kunnen worden gegroepeerd, en grote taken kunnen in meerdere kleinere taken worden verdeeld. Ontwikkelaars schatten taken en deadlines voor de voltooiing ervan in. Het is voor een ontwikkelaar van groot belang om de uitvoeringstijd van een taak nauwkeurig te bepalen. Het kan nodig zijn om bepaalde taal opnieuw te evalueren en het releaseplan na elke drie of vijf iteraties te herzien - dit is volkomen acceptabel. Als je de belangrijkste werkgebieden eerst uitvoert, heb je altijd tijd om het maximale uit je klanten te halen. Een iteratieve ontwikkelstijl verbetert het ontwikkelproces.

Staande vergadering

Elke ochtend wordt er een bijeenkomst gehouden om problemen en de oplossingen ervan te bespreken en de concentratie van het team te versterken. De vergadering wordt staand gehouden om langdurige discussies te vermijden die niet voor alle teamleden interessant zijn.
In een typische bijeenkomst dragen de meeste deelnemers niets bij; ze nemen alleen deel om te horen wat anderen te zeggen hebben. Er wordt een grote hoeveelheid tijd van mensen verspild aan het ontvangen van een kleine hoeveelheid communicatie. Daarom neemt het feit dat iedereen in vergaderingen aanwezig is, middelen weg van het project en ontstaat er chaos in de planning.
Dit soort communicatie vereist een staande vergadering. Het is veel beter om één korte, verplichte vergadering te houden dan vele lange vergaderingen die de meeste ontwikkelaars toch moeten bijwonen.
Als u dagelijks staande vergaderingen heeft, mogen alle andere vergaderingen alleen worden bijgewoond door de mensen die nodig zijn en iets ter tafel willen brengen. Bovendien is het zelfs mogelijk om sommige bijeenkomsten te vermijden. Omdat het aantal deelnemers beperkt is, kunnen de meeste bijeenkomsten spontaan voor een monitor worden gehouden, waar de uitwisseling van ideeën veel intenser is.
De dagelijkse ochtendvergadering is niet weer een tijdverspilling. Hiermee kunt u veel andere vergaderingen vermijden en bespaart u meer tijd dan u eraan besteedt.

Eenvoud

Een eenvoudig ontwerp kost altijd minder tijd dan een complex ontwerp. Doe dus altijd de eenvoudigste dingen die wel werken. Het is altijd sneller en goedkoper om complexe code meteen te vervangen, voordat je er veel tijd aan besteedt. Houd de zaken zo eenvoudig mogelijk zonder functionaliteit toe te voegen vóór de planning. Houd er rekening mee: een ontwerp eenvoudig houden is hard werken.

Metafoor systeem

De keuze voor een metafoorsysteem is nodig om het team binnen hetzelfde raamwerk te houden bij het benoemen van klassen en methoden. Hoe u uw objecten een naam geeft, is erg belangrijk voor het begrijpen van het algehele systeemontwerp en het hergebruik van code. Als een ontwikkelaar correct kan voorspellen hoe een bestaand object gaat heten, levert dat tijdwinst op. Gebruik een naamgevingssysteem voor uw objecten dat iedereen kan begrijpen zonder specifieke systeemkennis.

Klant op de werkplek

Het grootste probleem bij softwareontwikkeling is het gebrek aan kennis van programmeurs in het vakgebied dat wordt ontwikkeld. Extreme programmering heeft een uitweg uit deze situatie gevonden. Nee, dit is geen ontwikkelaarsstage bij de klant - dan wil hij niet programmeren. Integendeel, het is de participatie van de klant in het ontwikkelingsproces.
Kan een programmeur, zonder de essentie van het vraagstuk grondig te begrijpen en geen telepaat te zijn, raden wat de klant wil? Het antwoord ligt voor de hand. De eenvoudigste manier om dit ongemak te overwinnen – en Extreme Programming leert ons de eenvoudigste oplossingen te vinden – is door de klant een directe vraag te stellen. Een rigoureuzere aanpak vereist een uitgebreide voorafgaande analyse van het gebied dat wordt ontwikkeld. In bepaalde gevallen is dit gerechtvaardigd, ook al is het duurder. Echte ervaring met het uitvoeren van alledaagse projecten leert dat het onmogelijk is om alle vereisten vooraf te verzamelen. Bovendien zal er, zelfs als we ervan uitgaan dat alle vereisten momenteel zijn verzameld, nog steeds één knelpunt zijn: programma's worden, net als alles in de natuur, niet onmiddellijk gemaakt en in de tussentijd kunnen bedrijfsprocessen veranderen. Hiermee moet rekening worden gehouden.
Velen twijfelen aan de mogelijkheid om de klant bij het ontwikkelingsproces te betrekken. Klanten zijn inderdaad verschillend. Mocht het niet lukken om de klant of diens vertegenwoordiger aan te trekken, dan is het soms raadzaam om tijdelijk een specialist in te huren op het vakgebied dat ontwikkeld wordt. Deze stap zal onduidelijkheden in het werk verminderen, de ontwikkelingssnelheid verhogen en het project dichter bij datgene brengen wat de klant wil ontvangen. Ook vanuit financieel oogpunt kan dit gunstig zijn: het salaris van een programmeur is immers soms aanzienlijk hoger dan het salaris van specialisten in andere branches.
Gebruikersverhaal. User Story (zoiets als het verhaal van een gebruiker) is een beschrijving van hoe het systeem zou moeten werken. Elke User Story wordt op een kaart geschreven en vertegenwoordigt een stukje systeemfunctionaliteit dat logisch is vanuit het perspectief van de klant. Het formulier bestaat uit één of twee alinea's tekst die begrijpelijk zijn voor de gebruiker (niet erg technisch).
User Story is geschreven door de Klant. Deze zijn vergelijkbaar met systeemgebruiksscenario's, maar zijn niet beperkt tot de gebruikersinterface. Voor elk verhaal worden functionele tests geschreven om te bevestigen dat dit verhaal correct is geïmplementeerd; dit worden ook wel acceptatietests genoemd.

Testen voordat de ontwikkeling begint

Testen is in klassieke zin een nogal saaie procedure. Meestal huren ze een tester in die periodiek dezelfde handelingen uitvoert en wacht op de dag waarop hij uiteindelijk wordt overgeplaatst naar een andere functie of de mogelijkheid zich voordoet om van baan te veranderen.
Bij extreem programmeren is de rol van testen interessanter: nu komt de test eerst, en dan de code. Hoe test je iets dat nog niet bestaat? Het antwoord is simpel en banaal: test je gedachten - wat je kunt verwachten van een toekomstig programma of functionaliteit. Hierdoor kunt u beter begrijpen wat programmeurs moeten doen en kunt u de functionaliteit van de code controleren zodra deze is geschreven.
Maar het kan zijn dat de test ook niet werkt. Dus wat, een test voor een test schrijven? En dan testen voor testen enzovoort tot in het oneindige? Helemaal niet. De test voor de test vervangt de code. Hoe komt het? Maar kijk: stel je voor dat je de moer in het midden van de bout moet bevestigen, zodat deze niet draait. Wat doen ze hiervoor? Schroef de tweede moer dicht bij de eerste, zodat elke moer voorkomt dat de aangrenzende moer draait. Hetzelfde geldt voor programmeren: de test test de code, en de code test de test.
De ervaring leert dat deze aanpak de ontwikkeling niet alleen niet vertraagt, maar ook versnelt. Als u weet wat er moet gebeuren en hoeveel werk er nodig is, bespaart u immers tijd door te weigeren onderdelen te verkopen waar momenteel geen vraag naar is.

Paar programmeren

Alle code voor het productiesysteem wordt in paren geschreven. Twee ontwikkelaars zitten naast elkaar. De een typt, de ander kijkt. Ze veranderen van tijd tot tijd. Het is niet toegestaan ​​om alleen te werken. Als de tweede van het paar om wat voor reden dan ook iets heeft gemist (ziek, gepensioneerd, enz.), Is hij verplicht alle door de eerste aangebrachte wijzigingen te herzien.
Het klinkt ongebruikelijk, maar na een korte aanpassingsperiode werken de meeste mensen goed in paren. Ze vinden het zelfs leuk omdat het werk merkbaar sneller klaar is. Het principe ‘Eén hoofd is goed, maar twee is beter’ geldt. Paren vinden meestal betere oplossingen. Bovendien neemt de kwaliteit van de code aanzienlijk toe, neemt het aantal fouten af ​​en wordt de kennisuitwisseling tussen ontwikkelaars versneld. Terwijl de ene persoon zich richt op de strategische visie van het object, implementeert de tweede de eigenschappen en methoden ervan.

Veranderende posities

Tijdens de volgende iteratie moeten alle werknemers naar nieuwe werkgebieden worden verplaatst. Dergelijke bewegingen zijn nodig om kennisisolatie te voorkomen en knelpunten weg te nemen. Bijzonder vruchtbaar is het vervangen van een van de ontwikkelaars in pair programming.

Collectief code-eigendom

Gedeeld code-eigendom moedigt ontwikkelaars aan om ideeën in te dienen voor alle delen van het project, niet alleen voor hun eigen modules. Elke ontwikkelaar kan elke code wijzigen om de functionaliteit uit te breiden en bugs op te lossen.
Op het eerste gezicht lijkt het chaos. Als je er echter rekening mee houdt dat in ieder geval elke code door een paar ontwikkelaars is gemaakt, dat je met tests de juistheid van de aangebrachte wijzigingen kunt controleren, en dat je in het echte leven nog steeds de code van iemand anders op de een of andere manier moet begrijpen, is het wordt duidelijk dat collectief eigenaarschap van de code het veel gemakkelijker maakt om veranderingen aan te brengen en het risico verkleint dat gepaard gaat met de hoge specialisatie van een of ander teamlid.

Coderingsconventie

Je maakt deel uit van een team dat al langere tijd aan dit project werkt. Mensen komen en gaan. Niemand codeert alleen en code is van iedereen. Er zullen altijd momenten zijn waarop je de code van iemand anders moet begrijpen en aanpassen. Ontwikkelaars zullen dubbele code verwijderen of wijzigen, klassen van anderen analyseren en verbeteren, enz. Na verloop van tijd zal het onmogelijk zijn om te zeggen wie de auteur van een bepaalde klasse is.
Daarom moet iedereen de algemene codeerstandaarden naleven: codeopmaak, naamgeving van klassen, variabelen, constanten, commentaarstijl. Op deze manier weten we zeker dat wanneer we wijzigingen aanbrengen in de code van iemand anders (wat nodig is voor agressieve en extreme vooruitgang), we er geen Babel Pandemonium van zullen maken.
Het bovenstaande betekent dat alle teamleden het eens moeten worden over gemeenschappelijke coderingsstandaarden. Het maakt niet uit welke. De regel is dat iedereen ze gehoorzaamt. Degenen die zich hier niet aan willen houden, verlaten het team.

Frequente integratie

Ontwikkelaars moeten hun code indien mogelijk om de paar uur integreren en vrijgeven. Wijzigingen mag u in ieder geval nooit langer dan één dag bewaren. Frequente integratie vermijdt vervreemding en fragmentatie in de ontwikkeling, waarbij ontwikkelaars niet kunnen communiceren in de zin van het delen van ideeën of het hergebruiken van code. Iedereen zou de nieuwste versie moeten gebruiken.
Elk paar ontwikkelaars moet hun code bijdragen zodra dit redelijkerwijs mogelijk is. Dit kan het geval zijn wanneer alle UnitTests 100% slagen. Door meerdere keren per dag wijzigingen door te geven, reduceer je integratieproblemen tot vrijwel nul. Integratie is een ‘betaal nu of betaal later meer’-activiteit. Door elke dag wijzigingen in kleine stapjes te integreren, hoeft u dus niet een week te besteden aan het aan elkaar koppelen van het systeem vlak voordat het project wordt opgeleverd. Werk altijd op de nieuwste versie van het systeem.

Veertigurige werkweek

Een mens, vooral als hij programmeur is, is tot veel zaken in staat: tot laat op het werk blijven, in het weekend naar zijn werk gaan, vakantie opgeven, een aantal dagen wakker blijven terwijl hij achter het toetsenbord zit... Wat kunt u in het algemeen doen ter wille van uw favoriete bezigheid. Maar extreme programmering is categorisch tegen dergelijke zelfopoffering en schending van geaccepteerde arbeidswetten.
Dit wordt niet alleen gedicteerd door overwegingen van legaliteit en menselijkheid, maar in de eerste plaats door de noodzaak om de werkefficiëntie en een strikte organisatie te vergroten. Extreme programmering is immers een collectief spel, niet bedoeld voor individuen, maar voor de hele groep. En zoiets als bijvoorbeeld paarprogrammering is alleen mogelijk als de bioritmen van de deelnemers gesynchroniseerd zijn. En het is onmogelijk als de een om negen uur naar zijn werk komt, en de tweede om twaalf uur, of de een besluit dat het beter voor hem is om op zaterdag en zondag te werken, terwijl de ander ongemakkelijk is.
Maar het belangrijkste is dat iemand voldoende rust nodig heeft om zijn gezondheid en prestaties te behouden. De achturige werkdag en de vijfdaagse werkweek zijn juist ingesteld om redenen van maximale productiviteit. In veel westerse bedrijven wordt het laattijdig verlaten van het werk beschouwd als een onvermogen om goed te presteren of als een onvermogen om de werktijd goed te beheren. In de meeste gevallen is dit waar. En vanuit medisch oogpunt leiden vertragingen op het werk tot constante vermoeidheid, prikkelbaarheid en verminderde hersenactiviteit. Is dit effectief? Hoe kunnen we in zo’n team een ​​constante open communicatie tussen ontwikkelaars organiseren, en zal pair programming mogelijk zijn? Het antwoord is negatief. Normen zijn normen en moeten worden nageleefd.

Conclusie

Deze methoden zijn niet toevallig samengesteld. Hun consistente combinatie kan het ontwikkelingsproces intellectueel weerklank geven, waardoor de kwaliteit van het product aanzienlijk wordt verhoogd en de releasetijd ervan wordt versneld. Het belangrijkste schoonheid van alle extreme programmering is de voorspelbaarheid en het minimaliseren van de ontwikkelingskosten; het aan de klant ter beschikking stellen van het product dat hij wenst te ontvangen op het moment van vrijgave; en natuurlijk communicatie en training van ontwikkelaars on-the-job.

Bibliografie:

Extreme Programming (XP) is ontstaan ​​als een evolutionaire methode voor bottom-up softwareontwikkeling. Deze aanpak is een voorbeeld van de zogenaamde Agile Ontwikkelmethode. Tot de groep ‘live’ methoden behoren naast het extreme programmeren ook de methoden SCRUM, DSDM (Dynamic Systems Development Method, een methode voor het ontwikkelen van dynamische systemen), Feature-Driven Development (ontwikkeling gedreven door systeemfuncties), etc.

De basisprincipes van live softwareontwikkeling zijn vastgelegd in het live ontwikkelingsmanifest, dat in 2000 verscheen.

• · De mensen die betrokken zijn bij een project en hun communicatie zijn belangrijker dan processen en hulpmiddelen.
• · Een werkprogramma is belangrijker dan uitgebreide documentatie.
• · Samenwerking met de klant is belangrijker dan het bespreken van de details van het contract.
• · Het doorwerken van veranderingen is belangrijker dan vasthouden aan plannen.

‘Levende’ methoden verschenen als protest tegen de buitensporige bureaucratisering van softwareontwikkeling, de overvloed aan nevendocumenten die niet nodig zijn om het eindresultaat te verkrijgen, die moeten worden opgesteld bij de uitvoering van een project in overeenstemming met de meeste ‘zware’ processen , extra werkzaamheden ter ondersteuning van het vaste proces van de organisatie, zoals dit nodig is binnen bijvoorbeeld CMM. De meeste van dergelijke werkzaamheden en documenten houden niet direct verband met softwareontwikkeling en kwaliteitsborging, maar zijn bedoeld om te voldoen aan de formele clausules van ontwikkelingscontracten en om certificaten te verkrijgen en te bevestigen voor naleving van verschillende normen.

Met 'Live'-methoden kunnen ontwikkelaars het grootste deel van hun inspanningen richten op ontwikkelingstaken en het voldoen aan echte gebruikersbehoeften. Door het ontbreken van stapels documenten en de noodzaak om ze in samenhang te bewaren, kunt u sneller en efficiënter reageren op veranderingen in de vereisten en in de omgeving waarin het toekomstige programma zal moeten werken.

XP heeft echter zijn eigen ontwikkelingsprocesdiagram (hoewel over het algemeen het veelgebruikte begrip van het 'ontwikkelingsproces' als een tamelijk rigide actieschema in tegenspraak is met het idee van 'levendige' ontwikkeling), weergegeven in figuur 1 .

Volgens de auteurs van XP volgt deze techniek niet zozeer enkele algemene actiepatronen, maar maakt zij gebruik van een combinatie van de volgende technieken. Elke techniek is echter belangrijk, en zonder het gebruik ervan wordt ontwikkeling niet als XP beschouwd, aldus Kent Beck, een van de auteurs van deze aanpak, samen met Ward Cunningham en Ron Jeffries.

· Live planning spel)

Zijn taak is om zo snel mogelijk te bepalen hoeveel werk er moet worden gedaan vóór de volgende softwareversie. De beslissing wordt ten eerste genomen op basis van de prioriteiten van de klant (d.w.z. zijn behoeften, wat hij nodig heeft van het systeem om zijn bedrijf succesvoller te runnen) en ten tweede op basis van technische beoordelingen (d.w.z. inschattingen van de complexiteit van ontwikkeling, compatibiliteit met andere elementen van het systeem, enz.). Plannen worden gewijzigd zodra deze afwijken van de werkelijkheid of de wensen van de klant.

Figuur 1

· Veel voorkomend wijziging versies (klein releases)

De allereerste werkende versie zou zo snel mogelijk moeten verschijnen en onmiddellijk in gebruik moeten worden genomen. Daaropvolgende versies worden met vrij korte tussenpozen voorbereid (van enkele uren voor kleine wijzigingen in een klein programma tot een maand of twee voor een grote herwerking van een groot systeem). Versies (releases) van het product moeten zo vaak mogelijk in gebruik worden genomen. Het voltooien van elke versie zou zo min mogelijk tijd in beslag moeten nemen. Bovendien moet elke versie voldoende betekenisvol zijn in termen van bruikbaarheid voor het bedrijfsleven.

· Metafoor van het systeem

De metafoor moet, in een vrij eenvoudige en begrijpelijke vorm voor het team, het basismechanisme van het systeem beschrijven. Dit concept doet denken aan de architectuur, maar zou de essentie van de technische beslissingen veel eenvoudiger moeten beschrijven, in slechts een of twee zinnen.

Architectuur is een idee van de componenten van een systeem en hoe ze met elkaar verbonden zijn. Ontwikkelaars gebruiken architectuur om te begrijpen waar nieuwe functionaliteit aan het systeem wordt toegevoegd en waarmee een nieuwe component zal communiceren.

De systeemmetafoor is een analogie van wat in de meeste technieken architectuur wordt genoemd. De systeemmetafoor geeft het team een ​​idee van hoe het systeem momenteel functioneert, waar nieuwe componenten worden toegevoegd en welke vorm deze moeten aannemen.

· Eenvoudig ontwerp oplossingen (eenvoudig ontwerp)

Het systeem moet op elk moment zo eenvoudig mogelijk worden ontworpen. Het is niet nodig om vooraf functies toe te voegen - alleen na een expliciet verzoek daartoe. Alle onnodige complexiteit wordt verwijderd zodra deze wordt ontdekt.

XP komt voort uit het feit dat tijdens het werkproces de omstandigheden van het probleem herhaaldelijk kunnen veranderen, wat betekent dat het product dat wordt ontwikkeld niet van tevoren in zijn geheel moet worden ontworpen. Als je een systeem van begin tot eind in detail probeert te ontwerpen wanneer je voor het eerst begint, verspil je je tijd. XP gaat ervan uit dat ontwerp zo'n belangrijk proces is dat het gedurende het hele project continu moet worden uitgevoerd. Het ontwerp moet in kleine stappen worden uitgevoerd, waarbij rekening moet worden gehouden met voortdurend veranderende eisen. Op elk moment proberen we het eenvoudigste ontwerp te gebruiken dat geschikt is om het huidige probleem op te lossen. Tegelijkertijd veranderen we het naarmate de omstandigheden van het probleem veranderen.

· Ontwikkeling op basis testen (testgestuurd ontwikkeling)

Ontwikkelaars schrijven eerst tests en proberen vervolgens hun modules zo te implementeren dat de tests werken. Klanten schrijven vooraf tests uit die de belangrijkste mogelijkheden van het systeem demonstreren, zodat ze kunnen zien dat het systeem echt werkt.

XP legt bijzondere nadruk op twee soorten testen:

ü testen van eenheden;

b acceptatietesten.

extreme programmeersoftware

Een ontwikkelaar kan pas zeker zijn van de juistheid van de code die hij heeft geschreven als absoluut alle tests van de modules van het systeem dat hij ontwikkelt, hebben gewerkt. Met unittests kunnen ontwikkelaars verifiëren of hun code correct werkt. Ze helpen andere ontwikkelaars ook te begrijpen waarom een ​​bepaald stuk code nodig is en hoe het functioneert. Met unittests kan de ontwikkelaar ook zonder zorgen refactoren.

Acceptatietests zorgen ervoor dat het systeem daadwerkelijk over de gestelde capaciteiten beschikt. Bovendien kunt u met acceptatietests de correcte werking van het te ontwikkelen product verifiëren.

Voor XP heeft een hogere prioriteit de aanpak die TDD (Test Driven Development) wordt genoemd. Eerst wordt een test geschreven die niet slaagt, vervolgens wordt de code zo geschreven dat de test slaagt, en pas dan wordt de code opnieuw bewerkt.

· Constante refactoring

Het is geen geheim dat de toevoeging van elke nieuwe functionaliteit en de groei van de code de ontwikkeling bemoeilijkt, fouten identificeert en daaropvolgende wijzigingen aanbrengt. Een van de trucs van Extreme Programming is het compenseren van toegevoegde functionaliteit met codeverbeteringen. Dit is codeverwerking of refactoring.

Programmeurs herwerken het systeem voortdurend om onnodige complexiteit te elimineren, de begrijpelijkheid van de code te vergroten, de flexibiliteit ervan te vergroten, maar zonder het gedrag ervan te veranderen, wat wordt geverifieerd door na elke herwerking van de tests uit te voeren. Tegelijkertijd wordt de voorkeur gegeven aan elegantere en flexibelere oplossingen, vergeleken met oplossingen die eenvoudigweg het gewenste resultaat opleveren. Niet-succesvol opnieuw ontworpen componenten moeten tijdens de testuitvoering worden geïdentificeerd en teruggezet naar de laatste intacte staat (samen met de componenten die ervan afhankelijk zijn).

Refactoring is een techniek om code te verbeteren zonder de functionaliteit ervan te veranderen. XP betekent dat zodra de code is geschreven, deze in de loop van een project vrijwel zeker meerdere keren zal worden herschreven. XP-ontwikkelaars herwerken meedogenloos eerder geschreven code om deze te verbeteren. Dit proces wordt refactoring genoemd. Het gebrek aan testdekking leidt tot een weigering om te refactoren vanwege de angst om het systeem te breken, wat leidt tot een geleidelijke degradatie van de code.

· Programmering paren programmering)

Ervaren ontwikkelaars hebben gemerkt dat het periodiek beoordelen van de code van anderen een positief effect heeft op de kwaliteit ervan. De meesters van Extreme Programming hebben deze aanpak ontwikkeld door code tijdens de ontwikkeling voortdurend te herzien via een techniek die pair programming wordt genoemd.

Het coderen wordt uitgevoerd door twee programmeurs op één computer. Het koppelen is willekeurig en varieert van taak tot taak. Degene in wiens handen het toetsenbord het huidige probleem op de beste manier probeert op te lossen. De tweede programmeur analyseert het werk van de eerste en geeft advies, overweegt de gevolgen van bepaalde beslissingen, nieuwe tests, minder directe maar flexibelere oplossingen. Indien nodig wordt het toetsenbord vrijelijk van de ene naar de andere overgedragen. Tijdens het werken aan een project staan ​​de paren niet vast: het wordt aanbevolen om ze door elkaar te halen, zodat elke programmeur in het team een ​​goed begrip heeft van het hele systeem. Op deze manier verbetert pair programming de samenwerking binnen het team.

· Collectief bezit code (collectief eigendom)

Collectief bezit betekent dat elk teamlid verantwoordelijk is voor alle broncode. Iedereen heeft dus het recht om wijzigingen aan te brengen in elk onderdeel van het programma. Pair programming ondersteunt deze praktijk: door in verschillende paren te werken, raken alle programmeurs vertrouwd met alle delen van de systeemcode. Een belangrijk voordeel van gedeeld code-eigendom is dat het het ontwikkelingsproces versnelt, omdat als er een fout optreedt, elke programmeur deze kan repareren.

Door elke programmeur het recht te geven om de code te wijzigen, lopen we het risico dat er bugs worden geïntroduceerd door programmeurs die denken te weten wat ze doen, maar geen rekening houden met bepaalde afhankelijkheden. Goed gedefinieerde UNIT-tests lossen dit probleem op: als niet-onderzochte afhankelijkheden fouten genereren, zal de volgende reeks UNIT-tests mislukken.

· Constante integratie (continu integratie)

Het systeem wordt geassembleerd en ondergaat zo vaak mogelijk een integratietest, meerdere keren per dag, telkens wanneer een paar programmeurs klaar zijn met het implementeren van de volgende functie.

Als u het systeem dat u ontwikkelt vaak genoeg integreert, kunt u de meeste problemen die ermee gepaard gaan, vermijden. Bij traditionele methoden wordt de integratie meestal helemaal aan het einde van het werk aan een product uitgevoerd, wanneer wordt aangenomen dat alle componenten van het systeem dat wordt ontwikkeld volledig klaar zijn. In XP wordt de code-integratie van het hele systeem meerdere keren per dag uitgevoerd, nadat de ontwikkelaars er zeker van zijn dat alle unit-tests correct verlopen.

Ondanks zijn eenvoud heeft deze techniek zijn eigen gebruiksregels, zoals het succes van de bestaande unit-tests voor de functionaliteit die wordt geïntegreerd, de aanwezigheid van functionele of acceptatietests en uiteraard de mogelijkheid om terug te keren naar een vorige staat. . Normaal gesproken worden de integratie en oplossing van de bijbehorende problemen op een aparte computer uitgevoerd door een aantal programmeurs. Hiermee minimaliseert u het risico op ongewenste gevolgen van de integratie.

· 40 uur werken een week

Overuren maken wordt gezien als een teken van grotere problemen in het project. Overwerk gedurende 2 weken achter elkaar is niet toegestaan ​​- dit put programmeurs uit en maakt hun werk aanzienlijk minder productief.

Een mens, vooral als hij een programmeur is, is tot veel zaken in staat: tot laat op het werk blijven, in het weekend naar zijn werk gaan, vakanties opgeven, een aantal dagen wakker blijven terwijl hij achter het toetsenbord zit... Wat kunt u in het algemeen doen ter wille van uw favoriete bezigheid. Maar extreme programmering is categorisch tegen dergelijke zelfopoffering en schending van geaccepteerde arbeidswetten.

Dit wordt niet alleen gedicteerd door overwegingen van legaliteit en menselijkheid, maar in de eerste plaats door de noodzaak om de werkefficiëntie en een strikte organisatie te vergroten. Extreme programmering is immers een collectief spel, niet bedoeld voor individuen, maar voor de hele groep. En zoiets als bijvoorbeeld paarprogrammering is alleen mogelijk als de bioritmen van de deelnemers gesynchroniseerd zijn. En het is onmogelijk als de een om negen uur naar zijn werk komt, en de tweede om twaalf uur, of de een besluit dat het beter voor hem is om op zaterdag en zondag te werken, terwijl de ander ongemakkelijk is.

Maar het belangrijkste is dat iemand voldoende rust nodig heeft om zijn gezondheid en prestaties te behouden. De achturige werkdag en de vijfdaagse werkweek zijn juist ingesteld om redenen van maximale productiviteit. In veel westerse bedrijven wordt het laattijdig verlaten van het werk beschouwd als een onvermogen om goed te presteren of als een onvermogen om de werktijd goed te beheren. In de meeste gevallen is dit waar. En vanuit medisch oogpunt leiden vertragingen op het werk tot constante vermoeidheid, prikkelbaarheid en verminderde hersenactiviteit. Is dit effectief? Hoe kunnen we in zo’n team een ​​constante open communicatie tussen ontwikkelaars organiseren, en zal pair programming mogelijk zijn? Het antwoord is negatief. Normen zijn normen en moeten worden nageleefd.

· Inclusie klant V team (ter plaatse klant)

Het grootste probleem bij softwareontwikkeling is het gebrek aan kennis van programmeurs in het vakgebied dat wordt ontwikkeld. Extreme programmering heeft een uitweg uit deze situatie gevonden. Nee, dit is geen ontwikkelaarsstage bij de klant - dan wil hij niet programmeren. Integendeel, het is de participatie van de klant in het ontwikkelingsproces.

In het ontwikkelteam zit altijd een klantvertegenwoordiger die de hele werkdag bereikbaar is en alle vragen over het systeem kan beantwoorden. Zijn verantwoordelijkheid is het onmiddellijk beantwoorden van vragen van welke aard dan ook met betrekking tot de functies van het systeem, de interface ervan, de vereiste prestaties, de juiste werking van het systeem in moeilijke situaties, de noodzaak om de communicatie met andere applicaties te onderhouden, enz.

Velen twijfelen aan de mogelijkheid om de klant bij het ontwikkelingsproces te betrekken. Klanten zijn inderdaad verschillend. Mocht het niet lukken om de klant of diens vertegenwoordiger aan te trekken, dan is het soms raadzaam om tijdelijk een specialist in te huren op het vakgebied dat ontwikkeld wordt. Deze stap zal onduidelijkheden in het werk verminderen, de ontwikkelingssnelheid verhogen en het project dichter bij datgene brengen wat de klant wil ontvangen. Ook vanuit financieel oogpunt kan dit gunstig zijn: het salaris van een programmeur is immers soms aanzienlijk hoger dan het salaris van specialisten in andere branches.

· Gebruik code Hoe faciliteiten communicatie

Code wordt gezien als het belangrijkste communicatiemiddel binnen een team. Duidelijkheid van de code is een van de belangrijkste prioriteiten. Het volgen van codeerstandaarden die deze duidelijkheid bieden, is absoluut noodzakelijk. Dergelijke standaarden moeten, naast de duidelijkheid van de code, zorgen voor minimaal taalgebruik (geen duplicatie van code en informatie) en moeten door alle teamleden worden geaccepteerd.

· Open werken ruimte (geopend werkruimte)

Het team is gehuisvest in een redelijk ruime ruimte om de communicatie te vergemakkelijken en groepsdiscussies mogelijk te maken bij het plannen en nemen van belangrijke technische beslissingen.

· Wijziging reglement Door nodig (net reglement)

Elk teamlid moet de genoemde regels accepteren, maar als dat nodig is, kan het team deze wijzigen als alle leden het met deze wijziging eens zijn.

Zoals uit de gebruikte technieken blijkt, is XP ontworpen voor gebruik binnen kleine teams (niet meer dan 10 programmeurs), wat wordt benadrukt door de auteurs van deze techniek. Een grotere teamgrootte vernietigt het communicatiegemak dat nodig is voor succes en maakt het onmogelijk om veel van de genoemde technieken te implementeren.