I min forrige artikkel startet jeg diskusjonen rundt dårlig utviklede vaner i et scrum-team som til slutt vil føre (før eller siden) til en svikt i leveringen. I denne artikkelen vil jeg utvide dette emnet en gang til og fokusere nå på funksjonelle prosesser i teamet.
De er like viktige som teamets tekniske fortreffelighet. Selv om menneskene på innsiden er superdyktige for jobben de skal levere, er det fortsatt områder som kan ødelegge deres innsats for perfeksjon. Og det vil ikke være så mye deres feil, da det vil være det direkte ansvaret for prosjektledelsens beslutninger og deres evne til å betjene teamet med passende prosesser for å støtte teamet med klare hensikter og forutsigbare aktiviteter.
Innholdsfortegnelse
Svært adskilt team med distinkte ferdigheter
Tenk deg at teamet har dyktige utviklere, helt uavhengige og med evnen til å holde det de lover og levere det avtalte sprintinnholdet akkurat i tide før sprinten avsluttes. Selv i et så perfekt scenario (som er høyst usannsynlig uansett), vil teamet ha problemer med å holde tritt med (stadig voksende) backlog-funksjoner hvis ferdighetene er strengt adskilt mellom teammedlemmene.
Få eksempler
- Teamet har 1 eller 2 DevOps-ingeniører som er i stand til å gjøre endringer i de automatiserte rørledningene eller ta seg av tjenestene inne på plattformen, men resten av teamet har ingen anelse om slike ting. Å diskutere disse historiene på scrum-seremonier som avgrensninger vil føre til bortkastet tid for flertallet av teamet ved å henge på møtet uten deltakelse og omvendt – DevOps-utvikleren vil ikke ha noen interesse i resten av de funksjonalitetsorienterte historiene, og tiden på møtet vil også for det meste være bortkastet.
- Det er en enkelt databaseekspert for hele teamet. Avhengig av kompleksiteten og bruken av dataløsningene i systemet teamet utvikler, kan denne personen være konstant overbelastet med historier de ikke har mulighet til å fullføre raskt nok, spesielt når de tar hensyn til prioriteringene deres. Enda verre, andre historier må også vente, ettersom de er avhengige av datakilden fra databasehistoriene.
- Når et bestemt produkt stort sett er orientert mot backend-utvikling, er den eneste front-end-utvikleren der i tilfelle (fordi fra tid til annen er det nødvendig med noen små endringer selv i UI-applikasjonen uansett). I så fall, igjen, er de fleste scrum-seremoniene bortkastet tid for dette teammedlemmet, ettersom kunnskapen deres er begrenset bare til frontend, og ingenting annet betyr noe.
Hvor den avsluttes
I alle de ovennevnte tilfellene er resultatet at folk enten kaster bort tiden sin, eller alternativt klarer de ikke å ta igjen etterspørselen. De blokkerer resten av teamet fra å starte arbeidet med de neste historiene, eller de reduserer effektivt den generelle effektiviteten til scrum-teamet fordi det er for mye tid som ikke blir brukt i spurten.
Teamet har imidlertid fortsatt dette antallet utviklere. Fra utsiden er det ikke synlig (selv ikke ønsker å bli avslørt) at personene i teamet ikke er i stand til å ta på seg noen historier bare fordi de er for orientert mot et bestemt ferdighetssett. Så de kan ikke hjelpe de andre teammedlemmene med historiene, selv om deres kapasitet tillater det, og prioriteringene for historier vil også favorisere det.
Det er til og med vanskelig for produkteieren å komponere noe meningsfylt sprintinnhold for teamet, siden produkteieren alltid må ta med i tankene hvor mange som kan jobbe med hver enkelt historie, og om flere lignende historier bringes til sprinten samtidig. , til syvende og sist blir kapasiteten til teamet overflyttet, selv om det faktisk er folk som muligens kan jobbe med disse historiene, men de har ikke ferdighetene til å starte med dem.
Løse dilemmaet
Det er et dilemma som skal løses, og prosjektledere skal være klar over hvilken vei de skal velge. Nærmere bestemt et valg mellom:
- Å ha mange fullstack-utviklere som er i stand til å jobbe med bredere innhold, men egentlig ikke eksperter på mange emner. Så de kan gå bredt, men ikke dypt. Da kan leveringen gå raskt, men kvaliteten kan lide.
- Å ha dedikerte eksperter for hver teknologi, men deretter akseptere begrensningen og jobbe hardere med bedre tilpasset utskriftsinnhold. Da kan folk gå dypt og bygge gode historier, men historiene må tilnærmes sekvensielt, og dermed ta lengre tid å levere.
Svak produkteier
Denne er ikke nødvendigvis et «prosessspørsmål» per definisjon, men jeg behandler det slik bare fordi det å lage solide historier kan forstås som en prosess som teamet skal ønske å ha bunnsolid og kompatibel med utviklingsteamet.
Det jeg mener med svak trenger ikke å referere til kunnskapsegenskapen til en person, men snarere til evnen til produkteieren til å tjene teamhistoriene som utviklere kan forstå og som gir en viss mening fra produktets veikartperspektiv. Begge disse er veldig viktige for et vellykket scrum-team.
Hvis historiene mangler detaljer for at utviklere tydelig skal kunne forstå formålet, funksjonsverdien eller tekniske forventninger, kan i utgangspunktet to scenarier skje:
- Utviklere vil bygge noe annerledes enn det produkteieren faktisk ønsket. Det er til og med vanskelig å få med seg under selve sprinten fordi produkteieren stort sett ikke har hatt muligheten til å spore fremdriften til historiene på et så detaljert nivå, og for det meste vil PO bare forvente at tingen vil skje (magisk).
- Utviklere vil bruke altfor mye tid på å avklare historiene og diskutere dem om og om igjen i stedet for å begynne å bygge dem. Dette innebærer mange tilleggssamtaler, gjentatte avtaler og utsettelse av arbeidet til sen sprintfase. Det når et punkt hvor de opprinnelige estimatene for historiene ikke lenger kan anses som nøyaktige, og historiene er ikke mulig å lukke innenfor spurten og ruller inn i de neste spurtene. I verste fall gjentar situasjonen seg i de påfølgende spurtene.
Tid for selvrefleksjon
Det er vanligvis vanskelig å innrømme, men produkteieren bør finne tid til å reflektere, se på etterslephistoriene som er opprettet, og til slutt sammenligne det med produktets veikart-visjon hvis det fortsatt er noen fornuftig kobling mellom disse to – hvis det er noen veikart i det hele tatt. Hvis ikke, er det den første tingen å løse. Noen ganger er løsningen å innrømme at produkteieren er for langt fra teamet og for langt fra eget mål.
I et slikt tilfelle skal produkteierdelen av teamet løses. Om ikke annet, kan det å bringe inn en solid forretningsanalytiker som er mer orientert mot teamets innhold enn forretningsinnhold (for det har vi allerede en produkteier i dette tilfellet) et gyldig alternativ å gå for, selv for prisen på økte totale kostnader for laget.
Teste prosesser uten fast tidslinje
Hva om testaktivitetene ikke er stramme til en konkret tidsplan i en scrum-sprint?
Ved første øyekast kan dette se ut som noe bra vi ønsker for et smidig / scrum-team. Fleksibilitet er alltid velkommen og høres bra ut når den presenteres utenfor.
Min erfaring viser at resultatet av denne friheten er mer kaos enn fleksibilitet. Det betyr ikke at løsningen på dette skal være å skape «fosser inne i sprint» med dedikerte testfaser som følges like etter at utviklingen er ferdig. Dette er på ingen måte den riktige tilnærmingen i dette tilfellet. Du kan lese mer om dette i innleggene mine om strategi for scrumtesting og livssyklus for smidig testing.
Vi kan fortsatt tillate litt fleksibilitet og velge testplanen ettersom den ser mest hensiktsmessig ut for det nåværende utviklingsteamet og de gitte produktegenskapene teamet leverer. Det er imidlertid to hovedmål som bør oppnås med dette valget:
Hvis disse betingelsene blir oppfylt, vil teamet naturligvis tilpasse seg tilpasningsprosessen, og leveringsplanen vil ikke bli påvirket av uplanlagte langvarige testaktiviteter.
Til slutt, det som betyr mest er pålitelig og forutsigbar sprintutgivelse, som leder meg til det siste punktet i denne bloggen.
Udefinert utgivelsesprosess
Nå er dette en så åpenbar ting for hvert scrum-lag. Men merkelig nok er det også vanligvis en av de mest undervurderte prosessene.
Svært ofte vil et scrum-team bare si at utgivelsen vil skje etter hver sprint, men det er ikke støttet av en solid prosess. Det som skjer da, i virkeligheten, er at det vil oppstå mye kaotiske, uforutsigbare aktiviteter i løpet av utgivelsestiden. Plutselig er alle mennesker opptatt av «frigjøringsoppgaver», og ingen er i stand til å fokusere på å fortsette å utvikle nye sprinthistorier. Sprint-beregninger er av, og utgivelsen ser ut som tilfeldig, uforutsigbar aktivitet fra 3. persons syn (vanligvis klienten).
Folk er så fokusert på etterslepet, sprintinnhold, utvikling, testing og til slutt å vise frem resultatene at de glemmer at når de er ferdige med alt dette, er neste sprint allerede i gang, og de taper allerede tid.
Ser etter et godt tidspunkt å slippe
Så når nøyaktig skal teamet gjøre selve utgivelsen til produksjon? Den eneste viktige tingen som betyr noe på slutten.
Svaret på det spørsmålet sitter i prosessen, forutsatt at du har en. Avhengig av:
- kompleksiteten til innholdet teamet produserer i spurtene,
- varigheten av en sprint,
- antall berørte komponenter i systemet
- antall personer som bruker og ber om endringene,
en gjentatt utgivelsesprosess bør etableres og følges fremover. De nøyaktige reglene for prosessen kan igjen være fleksible i definisjonen. Men som det er med testaktiviteter, gjør det til en bunnsolid vane som er forutsigbar og planlagt for konkrete dager i fremtiden, noe å stole på og referere til.
Valg å velge
De mulige formene for en slik prosess kan være en av følgende eller andre:
- Fullfør testingen av funksjonene fra gjeldende sprint i løpet av neste sprint og slipp innholdet på slutten av sprinten (når testingen er fullført). Dette betyr at hver utgivelse ikke vil ha noe innhold fra den aller siste spurten, men den vil inneholde historier fra de to spurtene før.
- Den siste spurten før utgivelse er alltid dedikert til å teste innholdet fra de to foregående spurtene.
- Dette betyr ikke at utviklingen under «testsprinten» vil bli stoppet; den sier bare at innholdet utviklet i den testsprinten ikke vil bli inkludert i neste utgivelse ennå.
- Hvis det allerede er nok automatiserte testaktiviteter på plass, prøv å gjøre utgivelsen etter slutten av hver sprint. Da må dette være en veldig streng prosess med dedikerte folk som fokuserer 100% på de få dagene. Det skal fortsatt ikke påvirke resten av utviklingsteamet på noen måte.
- Du kan også velge å gi ut en gang per måned eller en gang per N måneder, hovedsakelig hvis det vil være greit fra sluttbrukernes perspektiv. Dette vil øke innsatsen på testsiden for hver sprint (ettersom innholdet blir større for hver utgivelse). Men på den annen side vil det bety mindre mengde gjentatte aktiviteter over tid, noe som i dette tilfellet kan ha fordeler for teamet. Som et resultat kan det gjøre det mulig for teamet å bygge flere nye funksjoner mellom utgivelsene, til tross for at funksjonene faktisk kommer til produksjon med en langsommere tråkkfrekvens.
Men som allerede nevnt noen ganger tidligere, er det ikke så viktig hvilken av disse prosessene som blir plukket ut. Det er mye viktigere hvor godt teamet vil holde seg til den prosessen og vil gjøre det til en slitesterk vane.
Du kan også lese denne veiledningen til prosess og praksis for utgivelsesadministrasjon.