Planningsspel

XP-planning behandelt twee belangrijke vragen in softwareontwikkeling: voorspellen wat er zal worden bereikt op de vervaldatum, en bepalen wat er vervolgens moet worden gedaan. De nadruk ligt op het sturen van het project – wat heel eenvoudig is – in plaats van op het exact voorspellen van wat er nodig zal zijn en hoe lang het zal duren – wat heel moeilijk is., Er zijn twee belangrijke planningsstappen in XP, die deze twee vragen aanpakken:

Release Planning is een praktijk waarbij de klant de gewenste functies aan de programmeurs presenteert en de programmeurs hun moeilijkheid inschatten. Met de kostenramingen in de hand, en met kennis van het belang van de functies, de klant stelt een plan voor het project. Initiële release plannen zijn noodzakelijkerwijs onnauwkeurig: noch de prioriteiten noch de schattingen zijn echt solide, en totdat het team begint te werken, zullen we niet weten hoe snel ze zullen gaan., Zelfs de eerste release plan is accuraat genoeg voor de besluitvorming, echter, en XP teams herzien het release plan regelmatig.

Iteratieplanning is de praktijk waarbij het team om de paar weken leiding krijgt gegeven. XP teams bouwen software in twee weken “iteraties”, het leveren van bruikbare software aan het einde van elke iteratie. Tijdens de Iteratieplanning presenteert de klant de gewenste functies voor de komende twee weken. De programmeurs splitsen ze op in taken en schatten hun kosten (op een fijner detailniveau dan in Release Planning)., Op basis van de hoeveelheid werk die in de vorige iteratie is verricht, ondertekent het team wat er in de huidige iteratie zal worden ondernomen.

deze planningsstappen zijn zeer eenvoudig, maar bieden toch zeer goede informatie en een uitstekende besturing in de handen van de klant. Om de paar weken is de hoeveelheid vooruitgang volledig zichtbaar. Er is geen “negentig procent gedaan” in XP: een feature story werd voltooid, of het was niet., Deze focus op zichtbaarheid resulteert in een mooie kleine paradox: aan de ene kant, met zoveel zichtbaarheid, is de klant in een positie om het project te annuleren als de vooruitgang niet voldoende is. Aan de andere kant, vooruitgang is zo zichtbaar, en de mogelijkheid om te beslissen wat er vervolgens wordt gedaan is zo compleet, dat XP projecten de neiging om meer van wat nodig is te leveren, met minder druk en stress.

Klanttesten

als onderdeel van het presenteren van elke gewenste functie, definieert de XP-klant een of meer geautomatiseerde acceptatietests om aan te tonen dat de functie werkt., Het team bouwt deze tests en gebruikt ze om zichzelf en de klant te bewijzen dat de functie correct is geïmplementeerd. Automatisering is belangrijk omdat in de pers van de tijd, handmatige tests worden overgeslagen. Dat is net als je lichten uitdoen als de nacht het donkerst wordt.

de beste XP-teams behandelen hun klanttests op dezelfde manier als ze programmeertests doen: zodra de test loopt, houdt het team het daarna correct. Dit betekent dat het systeem alleen maar verbetert, altijd vooruitkeuken, nooit terugvallen.,

kleine Releases

XP-teams oefenen kleine releases op twee belangrijke manieren:

ten eerste brengt het team draaiende, geteste software uit, waarbij elke iteratie bedrijfswaarde wordt gekozen door de klant. De klant kan deze software gebruiken voor elk doel, of evaluatie of zelfs release aan eindgebruikers (sterk aanbevolen). Het belangrijkste aspect is dat de software zichtbaar is, en gegeven aan de klant, aan het einde van elke iteratie. Dit houdt alles open en tastbaar.

ten tweede geven XP-teams ook regelmatig vrij aan hun eindgebruikers., XP Web projecten release zo vaak als dagelijks, in huis projecten maandelijks of vaker. Zelfs krimpverpakte producten worden zo vaak als driemaandelijks verzonden.

Het lijkt misschien onmogelijk om zo vaak goede versies te maken, maar XP-teams overal doen het de hele tijd. Zie continue integratie voor meer informatie hierover, en merk op dat deze frequente releases betrouwbaar worden gehouden door xp ‘ s obsessie met testen, zoals hier beschreven in Customer Tests en Test-Driven Development.

eenvoudig ontwerp

XP teams bouwen software om een eenvoudig maar altijd adequaat ontwerp., Ze beginnen eenvoudig, en door programmer testen en ontwerpverbetering, houden ze dat zo. Een XP-team houdt het ontwerp precies geschikt voor de huidige functionaliteit van het systeem. Er is geen verspilde beweging, en de software is altijd klaar voor wat er gaat komen.

