Scrum utviklingsmetodikk. Scrum: en revolusjonerende prosjektledelsesmetode

Hva er Scrum-metodikk? Hvordan bruke det i utvikling og ikke bare? Hvorfor er ikke fleksibilitet alltid bra?

Studiet fortsetter, tre ganger i uken blir jeg kjent med ny kunnskap fra feltet utvikling og forståelse av digitale produkter fra innsiden. For en markedsfører er dette en ny verden. Du hører om en slags Agile, du forstår at dette er relatert til utvikling og du kan enkelt holde samtalen i generelle vendinger. Men så snart det kommer til detaljer, "floated".

Scrum-metodikken er den mest populære blant alt smidig i utvikling og utover. Det ble interessant for meg å forstå hva det er og hva som er den praktiske anvendelsen av dette verktøyet. Jeg presenterer en anmeldelse for din vurdering.

Hva er Scrum

Scrum er en smidig utviklingsmetodikk eller et smidig styringsrammeverk (dvs. struktur) med vekt på prosesskvalitet.

Essensen av metodikken koker ned til det faktum at opprettelsen av et produkt er delt inn i visse deler. Et stykke tid eller en sprint (vanligvis 2 uker) er tildelt for å gjennomføre slike deler. På slutten av hver slik sprint skal det holdes en demonstrasjon av det fullførte stykket. Figuren ovenfor er bare et generelt prinsipp for prosesser. La oss ta en nærmere titt.

Hvordan Scrum fungerer

Hvordan Scrum faktisk fungerer, se nedenfor.

Så langt ser det ut som en kinesisk bokstav, så jeg foreslår å se på de enkelte delene og demontere hvert element i strukturen. Jeg anbefaler på det sterkeste Boris Wolfsans bok "Agile Methodologies", det var hun som dannet grunnlaget for dette materialet (noen av bildene er derfra).

Scrum struktur

La oss se hvilke elementer Scrum består av.

Roller

• Produkteier (produkteier/leder). Setter en oppgave, bestemmer prioriteringer for oppgaver, samhandler med kunden.
• En Scrum Master er en person som er ansvarlig for prosessene i teamet, koordinerer arbeidet, overvåker den interne atmosfæren. Planlegger sprinten, organiserer scrum-møtet, deltar i demonstrasjonen av resultatene på slutten av hver sprint.

Scrum-møte - et daglig møte, et møte, hvor fremdriften i sprinten analyseres. Hva er gjort, er det noen problemer, hva planlegges å gjøre. Ikke mer enn 15 minutter per møte. Alle teammedlemmer må snakke. Scrum Master holder styr på alles timing og ytelse.

• Team - 7±2 personer som implementerer kravene til produktet eier.

Gjenstander

• Produktetterslep. Liste over krav med prioriterte og arbeidskostnader.
• Sprint-etterslep. En del av sprintetterslepet, det vil si flere oppgaver som virkelig får plass i en sprint.
• Produktøkning. Ferdig del av produktet for demonstrasjon. I digitale prosjekter kan det være funksjonalitet. For eksempel et fungerende registreringsskjema på nettstedet, som kan vises.

Prosesser

• Sprintplanlegging. Et team med en Scrum Master planlegger en arbeidsplan for neste sprint, det vil si at den kompilerer en sprintbacklog (liste) med oppgaver.
• Sprint gjennomgang. Demonstrasjon av produktøkningen etter hver sprint. Teamet viser arbeidsfunksjonaliteten til produkteier (og kunden på forespørsel), som igjen gjør endringer i kravene ved behov.
• Retrospektiv. Gjennomgang av forrige sprint for å forbedre prosessene. Teamet, Scrum Master og Product Owner diskuterer siste sprint, trekker konklusjoner, tenker på hva som kan forbedres.
• Scrum rally. (se definisjonen ovenfor i «Roller»-blokken)
• Sprint. Som regel en to ukers periode hvor teamet klarer å utvikle funksjonalitet klar for demonstrasjon.

Unnskyld at jeg avbryter lesingen. Bli med på telegramkanalen min. Ferske kunngjøringer av artikler, utvikling av digitale produkter og veksthack, alt er der. Venter på deg! Vi fortsetter ...

Scrum eksempel

Tenk deg at du trenger å lage en side / tjeneste for rengjøring i sommerhyttene dine. Du har et landsted hvor det er komplette sømmer på stedet, og det er ikke mulig å bruke helgene på å rydde, fordi du også vil slappe av litt. Derfor, voila, service Uberimoydvor!

Vi tror at tjenesten vil være basert på nettstedet. Brukeren registrerer seg, legger igjen en forespørsel og operatøren ringer ham tilbake, som avklarer detaljene og avtaler et passende tidspunkt for klienten. Vi ønsker å bruke Scrum til å utvikle siden.

La oss velge for eksempel en viktig oppgave eller brukerhistorie (brukerhistorie) som en del av å lage et nettsted: “Registrering av en klient/bruker”. Og del den ned i mindre biter. Vi lager en produktbacklog.

Hovedbrukerhistorien er dekomponert i små oppgaver. Deretter blir det sammen med laget prioritert og oppgaver fordelt på sprint. Ikke glem hovedregelen, etter sprinten bør vi ha ferdig funksjonalitet for demonstrasjon.

I praksis er det mange flere brukerhistorier (som «Brukerregistrering»). En tjeneste/produkt kan inneholde mange slike historier, så prioriteringen bygges fra topp til bunn, fra venstre til høyre. I øvre venstre del er de viktigste brukerhistoriene (Aktivitet) og de viktigste oppgavene.

For å vise etterslepet av oppgaver, brukes vanlige klistremerker, en tavle (noen ganger til og med en vegg). Slik kan det se ut.

Det er tydelig at det rett og slett er umulig å administrere en slik "koloss" i sanntid, derfor flyttes hele veggen til en spesiell programvare / program (Jira, Trello, Redmine og andre prosjektledelsessporere) for å gjøre det lettere for arbeidet. . Der kan du tildele oppgaveansvarlige og utførende, endre oppgavestatuser med mer.

Veggen fungerer også bra, for på etableringsstadiet er hele teamet lidenskapelig og føler deres bidrag til felles sak. Men etter at det må overføres til et passende verktøy.

La oss komme tilbake til å rydde i hagen. Så vi valgte sprint med oppgaver og satte i gang. Teamet utfører arbeidsmengden hver dag, og scrum-masteren organiserer 15-minutters planleggingsmøter (scrum-møter), hvor han oppdaterer status på sprintoppgavene og finner ut av eventuelle vanskeligheter i arbeidet.

Det er svært viktig at Scrum Master overvåker klimaet og relasjonene i teamet, hans oppgave er å danne og opprettholde et selvorganiserende motivert team. For å gjøre dette er det nødvendig å løse problemer og misforståelser mellom alle deltakerne. Scrum Master er treneren som forbedrer laget.

Etter en 2-ukers sprint gjennomfører Scrum Master og teamet en funksjonell demonstrasjon. I vårt eksempel klarte vi å lage et registreringsskjema og vise det til produktets eier. Han gjennomgår og gjør justeringer om nødvendig. Etter å ha akseptert arbeidet går vi videre til neste sprint.

Retrospektiv: Sprintanalyse

Noen dager etter slutten av sprinten, bør produkteier, scrum master og team møtes og holde en retrospektiv (sprint review). Dette er et møte i flere timer (avhengig av sprintens varighet og størrelsen på laget), som ordner opp i vanskelighetene som oppsto i siste sprinten.

Deltakerne deler sine meninger og bestemmer hva som kan forbedres i fremtidige spurter. Dermed er det en naturlig utvikling av prosesser, siden med hver ny iterasjon blir tidligere erfaring tatt i betraktning og analysert.

Hvordan prioritere

Det er bra at vi bruker Scrum-administrasjon, men hvordan prioritere en enorm liste med brukerhistorier? Tross alt kan prosjektet inneholde mange slike historier.

Det er det en produkteier er til for. Det er han som forstår publikums behov, overvåker markedet og trekker konklusjoner om hva som bør gjøres i etterslepet. Hovedoppgaven er å løse kundens behov og starte bedre med det viktigste.

