I min tidligere artikel startede jeg diskussionen omkring dårligt udviklede vaner i et scrum-team, der i sidste ende vil føre (før eller siden) til en fejl i leveringen. I denne artikel vil jeg gerne udvide dette emne endnu en gang og fokusere nu på funktionelle processer inde i teamet.
De er lige så vigtige som holdets tekniske ekspertise. Selvom folkene indeni er super dygtige til det job, de er ved at levere, er der stadig områder, der kan ødelægge deres indsats for perfektion. Og det vil ikke være så meget deres skyld, da det vil være det direkte ansvar for projektledelsens beslutninger og deres evne til at betjene teamet med passende processer for at støtte teamet med klare hensigter og forudsigelige aktiviteter.
Indholdsfortegnelse
Meget adskilt team med forskellige kompetencer
Forestil dig, at teamet har dygtige udviklere, perfekt uafhængige og med evnen til at holde hvad de lover og levere det aftalte sprintindhold lige i tide inden sprintets afslutning. Selv i et så perfekt scenarie (hvilket er højst usandsynligt alligevel), vil teamet have problemer med at holde trit med (stadigt voksende) backlog-funktioner, hvis færdighederne er strengt adskilt mellem teammedlemmerne.
Få eksempler
- Teamet har 1 eller 2 DevOps-ingeniører, der er i stand til at foretage ændringer i de automatiserede pipelines eller tage sig af tjenesterne inde i platformen, men resten af teamet har ingen anelse om sådanne ting. At diskutere disse historier om scrum-ceremonier som raffinementer vil føre til spildtid for størstedelen af teamet ved at hænge på mødet uden nogen deltagelse og omvendt – DevOps-udvikleren vil ikke have nogen interesse i resten af de funktionalitetsorienterede historier, og tiden på mødet vil også for det meste være spildt.
- Der er en enkelt databaseekspert til hele teamet. Afhængigt af kompleksiteten og brugen af dataløsningerne i det system, som teamet udvikler, kan denne person konstant være overbelastet med historier, som de ikke har mulighed for at færdiggøre hurtigt nok, især når deres prioriteter tages i betragtning. Endnu værre, andre historier må også vente, da de er afhængige af datakilden fra databasehistorierne.
- Når et bestemt produkt for det meste er orienteret mod backend-udvikling, er den eneste frontend-udvikler der for en sikkerheds skyld (fordi der fra tid til anden er behov for en lille ændring selv i UI-applikationen alligevel). I så fald er de fleste scrum-ceremonier igen spild af tid for dette teammedlem, da deres viden kun er begrænset til frontend, og intet andet betyder noget.
Hvor det slutter
I ethvert af ovenstående tilfælde er resultatet, at folk enten spilder deres tid, eller alternativt er de ude af stand til at indhente efterslæbet. De blokerer resten af holdet fra at begynde arbejdet med de næste historier, eller de formindsker effektivt scrum-holdets samlede effektivitet, fordi der er for meget tid, der ikke bliver brugt i spurten.
Holdet har dog stadig dette antal udviklere. Udefra er det ikke synligt (selv ikke ønsker at blive afsløret), at personerne i teamet ikke er i stand til at påtage sig nogle historier, bare fordi de er for orienteret til nogle specifikke færdigheder. Så de kan ikke hjælpe de andre teammedlemmer med historierne, selvom deres kapacitet ville tillade det, og prioriteterne for historier ville også favorisere det.
Det er endda svært for produktejeren at sammensætte noget meningsfuldt sprintindhold til teamet, da produktejeren altid skal tage højde for, hvor mange mennesker der kan arbejde på hver enkelt historie, og hvis flere lignende historier bringes til spurten på samme tid. , i sidste ende er holdets kapacitet oversvømmet, selvom der faktisk er folk, der muligvis kunne arbejde på disse historier, men de har ikke evnerne til at starte med dem.
Løsning af dilemmaet
Det er et dilemma, der skal løses, og projektledere skal være opmærksomme på, hvilken vej de skal vælge. Konkret et valg mellem:
- At have mange fuldstack-udviklere, der er i stand til at arbejde med bredere indhold, men ikke rigtig eksperter i mange emner. Så de kan gå bredt, men ikke dybt. Så kan leveringen gå hurtigt, men kvaliteten kan lide.
- At have dedikerede eksperter til hver teknologi, men derefter acceptere begrænsningen og arbejde hårdere på bedre tilpasset printindhold. Så kan folk gå dybt i dybden og bygge gode historier, men historierne skal gribes an sekventielt og dermed tage længere tid at levere.
Svag produktejer
Denne er ikke nødvendigvis et “procesproblem” per definition, men jeg behandler det sådan, bare fordi skabelsen af solide historier kan forstås som en proces, som teamet skulle ønske at have bundsolid og kompatibel med udviklingsteamet.
Det, jeg mener med svag, behøver ikke at henvise til en persons videnegenskab, men snarere til produktejerens evne til at servere teamhistorier, som udviklere kan forstå, og som giver en klar mening ud fra produktkøreplanens perspektiv. Begge disse er meget vigtige for et succesfuldt scrum-hold.
Hvis historierne mangler detaljer for, at udviklere klart kan forstå formålet, funktionel værdi eller tekniske forventninger, så kan der grundlæggende ske to scenarier:
- Udviklere vil bygge noget anderledes end det, produktejeren faktisk ønskede. Det er endda svært at fange under selve spurten, fordi produktejeren for det meste ikke har haft mulighed for at spore historiernes fremskridt på et så detaljeret niveau, og for det meste vil PO bare forvente, at tingene vil ske (magisk).
- Udviklere vil bruge alt for meget tid på at afklare historierne og diskutere dem igen og igen i stedet for at begynde at bygge dem. Dette indebærer mange ekstra opkald, gentagne aftaler og udsættelse af arbejdet til den sene sprintfase. Det når et punkt, hvor de oprindelige estimater for historierne ikke længere kan betragtes som nøjagtige, og historierne er ikke mulige at lukke inden for spurten og ruller ind i de næste spurter. I værste fald gentager situationen sig så i de efterfølgende spurter.
Tid til selvrefleksion
Det er normalt svært at indrømme, men produktejeren bør finde tid til at reflektere, se på de oprettede backlog-historier og til sidst sammenligne det med produktkøreplansvisionen, hvis der stadig er nogen fornuftig forbindelse mellem de to – hvis der er en køreplan overhovedet. Hvis ikke, er det den første ting at løse. Nogle gange er løsningen at indrømme, at produktejeren er for langt fra holdet og for langt fra eget mål.
I et sådant tilfælde skal produktejerdelen af teamet løses. Om ikke andet, kan det være en gyldig mulighed at gå efter, at bringe en solid forretningsanalytiker ind i teamet, der er mere orienteret mod teamets indhold frem for forretningsindhold (for det har vi allerede en produktejer i dette tilfælde), selv for prisen på øgede samlede omkostninger for holdet.
Test af processer uden fast tidslinje
Hvad hvis testaktiviteterne ikke er stramme til en konkret tidsplan i en scrum-sprint?
Ved første øjekast kan dette ligne noget godt, vi ønsker for et agilt/scrum-team. Fleksibilitet er altid velkommen og lyder godt, når det præsenteres udenfor.
Min erfaring viser, at resultatet af denne frihed er mere kaos end fleksibilitet. Det betyder ikke, at løsningen på dette skal være at skabe “vandfald i sprint” med dedikerede testfaser, der følges lige efter udviklingen er færdig. Dette er på ingen måde den rigtige tilgang i dette tilfælde. Du kan læse mere om dette i mine indlæg om scrum-teststrategi og agil testlivscyklus.
Vi kan stadig tillade en vis fleksibilitet og vælge testplanen, da den ser mest passende ud for det nuværende udviklingsteam og de givne produktegenskaber, som teamet leverer. Der er dog to hovedmål, der bør opnås med dette valg:
Hvis disse betingelser vil blive opfyldt, vil teamet naturligvis tilpasse sig tilpasningsprocessen, og leveringsplanen vil ikke blive påvirket af uplanlagte længerevarende testaktiviteter.
I sidste ende er det, der betyder mest, pålidelig og forudsigelig sprintudgivelse, som fører mig til det sidste punkt på denne blog.
Udefineret frigivelsesproces
Nu er dette en så indlysende ting for hvert scrum-hold. Alligevel er det mærkeligt nok også normalt en af de mest undervurderede processer.
Meget ofte vil et scrum-team bare sige, at udgivelsen vil være efter hver sprint, men det er ikke understøttet af en solid proces. Det, der så sker, er i virkeligheden, at der vil opstå en masse kaotiske, uforudsigelige aktiviteter i løbet af udgivelsestiden. Pludselig er alle mennesker optaget af “frigivelsesopgaver”, og ingen er i stand til at fokusere på at fortsætte med at udvikle nye sprinthistorier. Sprint-metrics er slået fra, og udgivelsen ligner tilfældig, uforudsigelig aktivitet set fra 3. persons (normalt klientens) synspunkt.
Folk er så fokuserede på efterslæbet, sprintindhold, udvikling, test og endelig fremvisning af resultaterne, at de glemmer, at når de er færdige med alt dette, er den næste sprint allerede i gang, og de taber allerede tid.
Leder efter et godt tidspunkt at frigive
Så hvornår præcist skal holdet lave selve udgivelsen til produktion? Den eneste vigtige ting, der betyder noget i slutningen.
Svaret på det spørgsmål sidder i processen, forudsat at du har en. Kommer an på:
- kompleksiteten af det indhold, holdet producerer i spurterne,
- varigheden af en sprint,
- antallet af berørte komponenter i systemet
- antallet af personer, der bruger og anmoder om ændringerne,
en gentagen frigivelsesproces bør etableres og følges fremadrettet. De nøjagtige regler for processen kan igen være fleksible til at definere. Men som det er med testaktiviteter, gør det til en stensikker vane, der er forudsigelig og planlagt til konkrete dage i fremtiden, det er noget at stole på og henvise til.
Valg at vælge
De mulige former for en sådan proces kan være en af følgende eller andre:
- Fuldfør testen af funktionerne fra den aktuelle sprint under den følgende sprint, og frigiv indholdet i slutningen af den sprint (når testen er afsluttet). Det betyder, at hver udgivelse ikke vil have noget indhold fra den allersidste sprint, men den vil indeholde historier fra de 2 sprints før.
- Den sidste sprint før release er altid dedikeret til at teste indholdet fra de to foregående sprints.
- Dette betyder ikke, at udviklingen under “testspurten” vil blive stoppet; det siger kun, at indholdet udviklet i den testsprint ikke vil blive inkluderet i den næste udgivelse endnu.
- Hvis der allerede er nok automatiserede testaktiviteter på plads, så stræb efter at udføre udgivelsen efter afslutningen af hver sprint. Så må dette være en meget stram proces med dedikerede mennesker, der fokuserer 100 % på de få dage. Det burde stadig ikke påvirke resten af udviklingsteamet på nogen måde.
- Du kan også vælge at udgive én gang om måneden eller én gang om måneden, primært hvis det vil være i orden fra slutbrugernes perspektiv. Dette vil øge indsatsen på testsiden for hver sprint (da indholdet vil være større for hver udgivelse). Men på den anden side vil det betyde færre gentagne aktiviteter over tid, hvilket i dette tilfælde kan have fordele for teamet. Som et resultat kan det gøre det muligt for teamet at bygge flere nye funktioner mellem udgivelserne, på trods af at funktionerne faktisk kommer til produktion med en langsommere kadence.
Men som allerede nævnt et par gange før, er det ikke så vigtigt, hvilken af disse processer der bliver valgt. Det er meget vigtigere, hvor godt teamet så holder fast i den proces og vil gøre det til en slidstærk vane.
Du kan også læse denne guide til udgivelseshåndteringsprocessen og -praksis.