ontwerp in XP is geen eenmalig iets, of een vooraanstaand iets, het is een all-the-time iets. Er zijn ontwerpstappen in release planning en iteratie planning, plus teams nemen deel aan snelle ontwerpsessies en ontwerprevisies door refactoring, gedurende het hele project., In een incrementeel, iteratief proces zoals Extreme programmering, is goed ontwerp essentieel. Daarom is er in de loop van de hele ontwikkeling zoveel aandacht voor design.

Pair Programming

alle productiesoftware in XP wordt gebouwd door twee programmeurs die naast elkaar op dezelfde machine zitten. Deze praktijk zorgt ervoor dat alle productiecode wordt beoordeeld door ten minste één andere programmeur, en resulteert in een beter ontwerp, beter testen en betere code.

het lijkt misschien inefficiënt om twee programmeurs “één programmeurswerk” te laten doen, maar het omgekeerde is waar., Onderzoek naar pair programming toont aan dat pairing betere code oplevert in ongeveer dezelfde tijd als programmeurs die alleen werken. Dat klopt: twee hoofden zijn echt beter dan één!

sommige programmeurs maken bezwaar om programmeren te koppelen zonder het ooit te proberen. Het duurt enige oefening om goed te doen, en je moet het goed doen voor een paar weken om de resultaten te zien. Negentig procent van de programmeurs die pair programming leren, geven er de voorkeur aan, dus we raden het ten zeerste aan aan alle teams.het koppelen van

dient niet alleen om betere code en tests te leveren, maar ook om kennis door het hele team te communiceren., Als paren schakelen, iedereen krijgt de voordelen van ieders gespecialiseerde kennis. Programmeurs leren, hun vaardigheden verbeteren, ze worden waardevoller voor het team en voor het bedrijf. Koppelen, zelfs op zichzelf buiten XP, is een grote overwinning voor iedereen.

Test-Driven Development

extreem programmeren is geobsedeerd door feedback, en in softwareontwikkeling vereist goede feedback goede testen. Top XP teams oefenen “test-driven development”, werken in zeer korte cycli van het toevoegen van een test, dan waardoor het werken., Bijna moeiteloos produceren teams code met bijna 100 procent testdekking, wat een grote stap voorwaarts is in de meeste winkels. (Als je programmeurs al nog meer geavanceerde testen doen, heb je meer kracht. Ga zo door, het kan alleen maar helpen!)

Het is niet genoeg om tests te schrijven: Je moet ze uitvoeren. Ook hier is Extreme programmering extreem. Deze “programmer tests”, of” unit tests ” worden allemaal samen verzameld, en elke keer dat een programmeur een code vrijmaakt in de repository (en paren meestal twee keer per dag of meer vrijgeven), moet elk van de programmer tests correct worden uitgevoerd., Honderd procent, de hele tijd! Dit betekent dat programmeurs onmiddellijk feedback krijgen over hoe ze het doen. Bovendien bieden deze tests onschatbare ondersteuning als het softwareontwerp wordt verbeterd.

ontwerpverbetering (Refactoring)

Extreme programmering richt zich op het leveren van bedrijfswaarde in elke iteratie. Om dit in de loop van het hele project te bereiken, moet de software goed ontworpen zijn. Het alternatief zou zijn om te vertragen en uiteindelijk vast te komen te zitten., Dus XP maakt gebruik van een proces van continue ontwerpverbetering genaamd Refactoring, uit de titel van Martin Fowler ‘ s boek, “Refactoring: Improving the Design of Existing Code”.

het refactoringproces richt zich op het verwijderen van duplicatie (een duidelijk teken van slecht ontwerp), en op het vergroten van de “samenhang” van de code, terwijl het verlagen van de “koppeling”. Hoge samenhang en lage koppeling zijn erkend als de kenmerken van goed ontworpen code voor ten minste dertig jaar. Het resultaat is dat XP teams beginnen met een goed, eenvoudig ontwerp, en hebben altijd een goed, eenvoudig ontwerp voor de software., Hierdoor kunnen ze hun ontwikkelingssnelheid behouden en in feite over het algemeen de snelheid verhogen naarmate het project vordert.

Refactoring wordt natuurlijk sterk ondersteund door uitgebreide tests om er zeker van te zijn dat er tijdens de ontwikkeling van het ontwerp niets kapot gaat. Zo zijn de testen van de klant en de programmeur een cruciale factor. De XP-praktijken ondersteunen elkaar: ze zijn samen sterker dan afzonderlijk.

continue integratie

