Extreme programmering

Extreme programmering is een software development methodiek die bedoeld is om kwaliteit van de software en het reactievermogen te verbeteren aan de veranderende eisen van de klant. Als een soort van agile software development, het pleit voor frequente "releases" in het kort de ontwikkeling cycli, die bedoeld is om de productiviteit te verbeteren en checkpoints waar nieuwe eisen van de klant kan worden vastgesteld introduceren.

Andere elementen van extreme programmering zijn: programmeren in paren of het doen van een uitgebreide code review, unit testen van code, het vermijden van het programmeren van de functies, totdat ze daadwerkelijk nodig zijn, een platte organisatiestructuur, eenvoud en duidelijkheid in de code, verwachten veranderingen in de eisen van de klant als tijd verstrijkt en het probleem wordt beter begrepen en frequente communicatie met de klant en tussen programmeurs. De methode ontleent zijn naam aan het idee dat de positieve elementen van de traditionele software engineering praktijken worden genomen om de "extreme" niveaus. Als voorbeeld worden code reviews als een gunstig praktijk; genomen tot het uiterste, code continu kan namelijk de praktijk van pair programming worden herzien.

Critici hebben opgemerkt verschillende potentiële nadelen, waaronder problemen met instabiele eisen, geen gedocumenteerde compromissen van de gebruiker conflicten, en een gebrek aan een totale ontwerp specificatie of document.

Geschiedenis

Extreme Programming is opgericht door Kent Beck tijdens zijn werk op de Chrysler Comprehensive Compensation System payroll project. Beck werd de C3 projectleider in maart 1996 begon de ontwikkeling gebruikte methodologie in het project te verfijnen en schreef een boek over de methodologie. Chrysler geannuleerd de C3 project in februari 2000, na zeven jaar, toen het bedrijf werd overgenomen door Daimler-Benz.

Hoewel extreme programmering zelf is relatief nieuw, veel van zijn praktijk zijn er al enige tijd; de methodologie, immers, neemt "best practices" aan extreme niveaus. Zo werd de 'praktijk test-first, planning en schrijven van tests voor elk micro-increment "al NASA's Project Mercury gebruikt in de vroege jaren 1960. Om de totale ontwikkeltijd verkorten, hebben een aantal formele testdocumenten ontwikkeld parallel de software klaar is om te testen. Een NASA onafhankelijke testgroep kan de testprocedures te schrijven, op basis van formele eisen en logische grenzen, voordat de software is geschreven en geïntegreerd met de hardware. In XP, wordt dit concept tot het uiterste niveau schrijven geautomatiseerde tests die de werking van zelfs kleine delen van software codering valideren, en niet alleen het testen van de grote kenmerken.

Origins

Software ontwikkeling in de jaren 1990 werd gevormd door twee grote invloeden: intern, object-georiënteerd programmeren vervangen procedurele programmering als de programmering paradigma begunstigd door sommigen in de industrie; extern, de opkomst van het internet en de dot-com boom benadrukte speed-to-market en de groei van het bedrijf als concurrerende zakelijke factoren. Snel veranderende eisen die kortere product life-cycli, en waren vaak onverenigbaar is met traditionele methoden van software-ontwikkeling.

De Chrysler Comprehensive Compensation System werd gestart met het oog op de beste manier om object technologieën te bepalen, met behulp van de payroll-systemen op Chrysler als object van onderzoek, met Smalltalk als de taal en de edelsteen van de toegang tot de gegevens laag. Zij brachten in Kent Beck, een prominente Smalltalk beoefenaar, om performance tuning te doen op het systeem, maar zijn rol breidde toen hij merkte een aantal problemen die zij hadden met hun ontwikkelingsproces. Hij nam deze gelegenheid te stellen en uit te voeren een aantal veranderingen in hun praktijken op basis van zijn werk met zijn frequente medewerker, Ward Cunningham. Beck beschrijft het aanvankelijke ontwerp van de methoden:

Beck uitgenodigd Ron Jeffries om het project te helpen ontwikkelen en verfijnen van deze methoden. Jeffries daarna fungeerde als coach aan de praktijken druppelen als gewoonten in de C3-team.

Informatie over de principes en praktijken achter XP werd verspreid naar de rest van de wereld door middel van discussies over de oorspronkelijke wiki, Cunningham WikiWikiWeb. Verschillende medewerkers besproken en uitgebreid op de ideeën, en een aantal spin-off methodologieën resulteerde. Ook zijn XP begrippen uiteengezet, verscheidene jaren, met een hypertekstsysteem map op XP website "circa 1999.

Beck bewerkt een reeks boeken op XP, te beginnen met zijn eigen Extreme Programming Explained, het verspreiden van zijn ideeën voor een veel groter publiek. Auteurs in de serie ging door verschillende aspecten bijwonen XP en zijn praktijken. De serie omvatte een boek dat kritiek van de praktijken was.

Huidige toestand

XP gegenereerd aanzienlijke belangstelling van software gemeenschappen in de late jaren 1990 en vroege jaren 2000, het zien van de goedkeuring in een aantal omgevingen radicaal verschillend van zijn oorsprong.

De hoge discipline vereist door de originele praktijken ging vaak langs de weg, waardoor sommige van deze praktijken, zoals die dacht te rigide, worden afgekeurd of verminderd, of zelfs afgemaakt, op de individuele sites. Bijvoorbeeld zou het gebruik van einde-dag integratie testen voor een bepaald project worden gewijzigd naar een einde van week schema, of eenvoudig gereduceerd onderling overeengekomen data. Zoals een meer ontspannen schema mensen kon vermijden gevoel gehaast om kunstmatige stubs te genereren alleen maar om het testen van het einde van de dag voorbij. Een minder stijf schema stelt daarentegen voor bepaalde complexe functies zijn vollediger ontwikkeld over een periode van meerdere dagen. Echter, een zekere mate van periodieke integratie testen groepen van mensen die werkzaam zijn in de niet-compatibele detecteren, tangent inspanningen niet al te veel werk is geïnvesteerd in uiteenlopende, verkeerde richtingen.

Inmiddels hebben andere agile development practices niet stilgestaan, en XP is nog steeds in ontwikkeling, assimileren meer lessen uit ervaringen in het veld, met andere praktijken te gebruiken. In de tweede editie van Extreme Programming Explained, vijf jaar na de eerste editie, Beck meer waarden en praktijken en gedifferentieerd tussen primaire en uitvloeisel praktijken toegevoegd.

Concept

Doelen

Extreme Programming Explained beschrijft extreme programmering als een software-ontwikkeling discipline die organiseert mensen om een ​​hogere kwaliteit van software productiever te produceren.

XP probeert de kosten van wijzigingen in de eisen verminderen door het hebben van meerdere korte ontwikkelcycli, in plaats van een lang. In deze leer, veranderingen zijn een natuurlijk, onvermijdelijk en wenselijk aspect van software-ontwikkeling van projecten en moeten worden gepland voor, in plaats van een poging om een ​​stabiele set van eisen te definiëren.

Extreme programmering introduceert ook een aantal fundamentele waarden, principes en praktijken op de top van de agile programmeringskader.

Activiteiten

XP beschrijft vier fundamentele activiteiten die worden uitgevoerd binnen het software ontwikkel proces: het coderen, testen, luisteren, en het ontwerpen. Elk van deze activiteiten wordt hieronder beschreven.

Codering

De voorstanders van XP betogen dat de enige echt belangrijk product van de ontwikkeling van het systeem proces is code - software-instructies die een computer kan interpreteren. Zonder code, is er geen werkende product.

Codering kan ook worden gebruikt om te achterhalen wat de meest geschikte oplossing. Codering kan ook helpen om gedachten over de programmering problemen communiceren. Een programmeur omgaan met een complexe programmering probleem, of vinden het moeilijk om de oplossing aan collega-programmeurs uit te leggen, kan het coderen op een vereenvoudigde wijze en gebruik de code te laten zien wat hij of zij bedoelt. Code, zeggen de voorstanders van deze positie, is altijd duidelijk en beknopt en kunnen niet worden uitgelegd in meer dan één manier. Andere programmeurs kunnen feedback over deze code te geven door ook het coderen van hun gedachten.

