Wat is agile methodologie? Moderne softwareontwikkeling uitgelegd

Elke technologieorganisatie lijkt tegenwoordig de agile methodologie voor softwareontwikkeling, of een versie daarvan, toe te passen. Of ze denken tenminste dat ze dat doen. Of u nu nieuw bent in agile applicatieontwikkeling of decennia geleden softwareontwikkeling hebt geleerd met behulp van de watervalsoftwareontwikkelingsmethodologie, tegenwoordig wordt uw werk op zijn minst beïnvloed door de agile-methodologie.

Maar wat is agile methodologie en hoe moet deze worden toegepast bij softwareontwikkeling? Hoe verschilt agile ontwikkeling in de praktijk van waterval? Wat is de agile levenscyclus van softwareontwikkeling, of agile SDLC? En wat is scrum agile versus Kanban en andere agile modellen? 

Agile werd formeel gelanceerd in 2001 toen 17 technologen het Agile Manifesto opstelden. Ze schreven vier belangrijke principes voor agile projectmanagement, met als doel betere software te ontwikkelen:

  • Individuen en interacties over processen en tools
  • Werkende software boven uitgebreide documentatie
  • Klantensamenwerking boven contractonderhandelingen
  • Reageren op omschakeling volgens een plan

Voordat agile: het tijdperk van de watervalmethodologie

Oude rotten zoals ik herinneren zich de dagen dat de watervalmethodologie de gouden standaard was voor softwareontwikkeling. Het softwareontwikkelingsproces vereiste een hoop documentatie vooraf voordat er met codering begon. Iemand, meestal de bedrijfsanalist, schreef eerst een document met zakelijke vereisten waarin alles werd vastgelegd wat het bedrijf nodig had in de applicatie. Deze documenten met zakelijke vereisten waren lang en bevatten alles: algemene strategie, uitgebreide functionele specificaties en visuele gebruikersinterfaceontwerpen.

Technologen namen het document met zakelijke vereisten en ontwikkelden hun eigen document met technische vereisten. Dit document definieerde de architectuur van de applicatie, datastructuren, objectgeoriënteerde functionele ontwerpen, gebruikersinterfaces en andere niet-functionele vereisten.

Dit ontwikkelingsproces voor watervalsoftware zou uiteindelijk beginnen met coderen, vervolgens integreren en uiteindelijk testen voordat een applicatie als productieklaar werd beschouwd. Het hele proces kan gemakkelijk een paar jaar duren.

Van ons ontwikkelaars werd verwacht dat we 'de specificatie' kenden, zoals de volledige documentatie werd genoemd, net zo goed als de auteurs van de documenten, en we werden vaak bestraft als we vergaten om een ​​belangrijk detail op pagina 77 van een 200- pagina document.

Softwareontwikkeling zelf was toen ook niet eenvoudig. Veel ontwikkeltools vereisten gespecialiseerde training, en er waren nergens in de buurt van de open source of commerciële softwarecomponenten, API's en webservices die tegenwoordig bestaan. We moesten dingen op laag niveau ontwikkelen, zoals het openen van databaseverbindingen en het multithreading van onze gegevensverwerking.

Zelfs voor basistoepassingen waren de teams groot en waren de communicatiemiddelen beperkt. Onze technische specificaties waren wat ons op één lijn bracht, en we gebruikten ze zoals de Bijbel. Als een vereiste veranderde, zouden we de bedrijfsleiders door een lang proces van beoordeling en afmelding leiden, omdat het doorgeven van wijzigingen binnen het team en het repareren van code duur was.

