Vad är smidig metodik? Modern programutveckling förklaras

Varje teknikorganisation i dag verkar utöva den smidiga metoden för mjukvaruutveckling, eller en version av den. Eller åtminstone tror de att de gör det. Oavsett om du är ny inom agil applikationsutveckling eller om du har lärt dig programvaruutveckling för flera decennier sedan med hjälp av metoderna för utveckling av programvara för vattenfall, påverkas ditt arbete idag åtminstone av den agila metoden.

Men vad är smidig metodik, och hur ska den tillämpas vid mjukvaruutveckling? Hur skiljer sig den smidiga utvecklingen från vattenfallet i praktiken? Vad är livscykeln för smidig mjukvaruutveckling eller smidig SDLC? Och vad är scrum agile kontra Kanban och andra smidiga modeller? 

Agile lanserades formellt 2001 när 17 tekniker utarbetade Agile Manifesto. De skrev fyra huvudprinciper för smidig projektledning, med målet att utveckla bättre programvara:

  • Individer och interaktioner över processer och verktyg
  • Arbetsprogramvara över omfattande dokumentation
  • Kundsamarbete över kontraktsförhandlingar
  • Svarar på förändring efter en plan

Innan smidig: Vattenfallsmetodens era

Gamla händer som jag minns de dagar då vattenfallsmetoden var guldstandarden för mjukvaruutveckling. Programvaruutvecklingsprocessen krävde massor av dokumentation framför allt innan någon kodning startade. Någon, vanligtvis affärsanalytiker, skrev först ett affärskravsdokument som fångade upp allt som företaget behövde i applikationen. Dessa dokument för affärsbehov var långa och detaljerade allt: övergripande strategi, omfattande funktionella specifikationer och visuella användargränssnittsdesigner.

Teknologer tog affärsdokumentet och utvecklade ett eget dokument för tekniska krav. Detta dokument definierade programmets arkitektur, datastrukturer, objektorienterade funktionella mönster, användargränssnitt och andra icke-funktionella krav.

Denna utvecklingsprocess för vattenfallsprogram skulle slutligen starta kodning, sedan integration och slutligen testning innan en applikation ansågs vara produktionsklar. Hela processen kan lätt ta ett par år.

Vi utvecklare förväntades känna "specifikationen", som den fullständiga dokumentationen kallades, lika bra som dokumentförfattarna gjorde, och vi blev ofta tuktade om vi glömde att korrekt implementera en nyckeldetalj som beskrivs på sidan 77 i en 200- siddokument.

Då var själva programvaruutvecklingen inte heller lätt. Många utvecklingsverktyg krävde specialutbildning, och det fanns inte någonstans nära öppen källkod eller kommersiella programvarukomponenter, API: er och webbtjänster som finns idag. Vi var tvungna att utveckla låga saker som att öppna databasanslutningar och multithreading vår databehandling.

För även grundläggande applikationer var teamen stora och kommunikationsverktygen begränsade. Våra tekniska specifikationer var det som passade oss, och vi utnyttjade dem som Bibeln. Om ett krav ändrades skulle vi sätta företagsledarna i en lång granskningsprocess och logga ut eftersom det var dyrt att kommunicera förändringar över hela teamet och fixa kod.

Eftersom programvaran utvecklades baserat på den tekniska arkitekturen utvecklades artefakter på lägre nivå först och beroende artefakter efteråt. Uppgifter tilldelades av skicklighet och det var vanligt att databasingenjörer först konstruerade tabellerna och andra databasartefakter, följt av applikationsutvecklarna som kodade funktionaliteten och affärslogiken, och slutligen överlagrades användargränssnittet. Det tog månader innan någon såg applikationen fungera och då blev intressenterna antyga och ofta smartare om vad de verkligen ville ha. Inte konstigt att genomföra ändringar var så dyrt!

Inte allt du placerade framför användarna fungerade som förväntat. Ibland skulle användarna inte använda en funktion alls. Andra gånger var en kapacitet mycket framgångsrik men krävde nyutveckling för att stödja nödvändig skalbarhet och prestanda. I vattenfallvärlden lärde du dig dessa saker först efter att programvaran hade distribuerats, efter en lång utvecklingscykel.

Relaterad video: Hur den smidiga metoden verkligen fungerar

Alla verkar prata om smidig programvaruutveckling, men många organisationer har inte ett fast grepp om hur processen fungerar. Titta på den här fem minuter långa videon så att du snabbt kan få fart.

Pivoten för smidig mjukvaruutveckling