Testen

Extreme programmering van aanpak is dat als een kleine test enkele gebreken te elimineren, veel getest veel meer gebreken elimineren.

  • Unit tests bepalen of een bepaalde functie werkt zoals bedoeld. Een programmeur schrijft zoveel geautomatiseerde tests als ze kunnen bedenken dat zou kunnen 'breken' van de code; Als alle tests met succes, dan is de codering is voltooid. Elk stuk van de code die is geschreven wordt getest voordat u naar de volgende functie.
  • Acceptatietests controleren of de eisen zoals begrepen door de programmeurs aan de werkelijke behoeften van de klant.

Systeembrede integratie testen werd aangemoedigd aanvankelijk als dagelijkse einde van de dag activiteit voor de vroegtijdige opsporing van onverenigbare interfaces te verbinden voordat de afzonderlijke secties sterk afweek van coherente functionaliteit. Echter, systeembrede integratie testen verlaagd, wekelijks of minder vaak, afhankelijk van de stabiliteit van de totale interfaces in het systeem.

Het luisteren

Programmeurs moeten naar wat de klanten nodig hebben van het systeem te doen, wat de "business logic" is nodig luisteren. Zij moeten begrijpen deze behoeften hoog in de feedback van de klant te geven over de technische aspecten van hoe het probleem kan worden opgelost of niet opgelost. De communicatie tussen de klant en programmeur wordt verder behandeld in de planning spel.

Ontwerpen

Vanuit het oogpunt van eenvoud Natuurlijk kan men zeggen dat ontwikkelsysteem niet meer dan coderen, testen en luisteren nodig. Indien deze activiteiten goed worden uitgevoerd, moet het resultaat steeds een systeem dat werkt zijn. In de praktijk zal deze niet werken. Men kan een lange weg afgelegd, zonder het ontwerpen, maar op een gegeven moment zal men vast komen te zitten. Wordt het systeem te complex en de afhankelijkheden binnen het systeem niet langer duidelijk zijn. Men kan dit voorkomen door een ontwerpstructuur de logica organiseert in het systeem. Goed ontwerp voorkomt veel afhankelijkheden binnen een systeem; Dit betekent dat het veranderen van een deel van het systeem geen invloed op andere delen van het systeem.

Waarden

Extreme programmering aanvankelijk opgenomen vier waarden in 1999: communicatie, eenvoud, feedback, en moed. Een nieuwe waarde, respect, werd toegevoegd in de tweede editie van Extreme Programming Explained. Deze vijf waarden worden hieronder beschreven.

Communicatie

Het bouwen van software systemen vereist communiceren systeemvereisten voor de ontwikkelaars van het systeem. In formele software-ontwikkeling methodieken, wordt deze taak volbracht door middel van documentatie. Extreme Programming technieken kunnen worden beschouwd als methoden voor het snel opbouwen en verspreiden van institutionele kennis tussen de leden van een ontwikkelingsteam. Het doel is om alle ontwikkelaars een gemeenschappelijk zicht op het systeem dat overeenkomt met de mening van de gebruikers van het systeem. Daartoe extreme programmering gunsten eenvoudige ontwerpen, gemeenschappelijke metaforen, medewerking van de gebruikers en programmeurs, frequente verbale communicatie en feedback.

Eenvoud