Samtidig er det nødvendig å ta hensyn til lagets evner. Hvor mange oppgaver kan hun løse i en sprint? Hva slags oppgaver er dette? Hvordan planlegge den generelle fremdriften? Evaluering inne i etterslepet vil hjelpe.

Evaluering av brukerhistorier inne i backlog

Vi har dannet et etterslep, men hvordan vurdere brukerhistorier med tanke på kompleksitet? Til dette brukes standardmetoden. Dette er et relativt estimat som lar deg forstå potensialet til teamet og grovt anslå ressursene.

Vi tar én brukerhistorie fra backlog som et eksempel og tildeler en verdi på én (story point) til den. Deretter vurderer vi andre brukerhistorier fra synspunktet til den valgte.

For eksempel, i vår tjeneste er det en brukerhistorie "Brukerregistrering". Vi tar det som en modell og gir en verdi på ett poeng eller ett historiepoeng (som det heter i fleksible metodikker). Hvert teammedlem skriver sin vurdering til resten av brukerhistoriene i listen, tar hensyn til oppgaven som ble tatt som modell og gir den til Scrum Master.

I eksemplet ovenfor koster "Fotogalleri med fornøyde kunder" 0,5 historiepoeng, det vil si at det er 2 ganger mindre komplisert enn vår referansehistorie "Brukerregistrering". Teammedlemmer gir alle karakterer anonymt, du kan skrive og snu på klistremerker.

Når alle har satt ned merkene, åpnes resultatene. Scrum Master organiserer en diskusjon mellom deltakerne som ga de mest ekstreme karakterene. På bildet over er disse 2 og 8. De blir enige seg imellom og andre valgomgang starter.

Alle deltakere må komme til en felles mening og poengsummene er på linje. Som et resultat får vi en oversikt over alle brukerhistorier, tatt i betraktning den relative vurderingen.

Videre, tatt i betraktning prioriteringene, rekrutteres oppgavene i sprint og arbeidet starter. Basert på resultatene av de fullførte spurtene blir det klart hvor mange historiepoeng laget omtrent kan fullføre. Og i prosessen med å analysere (retrospektiv) etterpå, kan vekstpunkter bli funnet.

Dermed får vi en intern måler eller valuta som laget får per sprint. Den kan brukes til å måle teamytelse og forutsi fremtidige iterasjoner.

Kan Scrum brukes utenom utvikling?

Ja og nei. Før jeg begynte å forstå hva disse 5 bokstavene (Scrum) betyr, brukte jeg allerede noen av prinsippene i arbeidet mitt. Planlegging, ved hjelp av ulike verktøy, og bygging av den såkalte «oppgavesprinten» har allerede vært.

Men det er fortsatt ikke Scrum. Scrum er en metodikk og system som lar deg være fleksibel og hele tiden forbedre prosesser innad i et team.

Oppgaver må være generiske. Uansett hva man kan si, er utvikling en ingeniørpraksis, det vil si at oppgaven kan bringes til en viss standard. Og det er mye lettere å gjøre dette enn for eksempel innen kreativitet, markedsføring eller ledelse.

Noen praksiser fra metodikken er ganske anvendelige på andre områder. Å jobbe med et team og analysere arbeidet som er gjort, ja. Forutsi oppgaver på et tidspunkt, ja. Oppgavestyring, i praktiske programmer, ja, også.

Når skal du bruke Scrum

Mest i små prosjekter og oppstartsbedrifter. Det er mulig i store, som Mail.ru, men det må være en viss handlefrihet og separate funksjonelle team med egen produkteier. Ikke glem at Scrum handler om fleksibilitet og endring. Lag bør ikke være mer enn 7 ± 2 personer, ellers vil det være umulig å effektivt organisere kommunikasjonen.

Nyanser

Hvis du bestemmer deg for å implementere Scrum i prosjektene dine, bør du vurdere følgende nyanser:

• Ingen kundeorientering. Ikke alle kunder vil være klare for visse Scrum-standarder.
• Risikoresponssystemet er ikke tatt i betraktning. Teamet kan bruke litt ekstra tid på å fullføre oppgaver, men hvis det er sterke avvik fra planen, stopper systemet.
• Team og menneskelige egenskaper. Siden det legges vekt på et selvorganiserende team, må alle deltakere ha et høyt ansvarsnivå og passende motivasjon. Å skape et slikt team er en veldig vanskelig oppgave.
• Scrum mester. Den som er ansvarlig for prosessene og motivasjonen i teamet må føle på alle deltakerne og sammenhengene innad i gruppen. Dette er en sjelden spesialist som også er vanskelig å finne på markedet.

La oss fullføre

Til tross for nyansene og særegenhetene til Scrum-metoder, vil jeg merke at den fortsatt er den mest populære blant alle smidige metoder. Deler av den kan brukes på andre forretningsområder, og prinsippene kan danne grunnlaget for din egen utviklingsstrategi.

Scrum er en av de mulige måtene å implementere Agile utviklingsmetodikk. I motsetning til fossefallsmodellen for programvarens livssyklus, er Scrums kjennetegn iterasjon.

Utviklingsprosessen er delt inn i separate stadier, resultatet av hver av dem er det ferdige produktet. På slutten av hvert trinn (i terminologien til Scrum - sprint) leveres det ferdige produktet til kunden. Tilbakemeldingen mottatt fra kunden lar deg identifisere mulige problemer eller revidere noen aspekter av den opprinnelige planen. På denne måten lar Scrum deg best følge prinsippene for smidig utvikling.

Før du fortsetter med å beskrive livssyklusen til et Scrum-prosjekt, er det verdt å snakke om hovedrollene i Scrum-metodikken:

• Produkteier (produkteier) representerer interessene til sluttbrukeren.
• Scrum mester overvåker overholdelse av prinsippene for Scrum-utvikling, koordinerer prosessen, gjennomfører daglige møter (Scrum Meetings).
• Scrum team (Scrum-team) involvert i produktutvikling. Scrum-teamet inkluderer programmerere, testere, analytikere og andre spesialister.

Så la oss se på de viktigste utviklingsstadiene som er spesifikke for Scrum.

Trinn 1: Lag en produktbacklog

En produktbacklog er en ordnet liste over krav til et produkt som utvikles. Elementene i denne listen kalles brukerhistorier. Hver historie har en unik ID. Her er et eksempel på brukerhistorier fra produktbackloggen som ble brukt mens du jobbet med XB Staff Manager:

Beskrivelsen av hver historie bør inkludere et sett med obligatoriske felt som kreves for videre arbeid med prosjektet:

• Betydning. Graden av viktighet av oppgaven i henhold til produktets eier. Beskrevet med et vilkårlig tall.
• Opprinnelig estimat. Foreløpig estimat av arbeidets omfang. Målt i historiepoeng.
• Hvordan demo. Beskriver hvordan du demonstrerer en fullført oppgave.

I tillegg til disse obligatoriske feltene kan flere legges til om nødvendig:

• Kategori (spor) tjener til å tillate produkteieren å velge alle varer i en bestemt kategori og sette dem til lav eller høy prioritet. Et eksempel på en slik kategori vil være "Kontrollpanel".
• Komponenter består av en liste over produktkomponenter som vil bli endret mens du arbeider med historien. Slike komponenter kan være applikasjonsmoduler som autentisering eller søk.
• Forespørsel-kunden er interessert i implementering av visse funksjoner. Dette feltet er nødvendig hvis du trenger å holde kunden oppdatert med gjeldende tilstand.
• ID i defektsporingssystemet (feilsporings-ID) inneholder lenker til oppdagede defekter relatert til historien med en spesifikk ID.

Når prosjektetterslepet er på plass, er neste steg å planlegge spurten.

Trinn 2: Planlegging av Sprint og Opprett Sprint Backlog

På planleggingsstadiet bestemmes sprintens varighet. En kort sprint lar deg slippe fungerende versjoner av produktet oftere, og derfor oftere motta tilbakemelding fra klienten og identifisere mulige feil i tide. På den annen side lar lange spurter deg bruke mer tid på å løse problemet. Den optimale sprintlengden velges som en mellomting mellom disse to løsningene og er vanligvis rundt 2 uker. På dette stadiet er samspillet mellom produkteier og Scrum-teamet viktig. Produkteieren bestemmer prioriteringen av en bestemt oppgave, og Scrum-teamets oppgave er å bestemme de nødvendige arbeidskostnadene.

