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.
![Metoder for programvareutvikling - 2]()
Fordeler:
![Metoder for programvareutvikling - 3]()
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:
![Metoder for programvareutvikling - 4]()
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
- 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.
- 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.
- 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
- 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
- Brukervennlighet
- Synlighet (hjelper med å finne flaskehalser, forenkler forståelse)
- Høy teaminvolvering i selve prosessen
- Svært fleksibel utvikling
- En ustabil oppgaveliste
- Vanskelig å søke på langsiktige prosjekter
- Mangel på harde tidsfrister
GO TO FULL VERSION