Software Utvikling livssyklus (SDLC). Scrum-Modellen Trinn for Trinn
Scrum rammeverket tillater å implementere Smidig utvikling metodikk. I motsetning til fossen modell av software development Scrum gjør en iterativ og inkrementell utvikling. Prosjektet deles i flere faser, som hver resultater i en klar-til-bruk produktet. På slutten av hvert trinn (kalt sprint i Scrum-terminologi), en brukbar produktet er levert til en kunde., Tilbakemeldinger bidrar til å avdekke mulige problemer eller endre den opprinnelige utviklingsplanen hvis det er nødvendig. Hvis du ønsker at prosjektet skal strengt følger de viktigste prinsippene i Agile manifesto, kan du bruke Scrum-modellen og være sikker på at du er på rett vei.
Her er de viktigste roller som er involvert i utviklingsprosessen, i henhold til Scrum-modell:
- produktet eieren tar vare på slutten brukerens interesser;
- Scrum master koordinerer hele utviklingsprosessen., En annen oppgave er å sørge for at Scrum er brukt riktig og for å holde regelmessige Scrum-møter;
- Scrum teamet utvikler produktet. Dens viktigste oppgaver er programmering, analyse, testing, osv.
Nå, la oss ta en titt på de viktigste trinnene i utviklingsprosessen at Scrum består av.
Faser av Scrum Modell
Trinn 1. Produktkøen Etableringen
En product backlog er en liste som inneholder funksjoner for å være implementert i løpet av utviklingsprosessen. Det er sortert etter prioritet, og alle ting er kalt en Bruker historien. Hver bruker historien får en unik ID., Som regel bruker historier har følgende format: Som en vil jeg så det . Denne listen nedenfor viser hvordan disse historiene kan se ut som.,ange varighet og start-dato for gjeldende de ved hjelp av dra-og-slipp, slik at jeg kan beregne den totale prosjekt tid
i Tillegg til disse obligatoriske felt, tilleggsutstyr som kan legges til ved behov:
- sporet er brukt for å velge alle bruker historier av en bestemt type for å endre deres prioritet., Kan bli brukt det til å øke prioritering av brukeren historier som er knyttet til kontrollpanel, for eksempel;
- Komponenter gjøre opp en liste over komponenter som vil bli endret underveis i arbeidet. Et program moduler, for eksempel godkjenning eller søk, for eksempel;
- anmoder er en kunde som er interessert i å gjennomføre noen bestemt funksjonalitet;
- Bug-sporings-ID-inneholder en liste over oppdagede feil som er knyttet til en riktig bruker-historien.
Trinn 2. Sprint-Planlegging og Sprint Backlog Etableringen
for det Første, bør du finne ut hva din sprint varighet vil være., En kort sprint gir deg mulighet til å slippe å jobbe versjon av et produkt oftere. Som et resultat av kundens tilbakemeldinger vil bli mottatt oftere, og alle mulige feil og feil vil bli avslørt i tide.
Som et alternativ, kan du foretrekker en sprint lenger varighet. Det vil tillate utviklere å arbeide mer grundig. Den optimale sprint varighet er definert som et gjennomsnitt av disse to alternativene. Som en regel, i et Scrum-modell, en sprint varer i ca 2-4 uker. Hva er mer viktig i denne fasen er det Sprint Mål. Målet er fastsatt for hver sprint., Og i samsvar med det sprint er fylt med brukeren historier. En annen viktig ting er det samarbeid mellom interessenter og gruppemedlemmer. Produktet eier avgjør betydningen av et riktig bruker-historien, mens Scrum team definerer den aktuelle lønnskostnader.
Etter at Scrum teamet kan velge den mest viktig bruker historier fra produktkøen. Deretter team-medlemmer bør avgjøre hvordan de vil løse dette, eller at oppgaven. Også, team kan dele bestemt bruker historier til de minste og slå dem deretter inn i rekken av oppgaver., Sprint backlog skal kunne opprettes ved siden. Det består av user stories som vil være fullført i løpet dagens sprint. Mengden av disse historiene er avhengig av deres kapasitet i historien poeng som er tilordnet til hver historie under evalueringsfasen. Scrum team bør være i stand til å fullføre alle disse historiene på gang.
Trinn 3. Arbeider på Sprint. Daglige Scrum-Møter
Etter faktisk bruker historier for den nåværende fasen er valgt, utvikling prosessen begynner.
for Å følge den aktuelle arbeidsprosessen, en oppgave for styret er ofte brukt., Det er vanligvis store kort med navn på bestemt bruker historier og en bunt av små klistrelapper med en beskrivelse av enkeltstående oppgaver som er nødvendige for gjennomføringen av dette, eller at historien. Hvert enkelt styremedlem er utviklet i henhold til de nærmere detaljer i et prosjekt. La oss ta en titt på et lite eksempel.
kortene kan arrangeres i henhold til deres betydning. Når arbeidet på en oppgave som har blitt startet, er den tilsvarende etiketten er flyttet fra «Å gjøre» – feltet for å «pågår» – en., Når arbeidet er fullført, klistremerke kan bli flyttet til «Testing» – feltet, og etter at oppgaven er ferdig testet, klistremerke går til «Ferdig» – felt. Et eksempel på hvordan Scrum oppgave styret kan se ut er vist nedenfor:
Det er også en mulighet til å bruke spesialisert programvare for denne oppgaven.
For eksempel, Atlassian JIRA.
en Annen viktig Scrum-funksjonen er Daglige Scrum-møter., Disse møtene’ hovedmål er å få full og veracious informasjon om det aktuelle prosjektet status og sørge for at alle medlemmene i teamet er på samme side. I løpet av Scrum-møter, hvert enkelt medlem av teamet, burde vite hva han eller hun har gjort for Sprint-Målet, noe som oppgave vil være det neste, og hvilke problemer team medlemmer møtte under arbeidet.
I tillegg, en burndown chart er en annen mye brukt verktøy som tillater overvåking daglig prosesser effektivt. Den viser hvor mange oppgaver forbli uferdige., Denne oversikten gir muligheten til å styre utviklingen prosessen og kan bli oppdatert etter hvert møte.
fra dag til Dag Scrum-møter bidra til å øke fleksibiliteten i utviklingsprosessen. De gjør også at forståelsen av hva som bør gjøres endringer.
X-aksen representerer de resterende dager av arbeidet, mens Y-aksen viser den totale mengden av historien poeng for dagens etappe. Etter en oppgave som krever at et visst antall av historien poeng for å fullføre er over, kan du legge til et punkt på diagrammet for å indikere nåværende fremgang.,
JIRA tillater deg å lage disse figurene også:
Denne oversikten hjelper med å trekke konklusjoner om gjeldende hastighet av arbeidet. Avhengig av disse konklusjonene, antall user stories for neste sprint kan bli endret.
Det er viktig å merke seg at, siden den ideelle resultatet av hver sprint i et Scrum-modellen er en fungerende produkt, full livssyklus testing prosessen er svært viktig. Det er forskjellige måter å minimere kostnadene av testing. Du kan For eksempel redusere den totale mengden av user stories., Som et resultat, antall mulige feil vil bli minimert. Den andre måten er å inkludere QA ingeniører i Scrum-team.
Les Også Hvorfor QA Spiller en viktig Rolle i en Høy Kvalitet Programvare produktutvikling
Trinn 4. Produktinkrement og Sprint Review
resultatet av hver sprint i Scrum er et potensielt shippable produktinkrement som kan være vist til kunden. Etter hver iterasjon, utvikling team lager en ny versjon av en programvare produkt med økt verdi., Under Sprint Review, som er slutten del av hver sprint, det samlede resultatet kan bli demonstrert og analysert. På grunnlag av alt dette info, interessenter kan ta en beslutning om ytterligere endringer i prosjektet og plan for neste sprint.
Trinn 5. Retrospektiv og Neste Sprint-Planlegging
Retrospektiv ‘ s hovedmål er å diskutere resultatene og finne måter å forbedre utviklingsprosessen på neste trinn., En viktig funksjon er at på dette stadiet er det prosesser i arbeid og samhandling som er diskutert for å forbedre arbeidet med Scrum teamet som helhet. Laget skal konkludere med hva som gikk bra i løpet av arbeidsprosessen, og hva som kan gjøres bedre i fremtiden iterasjon. Når måter forbedring er definert, kan teamet konsentrere seg om neste sprint-planlegging.
Konklusjon
De viktigste særtrekkene av Scrum er fleksibilitet og kontinuerlig fremgang. Det er forutsatt at det meste av permanent kommunikasjon og tett samarbeid mellom aktørene på hvert trinn., Scrum tilnærmingen innebærer en kontinuerlig iterativ og inkrementell utvikling. Målet er å sikre muligheten til hele tiden å øke produktets verdi og opprettholde fleksibilitet i å velge prioriteringer for videre spill.
Når er det sprint er ferdig, kan kunden evaluere arbeidet funksjonalitet for et produkt på det nåværende stadiet og foreta en informert beslutning om hvordan prosjektet skal utvikle seg i løpet av de neste sprint.,
Selv om det i henhold til Agile manifesto, bør du foretrekker å arbeide programvare over omfattende dokumentasjon, ingenting som hindrer utviklere fra bruk av en Programvare Krav-Spesifikasjonen. SRS er flinke til å si hva et system eller produkt bør gjøre. Til tross for at SRS kan gå glipp av noen smidig aspekter ved utvikling av et prosjekt, for eksempel samarbeid, kan det fortsatt være et godt verktøy for planlegging og planlegging.
– >