Under sprintplanleggingen velger teamet de høyest prioriterte brukerhistoriene fra produktbacklogen og bestemmer hvordan oppgavene skal løses. Historiene valgt ut for implementering i løpet av denne sprinten er Sprint-etterslep. Antall historier som kommer inn i sprintbacklogen avhenger av varigheten deres i historiepoengene som er tildelt hver historie under forhåndsevalueringsfasen. Dette tallet er valgt slik at hver historie er vellykket implementert ved slutten av spurten.

Trinn 3. Arbeid på sprinten. Scrum møter

Etter at de relevante brukerhistoriene for denne sprinten er bestemt, starter prosessen.

For å visualisere utviklingsprosessen er det praktisk å bruke kartotekkort. De kan ha form av store kort med navnet på en bestemt historie og små klistremerker som beskriver de individuelle oppgavene som trengs for å fullføre historien. Når du begynner å jobbe med en bestemt oppgave, flyttes klistremerket fra "Planlagt"-feltet til "Pågår"-området. Når arbeidet med oppgaven er fullført, flyttes klistremerket til "Testing"-feltet og deretter, hvis testingen er fullført, til "Done"-feltet. Ved å rangere historiene i henhold til deres betydning, kan du få en ide om den nåværende tilstanden til prosjektet:

Programvare utviklet for denne typen oppgaver kan også brukes. Et eksempel på slik programvare er for eksempel Atlassian JIRA.

Et viktig kjennetegn ved Scrum er daglige Scrum-møter, hvis formål er å gi teamet fullstendig og pålitelig informasjon om hvilket stadium utviklingsprosessen er på. Under møtet rapporterer hvert medlem av Scrum-teamet hvilken oppgave de har utført, hva som skal gjøres og hvilke vanskeligheter de har møtt under arbeidet.

Resultatet av hvert møte er også nedbrenningsdiagram. På X-aksen viser den arbeidsdagene på sprinten, og på Y-aksen det totale antallet historiepoeng for denne sprinten. Etter å ha fullført en oppgave som krevde et visst antall historiepunkter for å løse den, kan du markere punktet på diagrammet hvor prosjektet befinner seg for øyeblikket. Et eksempel på et slikt diagram bygget i JIRA er vist nedenfor:

Det lar deg evaluere tempoet i teamet og bestemme om du vil øke eller redusere antall historier i neste sprint. Daglige møter bidrar til å øke fleksibiliteten i utviklingsprosessen og gi en ide om de nødvendige justeringene som må gjøres laget på designstadiet av påfølgende spurter.

Trinn 4: Testing og demo av produktet

Siden hver sprint ideelt sett resulterer i et produkt som er klart til bruk, spiller testprosessen en viktig rolle i Scrum. Det er ulike måter å minimere kostnadene på på dette stadiet, fra å redusere antall historier i sprinten og, som et resultat, redusere antall feil til å inkludere testere i Scrum-teamet.

Finalen i hver sprint er en demonstrasjon av det ferdige produktet. Scrum-teamet skriver en anmeldelse som beskriver målene for sprinten, oppgavene som ble satt og hvordan de ble løst. Produkteier, kunder og brukere bestemmer på bakgrunn av gjennomgang og demonstrasjon hva som skal endres i den videre utviklingsprosessen.

Trinn 5. Retrospektiv. Planlegging for neste sprint

Basert på produkttilbakemeldinger mottatt etter demonstrasjonen, gjennomføres en retrospektiv. Hovedmålet er å finne ut hvordan utviklingsprosessen kan forbedres i neste sprint for å unngå problemer og jobbe mer effektivt. Når måtene å forbedre kvaliteten på arbeidet er identifisert, kan teamet begynne å planlegge neste sprint.

Konklusjon

Særtrekk ved Scrum er fleksibilitet og fokus på kontinuerlig utvikling og endring. Dette oppnås i stor grad gjennom kontinuerlig kommunikasjon og samhandling. Under sprintplanleggingsfasen kommuniserer Product Owner med Scrum-teamet for å finne ut hvilke oppgaver User Stories kan deles inn i og hvordan de kan implementeres. Under daglige møter diskuterer medlemmer av Scrum-teamet gjennomføringen av hver enkelt oppgave og bestemmer mulige løsninger på problemene som har oppstått. På slutten av sprinten presenteres det ferdige produktet for kunden, som kan vurdere gjeldende funksjonalitet og notere hva han ønsker å endre. Dette kjennetegnet til Scrum kan være nyttig dersom kundens visjon om hvordan produktet skal se ut endres over tid. Og til slutt blir all informasjon som mottas på disse stadiene tatt hensyn til i alle påfølgende spurter, noe som bidrar til å optimalisere utviklingsprosessen på best mulig måte.

De følgende to fanene endrer innholdet nedenfor.

Hva er Scrum. Essensen av teknikken

De som er involvert i prosjektledelse, og bare ledelse, er godt klar over hvor vanskelig det er å organisere et godt koordinert teamarbeid. på grunn av mangel på sammenheng, planer blir stadig brutt, det er forsinkelser i tidsplanen, prosjektbudsjettet er oppblåst, penger og tid sklir mellom fingrene våre, oppgavene til forskjellige avdelinger dupliseres, folk krangler og hjelper ikke hverandre, selv om , ser det ut til at deres innsats er rettet mot å oppnå det samme målet. I tillegg er kundene ofte misfornøyde med den endelige versjonen av det opprettede produktet.

Scrum, utviklet av Jeff Sutherland og Ken Schwaber, har som mål å løse alle disse problemene. Scrum— dette er det motsatte av den klassiske steg-for-steg-tilnærmingen som brukes til gjennomføring av prosjekter. Scrum-metodikken har blitt tatt i bruk av mange selskaper, både fra teknologibransjene der den kommer fra, så vel som fra tradisjonelle og til og med non-profit. Tilnærmingen som underbygger Scrum-metodikken kan brukes på en rekke aktiviteter som krever teamarbeid.

Viktige kjennetegn ved Scrum er dens fleksibilitet og fokus på klienten, da det innebærer hans (klient) direkte deltakelse i arbeidsprosessen.

Scrum krever ikke implementering noen dyre verktøy. Omrisset av Scrum-metodikken kan oppsummeres som følger:

1. For å komme i gang, velg« Produkteier» — en person med en visjon om hva du skal skape eller oppnå.

2. Da må du samle"Team" , som vil omfatte personer som direkte utfører arbeidet. De må ha ferdighetene og kunnskapene til å bidra til å bringe produkteierens idé ut i livet.

3. Velg en Scrum Master Noen som vil overvåke fremdriften i prosjektet, sørge for korte møter og hjelpe teamet med å fjerne hindringer for å nå målet.

4. Når du kommer i gang, må du lage den mest komplette listen over alle kravene til produktet eller målet. Elementer på denne listen bør prioriteres. Listen heter"Produktetterslep" . Det kan utvikles og endres gjennom prosjektets levetid.

5. Teammedlemmer bør rangere hvert element i sitt eget karaktersystem for kompleksiteten og kostnadene som vil kreves for å fullføre den.

6. Deretter deltakerne scrum master og produktets eier må utføre den første Scrum møte hvor de planlegger å spurte— en viss tid for å fullføre en del av oppgavene. Varigheten av sprinten bør ikke overstige en måned. For hver sprint tjener laget et visst antall poeng. Laget må hele tiden strebe etter å overgå antall poeng opptjent i forrige sprint i den nye sprinten, det vil si målet.— stadig overgå dine egne resultater— « øke ytelsesdynamikken» .

7. For at alle deltakere skal være klar over tingenes tilstand er det nødvendig å starte scrum bord med tre kolonner:« Trenger å gjøre eller etterslep» ; " I jobb " ; "laget" . Deltakerne klistrer klistremerker med oppgaver på tavlen, som i arbeidsprosessen vekselvis flytter seg fra kolonnen"Backlog" til kolonnen "pågår" og deretter til "ferdig".

