Alt du trenger å vite om metoder for programvareutvikling: trender, prinsipper og fallgruver for nybegynnere

Programvareutvikling er en kompleks forretningsprosess. Dette betyr at IT-fagfolk må snakke språket optimalisering, planlegging og kostnadsberegning. En forståelse av ledelseskonsepter gir både arbeidsgivere og utviklere en stor fordel og bidrar til å ta samarbeid til neste nivå.

OBS, nybegynnere! Modeller, metoder og generell forvirring

For å starte, må vi gjøre en viktig avklaring: programvareutviklingsmodeller og programvareutviklingsmetoder er separate og forskjellige. Modeller forutsier hvordan et system vil oppføre seg. Det kreves metoder for at systemet skal fungere som det skal. Forvirrende programvareutviklingsmodeller og -metoder er standard operasjonsprosedyre for enhver IT-nybegynner, så dette regnes ikke som en stor tabbe. Et eksempel på en modell er den klassiske fossefallsmodellen , med sin lineære progresjon, klare definisjon av mål for hvert trinn, og streng kontroll over tidsfrister. En annen modell er spiralmodellen, med fokus på tidlig oppdagelse og reduksjon av prosjektrisiko. Spiralutvikling starter i det små, først løser lokale problemer, og deretter videre til mer komplekse. Til slutt er en annen modell iterativ og inkrementell utvikling (IID) , der prosjektets livssyklus er brutt ned i en serie iterasjoner, som hver ligner et "miniprosjekt". Generelt er en modell en beskrivelse av programvareutviklingsprosessen . Men metodikk er systemer for å kontrollere, evaluere og overvåke arbeid på tildelte oppgaver. Metoder er pinnen og gulroten til den moderne tidsalder, nødvendig for å kontrollere hvert trinn i utviklingsprosessen. De velges basert på retningen til prosjektet, dets budsjett og fristene for gjennomføring av det endelige produktet. Dessuten kan metoder velges basert på temperamentet til prosjektlederen og hans eller hennes team. Selv basert på filosofien til selskapet eller kunden. La oss ta en titt på de mest populære metodene.

1. Scrum

Scrum er en smidig prosjektledelsesmetode. Den er basert på "sprints", eller korte iterasjoner, strengt begrenset i tid (vanligvis 2-4 uker). Dette minimerer varigheten av møtene, men øker frekvensen. Hver sprint består av en liste over oppgaver som skal fullføres ved slutten av iterasjonen, og hver av dem har sin egen "vekt". Under møtene diskuterer teamet hva teammedlemmene har gjort, hva de planlegger å gjøre og hvilke problemer det er. Scrum bruker en backlog for planlegging. I denne tilnærmingen har lag generelt en scrum master. Denne personen hjelper teamet til å jobbe uten avbrudd og skaper et behagelig miljø for teamet. Prosjektet vil også ha noen i rollen som produkteier. Denne personen er utviklingssjef, overvåker produktet og fungerer som hovedleddet mellom det kunden etterspør og det teamet produserer.

Fordeler:

• evne til raskt å starte et prosjekt med lavest mulig budsjett;
• daglig overvåking av fremdrift, hyppige prosjektdemoer;
• muligheten til å gjøre justeringer underveis i prosjektet.

Ulemper:

• vanskeligheter med å inngå kontrakter på grunn av mangel på et fast budsjett;
• fungerer ikke for et uerfarent team eller når tidsfrister eller budsjett er undervurdert;
• evnen til hele tiden å gjøre endringer mellom spurtene kan skape forvirring.

Hvem er det til?

Et slikt system er egnet for prosjekter på opptil ti personer, enten de er uavhengige eller finnes i store selskaper. Dette er praktisk hvis teamet har mye arbeid og en lang livssyklus som tvinger dem til å endre seg og tilpasse seg nye markedsforhold.

2. Kanban

Den viktigste funksjonen til Kanban er visualisering av prosjektets livssyklus. Det opprettes kolonner for å utføre arbeidselementer. Arbeidspunktene håndteres individuelt. Kolonnene er merket med statuser som: Å gjøre, Pågår, Kodegjennomgang, Under testing, Ferdig (selvfølgelig kan kolonnenavnene variere). Hvert teammedlems mål er å redusere antall arbeidselementer i den første kolonnen. Kanbans tilnærming er intuitiv og hjelper deg å forstå hvor problemene ligger. Strukturen til Kanban er ikke definitivt og ugjenkallelig fast: avhengig av prosjektets spesifikasjoner, kan du legge til improviserte kolonner. For eksempel bruker noen team et system der du må definere ferdige regler for et arbeidselement før du utfører det. I dette tilfellet legges det til to kolonner: Spesifiser (spesifiser parametrene) og Implementer (kom i gang).

Fordeler:

• fleksibilitet i planleggingen. Teamet konsentrerer seg kun om det nåværende arbeidet, prioriteringen av en oppgave er også definert;
• synlighet. Når alle deltakerne har tilgang til data, er globale problemer lettere å få øye på;
• høy involvering i utviklingsprosessen. Å visualisere prosesser øker selvorganisering og selvkontroll.

Ulemper:

• jobber ikke med team på mer enn fem personer;
• ikke beregnet for langsiktig planlegging;
• ikke egnet for et umotivert lag. Kanban har ikke tidsfrister for hvert arbeidselement. Metodikken fastsetter heller ikke straff for forsinkelser.

Hvem er det til?

Kanban fungerer utmerket i selskaper hvor teamet er motivert til å vokse og oppnå resultater. Det burde være åpenbart allerede - dette er for et lite team. Kanskje til og med en avdeling eller del av et team.

3. Rational Unified Process (RUP)

RUP-metodikken bruker en iterativ utviklingsmodell. På slutten av hver iterasjon (som tar 2 til 6 uker), bør teamet oppnå de planlagte målene og få en fungerende, om enn midlertidig, versjon av prosjektet. RUP etterlyser en inndeling av prosjektet i fire faser . I hver fase utføres arbeid med neste generasjon av produktet: begynnelse, utdyping, konstruksjon og overgang. På slutten av en fase oppnås en prosjektmilepæl. Øyeblikket da teamet evaluerer resultatene kan betraktes som en prosjektmilepæl. Dette betyr at metodikken innebærer at hovedtrekkene frigis i første fase, og tillegg legges til i påfølgende faser.

Fordeler:

• gjør det mulig å håndtere skiftende oppgaver, både fra kundens side og endringer som oppstår i løpet av arbeidet;
• sikrer kontinuerlig forbedring av produktet. Under iterasjoner kan du evaluere prosjektet nøye;
• gjør det mulig å identifisere og eliminere risiko i de tidlige stadiene av arbeidet, samt å effektivt kontrollere kvaliteten på utviklingen.

Ulemper:

• Denne metodikken er ganske kompleks og vanskelig å implementere i et lite team eller selskap;
• avhenger av eksperters evne til å sette oppgaver;
• trenger overdreven dokumentasjon av krav.

Hvem er det til?

Store prosjekter med klart etablerte krav og risikoer som er godt forstått, når produktet skal frigis så raskt som mulig. Selv på bekostning av funksjonalitet, for raskt å okkupere din nisje og først senere legge til prikken over i'en.

Det er mange metoder, men én trend

I tillegg til scrum og Kanban, som unektelig er populære og basert på smidige prinsipper , samt den hardføre, iterative RUP-metodikken, bruker bedrifter mange varianter av metoder. Ett selskap kan være nærmere ekstrem programmering og ta de raskeste og enkleste avgjørelsene. En annen kan være nærmere testdrevet utvikling. En annen kan fortsatt foretrekke rask applikasjonsutvikling (RAD). Når det er sagt, er det en sterk, ubestridelig trend mot å bruke flere metoder samtidig. Eller til og med å kombinere modeller og metoder til et unikt styringssystem. Dagens bedrifter streber etter å eliminere byråkratiske barrierer og skape en atmosfære av enhetlig teamarbeid i organisasjonen, uten å flytte ansvar mellom avdelinger og organisatoriske enheter. I følge Scrum Alliance, 70 % av IT-selskapene bruker scrum. Blant dem er slike giganter som Google, Amazon, Salesforce, Microsoft og Adobe. Startups og unge prosjekter er mer tilbøyelige til Kanban, men Toyota og for eksempel spillerne på Wargaming bruker det også. Scrum er et planleggingsverktøy, mens Kanban er for å overvåke fremdriften. Når det gjelder RUP, brukes det oftest av vestlige selskaper med 50-200 ansatte og inntekter på 1-10 millioner dollar. Imidlertid modifiserte IBM RUP for å komme nærmere smidige prinsipper, og ga ut OpenUP-metoden (RUP, men smidig). Denne anerkjente smidige metodikken driver nå IT-verdenen . Dette er ikke bare en forbigående kjepphest – det er fortsatt innovativt, og faktisk brukes det i mange store selskaper. Agile brukes i Silicon Valley. Facebook og Uber bruker det.

Bunnlinjen

Hvert prosjekt har sin egen programvareutviklingsmetodikk, som avhenger av teamet, finansiering, tidsfrister og kundekrav. Det er ingen universell styringsteknikk: Selv den svært populære smidige metodikken kan ikke sikre den beste tilnærmingen til utviklingsprosessen. Som et resultat blir metodikk valgt med omhu, noen ganger til og med på prinsippet. Så mye at vi kan trekke konklusjoner om et selskap selv eller om dets kunder ved å se på metodikken. Metodikk blandes, suppleres med modeller og tilpasses. Så mye at de gir opphav til nye tilnærminger. Når det er sagt, forblir ledelsesområdet til syvende og sist i hendene på scrum og Kanban, med uventede elementer av fossefallsmodellen eller den iterative RUP-metodikken.