Hver teknologiorganisasjon i dag ser ut til å praktisere den smidige metoden for programvareutvikling, eller en versjon av den. Eller i det minste tror de at de gjør det. Enten du er nybegynner for smidig applikasjonsutvikling eller om du har lært programvareutvikling for flere tiår siden ved å bruke metodikken for utvikling av programvare for fossefall, i dag er arbeidet ditt i det minste påvirket av den smidige metoden.
Men hva er smidig metodikk, og hvordan skal den praktiseres i programvareutvikling? Hvordan skiller smidig utvikling seg fra fossen i praksis? Hva er livssyklusen for smidig programvareutvikling, eller smidig SDLC? Og hva er scrum agile versus Kanban og andre smidige modeller?
Agile ble formelt lansert i 2001 da 17 teknologer utarbeidet Agile Manifesto. De skrev fire hovedprinsipper for smidig prosjektledelse, med målet om å utvikle bedre programvare:
- Enkeltpersoner og interaksjoner over prosesser og verktøy
- Arbeidsprogramvare over omfattende dokumentasjon
- Kundesamarbeid over kontraktsforhandlinger
- Svar på endring etter en plan
Før smidig: Era med fossefallmetodikk
Gamle hender som meg husker dagene da fossemetodologien var gullstandarden for programvareutvikling. Programvareutviklingsprosessen krevde massevis av dokumentasjon foran hver koding startet. Noen, vanligvis forretningsanalytikeren, skrev først et forretningskravdokument som fanget opp alt virksomheten trengte i applikasjonen. Disse dokumentene for forretningskrav var lange, med detaljer om alt: overordnet strategi, omfattende funksjonsspesifikasjoner og visuelt design av brukergrensesnitt.
Teknologer tok forretningskravdokumentet og utviklet sitt eget tekniske kravdokument. Dette dokumentet definerte applikasjonens arkitektur, datastrukturer, objektorienterte funksjonelle design, brukergrensesnitt og andre ikke-funksjonelle krav.
Denne utviklingsprosessen for fossefall programvare vil endelig starte koding, deretter integrering, og til slutt teste før en applikasjon ble ansett som produksjonsklar. Hele prosessen kan lett ta et par år.
Vi utviklere ble forventet å kjenne "spesifikasjonen", som den komplette dokumentasjonen ble kalt, like godt som dokumentforfatterne gjorde, og vi ble ofte tuktet hvis vi glemte å implementere en nøkkeldetalj skissert på side 77 i en 200- sidedokument.
Den gang var programvareutvikling i seg selv heller ikke lett. Mange utviklingsverktøy krevde spesialisert opplæring, og det var ikke i nærheten av åpen kildekode eller kommersiell programvarekomponenter, API-er og webtjenester som finnes i dag. Vi måtte utvikle ting på lavt nivå som å åpne databaseforbindelser og multitråding av databehandlingen vår.
Til og med grunnleggende applikasjoner var teamene store og kommunikasjonsverktøyene begrenset. Våre tekniske spesifikasjoner var det som passet oss, og vi utnyttet dem som Bibelen. Hvis et krav endret seg, ville vi sette virksomhetslederne gjennom en lang prosess med gjennomgang og avmelding fordi det var dyrt å kommunisere endringer på tvers av teamet og fikse koden.
Fordi programvaren ble utviklet basert på den tekniske arkitekturen, ble gjenstander på lavere nivå utviklet først og avhengige gjenstander etterpå. Oppgaver ble tildelt av dyktighet, og det var vanlig at databaseingeniører først konstruerte tabellene og andre databaseartefakter, etterfulgt av applikasjonsutviklerne som kodet funksjonaliteten og forretningslogikken, og til slutt ble brukergrensesnittet lagt. Det tok måneder før noen så søknaden fungere, og da ble interessentene antsy og ofte smartere om hva de egentlig ønsket. Ikke rart å implementere endringer var så dyrt!
Ikke alt du la foran brukerne fungerte som forventet. Noen ganger brukerne ikke bruke en funksjon i det hele tatt. Andre ganger var en evne vellykket, men krevde nyutvikling for å støtte nødvendig skalerbarhet og ytelse. I fosseverdenen lærte du bare disse tingene etter at programvaren ble distribuert, etter en lang utviklingssyklus.
Relatert video: Hvordan den smidige metoden virkelig fungerer
Alle ser ut til å snakke om smidig programvareutvikling, men mange organisasjoner har ikke et godt grep om hvordan prosessen fungerer. Se denne fem minutter lange videoen for å komme deg raskt opp.
Sentralen for smidig programvareutvikling
Oppfunnet i 1970 var fossen metodikk revolusjonerende fordi den førte disiplin til programvareutvikling for å sikre at det var en klar spesifikasjon å følge. Det var basert på fosseframstillingsmetoden avledet av Henry Fords 1913 monteringslinjeinnovasjoner, som ga sikkerhet for hvert trinn i produksjonsprosessen for å garantere at det endelige produktet samsvarte med det som ble spesifisert i utgangspunktet.
Da fossemetodologien kom til programvareverdenen, var databehandlingssystemer og deres applikasjoner vanligvis komplekse og monolittiske, noe som krevde en disiplin og et klart resultat å levere. Kravene endret seg også sakte sammenlignet med i dag, så storskala innsats var mindre problematisk. Faktisk ble systemer bygget under antagelse om at de ikke ville endres, men ville være evige slagskip. Flereårs tidsrammer var vanlige ikke bare innen programvareutvikling, men også i produksjon og andre virksomhetsaktiviteter. Men fossens stivhet ble en akilleshæl i internettiden, hvor fart og fleksibilitet var nødvendig.
Programvareutviklingsmetodikk begynte å endres da utviklere begynte å jobbe med internettapplikasjoner. Mye av det tidlige arbeidet ble gjort i oppstart hvor team var mindre, ble samlet og ofte ikke hadde tradisjonell informatikkbakgrunn. Det var økonomisk og konkurransedyktig press for å bringe nettsteder, applikasjoner og nye muligheter raskere til markedet. Utviklingsverktøyene og plattformene endret seg raskt som svar.
Dette førte til at mange av oss jobbet i oppstart for å stille spørsmål ved fossemetodologien og se etter måter å bli mer effektive. Vi hadde ikke råd til å gjøre all detaljert dokumentasjon foran, og vi trengte en mer iterativ og samarbeidsprosess. Vi diskuterte fremdeles endringer i kravene, men vi var mer åpne for eksperimentering og for å tilpasse oss sluttbrukernes behov. Organisasjonene våre var mindre strukturerte og applikasjonene våre var mindre komplekse enn bedriftens eldre systemer, så vi var mye mer åpne for å bygge mot å kjøpe applikasjoner. Enda viktigere, vi prøvde å vokse bedrifter, så når brukerne våre fortalte at noe ikke fungerte, valgte vi oftere enn ikke å lytte til dem.
Våre ferdigheter og våre evner til å innovere ble strategisk viktig. Du kunne samle inn alle pengene du ønsket, men du kunne ikke tiltrekke deg dyktige programvareutviklere som kunne jobbe med raskt skiftende internettteknologier hvis du skulle behandle dem som underordnede kodere som slavisk fulgte "spesifikasjonen". Vi avviste prosjektledere som kom inn med end-to-end tidsplaner som beskriver hva vi skal utvikle, når applikasjoner skal sendes, og noen ganger til og med hvordan vi skal strukturere koden. Vi var forferdelig på å treffe de tre måneders og seks måneders tidsplanene som fossefallprosjektlederne utarbeidet og uopphørlig oppdaterte.
I stedet begynte vi å fortelle dem hvordan internettapplikasjoner måtte konstrueres, og vi leverte resultater etter en tidsplan som vi tegnet iterativt. Det viser seg at vi ikke var så dårlige til å levere det vi sa at vi ville gjort når vi forpliktet oss til det i små intervaller på en uke til fire uker.
I 2001 kom en gruppe erfarne programvareutviklere sammen og innså at de samlet praktiserte programvareutvikling annerledes enn den klassiske fossen. Og de var ikke alle i oppstart. Denne gruppen, som inkluderte teknologiarmaturer Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber og Jeff Sutherland, kom opp med Agile Manifesto som dokumenterte deres felles tro på hvordan en moderne programvareutviklingsprosess skulle fungere. De la vekt på samarbeid om dokumentasjon, egenorganisasjon snarere enn stiv ledelsespraksis, og evnen til å klare å endre seg i stedet for å låse deg fast i en rigid fossefallutviklingsprosess.
Fra disse prinsippene ble den smidige metoden for programvareutvikling født.
Rollene i den smidige metodikken
En smidig programvareutviklingsprosess starter alltid med å definere brukerne og dokumentere en visjonserklæring om et omfang av problemer, muligheter og verdier som skal tas opp. Produkteieren fanger denne visjonen og samarbeider med et tverrfaglig team (eller team) for å levere denne visjonen. Her er rollene i den prosessen.
Bruker
Agile prosesser begynner alltid med brukeren eller kunden i tankene. I dag definerer vi dem ofte med brukerpersoner for å illustrere forskjellige roller i en arbeidsflyt programvaren støtter eller forskjellige typer kundebehov og atferd.
Produkteier
Selve den smidige utviklingsprosessen begynner med noen som kreves for å være kundens stemme, inkludert eventuelle interne interessenter. Denne personen brenner ut all innsikt, ideer og tilbakemeldinger for å skape en produktvisjon. Disse produktvisjonene er ofte korte og greie, men de tegner likevel et bilde av hvem kunden er, hvilke verdier som blir adressert, og en strategi for hvordan de skal adresseres. Jeg kan forestille meg Googles opprinnelige visjon så ut som "La oss gjøre det enkelt for alle med internettilgang å finne relevante nettsteder og websider med et enkelt, nøkkelorddrevet grensesnitt og en algoritme som rangerer anerkjente kilder høyere i søkeresultatene."
Vi kaller denne personen produkteier. Hans eller hennes ansvar er å definere denne visjonen og deretter jobbe med et utviklingsteam for å gjøre den virkelig.
For å samarbeide med utviklingsteamet deler produkteieren ned produktvisjonen i en serie brukerhistorier som nærmere angir hvem målbrukeren er, hvilket problem som løses for dem, hvorfor løsningen er viktig for dem, og hvilke begrensninger og akseptkriterier definerer løsningen. Disse brukerhistoriene blir prioritert av produkteieren, gjennomgått av teamet for å sikre at de har en felles forståelse av hva som blir bedt om dem.
Programvareutviklingsteam
I smidighet skiller utviklingsteamet og dets medlemmers ansvar seg fra det som er i tradisjonell programvareutvikling.
Teamene er tverrfaglige, sammensatt av en mangfoldig gruppe mennesker med ferdigheter til å få jobben gjort. Fordi fokuset er på å levere fungerende programvare, må teamet fullføre applikasjoner som fungerer helt fra ende til annen. Så databasen, forretningslogikken og brukergrensesnittet til del av applikasjonen blir utviklet og deretter demoed - ikke hele applikasjonen. For å gjøre dette må teammedlemmene samarbeide. De møtes ofte for å sikre at alle er tilpasset hva de bygger, om hvem som gjør hva og om nøyaktig hvordan programvaren utvikles.
I tillegg til utviklere kan programvareutviklingsteam inkludere kvalitetssikringsingeniører (QA), andre ingeniører (for eksempel for databaser og back-end-systemer), designere og analytikere, avhengig av typen programvareprosjekt.
Scrum, Kanban og andre smidige rammer
Mange smidige rammer som gir spesifikk informasjon om utviklingsprosesser og smidig utviklingspraksis, tilpasset en livssyklus for programvareutvikling.
Det mest populære smidige rammeverket kalles scrum. Den fokuserer på en leveringskadens kalt a sprint og møtestrukturer som inkluderer følgende:
- Planlegging - hvor sprintprioriteter identifiseres
- Forpliktelse - der teamet gjennomgår en liste eller etterslep av brukerhistorier og bestemmer hvor mye arbeid som kan gjøres i løpet av sprinten
- Daglige standupmøter - slik at team kan kommunisere oppdateringer om utviklingsstatus og strategier)
Sprints avsluttes med et demo-møte der funksjonaliteten vises til produkteieren, etterfulgt av et retrospektivt møte der teamet diskuterer hva som gikk bra og hva som må forbedres i prosessen.
Mange organisasjoner ansetter scrummasters eller trenere for å hjelpe lagene med å administrere scrumprosessen.
Selv om scrum dominerer, er det andre smidige rammer:
- Kanban fungerer som en fan-in og fan-out prosess der teamet henter brukerhistorier fra et inntakstavle og trakter dem gjennom en iscenesatt utviklingsprosess til de er fullført.
- Noen organisasjoner bruker en hybrid agile og foss tilnærming, ved hjelp av smidige prosesser for nye applikasjoner og foss for eldre.
- Det er også flere rammer som gjør det mulig for organisasjoner å skalere øvelsen til flere lag.
Mens smidige rammer definerer prosess og samarbeid, er smidig utviklingspraksis spesifikk for å takle programvareutviklingsoppgaver som utføres i samsvar med et smidig rammeverk.
Så for eksempel:
- Noen lag vedtar parprogrammering, der to utviklere koder sammen for å drive høyere kvalitetskode og for å gjøre det mulig for flere seniorutviklere å veilede junior.
- Mer avanserte team vedtar testdrevet utvikling og automatisering for å sikre at den underliggende funksjonaliteten leverer de forventede resultatene.
- Mange team vedtar også tekniske standarder slik at utviklerens tolkning av en brukerhistorie ikke bare fører til ønsket funksjonalitet, men også oppfyller sikkerhet, kodekvalitet, navngivningskonvensjoner og andre tekniske standarder.