8. Holdes daglig Scrum møte . Ifølge Jeff Sutherland« er pulsen på hele Scrum-prosessen» . Essensen er enkel— daglig, på farten, femten minutter for alle å svare på tre spørsmål:« » , « » , « » .

9. På slutten av sprinten vurderer laget den— holder et møte hvor deltakerne forteller om hva som er gjort til sprinten.

10. Etter å ha vist resultatet av sprinten, holder deltakerne et retrospektivt møte, hvor de diskuterer hva laget gjorde bra, hva som kan gjøres bedre, hva som kan forbedres akkurat nå.

Ulemper med tradisjonell tilnærming til prosjektledelse

Som bokforfatter Jeff Sutherland påpeker, er det mange ulemper ved den tradisjonelle tilnærmingen til prosjektgjennomføring i form av en fossefallsmodell som involverer steg-for-steg fremgang mot et mål. Hele prosessen er veldig langsom, uforutsigbare vanskeligheter oppstår ofte og dessuten skjer det ofte at utøveren lager et produkt som absolutt ikke tilfredsstiller kunden.

Fossmodell innebærer bruk av Gantt-diagrammer— grafer som viser stadier av arbeidet og tidspunktet for gjennomføringen av dem. Prosjektets fremdrift markeres i detalj og hvert trinn i arbeidet reflekteres. Det antas at hver fase av prosjektet sekvensielt går over i en annen,— dette er prinsippet for kaskaden.

Hvorfor? Som Jeff Sutherland påpeker, kom Henry Gant med slike diagrammer allerede i 1910. De ble utbredt i første verdenskrig. Men,« alle som har studert historien til denne krigen vet at verken opplæring av arbeidskraft eller organisasjonssystemet noen gang har vært dens sterke sider. Jeg kan ikke forstå hvorfor første verdenskrig konseptblir de factoanalytisk designverktøy og brukes selv i det 21. århundre. Vi forlot prinsippene for skyttergravskrigføring, men på en eller annen måte "graven" hennes organisasjonsideer er fortsatt populære den dag i dag» .

Under moderne forhold er denne ordningen upassende og ligner modellen til politbyrået til sentralkomiteen til CPSU, som"trodde" rapporter som den mottok like før Sovjetunionens sammenbrudd og som hadde lite å gjøre med den virkelige tilstanden.

Filosofi av scrum

Scrum-metodikken reflekterer forfatterens lidenskap for japansk kampsport. I følge ham i Japan« Scrum blir ikke behandlet som en kortvarig kjepphest. Japanerne ser på Scrum som en tilnærming til å løse problemer, som en måte å gjøre ting på, som en måte å være på. — generelt, som en livsstil. Når jeg lærer folk denne teknikken, snakker jeg ofte om min mangeårige erfaring i den japanske kampsporten aikido. » .

Det Aikido og Scrum har til felles er at de bare kan mestres i arbeidsprosessen, når« din kropp, ditt sinn og din ånd er forent gjennom konstant praksis og streben etter fortreffelighet. Ved å praktisere aikido forstår vi konseptet shuhari (Shu Ha Ri) — det er både et begrep om kampsport og en indikator på ferdighetsnivået » .

Essensen av teamarbeid i Scrum

Scrum- det er først og fremst teamarbeid. Forfatteren identifiserer tre kjennetegn ved de beste lagene:

den uendelige søken etter perfeksjon;

• autonomi - evnen til å organisere seg selv;
• multifunksjonalitet. Tilstedeværelsen av ulike spesialister og en kultur for samhandling og gjensidig bistand.

Hvor stort skal et lag være? Jeff Sutherland anbefaler små grupper— rundt syv personer. Han siterer data om at hvis en gruppe består av mer enn ni personer, faller hastigheten på arbeidet.

I tillegg minner forfatteren om "Brooks' lov":

« Hvis prosjektet ikke er i rute, vil det å legge til arbeidskraft forsinke det ytterligere. » .

Sjef for laget er en scrum master . Hans plikt— holde møter korte, holde dem åpne, hjelpe gruppen å gå gjennom hindringer som forstyrrer arbeidet, lede teamet på en vei for kontinuerlig forbedring« og se jevnlig etter svaret på spørsmålet« Hvordan kan vi gjøre enda bedre det vi allerede gjør bra?» .

Ingen multitasking

Forfatteren advarer mot multitasking— faktisk eksisterer den ikke, hjernen vår kan ikke utføre to handlinger samtidig, den bytter bare mellom oppgaver, og den totale utførelsestiden for hver av dem øker sammenlignet med om vi utførte dem én etter én. Scrum-metodikken forutsetter at du må utføre alle oppgavene én etter én, og ikke« balansere fem prosjekter samtidig» .

« Ved å følge den tradisjonelle metoden, det vil si å prøve å gjøre alt på en gang, vil gruppen fullføre sine tre prosjekter før slutten av juli. Hvis gruppen kommer i gang med en smidig strategi som Scrum og jobber med hvert prosjekt etter tur, og minimerer tiden og kreftene brukt på kontekstbytte, bør de være i stand til å fullføre alt innen begynnelsen av mai. » .

Essensen av arbeidet er flyten

Scrum hjelper deg med å komme inn"flyt" - tilstanden med høyeste konsentrasjon, når du gjør det du trenger å gjøre uten å anstrenge deg, uten å tvinge deg selv eller presse deg. Forfatteren mener at det viktigste for vellykket arbeid— oppnå og administrere denne tilstanden.« I arbeidet ditt må du oppnå det viktigste— uanstrengt flytkontroll. I kampsport eller meditasjonspraksis oppnår vi en følelse av enhet i bevegelse som er uanstrengt,— det er energien som flyter fritt gjennom oss. Når du ser på flotte dansere eller sangere, kan du føle hvordan de bukker under for denne energien. Vi må strebe for å oppnå denne tilstanden i vårt arbeid.» .

Hvordan nå det? Bak tilstanden til flyt er en intern disiplin,

« Det skal ikke være en eneste bevegelse bortkastet » .

Scrum og lykke

Folk ønsker å være lykkelige. Men Jeff Sutherland er sikker på at lykken— dette er ikke et inaktivt vegetativt liv, men et lyst, rikt og aktivt liv. Scrum bidrar til et lykkelig liv, da det hjelper å jobbe og opptre produktivt.

På slutten av hver sprint holder deltakerne et retrospektivt møte der de snakker om arbeidet sitt og flytter de vurderte oppgavene til spalten"laget" og diskuter deretter hva som er bra og hva som kan forbedres. De finner hovedhindringen og tenker på hvordan de skal eliminere den i neste sprint. Dette er løsningen på problemet med kontinuerlig forbedring.

Elementer av Scrum

Sprints

Som nevnt ovenfor, i begynnelsen av sprinten, og for å sikre åpenhet og synlighet, må du starte et spesielt brett og dele det inn i tre kolonner:"Backlog"; " I jobb " ; "laget" . Før hver sprint stikker lagmedlemmer i en kolonne"Backlog" klistremerker med oppgaver de tror de kan fullføre i en sprint. I løpet av sprinten limer ethvert medlem av teamet, som har tatt opp oppgaven, klistremerket fra seksjonen på nytt"Backlog" til kolonnen "Pågår" . Etter å ha fullført oppgaven- i kolonnen "Ferdig". . Dermed ser alle hva andre deltakere jobber med for tiden.

Det er imidlertid en viktig merknad— « ingenting overføres til kolonnen"laget" inntil den delen av prosjektet er testet av oppdragsgiver» .

« Et annet kritisk aspekt ved sprinten er at når teamet godkjenner listen over krav, oppgavene fra den listen „ er blokkert“ . Ingen har rett til å endre eller legge til dem. » . Forfatteren anbefaler dette på grunn av at enhver forstyrrelse vil bremse arbeidet til teamet.

Daglige møter

Poenget er at de holdes stående, hver dag, på samme tid, deres varighet overstiger ikke femten minutter og deltakerne stiller de samme tre spørsmålene:« Hva gjorde du i går for å hjelpe laget med å fullføre sprinten?» , « Hva vil du gjøre i dag for å hjelpe laget med å fullføre sprinten?» , « Hvilke hindringer står i veien for laget?» .

