Metoder for programvareutvikling

Ved mange intervjuer vil du sannsynligvis bli spurt om metodikk. Dette er ikke det viktigste eller vanskeligste spørsmålet, men å ha et jukseark ville vært fint. I denne artikkelen skal vi prøve å formidle hva en utviklingsmetodikk er og sammenligne dem. En programvareutviklingsmetodikk er en prosess som brukes til å utvikle et bestemt produkt, det vil si at det er en måte å organisere utvikling av et team av utviklere. Det finnes mange forskjellige utviklingsmodeller, som hver definerer sin egen tilnærming. Det kan ikke sies at noen av dem skal brukes til hvert prosjekt. Riktig tilnærming avhenger helt av situasjonen. Jeg har tenkt å vurdere tre av dem mer detaljert.

Foss

Fossmetodikken er en av de eldste og innebærer en strengt sekvensiell implementering: hvert trinn må fullføres før det neste begynner. En overgang til neste trinn betyr med andre ord at arbeidet til forrige trinn er 100 % fullført. Bildet viser hvordan det fungerer: Først analyserer vi problemet (dokumenterer oppgaver, diskuterer utfordringer), deretter designer vi (prosjektets struktur tar form på dette stadiet), og deretter koder og tester vi. Det er ikke tillatt å gå tilbake til tidligere stadier. Denne tilnærmingen anbefales for små prosjekter der kravene er kjent på forhånd og neppe vil endre seg. Fordeler:

• Komplett og konsistent dokumentasjon på hvert trinn
• Brukervennlighet
• Stabile krav
• Budsjetter og tidsfrister er forhåndsdefinerte

Ulemper:

• En stor mengde dokumentasjon
• Ikke veldig fleksibel
• Klienten kan ikke se en demoversjon av produktet
• Ingen mulighet til å gå bakover

Scrum

Scrum er en programvareutviklingsmetodikk som deler opp hele prosessen i iterasjoner. På slutten av hver interaksjon er teamet klare til å gi en demoversjon av produktet. Bildet viser at teamet går gjennom alle utviklingsstadier parallelt, noe som gjør det mulig å ha en ferdig del av prosjektet på slutten av hver iterasjon. Jeg skal prøve å kort forklare essensen av metodikken ved hjelp av enkle ord, men det er mye terminologi. Jeg tror det viktigste er å forstå essensen. Du vil huske terminologien med erfaring. All utvikling er delt inn i sprint (ofte 2-3 uker). Det er et etterslep(oppgaveliste) for hele utviklingsperioden og for hver enkelt sprint. Hver oppgave har sitt eget historiepunkt (vanskelighetsgrad). Hver deltaker i prosessen har en rolle:

• Scrum-teamet består av fagfolk (utviklere, testere, designere) som jobber med et prosjekt.
• Scrum master er personen som sørger for at prinsippene for scrum blir respektert.
• Produkteieren er kunden.

Denne metodikken er avhengig av kommunikasjon, så det er et stort antall møter:

• Stand-up – Dette er et kort møte som holdes hver dag, der alle teammedlemmene deltar. Hver deltaker svarer på 3 spørsmål: Hva gjorde jeg? Hva skal jeg gjøre? Og hvilke blokkeringsproblemer er det?
• Planleggingsmøte – Dette møtet holdes i begynnelsen av sprinten. Oppgavene som må utføres i neste sprint identifiseres på dette møtet.
• Retrospektiv - Dette møtet holdes på slutten av sprinten og formålet er å identifisere hva som ble gjort bra og hva som kan forbedres.

Fordeler:

• Kunden kan se resultater under utviklingsprosessen
• Daglig oppfølging av utviklingsprosessen
• Evne til å gjøre justeringer under utvikling
• Etablert kommunikasjon med alle teammedlemmer
• En liten mengde dokumentasjon

Ulemper:

• Vanskelig å vurdere arbeidskraft og andre kostnader som kreves for utvikling
• Vanskelig å identifisere flaskehalser før utviklingen starter
• Behovet for å involvere alle i arbeidet til andre teammedlemmer.

Kanban

Kanban er en metode basert på å visualisere fremdriften i å fullføre teamets oppgaver. Hovedideen er å redusere antall oppgaver som for øyeblikket utføres (i kolonnen "I Progress"). I scrum er teamet fokusert på å fullføre spurter. I Kanban inntar oppgaven den fremste posisjonen. Dette er bra for prosjekter i vedlikeholdsfasen, der den grunnleggende funksjonaliteten allerede er implementert, og det gjenstår minimale forbedringer og feilretting. I Kanban tildeles oppgaver individuelt. En oppgave går gjennom alle ledd i tavlen, uavhengig av andre oppgaver, og når den er fullført kan den vises til kunden. Et Kanban-tavle består av kolonner, som hver representerer en egen utviklingsprosess. Noen kolonner (for eksempel «Pågår» ) begrense antall oppgaver de kan holde. Dette bidrar til raskt og enkelt å finne problemområder i oppgavefordelingen. Bildet viser et eksempel på nettopp et slikt brett. Antall kolonner og navnene deres kan variere. Jeg vil presentere de vanligste:

• Å gjøre – Listen over oppgaver som må gjøres
• Pågår – Oppgaver som jobbes med
• Kodegjennomgang – Oppgaver som er utført og sendt inn for gjennomgang
• I testing – Oppgaver klare for testing
• Ferdig – Ferdige oppgaver

Fordeler:

• Brukervennlighet
• Synlighet (hjelper med å finne flaskehalser, forenkler forståelse)
• Høy teaminvolvering i selve prosessen
• Svært fleksibel utvikling

Ulemper:

• En ustabil oppgaveliste
• Vanskelig å søke på langsiktige prosjekter
• Mangel på harde tidsfrister

Et siste ord om metoder for programvareutvikling

Personer som innehar eller håper på lederstillinger må forstå programvareutviklingsmetoder grundig, men alle trenger å forstå i det minste det grunnleggende. Metoder er en integrert del av utviklingsprosessen og brukes ikke bare i IT-sfæren. Takk for at du tok deg tid til å lese artikkelen min. Jeg håper det var nyttig for deg. Jeg prøvde å beskrive bare nøkkelpunktene så lett tilgjengelig og konsist som mulig. Som et resultat er ikke denne artikkelen uttømmende. Jeg vil gjerne høre din mening om det og svare på spørsmålene dine. Beste ønsker!