Agile softwareudvikling livscyklusfaser forklaret
#På opstart
Agile softwareudviklingsmetoden er en af de mest enkle, men effektive måder at levere et godt produkt på markedet. Og alligevel begyndte folk et sted undervejs at overkomplisere det virkelig. Korrekt implementeret Agile er hurtig, fleksibel, fejlsikker og simpelthen bedre måde at styre softwareudviklingsteams på. I denne artikel forklarer vi Agile softwareudviklings livscyklusfaser, og hvordan man integrerer Agile-principper.
Indholdsfortegnelse
Nøgleprincipperne for agil udvikling
Hovedidéerne bag Agile udvikling blev beskrevet i det oprindelige Manifest for Agile Software Development. Når de er opsummeret, er de:
- Ændring er uundgåelig. Projektet skal tilpasse sig det snarere end at ignorere det.
- t levere resultater er vigtigere end etablerede processer og værktøjer;
- Reelle kunders behov prioriteres højere end kravene i udviklingsplanerne.
Disse ideer er yderligere beskrevet i nøgleprincipperne for agil softwareudvikling.
Fokus bag Agile er slutbrugernes tilfredshed. Alle de opgaver, der ikke direkte arbejder med at forbedre det, er sekundære. Og mens Agile-udviklingsholdene stadig arbejder på at etablere processer, skrive dokumentation og følge planerne, kan disse opgaver udsættes eller udføres på et minimalt acceptabelt niveau, hvis de truer effektiviteten af udviklingen.
Agile Methodology Forklaret
Det vigtigste redskab til agil udvikling er iteration. Iteration er en proces, hvor et sæt handlinger gentages i en sekvens, indtil en betingelse er opfyldt.
Forskellige Agile udviklingsmetoder opnår iteration på forskellige måder. Scrum implementerer for eksempel Sprints. Sprints er faste tidsperioder – generelt 1-2 uger lange – hvor udviklingsteamet gennemfører en bestemt del af funktionaliteten og opnår foruddefinerede mål.
Brug for hjælp til softwareudvikling?
Relevant leverer fuldcyklus softwareudviklingstjenester fra markedsundersøgelser og forretningsanalyser til design, udvikling og lancering. Vi kan hjælpe dig med at opbygge dit produkt fra A til Z. Kontakt os for at få et tilbud.
Få et gratis tilbud
Her er et eksempel på arbejdsgangen inden for en enkelt Scrum Sprint:
- Produktejeren – den, der er ansvarlig for dens afslutning – gennemgår de ufuldstændige opgaver i Product Backlog. De forældede opgaver fjernes, mens de nye tilføjes;
- Produktejeren fastlægger omfanget af den nye Sprint og det mål, den sigter mod at nå.
- Produktejeren har en planlægning Møde med udviklingsteamet. De opretter brugerhistorier, der nedbrydes i opgaverne for visse Sprint, der er gemt i Backlog.
- Udviklingsteamet afholder daglige møder, hvor de holder sig opdateret om fremskridtene for hvert teammedlem;
- Når tidsrammen for Sprint løber ud, betragtes Sprint som komplet. De ufærdige opgaver flyttes tilbage til Product Backlog; I undtagelsestilfælde kan en Sprint-slutdato ændres af en produktejer.
- Produktejeren holder en demonstration for kunden og viser det arbejde, der er udført under Sprint.
- Produktejeren holder et møde med udviklingsteamet, hvor resultaterne af Sprint er gennemgået. Holdet fastslår, hvad der blev gjort godt, og hvilke processer der kan forbedres i næste sprint. Denne anmeldelse kaldes en Sprint Retrospective.
- Den næste sprint begynder.
Den regelmæssige gennemgang af Backlog hjælper med at bevare relevansen af funktionerne i Backlog. Det begrænsede omfang af Sprints og deres foruddefinerede mål hjælper udviklerne med at gennemføre meningsfuldt arbejde til tiden. De kontinuerlige fremvisninger af nye funktioner holder kunden tilfreds og i stand til at give feedback. Samlet set bliver udviklingen mere effektiv.
BEMÆRK. Scrum er kun en agil metode blandt mange. For eksempel har Kanban ikke nogen Sprint-ækvivalent og holder i stedet sin relevans via den konstant opdaterede Task Priority Queue.
Download ebogen
Nøgle Agile Softwareudvikling Livscyklusfaser
Når du nedbryder det til kernebegreberne, er Agile-udviklingen ikke så vanskelig, og selvom det kan virke spildende med antallet af involverede møder sparer det meget tid ved at optimere udviklingsopgaverne og reducere fejlene i planlægningsfasen.
Fase 1: Krav
Inden en produktejer overhovedet kan begynde at designe et projekt, skal de oprette den oprindelige dokumentation, der viser de oprindelige krav. De er:
- Slutresultatet projektet skal nå. For eksempel en teksteditor;
- De funktioner, den understøtter. F.eks. Forskellige skriftstørrelser;
- De funktioner, som det oprindeligt ikke understøtter. For eksempel at tilføje animationer til teksten eller evnen til at integrere video;
En generel anbefaling er at sænke disse oprindelige krav så hårdt man kan, kun tilføje de absolut nødvendige funktioner og ignorere dem, der vil ikke blive brugt ofte. Udviklere kan arbejde på dem senere, når appen er implementeret, og kernefunktionerne fungerer godt.
BEMÆRK: Hvis udviklere vælger at ignorere dette trin, er de tilbøjelige til at krybe funktioner – situation, når nye ikke-afgørende funktioner tilføjes konstant til projektet og tager udvikleres tid væk fra de vigtige opgaver.
Ved yderligere iterationer gennemgår klienten og produktejeren kravene og gør dem mere relevante.
Fase 2: design
Der er to måder at komme til design i softwareudviklingen – den ene er det visuelle design og den anden er appens arkitektoniske struktur.
Software Design
Under den første iteration samler produktejeren deres udviklingsteam og introducerer de krav, der blev oprettet i den forrige fase. Teamet diskuterer derefter, hvordan man tackler disse krav, og foreslår de nødvendige værktøjer til at opnå det bedste resultat. For eksempel definerer teamet det programmeringssprog, rammer og biblioteker, som projektet skal bruge.
På yderligere iterationer diskuterer udviklerne funktionens implementering og den interne struktur af come.
UI / UX Design
Under dette SDLC-trin opretter designerne en grov mock-up af brugergrænsefladen. Hvis produktet er forbrugerklasse, er brugergrænsefladen og brugeroplevelsen vigtigst. Så det er generelt en god ide at gennemgå de mulige konkurrenter for at se, hvad de gør rigtigt – og især hvad de gør forkert.
Yderligere iterationer bruges på at finjustere det oprindelige design og / eller omarbejde det, så det passer til nye funktioner.
Fase 3. Udvikling og kodning
Udviklingsfasen handler om at skrive kode og konvertere designdokumentation til den aktuelle software inden for softwareudviklingsprocessen. Denne fase af SDLC er generelt den længste, da den er rygraden i hele processen.
Der er ikke mange ændringer mellem gentagelserne her.
Fase 4. Integration og test
Dette trin bruges på at sikre, at softwaren er fejlfri og kompatibel med alt andet, som udviklerne har skrevet før. Kvalitetssikringsteamet gennemfører en række tests for at sikre, at koden er ren, og at forretningsmæssige mål for løsningen er opfyldt.
Under de videre iterationer af dette SDLC-trin bliver testen mere involveret og konti ikke kun til testning af funktionalitet, men også til systemintegration, interoperabilitet og test af brugeraccept osv.
Fase 5. Implementering og implementering
Applikationen implementeres på serverne og leveres til kunderne – enten til demoen eller den faktiske brug. Yderligere iterationer opdaterer den allerede installerede software, introducerer nye funktioner og løser fejl.
Download whitepaper
Fase 6. Gennemgang
Når alle tidligere udviklingsfaser er afsluttet, samler produktejeren udviklingsteamet igen og gennemgår de fremskridt, der er gjort med at opfylde kravene. Teamet introducerer deres ideer til løsning af de problemer, der opstod i de foregående faser, og Produktejeren tager deres forslag i betragtning.
Derefter begynder Agile softwareudviklings livscyklusfaser på ny – enten med en ny iteration eller ved at bevæge sig mod næste trin.
Inkorporerer generelle magre principper inden for agil metode
De magre principper er:
- Fjern affald;
- Byg kvalitet;
- Opret viden;
- Vis ansvar;
- Lever hurtigt;
- Respekter mennesker;
- Optimer som helhed.
Samlet set svarer disse værdier ret godt til Agile-metoden og kan bruges til at supplere den, hvis der opstår spørgsmål .
Konklusion
Softwareudvikling er en struktureret iterativ proces. Der er dog ingen “korrekt” måde at gøre Agile på – der er bare dem, der passer eller ikke passer til et bestemt hold.Hver virksomhed har sin egen idé om, hvad der er Agile udvikling, og hver enkelt har sine fordele. Det, der betyder noget i slutningen af dagen, er et værdifuldt slutprodukt, der leveres til tiden.
Og det er sådan, at vi i Relevant Software udvikler veltilpassede applikationer, der imødekommer vores kunders forretningsbehov. Vi bruger Agile paradigmer til alle vores projekter og leverer konstant fremragende resultater.