Gjør det til slutten

I Scrum er det viktig å lære å kjenne rytmen i laget. I verste fall— når på slutten av sprinten noe forblir halvferdig. Det er bedre å ikke starte det i det hele tatt.

« Ressurser, innsats, tid, penger er brukt, men et fullt fungerende produkt har ikke blitt mottatt » .

Planlegging i Scrum

Hvordan fungerer planleggingsprosessen i Scrum? Først må du lage en liste over alle tingene som påvirker målet ditt. Så prioriter dem. Hvis du ikke oppfyller tids- og budsjettbegrensningene, kan du lettere eliminere de siste elementene på listen.

Hva skal jeg gjøre videre? Hvert element på listen må evalueres i forhold til hvor mye innsats, tid og andre ressurser som vil bli brukt på implementeringen. Hvordan gjøre en vurdering? Forfatteren foreslår en skala for relative vurderinger. Du kan for eksempel sammenligne oppgaver"hos hunder". Dette problemet - dachs eller retriever? Eller kanskje en hund?

Men i alle fall er det mer praktisk å angi numeriske verdier. For eksempel,« Dachshund— enhet; stor dansk— tretten; labradoren ble en femmer, og bulldogen — troika» .

Forfatteren foreslår også å bruke en interessant pokerplanleggingsteknikk. Dens essens— hver deltaker i planleggingsprosessen får en kortstokk med Fibonacci-tall— 1, 2, 3, 5, 8, 13 og så videre. Hvert punkt på listen, en arbeidsenhet som må estimeres, er lagt ut på bordet.

Krav er historier

For å lykkes og forståelig å formulere en liste over krav til et produkt og kompilere en backlog, tar Scrum en ekstraordinær tilnærming. I stedet for en enkel liste med oppgaver, kompileres brukerhistorier— noveller som inneholder brukernes ønsker til sluttproduktet.

« Tenk deg at du komponerer „ Amazon.com brukerønske “ . Prøveversjonen ser slik ut: „ Som forbruker trenger jeg verdens største bokhandel hvor jeg kan kjøpe hvilken som helst bok til enhver tid. “ .Denne beskrivelsen passer til karakteren til Amazon, men historien er for vag til å være noegjøre. Vi må fragmentere historien vår. Gjør det veldig konkret og funksjonelt. Her er noen eksempler på brukerhistorier som du kan skrive med en boklig i tankene. online-butikk : Som forbruker synes jeg det er praktisk å søke etter bøker etter sjanger slik at jeg raskt kan finne de jeg liker å lese. Som forbruker vil jeg legge hver enkelt i handlekurven når jeg velger bøker å kjøpe. Som et produkt lanseringsansvarlig ønsker jeg å kunne spore våre kunders kjøp å være klar over hvilke bøker de kan tilby Her er profesjonelt laget brukerønsker som gruppen bør ta hensyn til. » .

Brukerhistorien skal være fullstendig, uavhengig av ulike forhold, implementert i praksis. Disse kriteriene snakker om historiens beredskap. Det er også viktig at historien kan vurderes for gjennomførbarhet.

Hvordan planlegge en sprint

I Scrum foregår planleggingsprosessen i begynnelsen av hver ny sprint og kalles— « sprintplanlegging» . « Alle samles, ser gjennom listen over brukerhistorier som allerede står i køen for utførelse; finne ut hvor mange oppgaver hvert medlem av gruppen kan ta på seg; vurdere nøye om de vil være i stand til å bringe de utvalgte oppgavene til full fullføring i løpet av denne spurten; om de vil være i stand til å demonstrere for kunden de fullførte arbeidsenhetene og vise ham de ferdige funksjonene til produktet; vil de kunne si til seg selv på slutten av spurten at de taklet alt » .

Etter det sier teamet enstemmig:"Fremover! » — og kommer på jobb

Men hva er arbeid? Rutine, forpliktelse? Når det gjelder Scrum, arbeid— dette er historie. Hva betyr det? Det betyr at du skal presentere en person som trenger det du holder på med; så hva det er, og til slutt, hvorfor folk trenger det.

Lag må kjenne dynamikken deres godt— hvor mye arbeid hun kan gjøre på en sprint. Dette vil hjelpe henne til å jobbe smartere og eliminere alle hindringer i veien.

« Dynamikk x tid = resultat. Ved å vite hvor fort du går fremover, vil du kunne forstå når du er i mål » .

Åpenhet i alt

Scrum innebærer åpenhet om alle handlinger og prosesser.

Dette omsettes til et tre-kolonne styre som alle teammedlemmer har tilgang til.

« Hemmelighold— gift. Ingenting kan holdes hemmelig. Alle bør vite alt, inkludert økonomiske data. Tilsløring av spor er bare nødvendig for de som leter etter egen fordel. » .

Produkteier

Scrum har tre roller: scrum team - utførere av spesifikke prosjekter; scrum master - er noen som overvåker fremdriften til prosjektet og hjelper teamet med å løse problemer, og produktets eier— den som bestemmer produktkonseptet og bygger produktreserven.

« Scrum Masterog teamet er ansvarlig for hvor raskt de jobber og hvor raskt de fullfører prosjektet. Produkteieren er ansvarlig for å gjøre effektivt teamarbeid til lønnsomme resultater. » . Produkteieren må kjenne markedet veldig godt og har myndighet til å ta beslutninger.

Dette kan være for mye ansvar for én person, så et team av produkteiere kan jobbe med store prosjekter.

Risikominimering i Scrum

Siden Scrum sørger for en trinnvis levering av prosjektet, bidrar dette til å minimere risiko. Dette bidrar til å vise produktet til kunden raskere og få tilbakemeldinger fra ham.

« Scrum-metodikken er nyttig for virksomheten fordi den raskt svarer på spørsmålet: kan vi tjene penger hvis vi gjør dette eller hint?

Du trenger ikke bruke store mengder penger før du forstår noe fungerer ikke.

Denne veiledningen for programvareutviklere og testere vil hjelpe deg å forstå og komme i gang med Agile SCRUM.

Lær de grunnleggende, men viktige begrepene som brukes i Agile Scrum-prosessen sammen med et ekte eksempel på hele prosessen.

SCRUM er en prosess i en smidig metodikk som er en kombinasjon av iterative og inkrementelle modeller.

En av hovedulempene med den tradisjonelle fossefallsmodellen er at inntil det første trinnet er fullført, går ikke søknaden videre til neste trinn. Hvis det skjer at noen endringer skjer på et senere tidspunkt i syklusen, vil det være svært vanskelig å implementere disse endringene, da dette vil innebære en gjennomgang av de tidligere stadiene og omgjøring av endringene.

Noen av nøkkelfunksjonene til SCRUM er:

• Organisert og motivert team
• Det er ingen krav til dokumenter, det er nok å ha nøyaktige tekster på realitet.
• Funksjonsteamet fungerer som en enhet.
• Nær kontakt med brukeren, hjelper til med å forstå funksjonene.
• Det er en presis tidsakse på maksimalt 1 måned.
• I stedet for å gjøre alt på en gang, gjør Scrum litt av alt over en gitt periode.
• Før du gjør noe, vurderes egenskapene og tilgjengeligheten til ressursene.

For å forstå denne metodikken godt, er det viktig å forstå nøkkelbegrepene til SCRUM.

Viktige SCRUM-vilkår:

1. Scrum team

Et scrum-team er et team på 7 +/- 2 medlemmer. Teammedlemmer er en blanding av kompetente utviklere, testere, databasefolk, støtteoperatører, etc., samt en produkteier og scrummaster. Alle disse menneskene jobber tett sammen over et gitt rekursivt spenn for å utvikle og utføre de spesifiserte funksjonene.

2. Sprint

Sprint er standardtidsperioden der arbeidet må være fullført og klart for gjennomgang eller produktutgivelse. Vanligvis tar denne perioden fra to uker til en måned. Når vi sier at vi gjennomfører 1 sprint per måned, betyr det at vi jobber en måned med oppgaver og har dem klare til gjennomgang innen utgangen av den måneden.