Omdat de software is ontwikkeld op basis van de technische architectuur, werden eerst artefacten op een lager niveau ontwikkeld en daarna afhankelijke artefacten. Taken werden toegewezen door vaardigheid, en het was gebruikelijk dat database-ingenieurs eerst de tabellen en andere database-artefacten construeerden, gevolgd door de applicatie-ontwikkelaars die de functionaliteit en bedrijfslogica codeerden, en ten slotte werd de gebruikersinterface bedekt. Het duurde maanden voordat iemand de applicatie zag werken en tegen die tijd begonnen de belanghebbenden antsy en vaak slimmer te worden over wat ze echt wilden. Geen wonder dat het doorvoeren van wijzigingen zo duur was!

Niet alles wat u voor gebruikers neerzet, werkte zoals verwacht. Soms zouden gebruikers een functie helemaal niet gebruiken. Andere keren was een mogelijkheid alom succesvol, maar moest opnieuw worden ontworpen om de noodzakelijke schaalbaarheid en prestaties te ondersteunen. In de watervalwereld leerde je deze dingen pas nadat de software was ingezet, na een lange ontwikkelcyclus.

Gerelateerde video: hoe de agile-methodologie echt werkt

Iedereen lijkt het over agile softwareontwikkeling te hebben, maar veel organisaties hebben geen goed zicht op hoe het proces werkt. Bekijk deze video van vijf minuten om snel aan de slag te gaan.

De spil naar agile softwareontwikkeling

De watervalmethodologie, uitgevonden in 1970, was revolutionair omdat het discipline bracht in de softwareontwikkeling om ervoor te zorgen dat er een duidelijke specificatie volgde. Het was gebaseerd op de watervalproductiemethode die was afgeleid van Henry Ford's innovaties aan de lopende band uit 1913, die zekerheid gaven bij elke stap in het productieproces om te garanderen dat het eindproduct overeenkwam met wat in de eerste plaats was gespecificeerd.

Toen de watervalmethodologie naar de softwarewereld kwam, waren computersystemen en hun toepassingen doorgaans complex en monolithisch, waarvoor een discipline en een duidelijk resultaat nodig waren. De eisen veranderden ook langzaam in vergelijking met vandaag, zodat grootschalige inspanningen minder problematisch waren. In feite werden systemen gebouwd in de veronderstelling dat ze niet zouden veranderen, maar dat het eeuwige oorlogsschepen zouden zijn. Tijdsbestekken van meerdere jaren waren niet alleen gebruikelijk bij softwareontwikkeling, maar ook bij productie en andere bedrijfsactiviteiten. Maar de starheid van de waterval werd een achilleshiel in het internettijdperk, waar snelheid en flexibiliteit vereist waren.

De methodologie voor softwareontwikkeling begon te veranderen toen ontwikkelaars aan internettoepassingen begonnen te werken. Veel van het vroege werk werd gedaan bij startups waar teams kleiner waren, colocated waren en vaak geen traditionele computerwetenschappelijke achtergrond hadden. Er was financiële en concurrentiedruk om websites, applicaties en nieuwe mogelijkheden sneller op de markt te brengen. De ontwikkeltools en -platforms veranderden snel als reactie daarop.

Dit bracht velen van ons die in startups werkten ertoe de watervalmethodologie in twijfel te trekken en naar manieren te zoeken om efficiënter te werken. We konden het ons niet veroorloven om alle gedetailleerde documentatie vooraf te doen, en we hadden een meer iteratief en samenwerkend proces nodig. We hebben nog steeds gedebatteerd over wijzigingen in de vereisten, maar we stonden meer open voor experimenten en voor aanpassing aan de behoeften van eindgebruikers. Onze organisaties waren minder gestructureerd en onze applicaties waren minder complex dan legacysystemen van bedrijven, dus we stonden veel meer open voor het bouwen of kopen van applicaties. Wat nog belangrijker was, we probeerden bedrijven te laten groeien, dus als onze gebruikers ons vertelden dat er iets niet werkte, kozen we er vaker voor om naar hen te luisteren.