Extreme Programming moedigt beginnen met de eenvoudigste oplossing. Extra functionaliteit kan later worden toegevoegd. Het verschil tussen deze benadering en de meer conventionele systeemontwikkeling methoden is de focus op het ontwerpen en coderen voor de behoeften van vandaag in plaats van die van morgen, volgende week of volgende maand. Dit wordt soms samengevat als "U bent niet gaat nodig hebben" aanpak. Voorstanders van XP erkennen het nadeel dat dit soms kan leiden tot meer inspanning morgen om het systeem te veranderen; hun claim is dat dit meer dan gecompenseerd door de voordelen van het investeren niet in mogelijke toekomstige eisen die kunnen veranderen voordat ze relevant geworden. Codering en het ontwerpen voor onzekere toekomstige eisen impliceert het risico van de uitgaven middelen op iets dat niet nodig zou zijn, terwijl het misschien uitstellen cruciale functies. Naar de "communicatie" waarde gerelateerd, moet eenvoud in design en codering van de kwaliteit van de communicatie te verbeteren. Een eenvoudig ontwerp met een zeer eenvoudige code kan gemakkelijk worden begrepen door de meeste programmeurs in het team.

Terugkoppeling

In extreme programmering, feedback betrekking op verschillende dimensies van de ontwikkeling van het systeem:

  • Feedback van het systeem: door het schrijven van unit tests, of het uitvoeren van periodieke integratie testen, de programmeurs hebben directe feedback van de toestand van het systeem na het doorvoeren van veranderingen.
  • Feedback van de klant: De functionele tests zijn geschreven door de klant en de testers. Zij zullen concrete feedback over de huidige staat van hun systeem te krijgen. Deze beoordeling wordt een keer gepland in de twee of drie weken, zodat de klant gemakkelijk kan sturen de ontwikkeling.
  • Feedback van het team: Wanneer klanten komen met nieuwe eisen aan de planning spel het team direct geeft een schatting van de tijd die het duurt om uit te voeren.

Terugkoppeling is nauw verwant aan communicatie en eenvoud. Gebreken in het systeem gemakkelijk gecommuniceerd door het schrijven van een unit test die bewijst een bepaald stuk code zal breken. De directe feedback van het systeem vertelt programmeurs om dit deel hercoderen. Een klant is in staat om het systeem te testen periodiek volgens de functionele eisen, genoemd gebruikersverhalen. Kent Beck te citeren, "Optimisme is een beroepsrisico van de programmering. Feedback is de behandeling."

Moed

Verschillende praktijken belichamen moed. Een daarvan is het gebod om altijd te ontwerpen en code voor vandaag en niet voor morgen. Dit is een poging om te voorkomen dat je verzanden in ontwerp en vereisen een veel moeite om uit te voeren iets anders. Moed stelt ontwikkelaars in staat om comfortabel met refactoring hun code indien nodig te voelen. Dit betekent herziening van het bestaande systeem en modificeren zodat toekomstige wijzigingen gemakkelijker kan worden uitgevoerd. Een ander voorbeeld van moed is te weten wanneer je moet code weg te gooien: de moed om de broncode te verwijderen dat is verouderd, het maakt niet uit hoe veel moeite werd gebruikt om die broncode te creëren. Ook moed betekent doorzettingsvermogen: Een programmeur kan worden geplakt op een complex probleem voor een hele dag, dan is het probleem op te lossen snel de volgende dag, maar alleen als ze zijn hardnekkig.

Eerbied

Het respect waarde omvat respect voor anderen en zelfrespect. Programmeurs moet nooit veranderingen die compilatie te breken, die deel uitmaken van de bestaande unit-tests mislukt, of dat het werk van hun collega's op andere wijze vertragen plegen. Leden respect voor hun eigen werk door altijd streven naar hoge kwaliteit en op zoek naar het beste ontwerp voor de oplossing bij de hand door middel van refactoring.

De vaststelling van de vier eerdere waarden leidt om respect opgedaan met anderen in het team. Niemand in het team moet ondergewaardeerd of genegeerd voelen. Dit zorgt voor een hoge mate van motivatie en moedigt loyaliteit richting het team en in de richting van het doel van het project. Deze waarde is erg afhankelijk van de andere waarden, en is sterk gericht mensen in een team.

Reglement

De eerste versie van de regels voor XP werd gepubliceerd in 1999 door Don Wells op de XP-website. 29 regels worden gegeven in de categorieën van de planning, het beheer, het ontwerpen, coderen en testen. Planning, het beheer en het ontwerpen worden opgeroepen expliciet op claims dat XP niet ondersteunt deze activiteiten tegen te gaan.

