Agile programvareutviklings livssyklusfaser forklart

#På oppstart

Agile programvareutviklingsmetodikk er en av de mest enkle, men effektive måtene å levere et flott produkt på markedet. Og likevel, et sted underveis, begynte folk å overkomplisere det virkelig. Riktig implementert Agile er rask, fleksibel, feilsikker og rett og slett bedre måte å administrere programvareutviklingsteam på. I denne artikkelen forklarer vi livssyklusfaser for Agile programvareutvikling og hvordan man tar i bruk Agile-prinsipper.

Nøkkelprinsippene for smidig utvikling

Hovedideene bak Agile utvikling ble skissert i det opprinnelige Manifest for Agile Software Development. Når de er oppsummert, er de:

• Endring er uunngåelig. Prosjektet må tilpasse seg det i stedet for å ignorere det.
• Å levere resultater er viktigere enn etablerte prosesser og verktøy;
• Ekte kunders behov prioriteres fremfor kravene i utviklingsplanene.

Disse ideene er nærmere beskrevet i hovedprinsippene for smidig programvareutvikling.

Fokuset bak Agile er sluttbrukertilfredshet. Alle oppgavene som ikke fungerer direkte for å forbedre det, er sekundære. Og mens Agile utviklingsteam fremdeles jobber med å etablere prosesser, skrive dokumentasjon og følge planene, kan disse oppgavene utsettes eller gjøres på et minimum akseptabelt nivå hvis de truer effektiviteten i utviklingen.

Agile Methodology Forklart

Hovedverktøyet for smidig utvikling er iterasjon. Iterasjon er en prosess der et sett med handlinger gjentas i en sekvens til en betingelse er oppfylt.

Ulike Agile utviklingsmetoder oppnår iterasjon på forskjellige måter. Scrum implementerer for eksempel Sprints. Sprints er faste tidsperioder – vanligvis 1-2 uker lange – der utviklingsteamet fullfører en viss del av funksjonaliteten og oppnår forhåndsdefinerte mål.

Her er et eksempel på arbeidsflyten i en enkelt Scrum Sprint:

• Produkteieren – den som er ansvarlig for fullførelsen – gjennomgår de ufullstendige oppgavene i Produktet. De foreldede oppgavene blir fjernet mens de nye blir lagt til;
• Produkteieren fastslår omfanget av den nye Sprint og målet den har som mål å oppnå.
• Produkteieren har en planlegging Møte med utviklingsteamet. De lager brukerhistorier som dekomponeres i oppgavene for visse Sprint som er lagret i Backlog.
• Utviklingsteamet holder daglige møter der de holder seg oppdatert om fremdriften til hvert teammedlem;
• Når tidsrammen til Sprint løper ut, anses Sprint som fullført. De uferdige oppgavene blir flyttet tilbake til Produktet Backlog; I unntakstilfeller kan en Sprint-sluttdato endres av en produkteier.
• Produkteieren holder en demonstrasjon for kunden og viser arbeidet som er utført under sprinten.
• Produkteieren holder et møte med utviklingsteamet, hvor resultatene av Sprint er gjennomgått. Teamet etablerer hva som ble gjort bra, og hvilke prosesser som kan forbedres i neste sprint. Denne anmeldelsen kalles en Sprint Retrospective.
• Neste sprint begynner.

Den jevnlige gjennomgangen av Backlog bidrar til å opprettholde relevansen av funksjonene i Backlog. Det begrensede omfanget av Sprints og deres forhåndsdefinerte mål hjelper utviklerne med å fullføre meningsfylt arbeid i tide. De kontinuerlige utstillingsvinduene med nye funksjoner holder kunden fornøyd og i stand til å gi tilbakemelding. Samlet sett blir utviklingen mer effektiv.

MERK. Scrum er bare en smidig metodikk blant mange. For eksempel har Kanban ikke noe Sprint-ekvivalent, og holder i stedet relevansen via den kontinuerlig oppdaterte oppgaveprioritetskøen.

Key Agile Software Development Lifecycle Phases

Når du deler den ned til kjernekonseptene, er Agile-utviklingen ikke så vanskelig. Og selv om den kan virke bortkastet med antall involverte møter sparer det mye tid ved å optimalisere utviklingsoppgavene og redusere feilene i planleggingsfasen.

Fase 1: Krav

Før en produkteier til og med kan begynne å designe et prosjekt, må de lage den opprinnelige dokumentasjonen som viser de opprinnelige kravene. De er:

• Sluttresultatet prosjektet skal oppnå. For eksempel en tekstredigerer;
• Funksjonene den støtter. For eksempel forskjellige skriftstørrelser;
• Funksjonene som den ikke støtter i utgangspunktet. For eksempel å legge til animasjoner i teksten eller muligheten til å legge inn video;

