3 faldgruber af skrum, og hvordan fikser man dem

Lad os slippe af med forfærdelige stand-up-møder, estimere helvede og give brugerværdi og opbygge fantastiske produkter i stedet.

Foto af Randy Fath på Unsplash

Hver gang du søger ledige stillinger efter softwareingeniører, er der næsten altid en universel færdighed, som en potentiel kandidat skal beherske. Denne evne er “Scrum”. Uanset om Scrum faktisk er en færdighed på samme måde som tømrer eller at skrive kode, har jeg altid fundet det interessant, at langt de fleste virksomheder har gjort Scrum til deres de-facto måde at arbejde på.

Fordelene ved at arbejde agile - hvilket næsten altid betyder en vis implementering af Scrum - er åbenlyse ud fra et ledelsesmæssigt perspektiv. Du bliver nødt til at beslutte, hvad der er værdifuldt arbejde med regelmæssige intervaller i stedet for at svæve dig selv i kvartalsvise køreplaner, og arbejdet er opdelt på en sådan måde, at i teorien skal alle være i stand til at udføre det.

Tilbage i 2018 skrev jeg en artikel, der beskrev, hvad jeg troede på det tidspunkt, var prisen på at bruge Scrum til softwareteknik. Denne artikel fik en masse ros fra frustrerede udviklere samt en god del kritik fra dem, der insisterer på, hvad jeg beskrev, var faux Scrum.

Siden da gik jeg på en rejse for at finde ud af, hvad der udgør denne “dårlige” Scrum. I stedet for at afskrive Scrum helt som noget, der umuligt kan fungere til softwareudvikling, fokuserede jeg på at kortlægge de dårlige elementer og forsøgte at formulere måder at omdanne dem til meningsfulde, produktive elementer.

I denne artikel reflekterer jeg over det, jeg har lært, siden jeg skrev den forrige artikel, og hvordan jeg tror, ​​Scrum kunne hjælpe dig og dit team med at opbygge bedre software.

Foretag nyttige daglige stand-up-møder

Dette er et interessant emne. Stand-up-møder er en af ​​hjørnestenene i Scrum. Ideen er, at et projekthold mødes tidligt om morgenen, står op og informerer hinanden om deres fremskridt og eventuelle hindringer, de kunne bruge hjælp til. Disse møder er teoretiske gode. Det får alle på den samme side, og da de forekommer i starten af ​​dagen, kan alle tilbringe deres dage produktivt.

Det, jeg imidlertid har fundet, er, at disse møder ofte misbruges af ledere for at afgøre, om alle gør deres job ordentligt, og om projektet stadig er i henhold til planen. Hvis du er usikker på, om dette er tilfældet eller ikke i dine stand-ups, er en god indikation at se, om den person, der taler, skaber øjenkontakt med deres manager eller med en af ​​deres kolleger. Hvis de primært leder deres tale til deres manager, er chancerne for, at det er et rapporteringsmøde i forklædning.

Hvis stand-up er managerorienteret, har det en tendens til at blive en øvelse i Jeg taler, ingen lytter. Alle stirrer bare på afstand, keder sig ud af sindet og venter på, at mødet er forbi. Ironisk nok har denne type stand-up også en tendens til at inkludere unødvendige detaljer bare for at rapportere til manageren, hvilket får det til at tage langt længere tid end det faktisk burde.

Heldigvis kan rettelsen til denne form for stand-up være enkel. Først skal du fjerne manageren fra stand-up. Tving arbejder, men du kan sandsynligvis overbevise dem om at gøre det ved bare at tale med dem. Forudsat at alle, der forbliver i mødet, arbejder på det samme projekt, ændres mødets tone efter et stykke tid.

I stedet for at mødet handler om at bevise, at du har gjort et meningsfuldt arbejde i går, og vil fortsætte med at gøre det i dag, vil mødet have en mere problemløsende karakter. Du skal beslutte stedet, hvilken opgave du skal tackle næste gang, og hvis der er noget, der blokerer for din sti, kan du adressere den lige der og der.

PS Hvis du er manager i denne historie, ved jeg, at det er vanskeligt at afskære dig selv fra mødet. Det er endnu sværere for teammedlemmer at anmode om dit fravær. Måske at diskutere dette med dit team og prøve manager-mindre møder i en kort periode kan være en god måde at måle, om mødet bliver mere produktivt uden dig.

Foto af Rob Hampson på Unsplash

Bemærk ikke brugerværdi

En af grundene til, at virksomheder implementerer rammer som Scrum, er fordi de hurtigt vil levere værdi til deres slutbrugere. Dette parrer fint sammen med den korte varighed af individuelle sprints såvel som med evnen til at foretage fokusjusteringer imellem dem.

Den største fejl, du kan begå her er at blive besat af at levere værdi til bare dine slutbrugere. Ligesom det ikke giver mening at tilføje et ekstra gulv til en bygning med rådne støttebjælker, giver det meget lidt mening at tilføje funktioner til et projekt, der smuldrer under sin egen vægt.