Uppfunnen 1970 var vattenfallsmetoden revolutionerande eftersom den förde disciplin till programvaruutveckling för att säkerställa att det fanns en tydlig specifikation att följa. Den baserades på tillverkningsmetoden för vattenfall som härrör från Henry Fords 1913 monteringslinjeinnovationer, som gav säkerhet om varje steg i produktionsprocessen för att garantera att den slutliga produkten matchade det som specificerades i första hand.

När vattenfallsmetoden kom till programvaruvärlden var datorsystem och deras applikationer vanligtvis komplexa och monolitiska, vilket krävde en disciplin och tydligt resultat för att leverera. Kraven förändrades också långsamt jämfört med idag, så storskaliga insatser var mindre problematiska. Faktum är att system byggdes under antagandet att de inte skulle förändras utan skulle vara eviga slagskepp. Fleråriga tidsramar var vanliga inte bara inom mjukvaruutveckling utan även inom tillverkning och andra företagsaktiviteter. Men vattenfallets styvhet blev en akilleshäl under internet-eran, där hastighet och flexibilitet krävdes.

Programvaruutvecklingsmetoden började förändras när utvecklare började arbeta med internetapplikationer. Mycket av det tidiga arbetet gjordes vid startups där team var mindre, samlades och ofta inte hade traditionell datavetenskaplig bakgrund. Det fanns ekonomiska och konkurrensutsatta tryck för att få webbplatser, applikationer och nya möjligheter snabbare på marknaden. Utvecklingsverktygen och plattformarna förändrades snabbt som svar.

Detta fick många av oss att arbeta i nystartade företag för att ifrågasätta vattenfallsmetodiken och leta efter sätt att bli mer effektiva. Vi hade inte råd att göra all den detaljerade dokumentationen i förväg, och vi behövde en mer iterativ och samarbetsprocess. Vi diskuterade fortfarande ändringar av kraven, men vi var mer öppna för experiment och anpassning till slutanvändarens behov. Våra organisationer var mindre strukturerade och våra applikationer var mindre komplexa än företagens äldre system, så vi var mycket mer öppna för att bygga kontra att köpa applikationer. Ännu viktigare, vi försökte växa företag, så när våra användare sa att något inte fungerade valde vi oftare än att lyssna på dem.

Vår kompetens och vår förmåga att förnya blev strategiskt viktig. Du kunde samla in alla pengar du ville ha, men du kunde inte locka talangfulla programutvecklare som kan arbeta med snabbt föränderliga internetteknologier om du skulle behandla dem som underordnade kodare som slaviskt följer "specifikationen". Vi avvisade projektledare som kom med slut-till-slut-scheman som beskriver vad vi ska utveckla, när applikationer ska skickas och ibland till och med hur vi ska strukturera koden. Vi var fruktansvärda på att träffa schema för tre månader och sex månader som projektledarna för vattenfallet utarbetade och oupphörligt uppdaterade.

Istället började vi berätta för dem hur internetapplikationer behövde konstrueras, och vi levererade resultat enligt ett schema som vi ritade iterativt. Det visar sig att vi inte var så dåliga att leverera det vi sa att vi skulle göra när vi åtagit oss det i små intervaller på en vecka till fyra veckor.

2001 träffades en grupp erfarna mjukvaruutvecklare och insåg att de tillsammans övade programvaruutveckling annorlunda än den klassiska vattenfallsmetoden. Och de var inte alla i startups. Denna grupp, som inkluderade teknikarmaturer Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber och Jeff Sutherland, kom fram till Agile Manifesto som dokumenterade deras gemensamma tro på hur en modern programvaruutvecklingsprocess ska fungera. De betonade samarbete över dokumentation, självorganisation snarare än styv förvaltningsmetod, och förmågan att lyckas med konstant förändring snarare än att låsa dig för en stel vattenfallsprocess.

Ur dessa principer föddes den smidiga metoden för mjukvaruutveckling.

Rollerna i den smidiga metoden

En smidig mjukvaruutvecklingsprocess börjar alltid med att definiera användarna och dokumentera ett visionsuttalande om en mängd problem, möjligheter och värden som ska hanteras. Produktägaren fångar upp denna vision och arbetar med ett tvärvetenskapligt team (eller team) för att leverera den visionen. Här är rollerna i den processen.

Användare

Agila processer börjar alltid med användaren eller kunden i åtanke. Idag definierar vi ofta dem med användarpersoner för att illustrera olika roller i ett arbetsflöde som programvaran stöder eller olika typer av kundbehov och beteenden.

Produktägare