En generell anbefaling er å senke disse innledende kravene så hardt man kan, bare legge til de absolutt nødvendige funksjonene og ignorere de som vil ikke bli brukt ofte. Utviklere kan jobbe med dem senere, når appen er distribuert og kjernefunksjonene fungerer bra.

MERK: Hvis utviklere velger å ignorere dette stadiet, er de utsatt for funksjonskryp – situasjon når nye ikke-avgjørende funksjoner blir stadig lagt til i prosjektet, og tar utvikleres tid fra de viktige oppgavene.

Ved ytterligere iterasjoner vurderer klienten og produkteieren kravene og gjør dem mer relevante.

Fase 2: design

Det er to måter å nærme seg design i programvareutviklingen – den ene er den visuelle designen og den andre er den arkitektoniske strukturen til appen.

Programvaredesign

I løpet av den første iterasjonen, setter produkteieren sammen sitt utviklingsteam og introduserer kravene som ble opprettet i forrige trinn. Teamet diskuterer deretter hvordan de skal takle disse kravene, og foreslår verktøyene som trengs for å oppnå det beste resultatet. For eksempel definerer teamet programmeringsspråk, rammeverk og biblioteker som prosjektet skal bruke.

På videre iterasjoner diskuterer utviklerne funksjonsimplementeringen og den interne strukturen til kom.

UI / UX Design

I løpet av dette SDLC-trinnet lager designerne en grov mock-up av brukergrensesnittet. Hvis produktet er forbrukergrad, er brukergrensesnittet og brukeropplevelsen viktigst. Så det er generelt lurt å se gjennom de mulige konkurrentene for å se hva de gjør riktig – og spesielt hva de gjør galt.

Ytterligere iterasjoner brukes på å finpusse den opprinnelige designen og / eller omarbeide den slik at den passer til nye funksjoner.

Fase 3. Utvikling og koding

Utviklingsfasen handler om å skrive kode og konvertere designdokumentasjon til selve programvaren i programvareutviklingsprosessen. Denne fasen av SDLC er vanligvis den lengste siden den er ryggraden i hele prosessen.

Det er ikke mange endringer mellom gjentakelsene her.

Fase 4. Integrasjon og testing

Dette trinnet brukes på å sørge for at programvaren er feilfri og kompatibel med alt annet som utviklerne har skrevet før. Kvalitetssikringsteamet utfører en rekke tester for å sikre at koden er ren og forretningsmessige mål for løsningen blir oppfylt.

Under den videre iterasjonen av dette SDLC-trinnet blir testingen mer involvert og regnskapet er ikke bare for funksjonalitetstesting, men også for systemintegrering, interoperabilitet og testing av brukeraksept osv.

Fase 5. Implementering og distribusjon

Programmet distribueres på serverne og leveres til kundene – enten for demoen eller for faktisk bruk. Ytterligere iterasjoner oppdaterer den allerede installerte programvaren, introduserer nye funksjoner og løser feil.

Fase 6. Gjennomgang

Når alle tidligere utviklingsfaser er fullført, samler produkteieren utviklingsteamet igjen og gjennomgår fremdriften som er gjort mot å fullføre kravene. Teamet introduserer ideene sine for å løse problemene som oppstod i løpet av de forrige fasene, og Produkteier tar hensyn til deres forslag.

Deretter starter livssyklusfasene for Agile programvareutvikling på nytt – enten med en ny iterasjon eller ved å gå mot neste trinn.

Innlemme generelle magre prinsipper innen smidig metodikk

De magre prinsippene er:

• Eliminer avfall;
• Bygg kvalitet;
• Lag kunnskap;
• Vis ansvar;
• Lever raskt;
• Respekter mennesker;
• Optimaliser som helhet.

Samlet sett samsvarer disse verdiene med Agile-metoden ganske bra og kan brukes til å supplere den hvis spørsmål oppstår .

Konklusjon

Programvareutvikling er en strukturert iterativ prosess. Imidlertid er det ingen eneste «riktige» måte å gjøre Agile på – det er bare de som passer eller ikke passer til et bestemt lag.Hvert selskap har sin egen ide om hva som er Agile utvikling, og hver og en har sine fordeler. Det som betyr noe på slutten av dagen er et verdifullt sluttprodukt levert i tide.

Og det er slik vi i Relevant Software utvikler godt skreddersydde applikasjoner som tilfredsstiller kundens forretningsbehov. Vi bruker Agile paradigmer for alle våre prosjekter og leverer kontinuerlig fremragende resultater.