"Så jeg vil gerne fortælle dig om Agile og Scrum ."
"I begyndelsen af det 21. århundrede blev den måde, folk tænkte om programmering på, vendt på hovedet."
"Alle var overbeviste om, at langsigtet planlægning ikke virkede, så de besluttede at opgive det helt."
"Hvordan gjorde de det?"
"Sådan gør du."
"De opfandt den mest fleksible projektstyringstilgang som muligt."
Her er hovedideerne bag agil udvikling :"
- mennesker og kommunikation er vigtigere end processer og værktøjer;
- et fungerende produkt er vigtigere end udtømmende dokumentation;
- at samarbejde med kunden er vigtigere end at opfylde betingelserne i en kontrakt;
- vilje til forandring er vigtigere end at holde sig til den oprindelige plan.
Her er principperne for hurtig udvikling:
- tilfredsstille kunden ved at levere værdifuld software tidligt og kontinuerligt;
- velkommen ændringer i kravene selv i slutningen af udviklingen (dette kan øge konkurrenceevnen for slutproduktet);
- levere fungerende software ofte (hver måned eller uge eller oftere);
- tæt daglig kommunikation mellem kunde og udviklere gennem hele projektet;
- projektet bearbejdes af motiverede personer, som får de nødvendige arbejdsforhold, støtte og tillid;
- den foretrukne metode til at kommunikere information er en personlig (ansigt til ansigt) samtale;
- fungerende software er det bedste mål for fremskridt;
- sponsorer, udviklere og brugere bør være i stand til at opretholde et konstant tempo i en ubestemt periode;
- konstant fokus på at forbedre teknisk ekspertise og brugervenligt design;
- enkelhed er kunsten ikke at udføre overflødigt arbejde;
- de bedste tekniske krav, design og arkitektur kommer fra et selvorganiseret team;
- konstant tilpasning til skiftende omstændigheder.
"Det største problem med softwareudvikling var, at ingen af deltagerne på noget tidspunkt havde fuldstændig information om, hvad de skulle gøre."
"Kunden kan fortælle dig, hvordan han forestiller sig programmet, men han vil udelade noget eller tage noget for givet."
"Lederen skal generelt oversætte krav fra programmeringsjargon til kundens sprog og tilbage igen."
"Der er for meget usikkerhed."
"Ofte er kundens krav sådan her: gør det på en eller anden måde, så vis mig det - hvis jeg ikke kan lide det, så kan du lave det om."
"Øh... det er forfærdeligt."
"Ifølge det nye paradigme udvikler programmører ikke længere et produkt eller program. I stedet implementerer de den funktionalitet, kunden har brug for."
"Hvad er forskellen?"
"Nå, antag, at programudviklingen plejede at tage et år. Og der skulle gå seks måneder, før der var noget at se på. Det er ligesom at bygge et stort hus: først graver man en grube til fundamentet, så hælder man fundamentet, bygge vægge, tag, trim osv."
"Men nu forsøger programmører at frigive den nødvendige funktionalitet så hurtigt som muligt. Det ville være som først at bygge en hytte, så et mobilhome, så et lille hus og først derefter et stort hus - i rater."
"I betragtning af at kunden sandsynligvis ikke helt ved, hvad han vil have, så er dette en meget rimelig tilgang."
"Antag, at kunden vil have et stort jagthytte."
"Udviklerne bygger en lille en til ham. Han bor i den en vinter. Så beslutter han sig for, at han ikke kan lide træhuse. Lad os lave et af mursten."
"Han bor i nærheden af søen en sommer, men myggene æder ham levende. Han havde hørt et sted, at søer er seje, og derfor havde han lyst til at have en. Men nu vil han ikke have en sø. Og det bliver nemmere at bygge huset på denne måde: ingen sø betyder ingen trussel om oversvømmelser, og du kan bygge huset på jorden i stedet for på pæle, hvilket vil være 25 % hurtigere."
"En interessant analogi. Ændrer kunderne virkelig deres krav så ofte?"
"Ja, men problemet er ikke kunden."
"For det første er det meget svært at forestille sig, hvordan tingene vil udvikle sig i fremtiden. Ledere, testere og programmører gør alle dette også. De ændrer også mening afhængigt af, hvordan tingene udspiller sig."
"For det andet, er kundens krav ikke det, der betyder mest? Når alt kommer til alt , er pointen med alt dette arbejde at skabe det, kunden har brug for , ikke det, han oprindeligt sagde for at skabe ."
"Ja, det plejede at fungere sådan her: Forretningsanalytikere lavede en liste over alle kravene. De ville inkludere denne liste i en kontrakt, underskrive den og kun arbejde i henhold til listen."
"Hvis listen manglede noget, som kunden virkelig havde brug for, men havde glemt, ville ingen gøre noget ved det."
"Jeg kan se. Det er nemmere at følge en plan, men ikke alt kan gøres efter en plan!"
"Nemlig."
"Det er derfor, agile udviklingsmetoder blev opfundet."
"Og i dag vil jeg fortælle dig om Scrum - den mest populære blandt dem.
"Det primære træk ved Scrum er opdelingen af projektudvikling i små iterationer - normalt 2-4 uger lange. Hver iteration kaldes en sprint."
"I starten af en sprint afholdes et sprintplanlægningsmøde. Det varer 3-4 timer."
"Til sidst er der en demonstration af alle de fuldt udførte opgaver."
"Sådan fungerer alt normalt:"
"Før den allerførste sprint danner kunden (eller en repræsentant for kunden) en kravliste, altså det sæt af ting, programmet skal kunne. Disse krav kaldes normalt user stories , og kunden er normalt kaldet produktejeren ."
"Han kaldes produktejeren , fordi produktet er skrevet til ham. Han, og han alene, definerer listen over krav - hvad, hvornår og i hvilken rækkefølge."
"Derudover tildeler produktejeren normalt opgaveprioriteter. Opgaver med højeste prioritet vil blive implementeret først. Hele listen af krav kaldes også produktbacklog . "
"Når en sprint begynder, samles alle til et møde. Scrum masteren , typisk et medlem af teamet, leder normalt mødet. Mødets mål er at udvælge opgaverne ( user story ) til den aktuelle sprint (iteration of development). "
"Først tildeler holdet hver opgave et groft estimat i abstrakte man-dage, også kendt som story points. Derefter beslutter holdet, hvor mange opgaver de vil have tid til at udføre i løbet af spurten."
"Igen er det holdet selv, der bestemmer, hvor mange opgaver de får tid til at udføre i løbet af spurten."
"Lad os sige, at produktejeren forventede, at teamet valgte de første 7 opgaver, men det valgte kun 5, så udskydes opgave 6 og 7 til næste sprint. Hvis det ikke passer produktejeren, kan han hæve opgavernes prioritet. 6 og 7 for at sikre, at de bliver udvalgt, men så falder nogle af de andre opgaver ud af spurten.«
" Scrum-mesteren kan også foreslå at dele nogle af opgaverne op i mindre og sætte forskellige prioriteter for dem for at gøre produktejeren så glad som muligt."
"Det er pointen med mødet: Opgaverne kan ændres og opdeles, prioriteringer kan ændres osv. Det er det arbejde, der ikke var synligt i starten, men som giver en masse værdi."
"Godt det. Det er ligesom at køre bil. Selvom du i første omgang tror, du bare skal køre ligeud, er virkeligheden, at du hele tiden skal undgå huller i vejen, styre til højre og venstre og passere andre eller lade dem passere dig."
"Ja, sådan noget."
"Listen over opgaver, der er valgt til spurten, kaldes sprintbacklog . "
"Programmererne bestemmer, hvem der skal gøre hvad, og først derefter går de i gang. "For at forbedre effektiviteten foreslår Scrum, at der afholdes et 5-15 minutters møde hver dag, hvor alle kan fortælle hinanden, hvad de lavede i går, og hvad de er. skal gøre i dag."
"Teamwork. Det kan jeg respektere!"
"For at gøre tingene lettere at visualisere, anbefales det normalt at vise den aktuelle sprintstatus på en speciel tavle:"
"Bemærk de tre kolonner til venstre."
"Forkortede opgavenavne skrives på sticky notes. Og sticky notes placeres i forskellige kolonner afhængigt af deres status (planlagt, i gang, udført)."
"Til højre kan du se et nedbrændingsdiagram . For hver dag viser dette diagram de opgaver, der stadig er uløste. Ideelt set falder antallet af ufuldstændige opgaver til nul under spurten."
"Når spurten er slut, giver scrum-masteren en demo for at vise listen over alt, der er helt færdigt."
"Så holder han et sprint retrospektivt møde , som også varer et par timer. Under dette møde forsøger deltagerne som regel at finde ud af, hvad der gik godt, og hvad (og hvordan) tingene kunne være gjort bedre."
"Normalt efter 2-3 sprints kan du identificere og eliminere de største problemer, der forhindrer holdet i at arbejde mere effektivt. Dette fører til større produktivitet uden at øge holdets arbejdsbyrde. Dette var ikke muligt før æraen med agile metoder. "
"Nogle gange afholdes der også et groomingmøde i løbet af spurten. Formålet er at planlægge næste sprint. Deltagerne afklarer normalt opgaveprioriteterne i dette møde. De kan også dele nogle opgaver op i dele og/eller tilføje nye opgaver til produktbacklogen . "
"Jamen, det er i bund og grund alt, hvad jeg har. Dette er bare en oversigt. Det er umuligt at forklare det hele med få ord, men du kan læse en god artikel om emnet her:"
GO TO FULL VERSION