Ligesom hvordan det at være i stand til at køre en bil ikke indebærer, at man ved, hvordan man bygger en bil, den person, der ”kører” udviklingsholdet, kender ikke nødvendigvis den bedste måde at bygge softwaren på. Hvis din bils mekaniker fortæller, at din bil ikke er sikker på at køre længere, ved du, at du tager en enorm risiko næste gang du tager den på ferie. Vi bør tage den samme forholdsregel, når en erfaren ingeniør fortæller os, at tilføjelse af noget, en bruger desperat ønsker, har stor indflydelse på kvaliteten af ​​vores kodebase.

Softwareingeniørerne, der arbejder på en kodebase hver eneste dag, er også dens mest intensive brugere. I modsætning til dine almindelige brugere, følger de ikke bare den glade vej; de følger enhver vej. Hvis et produkts implementering bliver indviklet, vil det gradvist blive vanskeligere for ingeniører at få noget meningsfuldt arbejde udført. De bruger en stor del af deres dage på at arbejde omkring ting snarere end at arbejde med ting.

Selvom der utvivlsomt er værdi i at skabe funktioner til vores slutbrugere, er det langt mere sandsynligt, at det har et produkt, der vil bevare både slutbrugere såvel som udviklere over en længere periode. Det betyder, at det undertiden også kan være en god ide at planlægge stort refactoringarbejde eller generel husholdning i sprints også. Ikke som arbejde i 2. klasse, men som førsteklasses - behandle det som arbejde, der er lige så vigtigt som at skabe nye funktioner.

Tag ikke skøn for evangeliet

For at bestemme mængden af ​​arbejde, der kan udføres i en sprint, prioriteres hver enkelt opgave på efterspørgslen og vurderes dens arbejde. Nogle gange gøres dette ved at estimere de faktiske timer, der er nødvendige for at gennemføre en opgave, andre gange mere vage erstatninger som point eller endda t-shirtstørrelser.

At skulle estimere det arbejde, der kan udføres under en sprint, er uden tvivl en af ​​de mest komplicerede dele af Scrum. Udviklere ser aldrig ud til at være enige om, hvor stor en indsats en bestemt opgave kræver, og det antages, at det endda er indlysende, hvad der skønnes at begynde med. Der er en række grunde til, at skøn næsten aldrig er præcise.

En af disse grunde er forudgående erfaring. Dette kan være en persons tidligere oplevelse eller holdet, men det gælder aldrig for hver enkelt person i teamet. Lad os sige, at et teammedlem har lang erfaring med at implementere godkendelsesmekanismer, der følger en bestemt standard. De kan være tilbøjelige til at estimere en godkendelsesimplementering som langt mindre "indsats" end nogen, der er mindre kyndig til emnet. Alligevel skal estimeringen være nøjagtig for alle på holdet, uanset hvem der faktisk ender med at udføre arbejdet.

En anden grund er, at det arbejde, der skønnes, næsten aldrig er klart. For et bageri er det forholdsvis ligetil at estimere, hvor lang tid det vil tage dem at bage hundrede brød. De ved, hvor lang tid man tager, hvor mange de kan bage ad gangen, og så gør du bare nogle enkle matematik.

Som enhver softwareingeniør ved, fungerer det ikke sådan, når det kommer til kode. Hver gang du dykker ned i et bestemt stykke kode, skal du ikke kun analysere og forstå det, men også forstå og analysere de ændringer, du er ved at foretage og dets potentielle konsekvenser. Det er ekstremt udfordrende at gøre, hvad må vi ikke estimere.

Du kan sandsynligvis komme med en masse flere grunde til, at arbejdsestimering er vanskelig, men pointen er, at du ikke bør tage noget skøn som evangelium. Antag, at holdet i bedste fald foretager en veluddannet gæt med de mennesker, de har på det tidspunkt.

Mens holdene bliver bedre til at estimere arbejde over tid, skal du altid huske på, at de mindste ting helt kan kaste estimatet væk. Den reelle værdi ligger i det faktiske udførte arbejde, ikke i, om estimeringen var korrekt eller ej.

Konklusion

Det er tydeligt, at Scrum er mere end summen af ​​dets dele. Ved kirurgisk implementering af ceremonierne og kaldelse af det Scrum vil du bare forlade dig med en masse ceremonier, som folk pludselig er nødt til at deltage i, men det vil ikke nødvendigvis gøre din udviklingsproces mere effektiv eller endnu mere smidig.

En Scrum-implementering skal være genstand for kontinuerlig forbedring. Hvis noget ikke fungerer for dit team; tilpas det. Scrum bør ikke være et uforanderligt sæt ceremonier og møder - det skal være en flydende ting, der vokser på dit team og giver dig et sæt retningslinjer, der hjælper dig med at blive mere produktiv og effektiv.

Jeg er på ingen måde en ivrig agil entusiast, og det bliver jeg sandsynligvis aldrig. Men i modsætning til den artikel, jeg skrev i 2018, måske har antydet, tror jeg ikke, at Scrum som en institution i sagens natur er en dårlig ting for softwareudviklingshold.

Hvis Scrum ikke føles som den rigtige pasform til dit team, skal du åbne samtalen. Se om andre mennesker på dit team føler sig på samme måde, og hvis de gør det, prøv at præcisere, hvad der nøjagtigt føles uproduktivt og foretage gradvise ændringer sammen.

Den bedste måde at udvikle software er den måde, der fungerer for dit team. Fokuser på det. Glem resten.