Een andere versie van XP regels werd voorgesteld door Ken Auer in XP / Agile Universe 2003. Hij voelde XP werd bepaald door de regels, niet zijn praktijken. Hij definieerde twee categorieën: "Rules of Engagement", die de omgeving waarin de ontwikkeling van software plaatsvinden effectief kunnen nemen dicteren, en "Spelregels", die de activiteiten en de regels van minuut tot minuut te definiëren in het kader van de Rules of Engagement.

Principes

De principes die de basis vormen van XP zijn gebaseerd op de waarden juist beschreven en zijn bedoeld om beslissingen te nemen in een systeem ontwikkeling project te bevorderen. De principes zijn bedoeld concreter dan de waarden en gemakkelijker vertaald naar begeleiding in praktijk zijn.

Terugkoppeling

Extreme programmering ziet feedback als het meest bruikbaar als het vaak en snel wordt gedaan. Hij benadrukt dat de minimale vertraging tussen een actie en de feedback is cruciaal voor het leren en het aanbrengen van wijzigingen. In tegenstelling tot de traditionele ontwikkeling van het systeem methoden, contact met de klant gebeurt in frequentere iteraties. De klant heeft een helder inzicht in het systeem dat wordt ontwikkeld, en kan feedback geven en sturen de ontwikkeling als dat nodig is. Met frequente feedback van de klant, zal een verkeerd ontwerp beslissing gemaakt door de ontwikkelaar worden opgemerkt en snel verholpen, voordat de ontwikkelaar besteedt veel tijd de uitvoering ervan.

Unit tests bijdragen tot een snelle terugkoppeling principe. Bij het schrijven van code, het uitvoeren van de unit test geeft direct feedback over hoe het systeem reageert op de veranderingen. Dit omvat het uitvoeren van niet alleen de unit tests die code van de ontwikkelaar te testen, maar draait bovendien alle unit tests tegen alle software, met behulp van een geautomatiseerd proces dat kan worden gestart door een enkel commando. Op die manier, als er wijzigingen van de ontwikkelaar veroorzaken van een storing in een ander gedeelte van het systeem dat de ontwikkelaar weet weinig of niets over de geautomatiseerde alles-unit-testsuite zal het niet direct zichtbaar, de waarschuwing van de ontwikkelaar van de onverenigbaarheid van zijn verandering andere delen van het systeem, en de noodzaak van het verwijderen of wijzigen van zijn verandering. Onder traditionele ontwikkeling praktijken, het ontbreken van een geautomatiseerde, uitgebreide unit-test suite betekende dat een dergelijke code verandering, aangenomen onschadelijk door de ontwikkelaar, zou zijn blijven zitten, verschijnen alleen tijdens integratie testen - of erger nog, alleen in de productie; en het bepalen welke code verandering het probleem veroorzaakt, onder alle wijzigingen die door de ontwikkelaars tijdens de weken of zelfs maanden voorafgaand aan integratie testen, was een enorme taak.

Ervan uitgaande dat de eenvoud

Dit is over de behandeling van elk probleem als de oplossing ervan waren "zeer eenvoudig". Traditionele systeemontwikkeling methoden zeggen om plannen voor de toekomst en om te coderen voor hergebruik. Extreme programmering verwerpt deze ideeën.

De voorstanders van extreme programmering zeggen dat het maken van grote veranderingen in een keer werkt niet. Extreme programmering geldt incrementele veranderingen: bijvoorbeeld, kan een systeem van kleine releases elke drie weken. Als er veel kleine stappen zijn gemaakt, heeft de klant meer controle over het ontwikkelingsproces en het systeem dat wordt ontwikkeld.

Omarmen verandering

Het principe van het omarmen verandering is over het niet werken tegen veranderingen, maar omarmen hen. Bijvoorbeeld, als in een van de iteratieve vergaderingen blijkt dat de eisen van de klant drastisch zijn veranderd, programmeurs zijn om dit te omarmen en het plan van de nieuwe eisen voor de volgende iteratie.

