Enhver teknologiorganisation i dag ser ud til at praktisere den smidige metode til softwareudvikling eller en version af den. Eller i det mindste tror de, de gør det. Uanset om du er ny inden for agil applikationsudvikling, eller du har lært softwareudvikling for årtier siden ved hjælp af metoden til udvikling af vandfaldssoftware, er dit arbejde i dag i det mindste påvirket af den agile metode.
Men hvad er agil metode, og hvordan skal den praktiseres i softwareudvikling? Hvordan adskiller agil udvikling sig fra vandfald i praksis? Hvad er den agile softwareudviklingslivscyklus eller smidig SDLC? Og hvad er scrum agile versus Kanban og andre smidige modeller?
Agile blev formelt lanceret i 2001, da 17 teknologer udarbejdede Agile Manifesto. De skrev fire hovedprincipper for agil projektledelse med det mål at udvikle bedre software:
- Enkeltpersoner og interaktioner over processer og værktøjer
- Arbejder software over omfattende dokumentation
- Kundesamarbejde over kontraktforhandling
- Svar på at skifte efter en plan
Før agil: æra med vandfaldsmetodologi
Gamle hænder som mig husker de dage, hvor vandfaldsmetoden var guldstandarden for softwareudvikling. Softwareudviklingsprocessen krævede masser af dokumentation foran, før kodning startede. Nogen, som regel forretningsanalytikeren, skrev først et forretningskravsdokument, der fangede alt, hvad virksomheden havde brug for i applikationen. Disse forretningskravsdokumenter var lange og detaljerede alt: overordnet strategi, omfattende funktionelle specifikationer og visuelt design af brugergrænseflader.
Teknologer tog forretningskravdokumentet og udviklede deres egne tekniske kravsdokument. Dette dokument definerede applikationens arkitektur, datastrukturer, objektorienterede funktionelle design, brugergrænseflader og andre ikke-funktionelle krav.
Denne udvikling af software til vandfaldssoftware vil endelig starte kodning, derefter integration og endelig test, før en applikation blev anset for at være produktionsklar. Hele processen kunne let tage et par år.
Det forventedes, at vi udviklere kendte “spec”, som den komplette dokumentation blev kaldt, lige så godt som dokumentforfatterne gjorde, og vi blev ofte tuktet, hvis vi glemte at implementere en nøgledetalje skitseret på side 77 i en 200- side dokument.
Dengang var selve softwareudviklingen heller ikke let. Mange udviklingsværktøjer krævede specialuddannelse, og der var ikke i nærheden af open source eller kommercielle softwarekomponenter, API'er og webservices, der findes i dag. Vi var nødt til at udvikle ting på lavt niveau, såsom åbning af databaseforbindelser og multithreading af vores databehandling.
Selv for grundlæggende applikationer var holdene store, og kommunikationsværktøjerne var begrænsede. Vores tekniske specifikationer tilpassede os, og vi udnyttede dem som Bibelen. Hvis et krav ændrede sig, ville vi sætte forretningslederne igennem en lang gennemgangsproces og afmelde, fordi det var dyrt at kommunikere ændringer på tværs af teamet og fastsætte kode.
Da softwaren blev udviklet baseret på den tekniske arkitektur, blev artefakter på lavere niveau udviklet først og afhængige artefakter bagefter. Opgaver blev tildelt efter dygtighed, og det var almindeligt, at databaseingeniører først konstruerede tabellerne og andre databaseartefakter efterfulgt af applikationsudviklerne, der kodede funktionaliteten og forretningslogikken, og derefter blev brugergrænsefladen til sidst overlejret. Det tog måneder, før nogen så applikationen fungere, og inden da blev interessenterne antsy og ofte klogere på, hvad de virkelig ønskede. Ikke underligt at implementere ændringer var så dyre!
Ikke alt, hvad du placerede foran brugerne, fungerede som forventet. Nogle gange bruger brugerne slet ikke en funktion. Andre gange var en kapacitet meget vellykket, men krævede genudvikling for at understøtte den nødvendige skalerbarhed og ydeevne. I vandfaldsverdenen lærte du kun disse ting, efter at softwaren blev implementeret, efter en lang udviklingscyklus.
Relateret video: Sådan fungerer den agile metode virkelig
Alle ser ud til at tale om agil softwareudvikling, men mange organisationer har ikke et fast greb om, hvordan processen fungerer. Se denne fem minutters video for at komme hurtigt i gang.
Pivot til agil softwareudvikling
Opfundet i 1970 var vandfaldsmetoden revolutionerende, fordi den bragte disciplin til softwareudvikling for at sikre, at der var en klar specifikation at følge. Det var baseret på metoden til fremstilling af vandfald afledt af Henry Fords 1913 samlebåndsinnovationer, som gav sikkerhed for hvert trin i produktionsprocessen for at garantere, at det endelige produkt matchede det, der i første omgang blev specificeret.
Da vandfaldsmetoden kom til softwareverdenen, var computersystemer og deres applikationer typisk komplekse og monolitiske, hvilket krævede en disciplin og et klart resultat at levere. Kravene ændrede sig også langsomt i forhold til i dag, så storstilet indsats var mindre problematisk. Faktisk blev systemer bygget under den antagelse, at de ikke ville ændre sig, men ville være evige slagskibe. Flerårige tidsrammer var almindelige ikke kun inden for softwareudvikling, men også inden for produktion og andre virksomhedsaktiviteter. Men vandfaldets stivhed blev en akilleshæl i internettiden, hvor hastighed og fleksibilitet var påkrævet.
Softwareudviklingsmetode begyndte at ændre sig, da udviklere begyndte at arbejde på internetapplikationer. Meget af det tidlige arbejde blev udført ved opstart, hvor hold var mindre, blev samlokaliseret og ofte ikke havde traditionel datalogisk baggrund. Der var økonomisk og konkurrencepræget pres for at bringe websteder, applikationer og nye muligheder hurtigere på markedet. Udviklingsværktøjerne og platformene ændrede sig hurtigt som svar.
Dette førte til, at mange af os arbejdede i startups for at sætte spørgsmålstegn ved vandfaldsmetoden og søge måder at blive mere effektive på. Vi havde ikke råd til at udføre al den detaljerede dokumentation på forhånd, og vi havde brug for en mere iterativ og samarbejdsproces. Vi diskuterede stadig ændringer i kravene, men vi var mere åbne over for eksperimenter og til at tilpasse sig slutbrugernes behov. Vores organisationer var mindre strukturerede, og vores applikationer var mindre komplekse end virksomhedens ældre systemer, så vi var meget mere åbne over for opbygning versus køb af applikationer. Endnu vigtigere, vi forsøgte at vokse virksomheder, så når vores brugere fortalte os, at noget ikke fungerede, valgte vi oftere end ikke at lytte til dem.
Vores færdigheder og vores evner til innovation blev strategisk vigtige. Du kunne samle alle de penge, du ønskede, men du kunne ikke tiltrække talentfulde softwareudviklere, der var i stand til at arbejde med hurtigt skiftende internetteknologier, hvis du skulle behandle dem som underordnede kodere, der slavisk fulgte "specifikationen". Vi afviste projektledere, der kom ind med end-to-end tidsplaner, der beskriver, hvad vi skal udvikle, hvornår applikationer skal sendes, og nogle gange endda hvordan strukturere koden. Vi var forfærdelige ved at ramme de tre måneders og seks måneders tidsplaner, som vandfaldsprojektledere udarbejdede og uophørligt opdaterede.
I stedet begyndte vi at fortælle dem, hvordan internetapplikationer skulle konstrueres, og vi leverede resultater på en tidsplan, som vi udarbejdede iterativt. Det viser sig, at vi ikke var så dårlige til at levere det, vi sagde, vi ville, når vi forpligtede os til det i små intervaller på en uge til fire uger.
I 2001 mødtes en gruppe erfarne softwareudviklere og indså, at de kollektivt praktiserede softwareudvikling anderledes end den klassiske vandfaldsmetode. Og de var ikke alle i startups. Denne gruppe, som omfattede teknologilamper Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber og Jeff Sutherland, kom op med Agile Manifestet, der dokumenterede deres fælles tro på, hvordan en moderne softwareudviklingsproces skulle fungere. De understregede samarbejde over dokumentation, selvorganisering snarere end stiv ledelsespraksis og evnen til at klare konstant forandring snarere end at låse dig fast i en stiv udviklingsproces med vandfald.
Fra disse principper blev den agile metode til softwareudvikling født.
Rollerne i den agile metode
En agil softwareudviklingsproces starter altid med at definere brugerne og dokumentere en vision om en række problemer, muligheder og værdier, der skal behandles. Produktejeren indfanger denne vision og arbejder med et tværfagligt team (eller teams) for at levere denne vision. Her er rollerne i den proces.
Bruger
Agile processer begynder altid med brugeren eller kunden i tankerne. I dag definerer vi dem ofte med brugerpersoner for at illustrere forskellige roller i en arbejdsgang, som softwaren understøtter eller forskellige typer kundebehov og adfærd.
Produkt ejer
Selve den agile udviklingsproces begynder med en person, der kræves for at være kundens stemme, herunder eventuelle interne interessenter. Den person distillerer al indsigt, ideer og feedback for at skabe en produktvision. Disse produktvisioner er ofte korte og ligetil, men de tegner ikke desto mindre et billede af, hvem kunden er, hvilke værdier der behandles, og en strategi for, hvordan de skal adresseres. Jeg kan forestille mig, at Googles oprindelige vision lignede "Lad os gøre det let for alle med internetadgang at finde relevante websteder og websider med en enkel, søgeordsdrevet grænseflade og en algoritme, der rangerer velrenommerede kilder højere i søgeresultaterne."
Vi kalder denne person produkt ejer. Hans eller hendes ansvar er at definere denne vision og derefter arbejde med et udviklingsteam for at gøre det virkelig.
For at arbejde med udviklingsteamet opdeler produktejeren produktvisionen i en række brugerhistorier, der præciserer mere, hvem målbrugeren er, hvilket problem der løses for dem, hvorfor løsningen er vigtig for dem, og hvilke begrænsninger og acceptkriterier definerer løsningen. Disse brugerhistorier prioriteres af produktejeren, gennemgås af teamet for at sikre, at de har en fælles forståelse af, hvad der bliver bedt om dem.
Softwareudviklingsteam
I smidighed adskiller udviklingsteamet og dets medlemmers ansvar sig fra det, der gælder for traditionel softwareudvikling.
Holdene er tværfaglige og består af en forskelligartet gruppe mennesker med færdighederne til at få arbejdet gjort. Fordi fokus er på at levere fungerende software, er holdet nødt til at færdiggøre end-to-end fungerende applikationer. Så databasen, forretningslogikken og brugergrænsefladen til en del af applikationen udvikles og derefter lukkes ned - ikke hele applikationen. For at gøre dette skal teammedlemmerne samarbejde. De mødes ofte for at sikre, at alle er tilpasset hvad de bygger, om hvem der gør hvad, og om præcis hvordan softwaren udvikles.
Ud over udviklere kan softwareudviklingsteam omfatte kvalitetssikringsingeniører (QA), andre ingeniører (f.eks. Til databaser og back-end-systemer), designere og analytikere, afhængigt af typen af softwareprojekt.
Scrum, Kanban og andre smidige rammer
Mange smidige rammer, der giver detaljerede oplysninger om udviklingsprocesser og adræt udviklingspraksis, tilpasset en livscyklus for softwareudvikling.
Den mest populære agile ramme kaldes scrum. Det fokuserer på en leveringskadens kaldet a sprint og mødestrukturer, der inkluderer følgende:
- Planlægning - hvor sprintprioriteter identificeres
- Forpligtelse - hvor holdet gennemgår en liste eller et efterslæb af brugerhistorier og beslutter, hvor meget arbejde der kan udføres i sprintens varighed
- Daglige standup-møder - så hold kan kommunikere opdateringer om deres udviklingsstatus og strategier)
Sprints slutter med et demo-møde, hvor funktionaliteten vises til produktejeren, efterfulgt af et retrospektivt møde, hvor teamet diskuterer, hvad der gik godt, og hvad der skal forbedres i deres proces.
Mange organisationer ansætter scrummastere eller trænere til at hjælpe hold med at styre scrumprocessen.
Selvom scrum dominerer, er der andre smidige rammer:
- Kanban fungerer som en fan-in og fan-out-proces, hvor teamet trækker brugerhistorier fra et indtagskort og trækker dem gennem en iscenesat udviklingsproces, indtil de er afsluttet.
- Nogle organisationer anvender en hybrid agil og vandfaldstilgang ved hjælp af smidige processer til nye applikationer og vandfald til ældre.
- Der er også flere rammer, der gør det muligt for organisationer at skalere praksis til flere hold.
Mens agile rammer definerer proces og samarbejde, er agile udviklingsmetoder specifikke for at løse softwareudviklingsopgaver, der udføres i overensstemmelse med en agil ramme.
Så for eksempel:
- Nogle hold anvender parprogrammering, hvor to udviklere koder sammen for at drive højere kvalitetskode og for at gøre det muligt for flere seniorudviklere at mentorere juniorer.
- Mere avancerede teams anvender testdrevet udvikling og automatisering for at sikre, at den underliggende funktionalitet leverer de forventede resultater.
- Mange hold vedtager også tekniske standarder, så udviklerens fortolkning af en brugerhistorie ikke kun fører til den ønskede funktionalitet, men også opfylder sikkerhed, kodekvalitet, navngivningskonventioner og andre tekniske standarder.
