Extreme Programming is een softwareontwikkelingsmethodologie die is ontworpen om de kwaliteit van software te verbeteren en het vermogen om zich goed aan te passen aan de veranderende behoeften van de klant of klant. Tijdens het Midden en het einde van de jaren negentig, terwijl het werken aan de Chrysler Comprehensive Compensation System (C3) te helpen beheren van het bedrijf payroll, software engineer Ken Beck eerst ontwikkelde de Extreme Programmeermethodologie., In oktober 1999 publiceerde hij Extreme Programming Explained, waarin de hele methode voor anderen werd beschreven, en kort daarna werd ook de officiële website gelanceerd.

net als bij andere Agile ontwikkelingsmethoden is Extreme Programming bedoeld om iteratieve en frequente kleine releases te leveren gedurende het hele project, waardoor zowel teamleden als klanten de voortgang van het project gedurende de gehele SDLC kunnen onderzoeken en beoordelen.,

in dit artikel zullen we precies onderzoeken wat extreem programmeren is en hoe het werkt, van de waarden en principes die erachter zitten, tot de regels en procedurele best practices die worden gebruikt om een nieuw extreem programmeren project te implementeren, dus laten we beginnen!,/td>

Rational Unified Proces Big Bang Model V-Model Conceptueel Model Kaizen Model Kanban-Model Spiraal Model

de Extreme Waarden

Deze vijf fundamentele waarden vormen het fundament waarop het geheel van de Extreme Programming paradigma is gebouwd, zodat de mensen die bij het project betrokken te voelen, vol vertrouwen in de richting van het project is het nemen van en het inzicht in hun persoonlijke feedback en inzicht is nodig en welkom zijn als iemand anders.,

eenvoud: we zullen doen wat nodig en gevraagd is, maar niet meer. Dit zal maximaliseren van de waarde gecreëerd voor de investering tot nu toe. We zullen kleine eenvoudige stappen nemen om ons doel te bereiken en mislukkingen te beperken als ze zich voordoen. We creëren iets waar we trots op zijn en onderhouden het op lange termijn tegen redelijke kosten.

communicatie: iedereen maakt deel uit van het team en we communiceren dagelijks van aangezicht tot aangezicht. We werken samen aan alles, van vereisten tot code. We zullen de beste oplossing voor ons probleem creëren die we samen kunnen.,

Feedback: we nemen elke iteratie commitment Serieus door werkende software te leveren. We demonstreren onze software vroeg en vaak luisteren dan zorgvuldig en maken eventuele wijzigingen. We zullen over het project praten en ons proces daaraan aanpassen, niet andersom.

Respect: iedereen geeft en voelt het respect dat ze verdienen als een gewaardeerd teamlid. Iedereen draagt waarde bij, ook al is het gewoon enthousiasme. Ontwikkelaars respecteren de expertise van de klanten en vice versa. Het Management respecteert ons recht om verantwoordelijkheid te nemen en gezag te krijgen over ons eigen werk.,

moed: we zullen de waarheid vertellen over vooruitgang en schattingen. We documenteren geen excuses voor mislukking Omdat we van plan zijn te slagen. We zijn nergens bang voor omdat niemand ooit alleen werkt. We zullen ons aanpassen aan veranderingen wanneer ze ooit plaatsvinden.

Extreme Rules

oorspronkelijk gepubliceerd door Don Wells in 1999, de eigenaar van de website van Extreme Programming, was deze set Extreme Programming Rules oorspronkelijk bedoeld om de claims tegen te gaan dat Extreme Programming sommige van de prominente disciplines die nodig zijn voor moderne ontwikkeling niet ondersteunt.,

Planning

• gebruikersverhalen worden geschreven.
• Release planning maakt het release schema.
• maak regelmatig kleine releases.
• het project is verdeeld in herhalingen.
• Iteratieplanning start elke iteratie.

beheren

• geef het team een speciale open werkruimte.
• Bepaal een duurzaam tempo.
• elke dag begint een stand up meeting.
• de Projectsnelheid wordt gemeten.
• Verplaats mensen.
• Fix Extreme programmering wanneer het breekt.

het ontwerpen van

• eenvoud.,
• Kies een systeemmetafoor.
• gebruik CRC-kaarten voor ontwerpsessies.
• maak spike-oplossingen om het risico te verminderen.
• Er is geen functionaliteit vroeg toegevoegd.
• Refactor waar en wanneer mogelijk.

codering

• de klant is altijd beschikbaar.
• Code moet worden geschreven volgens overeengekomen standaarden.
• Codeer eerst de eenheidstest.
• alle productiecode is een paar geprogrammeerd.
• slechts één paar integreert code tegelijk.
• integreer vaak.
• een speciale integratiecomputer opzetten.
• gebruik collectief eigendom.,

testen

• alle codes moeten unit tests hebben.
• alle code moet alle eenheidstests doorstaan voordat deze kan worden vrijgegeven.
• wanneer een bug wordt gevonden, worden tests aangemaakt.
• acceptatietesten worden vaak uitgevoerd en de score wordt gepubliceerd.

Extreme praktijken

deze twaalf best practices voor Extreme programmering zijn gebaseerd op wat destijds als de beste praktijken voor softwareontwikkeling werd beschouwd.,