3. Produkteier

Produkteieren er toppselgeren eller hovedbrukeren av applikasjonen som utvikles.

Produkteier er personen som representerer kundesiden. Han/hun har avgjørende myndighet og skal alltid være tilgjengelig for laget. Han/hun bør være tilgjengelig i tilfelle noen trenger å forklare noe. Det er viktig for produkteier å forstå og ikke stille nye krav midt i en sprint eller når den allerede har begynt.

4. Scrum Master

Scrum Master er koordinator for scrum-teamet. Han/hun sørger for at scrum-teamet er produktivt og progressivt. I tilfelle forstyrrelser finner og eliminerer scrum-mesteren dem for laget.

5. Brukerhistorie

Brukerhistorier er krav eller funksjoner som må oppfylles. I scrum har vi ikke disse store dokumentkravene, i stedet er kravene oppgitt i et enkelt avsnitt, vanligvis i dette formatet:

Hvordan<тип пользователя>

Jeg ønsker<доступная цель>

for prestasjon<результат/причина>

For eksempel:

Som administrator ønsker jeg å kunne låse passordet for å begrense uautorisert tilgang i tilfelle brukeren skriver inn feil passord 3 ganger på rad.

Det er noen kjennetegn ved brukerhistorier som bør følges. Brukerhistorier bør være konsise, realistiske, muligens vurderende, komplette, reversible og testbare.

Hver brukerhistorie har et akseptkriterium som må være klart definert og forstått av teamet. Akseptkriterier beskriver brukerhistorier i detalj, gir støttede dokumenter. Dette lar deg gå ned i brukerhistorier. Ethvert medlem av teamet kan skrive ned akseptkriteriene. Valideringsteamet baserer sine testtilfeller/betingelser på disse kriteriene.

6. "Epos"

Epos er obskure brukerhistorier. Eller du kan si at dette er brukerhistorier som ikke er definert og lagres for fremtidige sprints. Bare prøv å relatere det til livet, forestill deg at du skal på ferie. Siden du reiser neste uke har du alt planlagt: bestille hotellrom, sightseeing, pakke reisebagen osv. Men hva med ferien neste år? Du har bare en vag idé om at du kan gå til XYZ, men du har ingen detaljert plan.

"Epic" er som ferien neste år: du vet at du kan dra, men hvor, når og med hvem - det er ingen tanker om dette ennå.

På samme måte er det funksjoner som bør implementeres i fremtiden, men detaljene deres er ennå ikke kjent. Vanligvis starter en mulighet med et "epos" og brytes deretter ned i historier som kan realiseres.

7. Produktønskelogg

Produktønskeloggen er et slags segment eller kilde hvor alle brukerhistorier er lagret. Det støttes av produktets eier. Du kan tenke på en produktønskelogg som en ønskeliste for en produkteier som prioriterer den etter forretningsbehov. Under planlegging (se neste avsnitt) er en av brukerhistoriene hentet fra backlog, teamet brainstormer, reflekterer, foredler og bestemmer i fellesskap (med innspill fra produkteier) hvilken brukerhistorie som skal aksepteres.

8. Sprint Ønskelogg

En brukerhistorie er hentet fra produktønskeloggen om gangen. Scrum-teamet brainstormer, bestemmer gjennomførbarhet og bestemmer hvilken historie de skal jobbe med i løpet av en gitt sprint. Den samlede listen over alle brukerhistorier som scrum-teamet jobber med i løpet av en bestemt sprint kalles sprintønskeloggen.

9. Poeng for brukerhistorie:

Disse punktene er en numerisk indikasjon på kompleksiteten til brukerhistorien. Basert på disse partiturene bestemmes poengsummen og mengden arbeid for én historie. Poeng er ikke absolutte, de er relative. For å sikre at innsatsen og estimatene våre er korrekte, må vi sjekke om brukerhistoriene er store. Jo mindre og tydeligere brukerhistorien er, desto mer nøyaktig vil vurderingen være.

Hver brukerhistorie blir tildelt en poengsum fra Fibonacci-serien (1, 2, 3, 5, 8, 13, 21). Jo høyere tall, jo vanskeligere er historien.

Mer presist altså

• Hvis du satser 1/2/3 poeng, betyr det at historien er liten og har lav vanskelighetsgrad.
• Gir du 5/8 poeng så er det middels vanskelighetsgrad og
• 13 og 21 poeng - historien er veldig komplisert.

Her ligger vanskeligheten i utviklingen og i mengden testarbeid.

For å bestemme hvor mange poeng som skal gis, starter scrum-teamet idédugnaden og bestemmer seg i fellesskap. Det kan være at utviklingsteamet vil gi en bestemt historie 3 poeng fordi det kan være 3 linjer med erstatningskode for dem, men testteamet vil gi 8 poeng fordi det ser ut til at denne kodeerstatningen vil påvirke modulene mer, så mengden arbeid mer under testing. Men uansett hvor mange poeng du gir, må du begrunne avgjørelsen din. Dermed foregår idédugnaden og laget bestemmer hvor mange poeng som skal settes.

Når du bestemmer deg for hvor mange poeng du skal satse, bør du vurdere følgende faktorer:

• Relasjon av historikk til andre apper/moduler,
• Ressurskompetansesett
• Kompleksiteten i historien
• narrativ læring,
• Akseptkriterier for brukerhistorier

Hvis du ikke er kjent med en bestemt historie, ikke endre størrelsen på den.
Hvis du ser at poengsummen til historien er veldig høy, kan du dele den opp i mindre historier.

10. Nedbrenningsdiagram

Nedbrenningsdiagrammet er en graf som viser estimert v/s av den faktiske innsatsen til scrum-oppgavene.

Dette er en sporingsmekanisme for en bestemt sprint. Hver dag spores oppgaver for å sjekke om historiene går mot ferdigstillelse eller ikke.

Eksempel: For å forstå dette, se på figuren:

Jeg velger:

• To ukers sprint (10 dager)
• 2 ressurser til faktisk sprintarbeid.

"Historie"-> kolonnen viser brukerhistoriene tatt for sprinten. "Oppgave" -> kolonnen viser en liste over oppgaver knyttet til brukerhistorier.

"Arbeidsomfang"-> kolonnen viser mengden arbeid. Nå er dette målet den totale mengden arbeid for å fullføre oppgaven. Den skildrer ikke mengden arbeid til noen bestemt person.

"Dag 1 - Dag 10"->– kolonne(r) viser/-tiden som gjenstår til slutten av historien. Vær oppmerksom på at dette IKKE er tiden som allerede har gått, MEN tiden som fortsatt gjenstår.

"Estimert mengde arbeid"-> indikator for den totale mengden arbeid. For "Start" er det bare summen av hele oppgaven: SUM(C5:C15)

Den totale arbeidsmengden som skal fullføres på 1 dag er 70 / 10 = 7. Så ved slutten av første dag skal arbeidsmengden reduseres til 70-7 = 63. Tilsvarende beregnes dette for alle dager t.o.m. den 10., når estimert arbeidsmengde må være null (linje 16)

"Resterende arbeidsmengde"-> som navnet antyder, er dette mengden arbeid som gjenstår for å fullføre historien. Det kan også skje at den faktiske arbeidsmengden blir større eller mindre enn forventet.

Du kan bruke funksjoner og diagrammer i Excel for å lage dette nedbrenningsdiagrammet.

Stadier av oppgavenedbrenningsdiagrammet:

1. Skriv inn alle historier (kolonne A5 - A15)
2. Skriv inn alle oppgaver (kolonne B5-B15)
3. Angi dager (1. dag - 10. dag)
4. Angi innledende arbeidsomfang (oppsummer oppgavene C5-C15)
5. Bruk formelen for å beregne "estimert arbeidsmengde" for hver dag (dag 1 til dag 10). Skriv inn formelen i D15 (c16-$C$ 16/10) og dra den til alle dager.
6. For hver dag, skriv inn den faktiske mengden arbeid. Skriv inn en formel i D17 (SUM (D5:D15)) for å summere gjenværende arbeidsmengde og dra den til alle andre dager.
7. Velg dette og lag et diagram som dette:

11. Lagfart

Det totale antallet poeng et scrum-lag beholder i en sprint kalles laghastighet. Et Scrum-team bedømmes etter hastigheten. Det skal sies at man bør huske på at det IKKE er målet å nå maksimalt antall poeng her, men den gode kvaliteten på resultatene øker komfortnivået til scrum-teamet.

For eksempel: For en bestemt sprint: det totale antallet brukerhistorier er 8. Hver av dem har et visst antall poeng

Dermed er hastighet summen av poeng = 30

12. Definisjon av «ferdig»:

En historie lages i Scrum, kun når det er utvikling, full kvalitetssikring og mulighet for å komme i produksjon.

Aktiviteter i SCRUM:

#1: Planleggingsmøte

Planleggingsmøtet er utgangspunktet for SCRUM. Dette er møtet hvor hele scrum-teamet samles. Produkteieren velger brukerhistorier fra produktønskeloggen basert på prioritet og teamet starter idédugnaden. Under diskusjonen bestemmer scrum-teamet kompleksiteten til historien og måler den i henhold til Fibonacci-serien. Teamet definerer oppgavene samt mengden arbeid (i timer) som kan gjøres for å fullføre implementeringen av brukerhistorien.

"Forhåndsmøteplanlegging" går foran møtet. Det er som leksene som scrum-teamet gjør før de møtes til et formelt planleggingsmøte. Teamet prøver å skrive ned avhengigheter eller andre faktorer som de ønsker å diskutere i møtet.

#2: Fullfør sprintoppgaver

Som navnet antyder, er det scrum-teamets jobb å fullføre oppgaven sin og flytte brukerhistorien til "ferdig"-status.

#3: Daglig scrum-møte (samtale)

I løpet av sprintsyklusen møtes scrum-teamet hver dag i ikke mer enn 15 minutter (dette kan være en samtale, som anbefales på begynnelsen av dagen). Møtet stiller 3 spørsmål:

1. Hva har teammedlemmet gjort siden forrige møte?
2. Hva planlegger teammedlemmet å gjøre i dag?
3. Er det noen hindringer for laget

Scrum Master jobber med å løse disse problemene. I tilfelle en deltaker støter på noen form for vanskeligheter, hjelper scrummasteren med å løse dem.

#4: Sammendragsanmeldelse

På slutten av hver sprintsyklus møtes SCRUM-teamet igjen og demonstrerer for produkteieren implementeringen av brukerhistorier. Produkteieren kan sammenligne historier i henhold til deres akseptkriterier. Det er igjen Scrum Masterens ansvar å presidere over dette møtet.

#5: Retrospektivt møte

Det retrospektive møtet finner sted etter gjennomgang av resultatene. SCRUM-teamet samler, diskuterer og dokumenterer følgende punkter:

1. Hva ble gjort bra i forrige sprint (beste praksis)
2. Det som ikke ble gjort bra
3. Lærdom fra dette
4. Handlingselementer.

Scrum-teamet bør fortsette å følge beste praksis, ignorere "ikke beste praksis" og følge lærdommen fra påfølgende spurter. Det retrospektive møtet bidrar til å kontinuerlig forbedre SCRUM-prosessen.

Hvordan gjennomføres prosessen? Eksempel!

Etter å ha lest om de tekniske sjargongene til SCRUM, la meg prøve å demonstrere hele prosessen med et eksempel.

Trinn 1: Tenk deg et SCRUM-team på 9 personer med 1 eier, 1 Scrum Master, 2 testere, 4 utviklere og 1 DBA.

Steg 2 A: En sprintsyklus, for eksempel, vil vare i 4 uker. Så vi har 1 måned på sprinten: fra 5. juni til 4. juli.

Trinn #3: Produkteieren har en prioritert liste over brukerhistorier i produktønskeloggen.

• Produkteieren tar 1 historie fra produktønsket, beskriver den og sender den videre til teamet for idédugnad.
• Hele teamet diskuterer og snakker direkte til produktets eier for å forklare brukerhistorien i detalj.
• Andre brukerhistorier aksepteres på samme måte. Om mulig kan teamet fortsette og også måle historier.

Etter diskusjonen går teammedlemmene tilbake til arbeidsplassene sine og

• Definer deres individuelle oppgaver for hver historie.
• Beregn nøyaktig hvor lang tid det vil ta dem å jobbe. Hvordan regner deltakeren denne tiden? La oss sjekke:

Total arbeidstid = 9

Minus 1 time for pause, minus 1 time for møter, minus 1 time for e-post, diskusjoner, feilsøking osv.
Så faktisk arbeidstid = 6

Totalt antall arbeidsdager i løpet av sprinten = 21 dager.
Totalt antall tilgjengelige timer = 21 * 6 = 126

Medlemmet er på ferie 2 dager = 12 timer (dette varierer for hvert medlem, noen kan ta ferie, noen kanskje ikke.)
Antall faktiske timer = 126-12 = 114 timer.

Dette betyr at medlemmet vanligvis vil være tilgjengelig i 114 timer i løpet av den spurten. Derfor vil han dele opp sin individuelle sprintoppgave på en slik måte at den på 114 timer er oppnådd.

• Den endelige vurderingen av brukerhistorien fra produktønskeloggen fullføres og historien flyttes til sprintønskeloggen.
• For hver historie kunngjør hvert teammedlem sine spesifikke oppgaver. Hvis du vil diskutere disse problemene, kan du måle eller endre størrelsen deres (tenk på Fibonacci-serien!).
• ScrumMasteren eller teamet legger inn sine individuelle oppgaver og sin tid for hver historie i programmet.
• Etter at alle historiene er fullført, noterer Scrum Master starthastigheten og sprinten begynner offisielt.

Trinn #6: Etter starten av sprinten begynner hvert teammedlem å jobbe med de tildelte oppgavene.

Trinn #7: Teamet møtes daglig i 15 minutter og diskuterer 3 spørsmål:

• Hva gjorde de i går?
• Hva har de tenkt å gjøre i dag
• Er det noen forstyrrelser?

Trinn #8: Scrum Master sporer fremgang daglig med et Burndown Chart

Trinn #9: I tilfelle forstyrrelser, løser ScrumMaster dem.

Trinn #10: 4. juli møtes teamet igjen for å gjennomgå resultatene. Hvert teammedlem demonstrerer den implementerte brukerhistorien til produkteieren.

Trinn #11: 5. juli møtes teamet igjen til et retrospektivt møte hvor de diskuterer

• Hva gikk bra?
• Hva gikk ikke bra
• Handlingselementer.

Trinn #12: 6. juli møtes laget igjen til planleggingsmøte for neste sprint, og syklusen fortsetter.

(Klikk for å forstørre bildet)

Programmer som kan brukes til SCRUM-aktiviteter:

Det er mange verktøy som kan brukes mye for å spore scrum-aktiviteter. Her er noen av dem:

• XPlanner
• Versjon én
• Sprintometer
• Scrum Ninja

Konklusjon:

I begynnelsen kan folk synes det er vanskelig å mestre denne teknikken, men med øvelse vil du se at SCRUM gjør underverker. SCRUM fokuserer ressursene slik at du kan se hvordan søknaden din utvikler seg.

Mange midlertidige organisasjoner inspirerer teamet (som en scrum-oppgave) til å vie et par timer til selvlæring og utvikling. Også under gjennomgangen viser teammedlemmer hva de har lært og presenterer noen ganger programmer eller applikasjoner de har utviklet. Personlig setter jeg pris på denne metoden fordi den gir folk en sjanse til å utvide sin kunnskap og også vise frem sine ferdigheter.

Jeg jobber med avhandlingen min innen prosjektledelse. I dag skal vi ta en rask titt på Scrum, se på vanlige feil som fører til problemer. Dette innlegget hevder ikke å være fullstendig, det er en oversikt og henvender seg til de som ennå ikke er kjent med Scrum, eller bare er delvis kjent (for eksempel jobber i en modifisert Scrum).

For tiden er Scrum en av de mest populære "metodene for programvareutvikling". Per definisjon er Scrum et utviklingsrammeverk der folk kan løse nye problemer samtidig som de er produktive og produserer produkter av høyeste verdi.