Praktijken

Extreme programmering is beschreven met 12 praktijken in vier gebieden:

Fijnschalige feedback

  • Pair programming
  • Planning spel
  • Test-driven development
  • Hele team

Continu proces

  • Continue integratie
  • Refactoring of ontwerp verbetering
  • Kleine releases

Gedeeld begrip

  • Coderingsnormen
  • Collectieve code eigendom
  • Eenvoudig ontwerp
  • Systeem metafoor

Welzijn programmeur

  • Duurzame tempo

Codering

  • De klant is altijd beschikbaar
  • Code De unit test eerste
  • Slechts één paar integreert code per keer
  • Verlaat optimalisatie tot het laatst
  • Geen overuren

Testen

  • Alle code moet unit tests
  • Alle code moet al unit tests doorstaan ​​voordat het kan worden vrijgegeven.
  • Als er een bug is gevonden tests worden gemaakt voordat de bug is gericht
  • Acceptatietesten worden vaak uitgevoerd en de resultaten zijn gepubliceerd

Controversiële aspecten

De praktijken in XP zijn zwaar gedebatteerd. Voorstanders van extreme programmering beweren dat door het hebben van het verzoek van de klant op het terrein verandert informeel, wordt het proces flexibel, en bespaart de kosten van formele overhead. Critici van XP beweren dat dit kan leiden tot dure rework en project scope creep dan wat eerder werd overeengekomen of gefinancierd.

Change-control boards zijn een teken dat er potentiële conflicten in de doelstellingen van het project en de beperkingen tussen meerdere gebruikers. Versnelde methoden XP zijn enigszins afhankelijk van programmeurs in staat om een ​​uniforme client standpunt aannemen, zodat de programmeur kan concentreren op codering, in plaats van de documentatie van de doelstellingen en beperkingen compromis. Dit geldt ook wanneer er meerdere programmering organisaties betrokken, met name organisaties die strijden voor de aandelen van de projecten.

Andere potentieel controversiële aspecten van extreme programmering zijn onder meer:

  • Eisen worden uitgedrukt als geautomatiseerde acceptatietesten plaats specificatie documenten.
  • Eisen worden stapsgewijs gedefinieerd, in plaats van te proberen om ze allemaal op voorhand.
  • Software-ontwikkelaars zijn meestal verplicht om te werken in tweetallen.
  • Er is geen grote design Up Front. Het grootste deel van het ontwerp activiteit vindt plaats op de vlieg en stapsgewijs, te beginnen met "de eenvoudigste ding dat zou kunnen werken" en het toevoegen van de complexiteit alleen wanneer het nodig is door niet testen. Critici vergelijk dit met "debuggen van een systeem in het uiterlijk 'en vrezen dit zal resulteren in meer re-design inspanning dan alleen opnieuw ontwerpen als eisen veranderen.
  • Een klant vertegenwoordiger aan het project verbonden. Deze rol kan een single-point-of-failure geworden voor het project, en sommige mensen vonden het een bron van stress. Ook bestaat het gevaar van micro-beheer door een niet-technisch vertegenwoordiger probeert het gebruik van technische software kenmerkende elementen dicteren.
  • Afhankelijkheid van alle andere aspecten van XP. "XP is als een ring van giftige slangen, daisy-chaining samen Al duurt het is een van hen onderuit los, en je een zeer boze, giftige slang op je af hebt. "

Schaalbaarheid

Historisch, XP werkt alleen op teams van twaalf of minder mensen. Een manier om deze beperking te omzeilen is om te breken het project in kleinere stukken en het team in kleinere groepen. Er werd beweerd dat XP is met succes gebruikt op teams van meer dan honderd ontwikkelaars. ThoughtWorks heeft redelijk succes op gedistribueerde XP projecten met maximaal zestig mensen beweerden.

