Spotify Model (Spotifay-model) er et sæt af organisatoriske teknikker, der bruges til softwareudvikling, og som giver dig mulighed for at skalere udviklingsteamet i overensstemmelse med principperne i Agile . Først brugt i udviklingen af Spotify -musiktjenesten [1] [2] [3] [4] .
Spotify-modellen var resultatet af et langsigtet eksperiment udført i virksomheden. Det resulterende skaleringssystem til softwareudvikling er ikke baseret på nogen af de velkendte rammer ( SAFe , Disciplined Agile osv.), men er baseret på klare definitioner af principper, roller og strategier for samarbejde. Det oprindelige valg af roller og principper gjorde det muligt for Spotify -udviklingsteamet at skabe en agil udviklingsmetodologi , der løste mange af de problemer, der var iboende i virksomhedsdækkende agile teams.
Fra et organisatorisk synspunkt har Spotify erstattet de generelt accepterede Scrum-hold med fleksible "teams" ( engelsk squad ), frie til at bestemme deres egne metoder og praksis og ikke begrænset af " scrum only " eller " kanban only " pålagt ovenfra [ 5] . Når teamet har demonstreret deres forståelse af agile metoder og evnen til selvorganisering, kan teamet frit vælge eller tilsidesætte de generelt accepterede begivenheder eller processer i Scrum eller Extreme Programming: for eksempel kan nogle teams bruge daglige "stående møder", mens andre - nej. I stedet for at følge specifik praksis, skal teams fokusere på følgende principper: autonomi, tilpasning til virksomhedens mission, høj motivation, tillid til fællesskabets ideer. Hvert af "squads" er fokuseret på en specifik del af produktets funktionalitet, såsom søgning eller afspilningslister, som giver dem mulighed for at blive eksperter på deres områder [2] .
På det næste niveau af interaktion forenes Spotify "hold" med en fælles eller lignende mission til "stammer" ( engelsk stamme ). "Tribes" mødes med jævne mellemrum for at diskutere og minimere afhængigheder og for at sikre, at "squads" arbejder på den samme mission. De fleste fællesmøder er spontane og ikke på forhånd planlagte.
For at samle medlemmer af forskellige teams, der arbejder i samme disciplin (hvilket ofte sker, når funktionelle teams erstattes af tværfunktionelle), bruger Spotify "afdelinger" ( eng. kapitel ) og "laug" ( eng. guild ). En "afdeling" refererer til en gruppe medarbejdere fra forskellige teams inden for samme disciplin, ekspertiseområde (f.eks. testere eller layoutdesignere), som mødes regelmæssigt for at sikre, at de nyeste trends og teknologier bliver brugt, deler viden og effektivt genbruge eksisterende løsninger. "lauget" er en mindre formel og mere inkluderende gruppe: for eksempel består tester-lauget ikke kun af en bred vifte af testere (inklusive både automatiserings- og manuelle testspecialister), men også af programmører, der ønsker at bedre forstå de processer, der testes. og bidrage til aktiviteter i denne retning [2] .
Den skaleringsmodel, der blev brugt i tilgangen, blev gradvist introduceret til Spotify i løbet af 2011-2012. Udviklingsteamet voksede hurtigt i størrelse - på tre år fra 30 til 250 ingeniører. På trods af denne vækst steg medarbejdertilfredsheden også gradvist, og i april 2012 var den 4,4 ud af 5 point [5] [6] .
Spotify er ikke det eneste sted, der bruger denne model. Uden for den blev Spotify-modellen brugt, for eksempel af Tech Mahindraat arbejde på et større projekt i bank- og forsikringssektoren [4] .
Der er en opfattelse af, at Spotify-modellen er en ramme til at skalere teams, der udvikler software efter principperne i Agile. Men givet det faktum, at Spotify-modellen ikke er baseret på nogen eksisterende ramme (f.eks. Scaled Agile Framework eller LeSS ), har den ikke et officielt certificeringssystem og blev udelukkende udviklet som en måde at organisere softwareudvikling i Spotify under hensyntagen til dets organisatoriske og kulturelle træk, så er det forkert at betragte denne model som en skaleringsramme for udviklingsteams, der følger principperne for Agile.
Henrik Knieberg, en af bidragyderne til udviklingen af tilrettelæggelsen af arbejdet inden for Spotify, argumenterede som reaktion på Spotify-modellens udbredelse og kopiering i andre virksomheder, at Spotify-modellen ikke er en teamskaleringsramme, og også at Spotify-modellen er strengt taget ikke "model" som sådan, men viser et eksempel på tilrettelæggelsen af arbejdet i en bestemt virksomhed. [7]
| Softwareudvikling | |
|---|---|
| Behandle | |
Koncepter på højt niveau | |
| Vejbeskrivelse |
|
| Udviklingsmetoder _ | |
| Modeller | |
| Bemærkelsesværdige tal |
|