"Så jeg vil fortelle deg om Agile og Scrum ."
"På begynnelsen av det 21. århundre ble måten folk tenkte på programmering snudd på hodet."
"Alle var overbevist om at langsiktig planlegging ikke fungerte, så de bestemte seg for å forlate det helt."
"Hvordan gjorde de det?"
"Dette er hvordan."
"De oppfant den mest fleksible prosjektledelsesmetoden som mulig."
Her er hovedideene bak smidig utvikling :"
- mennesker og kommunikasjon er viktigere enn prosesser og verktøy;
- et fungerende produkt er viktigere enn uttømmende dokumentasjon;
- å samarbeide med kunden er viktigere enn å oppfylle vilkårene i en kontrakt;
- endringsvilje er viktigere enn å holde seg til den opprinnelige planen.
Her er prinsippene for rask utvikling:
- tilfredsstille kunden ved å levere verdifull programvare tidlig og kontinuerlig;
- velkommen endringer i kravene selv på slutten av utviklingen (dette kan øke konkurranseevnen til sluttproduktet);
- levere fungerende programvare ofte (hver måned eller uke eller oftere);
- tett daglig kommunikasjon mellom kunde og utviklere gjennom hele prosjektet;
- prosjektet arbeides med av motiverte personer som gis nødvendige arbeidsforhold, støtte og tillit;
- den foretrukne metoden for å kommunisere informasjon er en personlig (ansikt til ansikt) samtale;
- fungerende programvare er det beste målet for fremgang;
- sponsorer, utviklere og brukere skal kunne opprettholde et konstant tempo på ubestemt tid;
- konstant fokus på å forbedre teknisk fortreffelighet og brukervennlig design;
- enkelhet er kunsten å ikke gjøre overflødig arbeid;
- de beste tekniske kravene, design og arkitektur kommer fra et selvorganisert team;
- konstant tilpasning til skiftende omstendigheter.
"Hovedproblemet med programvareutvikling var at ingen av deltakerne på noe tidspunkt hadde fullstendig informasjon om hva de skulle gjøre."
"Kunden kan fortelle deg hvordan han ser for seg programmet, men han vil utelate noe eller ta noe for gitt."
"Lederen må generelt oversette krav fra programmeringssjargong til språket til kunden og tilbake igjen."
— Det er for mye usikkerhet.
"Ofte er kundens krav slik: gjør det på en eller annen måte, så vis meg det - hvis jeg ikke liker det, kan du gjøre det på nytt."
"Øh... det er forferdelig."
"I følge det nye paradigmet utvikler ikke programmerere lenger et produkt eller program. I stedet implementerer de funksjonaliteten kunden trenger."
"Hva er forskjellen?"
"Vel, anta at programutviklingen pleide å ta et år. Og det måtte gå seks måneder før det var noe å se på. Det er som å bygge et stort hus: først graver du en grop for fundamentet, så tømmer du fundamentet, bygge vegger, tak, trim osv."
"Men nå prøver programmerere å frigjøre den nødvendige funksjonaliteten så snart som mulig. Dette vil være som å først bygge en hytte, deretter en bobil, så et lite hus, og først deretter et stort hus - i avdrag."
"Med tanke på at kunden sannsynligvis ikke helt vet hva han vil ha, så er dette en veldig rimelig tilnærming."
"Anta at kunden vil ha en stor jakthytte."
"Utviklerne bygger en liten en til ham. Han bor i den en vinter. Så bestemmer han seg for at han ikke liker trehus. La oss lage en av murstein."
"Han bor i nærheten av innsjøen en sommer, men myggen spiser ham levende. Han hadde hørt et sted at innsjøer er kule, og så han så lyst på å ha en. Men nå vil han ikke ha en innsjø. Og det blir lettere å bygge huset på denne måten: ingen innsjø betyr ingen trussel om flom, og du kan bygge huset på bakken i stedet for på påler, som vil være 25 % raskere."
"En interessant analogi. Endrer kundene virkelig kravene sine så ofte?"
"Ja, men problemet er ikke kunden."
"For det første er det veldig vanskelig å forestille seg hvordan ting vil slå ut i fremtiden. Ledere, testere og programmerere gjør alle dette også. De ombestemmer seg også avhengig av hvordan ting blir."
"For det andre, er ikke kundens krav det som betyr mest? Tross alt er poenget med alt dette arbeidet å skape det kunden trenger , ikke det han i utgangspunktet sa for å skape ."
"Det fungerte faktisk slik: Forretningsanalytikere ville lage en liste over alle kravene. De ville inkludere denne listen i en kontrakt, signere den og bare jobbe i henhold til listen."
"Hvis listen manglet noe som kunden virkelig trengte, men som hadde glemt, ville ingen gjort noe med det."
"Jeg skjønner. Det er lettere å følge en plan, men ikke alt kan gjøres etter en plan!"
"Nøyaktig."
"Det er derfor smidige utviklingsmetoder ble oppfunnet."
"Og i dag skal jeg fortelle deg om Scrum - den mest populære blant dem.
"Den primære funksjonen til Scrum er inndelingen av prosjektutvikling i små iterasjoner - vanligvis 2-4 uker lange. Hver iterasjon kalles en sprint."
"I begynnelsen av en sprint avholdes et sprintplanleggingsmøte. Det varer i 3-4 timer."
"På slutten er det en demonstrasjon av alle de fullførte oppgavene."
"Slik fungerer alt vanligvis:"
"Før den aller første spurten danner kunden (eller en representant for kunden) en kravliste, dvs. det settet med ting programmet skal kunne gjøre. Disse kravene kalles vanligvis user stories , og kunden er vanligvis kalt produkteieren ."
"Han kalles produkteieren , fordi produktet er skrevet for ham. Han, og han alene, definerer listen over krav - hva, når og i hvilken rekkefølge."
"I tillegg tildeler produkteieren vanligvis oppgaveprioriteringer. Oppgaver med høyest prioritet vil bli implementert først. Hele listen med krav kalles også produktbacklog . "
"Når en sprint begynner, samles alle til et møte. Scrummasteren , typisk et medlem av teamet, leder vanligvis møtet. Møtet har som mål å velge oppgavene ( brukerhistorie ) for den aktuelle sprinten (iterasjon av utvikling). "
"Først tildeler teamet hver oppgave et grovt anslag i abstrakte dagsverk, også kjent som historiepoeng. Deretter bestemmer teamet hvor mange oppgaver de skal rekke å fullføre i løpet av sprinten."
"Igjen er det laget selv som bestemmer hvor mange oppgaver de skal rekke å fullføre i løpet av sprinten."
"La oss si at produkteieren forventet at teamet skulle velge de første 7 oppgavene, men det valgte bare 5, deretter blir oppgave 6 og 7 utsatt til neste sprint. Hvis det ikke passer produkteieren, kan han øke prioriteringen av oppgavene 6 og 7 for å sikre at de blir valgt ut, men da faller noen av de andre oppgavene ut av spurten.»
" Scrum-mesteren kan også foreslå å dele opp noen av oppgavene i mindre og sette forskjellige prioriteringer for dem for å gjøre produkteieren så fornøyd som mulig."
"Det er poenget med møtet: oppgaver kan endres og splittes opp, prioriteringer kan endres osv. Dette er arbeidet som ikke var synlig i utgangspunktet, men som gir mye verdi."
"Skjønner det. Det er som å kjøre bil. Selv om du i utgangspunktet tror at du bare trenger å gå rett, er realiteten at du hele tiden må unngå jettegryter, styre til høyre og venstre, og passere andre eller la dem passere deg."
"Ja, noe sånt."
"Listen over oppgaver som er valgt for sprinten kalles sprintbacklog ."
"Programmererne bestemmer hvem som skal gjøre hva, og først da begynner de å jobbe. "For å forbedre effektiviteten foreslår Scrum at det holdes et 5-15 minutters møte hver dag der alle kan fortelle hverandre hva de gjorde i går og hva de er. skal gjøre i dag."
"Lagarbeid. Det kan jeg respektere!"
"For å gjøre ting lettere å visualisere, anbefales det vanligvis å vise gjeldende sprintstatus på et spesielt brett:"
"Legg merke til de tre kolonnene til venstre."
"Forkortede oppgavenavn skrives på klistrelapper. Og lappene plasseres i forskjellige kolonner avhengig av status (planlagt, pågår, ferdig)."
"Til høyre kan du se et nedbrenningsdiagram . For hver dag viser dette diagrammet oppgavene som fortsatt er ugjorte. Ideelt sett faller antallet ufullstendige oppgaver til null i løpet av sprinten."
"Når sprinten er over, gir scrum-mesteren en demo for å vise listen over alt som er helt ferdig."
"Deretter holder han et sprint retrospektivt møte , som også varer et par timer. Under dette møtet prøver deltakerne vanligvis å finne ut hva som gikk bra og hva (og hvordan) ting kunne vært gjort bedre."
"Vanligvis etter 2-3 spurter, kan du identifisere og eliminere hovedproblemene som hindrer teamet i å jobbe mer effektivt. Dette fører til større produktivitet uten å øke teamets arbeidsmengde. Dette var ikke mulig før epoken med smidige metoder. "
"Noen ganger holdes det også et stellemøte i løpet av sprinten. Hensikten er å planlegge neste sprint. Deltakerne avklarer vanligvis oppgaveprioriteringer i dette møtet. De kan også dele opp noen oppgaver i deler og/eller legge til nye oppgaver til produktbacklogen . "
"Vel, det er i grunnen alt jeg har. Dette er bare en oversikt. Det er umulig å forklare det hele med bare noen få ord, men du kan lese en god artikkel om emnet her:"
GO TO FULL VERSION