Extreme Programmeerteams houden het systeem te allen tijde volledig geïntegreerd. We zeggen dat dagelijkse builds zijn voor watjes: XP teams bouwen meerdere keren per dag., (Een XP team van veertig mensen bouwt minstens acht of tien keer per dag!)

Het voordeel van deze praktijk kan worden gezien door terug te denken aan projecten waarvan je misschien gehoord hebt (of er zelfs deel van hebt uitgemaakt) waar het bouwproces wekelijks of minder vaak plaatsvond, en meestal leidde tot “integratie hel”, waar alles brak en niemand wist waarom.

zelden voorkomende integratie leidt tot ernstige problemen op een softwareproject., Allereerst, hoewel integratie cruciaal is voor het verzenden van goede werkende code, wordt het team er niet op geoefend, en vaak wordt het gedelegeerd aan mensen die niet bekend zijn met het hele systeem. Ten tweede, zelden geïntegreerde code is vaak – ik zou zeggen meestal-buggy code. Problemen sluipen in op integratie tijd die niet worden gedetecteerd door een van de testen die plaatsvindt op een niet-geïntegreerd systeem. Ten derde, zwak integratieproces leidt tot lange code bevriest., Code bevriest betekent dat je lange tijd periodes waarin de programmeurs kunnen werken aan belangrijke shippable functies, maar dat deze functies moeten worden tegengehouden. Dit verzwakt uw positie in de markt, of bij uw eindgebruikers.

collectief Code-eigendom

bij een extreem Programmeerproject kan elk paar programmeurs elke code op elk moment verbeteren. Dit betekent dat alle code het voordeel krijgt van de aandacht van veel mensen, wat de kwaliteit van de code verhoogt en defecten vermindert., Er is nog een ander belangrijk voordeel: wanneer code eigendom is van individuen, worden de vereiste functies vaak op de verkeerde plaats geplaatst, omdat een programmeur ontdekt dat hij ergens in code een functie nodig heeft die hij niet bezit. De eigenaar is te druk om het te doen, dus de programmeur zet de functie in zijn eigen code, waar het niet thuishoort. Dit leidt tot lelijke, moeilijk te onderhouden code, vol duplicatie en met lage (slechte) cohesie.

collectief eigendom kan een probleem zijn als mensen blindelings werken aan code die ze niet begrijpen., XP vermijdt deze problemen door middel van twee belangrijke technieken: de programmeur testen vangen fouten, en paar programmering betekent dat de beste manier om te werken aan Onbekende code is om te koppelen met de expert. Naast het garanderen van goede aanpassingen wanneer dat nodig is, verspreidt deze praktijk kennis door het hele team.

Codeerstandaard

XP-teams volgen een gemeenschappelijke codeerstandaard, zodat alle code in het systeem eruit ziet alsof het geschreven is door een enkele – zeer competente – persoon., De details van de standaard zijn niet belangrijk: wat belangrijk is, is dat alle code er vertrouwd uitziet, ter ondersteuning van collectieve eigendom.

metafoor

Extreme Programmeerteams ontwikkelen een gemeenschappelijke visie op hoe het programma werkt, die we de “metafoor”noemen. Op zijn best, de metafoor is een eenvoudige evocatieve beschrijving van hoe het programma werkt, zoals “dit programma werkt als een bijenkorf, uit te gaan voor stuifmeel en breng het terug naar de korf” als een beschrijving voor een agent-based informatie retrieval systeem.

soms ontstaat er geen voldoende poëtische metafoor., In ieder geval, met of zonder levendige beelden, gebruiken XP-teams een gemeenschappelijk systeem van namen om er zeker van te zijn dat iedereen begrijpt hoe het systeem werkt en waar te zoeken om de functionaliteit te vinden die u zoekt, of om de juiste plaats te vinden om de functionaliteit te plaatsen die u op het punt staat toe te voegen.

Sustainable Pace

Extreme Programmeerteams zijn er voor de lange termijn. Ze werken hard, en in een tempo dat voor onbepaalde tijd kan worden volgehouden. Dit betekent dat ze overwerken wanneer het effectief is, en dat ze normaal werken op een zodanige manier dat de productiviteit week in en week uit te maximaliseren., Het is vrij goed begrepen deze dagen dat death march projecten zijn noch productief noch produceren kwaliteit software. XP teams doen mee om te winnen, niet om te sterven.

conclusie

extreem programmeren is een discipline van softwareontwikkeling gebaseerd op waarden als eenvoud, Communicatie, feedback en moed. Het werkt door het hele team samen te brengen in de aanwezigheid van eenvoudige praktijken, met genoeg feedback om het team in staat te stellen te zien waar ze zijn en om de praktijken af te stemmen op hun unieke situatie.