Onze vaardigheden en ons vermogen om te innoveren werden strategisch belangrijk. Je zou al het geld kunnen inzamelen dat je wilde, maar je zou geen getalenteerde softwareontwikkelaars kunnen aantrekken die in staat zijn om te werken met snel veranderende internettechnologieën als je ze zou behandelen als ondergeschikte codeerders die slaafs "de specificatie" volgden. We wezen projectmanagers af die binnenkwamen met end-to-end-schema's waarin werd beschreven wat we moesten ontwikkelen, wanneer applicaties zouden moeten worden verzonden en soms zelfs hoe de code moest worden gestructureerd. We waren vreselijk in het halen van de drie- en zesmaandelijkse schema's die de projectmanagers van de waterval hadden opgesteld en voortdurend bijgewerkt.

In plaats daarvan begonnen we hen te vertellen hoe internettoepassingen moesten worden ontworpen, en we leverden resultaten op volgens een planning die we iteratief hadden opgesteld. Het blijkt dat we niet zo slecht waren in het leveren van wat we beloofden als we ons ervoor inzetten met kleine tussenpozen van een week tot vier weken.

In 2001 kwam een ​​groep ervaren softwareontwikkelaars bij elkaar en realiseerde zich dat ze gezamenlijk softwareontwikkeling anders beoefenden dan de klassieke watervalmethodologie. En ze zaten niet allemaal in startups. Deze groep, waaronder technologieleden Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber en Jeff Sutherland, kwam met het Agile Manifesto waarin hun gedeelde opvattingen over hoe een modern softwareontwikkelingsproces zou moeten werken, werden gedocumenteerd. Ze legden de nadruk op samenwerking boven documentatie, op zelforganisatie in plaats van op rigide managementpraktijken en op het vermogen om constant te veranderen in plaats van jezelf op te sluiten in een rigide watervalontwikkelingsproces.

Uit die principes ontstond de agile methodologie voor softwareontwikkeling.

De rollen in de agile methodiek

Een agile softwareontwikkelingsproces begint altijd met het definiëren van de gebruikers en het documenteren van een visieverklaring over een reeks problemen, kansen en waarden die moeten worden aangepakt. De producteigenaar legt deze visie vast en werkt met een multidisciplinair team (of teams) om deze visie waar te maken. Hier zijn de rollen in dat proces.

Gebruiker

Agile processen beginnen altijd met de gebruiker of klant in gedachten. Tegenwoordig definiëren we ze vaak met gebruikerspersonages om verschillende rollen in een workflow die de software ondersteunt of verschillende soorten klantbehoeften en -gedragingen te illustreren.

Product eigenaar

Het agile ontwikkelproces zelf begint bij iemand die de stem van de klant moet zijn, inclusief eventuele interne stakeholders. Die persoon distilleert alle inzichten, ideeën en feedback om een ​​productvisie te creëren. Deze productvisies zijn vaak kort en duidelijk, maar geven niettemin een beeld van wie de klant is, welke waarden worden aangesproken en een strategie om deze aan te pakken. Ik kan me voorstellen dat de oorspronkelijke visie van Google er ongeveer zo uitzag als: "Laten we het iedereen met internettoegang gemakkelijk maken om relevante websites en webpagina's te vinden met een eenvoudige, trefwoordgestuurde interface en een algoritme dat betrouwbare bronnen hoger in de zoekresultaten plaatst."

We noemen deze persoon de product owner . Zijn of haar verantwoordelijkheid is om deze visie te definiëren en vervolgens met een ontwikkelingsteam samen te werken om deze waar te maken.

Om met het ontwikkelingsteam samen te werken, splitst de producteigenaar de productvisie op in een reeks gebruikersverhalen die in meer detail beschrijven wie de beoogde gebruiker is, welk probleem voor hen wordt opgelost, waarom de oplossing belangrijk voor hen is, en welke beperkingen en acceptatiecriteria de oplossing definiëren. Deze gebruikersverhalen krijgen prioriteit van de producteigenaar, beoordeeld door het team om ervoor te zorgen dat ze een gedeeld begrip hebben van wat er van hen wordt gevraagd.