fijnschalen feedback

Pair programming

in essentie betekent pair programming dat twee mensen tegelijkertijd aan hetzelfde systeem werken bij het ontwikkelen van een productiecode. Door regelmatig wisselende partners in het hele team, bevordert Extreme programmering betere communicatie en teambuilding.

Planning spel

vaak neemt dit de vorm aan van een vergadering met een frequent en duidelijk gedefinieerd interval (elke één of twee weken), waar het grootste deel van de planning voor het project plaatsvindt.,

binnen deze procedure bestaat de fase van het plannen van de introductie, waarin wordt bepaald wat nodig is voor de dreigende introductie. Secties van Release Planning omvatten:

• exploratiefase: Story cards worden gebruikt om de meest waardevolle behoeften van klanten in detail te beschrijven.
• Verbintenisfase: Planning en toezeggingen van het team worden gedaan om te voldoen aan de behoeften van de volgende vrijgave van het schema en deze op tijd uit te krijgen.,
• Stuurfase: hierdoor kunnen eerder ontwikkelde plannen worden aangepast op basis van de veranderende behoeften van het project, vergelijkbaar met vele andere Agile Modelmethodologieën.

na de Release Planning is ook de iteratie Planning sectie, die bestaat uit dezelfde drie sub-fasen van zijn eigen, maar met varianten op hun implementaties:

• exploratiefase: alle projectvereisten worden opgeschreven.
• Commitment fase: noodzakelijke taken die nog moeten worden voltooid om te voldoen aan de komende iteratie release worden toegewezen aan ontwikkelaars en op de juiste wijze gepland.,
• Stuurfase: de ontwikkeling vindt plaats en na voltooiing wordt de resulterende iteratie vergeleken met de geschetste verhaalkaarten die aan het begin van de planningsprocedure zijn gemaakt.

Test-driven development

hoewel een heel artikel geschreven kan worden over test-driven development, is het concept vrij bekend onder ontwikkelaars en betekent het effectief dat tests worden gegenereerd voor elke vereiste van het project, en alleen dan wordt code ontwikkeld die met succes deze tests zal doorstaan.,

heel team

net als bij veel andere SDLC-methoden en-praktijken, bevordert Extreme Programming de inclusie van klanten en cliënten gedurende het hele proces, waarbij hun feedback wordt gebruikt om te allen tijde het project vorm te geven.

continu proces

continue integratie

een andere gangbare praktijk in de moderne ontwikkeling, het idee achter continue integratie is dat alle code die door het hele team is ontwikkeld, vele malen per dag wordt samengevoegd tot één gemeenschappelijke repository., Dit zorgt ervoor dat eventuele problemen met integratie in het hele project worden opgemerkt en zo snel mogelijk worden aangepakt.

Code refactoring

een andere veel voorkomende praktijk, het idee achter code refactoring is simpelweg het verbeteren en herontwerpen van de structuur van reeds bestaande code, zonder het fundamentele gedrag ervan te wijzigen. Eenvoudige voorbeelden van refactoring zijn de vaststelling van onjuist namen variabelen of methoden, en het verminderen van herhaalde code tot een enkele methode of functie.,

kleine releases

Dit concept sluit nauw aan bij de praktijk van het iteratieve Model en zorgt ervoor dat het project regelmatig gerepatrieerde, kleine releases bevat, zodat zowel de klant als alle teamleden een idee kunnen krijgen van hoe het project zich ontwikkelt.

gedeeld begrip

coderingsstandaarden

de coderingsstandaard is gewoon een reeks best practices binnen de code zelf, zoals opmaak en stijl, waaraan het hele team zich gedurende de gehele levenscyclus van het project houdt., Dit bevordert een beter begrip en leesbaarheid van de code, niet alleen voor huidige leden, maar ook voor toekomstige ontwikkelaars.

collectief code-eigendom

Deze praktijk staat elke ontwikkelaar in het team toe om elke sectie van de code te wijzigen, indien nodig. Hoewel deze praktijk kan gevaarlijk klinken voor sommigen, het versnelt de ontwikkelingstijd, en eventuele problemen kunnen worden gedempt met de juiste unit testen.

eenvoudig ontwerp

Er is weinig reden om dingen te compliceren wanneer een eenvoudigere optie beschikbaar is., Deze basispraktijk om alle componenten en code zo eenvoudig mogelijk te houden, zorgt ervoor dat het hele team altijd evalueert of dingen op een gemakkelijkere manier kunnen worden gedaan.

Systeemmetafoor

als onderdeel van de coderingsnormen is de systeemmetafoor het idee dat elke persoon in het team in staat moet zijn om te kijken naar de high-level code die wordt ontwikkeld, en een duidelijk begrip moet hebben van welke functionaliteit die code presteert.,

Programmer welfare

Sustainable pace

een belangrijk concept voor een betere balans tussen werk en privé met ontwikkelaars in een extreem Programmeerproject is de notie dat niemand meer dan de normale werkweek hoeft te werken. Overwerk wordt afgekeurd, net als het concept van “crunch time”, waar ontwikkelaars worden verwacht om extreme uren te werken in de buurt van het einde van een release om alles voltooid op tijd.