In 2004 werd de industriële extreme programmering geïntroduceerd als een evolutie van XP. Het is bedoeld om het vermogen om te werken in grote en verspreide teams brengen. Het heeft nu 23 praktijken en flexibel waarden. Omdat het een nieuw lid van de Agile familie, is er niet genoeg gegevens om de bruikbaarheid te bewijzen; maar het beweert te zijn een antwoord op wat het ziet als onvolkomenheden XP zijn.

Scheidbaarheid en reacties

In 2003, Matt Stephens en Doug Rosenberg gepubliceerd Extreme Programming herwerkt: De zaak tegen XP, waarbij de waarde van de XP-proces ondervraagd en suggereerde manieren waarop het kan worden verbeterd. Dit leidde tot een lang debat in artikelen, internet nieuwsgroepen en website chat areas. De kern argument van het boek is dat de praktijken van XP zijn van elkaar afhankelijk, maar dat weinig praktische organisaties zijn bereid / in staat om alle praktijken te nemen; dus het gehele proces mislukt. Het boek maakt ook andere punten van kritiek, en het trekt een gelijkenis van XP "collectieve eigendom" model om het socialisme op een negatieve manier.

Bepaalde aspecten van XP zijn veranderd sinds de publicatie van Extreme Programming herwerkt; met name, XP biedt nu modificaties van de werkwijzen zolang de gewenste doelstellingen wordt voldaan. XP gebruikt ook steeds meer generieke termen voor processen. Sommigen beweren dat deze veranderingen ongeldig eerdere kritiek; anderen beweren dat dit is gewoon het besproeien van het proces naar beneden.

Andere auteurs hebben geprobeerd om XP te verzoenen met de oudere methoden om een ​​uniforme methodiek vormen. Sommige XP getracht te vervangen, zoals de waterval methode; Bijvoorbeeld: Project Lifecycles: Waterval, Rapid Application Development, en All That. JPMorgan Chase & amp; Co geprobeerd combineren XP met de computer programmeren methoden Capability Maturity Model integratie, en Six Sigma. Zij vonden dat de drie systemen versterkt elkaar goed, wat leidt tot een betere ontwikkeling en niet met elkaar in tegenspraak.

Kritiek

Extreme programmering van de eerste buzz en controversiële leerstellingen, zoals pair programming en continue ontwerp, hebben vooral kritiek, zoals die uit McBreen en Boehm en Turner., Matt Stephens en Doug Rosenberg aangetrokken. Veel van de kritiek, maar worden verondersteld door Agile beoefenaars om misverstanden van agile ontwikkeling.

In het bijzonder, extreme programmering is beoordeeld en bekritiseerd door Matt Stephens en Doug Rosenberg Extreme Programming herwerkt.

Kritiek onder andere:

  • een methodologie is zo effectief als de betrokken mensen, is Agile niet dit op te lossen
  • vaak gebruikt als middel om geld randen van klanten door gebrek aan die een deliverable product
  • gebrek aan structuur en de nodige documentatie
  • werkt alleen met senior-level ontwikkelaars
  • bevat onvoldoende software design
  • vereist bijeenkomsten met regelmatige tussenpozen met enorme kosten voor klanten
  • vergt te veel culturele verandering te nemen
  • kan leiden tot meer moeilijke contractonderhandelingen
  • kan zeer inefficiënt zijn; of aan de vereisten voor een gebied van de code verandering door verschillende iteraties, kan het nodig zijn dezelfde programmering meerdere malen over worden gedaan. Overwegende dat indien een plan er moet worden gevolgd, wordt een enkel gebied van de code naar verwachting één keer worden beschreven.
  • onmogelijk om realistische inschattingen van het werk inspanning die nodig is om een ​​offerte te bieden, want aan het begin van het project niemand kent de hele scope / eisen te ontwikkelen
  • kan het risico van scope creep toenemen als gevolg van het gebrek aan gedetailleerde documentatievereisten
  • Agile-functie is gedreven; niet-functionele kwaliteit attributen hard gebruikersverhalen worden geplaatst.
(0)
(0)
Commentaren - 0
Geen commentaar

Voeg een reactie

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Tekens over: 3000
captcha