Dette antyder at det i Scrum er umulig å finne svar på alle spørsmål og handlingsinstruksjoner i alle situasjoner (for eksempel indikerer den offisielle beskrivelsen av Scrum bare behovet for å estimere tiden som kreves for å fullføre arbeidet, men spesifiserer ikke typen det kan være å planlegge poker og en annen måte å evaluere på). Dermed er ikke navnet på selve emnet riktig :)

Når vi snakker om Scrum-metodikken, mener de oftest en smidig programvareutviklingsmetodikk bygget på reglene og praksisene til Scrum, så det kan godt vise seg at din Scrum er kulere enn min Scrum, og også være så langt unna som VAZ 7 er fra BMW 7-serie :)

Roller i Scrum

Det er 3 grunnleggende roller i klassisk Scrum:
-produkteier
-Scrummaster
-Utviklingsteam

produkteier(PO) er bindeleddet mellom utviklingsteamet og kunden. Oppgaven til PO er å maksimere verdien av produktet som utvikles og teamets arbeid.

Et av de viktigste PO-verktøyene er Product Backlog. Produktbackloggen inneholder arbeidsoppgavene som kreves for å fullføre (som Story, Bug, Task, etc.), sortert i prioritert rekkefølge (haster).

Scrummaster(SM) er en tjener-leder. Oppgaven til Scrum Master er å hjelpe teamet med å maksimere sin effektivitet ved å fjerne hindringer, hjelpe, trene og motivere teamet, hjelpe PO

Utviklingsteam(Utviklingsteam, DT) består av spesialister som jobber direkte med produktet som produseres. I følge The Scrum Guide (et dokument som er den offisielle beskrivelsen av Scrum fra forfatterne), skal DT-er ha følgende kvaliteter og egenskaper:
- Vær selvorganiserende. Ingen (inkludert SM og PO) kan fortelle teamet hvordan de skal konvertere produktreserven til et fungerende produkt
- Vær multifunksjonell, ha alle nødvendige ferdigheter for å gi ut et fungerende produkt
-Hele teamet er ansvarlig for arbeidet som utføres, ikke individuelle teammedlemmer

Anbefalt lagstørrelse er 7 (pluss eller minus 2) personer. I følge Scrum-ideologene krever større team for mye kommunikasjonsressurser, mens mindre team øker risikoen (på grunn av mulig mangel på nødvendige ferdigheter) og reduserer mengden arbeid som teamet kan fullføre i løpet av en tidsenhet.

Scrum prosess

Grunnlaget for Scrum er Sprint, hvor det arbeides med produktet. På slutten av Sprint bør en ny fungerende versjon av produktet mottas. Sprint er alltid begrenset i tid (1-4 uker) og har samme varighet gjennom hele produktets levetid.

Før starten av hver Sprint utføres Sprint Planlegging, som evaluerer innholdet i Product Backlog og genererer en Sprint Backlog som inneholder oppgavene (Story, Bugs, Tasks) som må fullføres i gjeldende sprint. Hver sprint skal ha et mål som er en motivasjonsfaktor og oppnås gjennom gjennomføring av oppgaver fra Sprint Backlog.

Daily Scrum produseres hver dag, der hvert teammedlem svarer på spørsmålene "hva gjorde jeg i går?", "Hva har jeg tenkt å gjøre i dag?", "Hvilke hindringer møtte jeg i arbeidet mitt?". Oppgaven til Daily Scrum er å fastslå status og fremdrift i arbeidet med Sprinten, tidlig oppdagelse av hindringer som har oppstått, og utvikling av beslutninger om å endre strategien som er nødvendig for å nå Sprintens mål.

På slutten av Sprint produseres Sprint Review og Sprint Retrospective, hvis oppgave er å evaluere effektiviteten (ytelsen) til teamet i forrige Sprint, forutsi forventet effektivitet (ytelsen) i neste sprint, identifisere eksisterende problemer, vurdere sannsynligheten for å fullføre alt nødvendig arbeid på produktet, og mer .

En skjematisk fremstilling av prosessen er vist i følgende figur:

Viktige, ofte glemte funksjoner

Du kan ofte høre at Scrum ikke fungerer, eller fungerer dårligere enn forventet. Det skal bemerkes at dette oftest skjer av en av følgende årsaker:

1. Scrum er påført feil eller ufullstendig.
I følge forfatterne av Scrum er empirisk erfaring hovedkilden til pålitelig informasjon. Behovet for en fullstendig og nøyaktig implementering av Scrum er indikert i The Scrum Guide og skyldes den atypiske organiseringen av prosessen, fraværet av en formell leder og leder.

2. Viktigheten av å jobbe med å motivere teamet undervurderes.
Et av kjerneprinsippene til Scrum er selvorganiserende, tverrfunksjonelle team. I følge sosiologisk forskning overstiger ikke antallet selvmotiverte ansatte som er i stand til selvorganisering 15 % av den yrkesaktive befolkningen.
Dermed er det kun en liten del av de ansatte som klarer å jobbe effektivt i Scrum uten vesentlige endringer i rollene som Scrum master og Product Owner, noe som er i strid med ideologien til Scrum, og potensielt fører til feil eller ufullstendig bruk av Scrum.

3. Scrum brukes for et produkt som kravene er i strid med Scrums ideologi.
Scrum tilhører Agile-familien, så Scrum ønsker endringer i krav til enhver tid velkommen (Produktbacklog kan endres når som helst). Dette gjør det vanskelig å bruke Scrum i fastkost-/fasttidsprosjekter. Scrum-ideologien sier at det er umulig å forutse alle endringer på forhånd, så det gir ingen mening å planlegge hele prosjektet på forhånd, begrense deg til just-in-time-planlegging, dvs. bare planlegge arbeidet som må gjøres i nåværende Sprint. Det er også andre restriksjoner.

Fordeler og ulemper

Scrum har noen ganske overbevisende fordeler. Scrum er kundefokusert, tilpasningsdyktig. Scrum gir klienten muligheten til å gjøre endringer i kravene til enhver tid (men garanterer ikke at disse endringene vil bli implementert). Muligheten til å endre krav er attraktiv for mange programvarekunder.

Scrum er ganske enkelt å lære, sparer tid ved å eliminere ikke-kritiske aktiviteter. Scrum lar deg få et potensielt fungerende produkt på slutten av hver Sprint.
Scrum legger vekt på et selvorganiserende, tverrfunksjonelt team som er i stand til å fullføre de nødvendige oppgavene med minimal koordinering. Dette er spesielt attraktivt for små bedrifter og nystartede bedrifter, da det eliminerer behovet for å ansette eller lære opp spesialisert ledere.

Scrum har selvfølgelig også viktige ulemper. På grunn av sin enkelhet og minimalisme, setter Scrum et lite antall ganske rigide regler. Imidlertid er dette i konflikt med ideen om å være kundesentrert i prinsippet, fordi kunden ikke bryr seg om de interne reglene til utviklingsteamet, spesielt hvis de begrenser kunden. For eksempel, om nødvendig, etter Sprint-klientens skjønn, kan backlog endres, til tross for den åpenbare motstriden med Scrum-reglene.

Problemet er større enn det ser ut til. Fordi Scrum tilhører Agile-familien, Scrum lager for eksempel ikke en kommunikasjonsplan og reagerer på risiko. Dermed gjør det vanskelig eller umulig å formelt (juridisk eller administrativt) motvirke brudd på Scrum-reglene.

En annen svak egenskap ved Scrum er vektleggingen av et selvorganiserende, tverrfunksjonelt team. Med en tilsynelatende nedgang i kostnadene for teamkoordinering, fører dette til en økning i kostnadene for personellvalg, motivasjon og opplæring. Under visse arbeidsmarkedsforhold er det kanskje ikke mulig å danne et fullverdig, effektivt Scrum-team.

Liste over kilder som er brukt

Scrum-guiden. Den definitive guiden til Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
Psykologi for ledelse, lærebok. (A. A. Trus)
Hvordan en tradisjonell prosjektleder forvandler seg til Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

På forhånd takk for eventuelle feil eller unøyaktigheter!