Själva den agila utvecklingsprocessen börjar med någon som krävs för att vara kundens röst, inklusive alla interna intressenter. Den personen destillerar alla insikter, idéer och feedback för att skapa en produktvision. Dessa produktvisioner är ofta korta och enkla, men ändå ger de en bild av vem kunden är, vilka värden som tas upp och en strategi för hur man ska ta itu med dem. Jag kan föreställa mig Googles ursprungliga vision såg ut som "Låt oss göra det enkelt för alla med internetåtkomst att hitta relevanta webbplatser och webbsidor med ett enkelt, sökordsdrivet gränssnitt och en algoritm som rankar ansedda källor högre i sökresultaten."

Vi kallar den här personen produktägaren . Hans eller hennes ansvar är att definiera denna vision och sedan arbeta med ett utvecklingsteam för att göra den verklig.

För att arbeta med utvecklingsteamet bryter produktägaren ner produktvisionen i en serie användarberättelser som närmare beskriver vem målanvändaren är, vilket problem som löses för dem, varför lösningen är viktig för dem och vilka begränsningar och acceptanskriterier definierar lösningen. Dessa användarberättelser prioriteras av produktägaren, granskas av teamet för att säkerställa att de har en gemensam förståelse för vad som efterfrågas av dem.

Program för utveckling av programvara

I agile skiljer sig utvecklingsteamet och dess medlemmars ansvar från det som gäller för traditionell programvaruutveckling.

Teamen är tvärvetenskapliga och består av en varierad grupp människor med färdigheterna för att få jobbet gjort. Eftersom fokus är på att leverera fungerande programvara måste teamet slutföra applikationer som fungerar helt och hållet. Så databasen, affärslogiken och användargränssnittet för en del av applikationen utvecklas och läggs sedan ner - inte hela applikationen. För att göra detta måste teammedlemmarna samarbeta. De träffas ofta för att se till att alla är anpassade efter vad de bygger, om vem som gör vad och om exakt hur programvaran utvecklas.

Förutom utvecklare kan programutvecklingsteam inkludera kvalitetssäkringsingenjörer (QA), andra ingenjörer (som för databaser och back-end-system), designers och analytiker, beroende på vilken typ av programvaruprojekt.

Scrum, Kanban och andra smidiga ramar

Många smidiga ramar som ger detaljer om utvecklingsprocesser och agila utvecklingsmetoder, anpassade till en livscykel för programvaruutveckling.

Det mest populära agila ramverket kallas scrum . Den fokuserar på en leveranskadens som kallas en sprint och mötesstrukturer som inkluderar följande:

  • Planering - där sprintprioriteringar identifieras
  • Engagemang - där laget granskar en lista eller eftersläpning av användarberättelser och bestämmer hur mycket arbete som ska göras under sprintens varaktighet 
  • Dagliga standupmöten - så att team kan kommunicera uppdateringar om deras utvecklingsstatus och strategier)

Sprints avslutas med ett demo-möte där funktionaliteten visas för produktägaren, följt av ett retrospektivt möte där teamet diskuterar vad som gick bra och vad som behöver förbättras i sin process.

Många organisationer använder scrummasters eller coacher för att hjälpa team att hantera scrumprocessen.

Även om scrum dominerar finns det andra smidiga ramar:

  • Kanban fungerar som en fan-in och fan-out-process där teamet drar användarberättelser från ett intagskort och trattar dem genom en iscensatt utvecklingsprocess tills de är färdiga.
  • Vissa organisationer använder sig av en hybrid agil och vattenfallstrategi, med hjälp av smidiga processer för nya applikationer och vattenfall för äldre.
  • Det finns också flera ramar som gör det möjligt för organisationer att skala övningen till flera lag.

Medan agila ramar definierar process och samarbete är agila utvecklingsmetoder specifika för att hantera programvaruutvecklingsuppgifter som utförs i linje med ett smidigt ramverk.

Så till exempel:

  • Vissa lag använder parprogrammering, där två utvecklare kodar tillsammans för att driva högre kvalitetskod och för att göra det möjligt för fler seniorutvecklare att mentorera junior.
  • Mer avancerade team använder testdriven utveckling och automatisering för att säkerställa att den underliggande funktionaliteten ger de förväntade resultaten.
  • Många lag antar också tekniska standarder så att utvecklarens tolkning av en användarberättelse inte bara leder till önskad funktionalitet utan också uppfyller säkerhet, kodkvalitet, namngivningskonventioner och andra tekniska standarder.

Varför den smidiga metoden är bättre