Software ontwikkelingsteam

Bij agile verschillen het ontwikkelteam en de verantwoordelijkheden van zijn leden van die bij traditionele softwareontwikkeling.

Teams zijn multidisciplinair en bestaan ​​uit een diverse groep mensen met de vaardigheden om de klus te klaren. Omdat de focus ligt op het leveren van werkende software, moet het team end-to-end functionerende applicaties voltooien. Dus de database, bedrijfslogica en gebruikersinterface van een deel van de applicatie worden ontwikkeld en vervolgens gedemonstreerd - niet de hele applicatie. Om dit te doen, moeten de teamleden samenwerken. Ze komen regelmatig bijeen om ervoor te zorgen dat iedereen op één lijn zit met wat ze bouwen, wie wat doet en hoe de software precies wordt ontwikkeld.

Naast ontwikkelaars kunnen softwareontwikkelingsteams bestaan ​​uit ingenieurs voor kwaliteitsborging (QA), andere ingenieurs (zoals voor databases en back-endsystemen), ontwerpers en analisten, afhankelijk van het type softwareproject.

Scrum, Kanban en andere agile frameworks

Veel agile frameworks die specifieke informatie bieden over ontwikkelingsprocessen en agile ontwikkelingspraktijken, afgestemd op de levenscyclus van softwareontwikkeling.

Het meest populaire agile framework heet scrum . Het richt zich op een aflevercadans, een sprint genaamd, en vergaderstructuren die het volgende omvatten:

  • Planning - waar sprintprioriteiten worden geïdentificeerd
  • Commitment - waar het team een ​​lijst of achterstand van gebruikersverhalen beoordeelt en beslist hoeveel werk er kan worden verzet tijdens de duur van de sprint 
  • Dagelijkse stand-up meetings - zodat teams updates over hun ontwikkelingsstatus en strategieën kunnen communiceren)

Sprints eindigen met een demo-meeting waar de functionaliteit aan de product owner getoond wordt, gevolgd door een retrospective meeting waar het team bespreekt wat er goed ging en wat er verbeterd moet worden in hun proces.

Veel organisaties gebruiken scrum-masters of coaches om teams te helpen het scrumproces te beheren.

Hoewel scrum domineert, zijn er andere agile frameworks:

  • Kanban werkt als een fan-in en fan-out proces waarbij het team user stories van een intake board haalt en ze door een gefaseerd ontwikkelingsproces leidt totdat ze zijn voltooid.
  • Sommige organisaties hanteren een hybride agile en watervalbenadering, waarbij ze agile processen gebruiken voor nieuwe applicaties en waterval voor legacy-applicaties.
  • Er zijn ook verschillende kaders om organisaties in staat te stellen de praktijk naar meerdere teams te schalen.

Terwijl agile frameworks proces en samenwerking definiëren, zijn agile ontwikkelingspraktijken specifiek voor het aanpakken van softwareontwikkelingstaken die worden uitgevoerd in overeenstemming met een agile framework.

Dus bijvoorbeeld:

  • Sommige teams passen pair-programmering toe, waarbij twee ontwikkelaars samen coderen om code van hogere kwaliteit te genereren en om meer senior ontwikkelaars in staat te stellen junior-ontwikkelaars te begeleiden.
  • Meer geavanceerde teams passen testgestuurde ontwikkeling en automatisering toe om ervoor te zorgen dat de onderliggende functionaliteit de verwachte resultaten oplevert.
  • Veel teams passen ook technische standaarden toe, zodat de interpretatie van een gebruikersverhaal door de ontwikkelaar niet alleen leidt tot de gewenste functionaliteit, maar ook voldoet aan beveiliging, codekwaliteit, naamgevingsconventies en andere technische standaarden.

Waarom de agile-methodologie beter is