Modelul Spotify (modelul Spotify) este un set de tehnici organizatorice utilizate pentru dezvoltarea de software care vă permite să scalați echipa de dezvoltare în conformitate cu principiile Agile . Utilizat pentru prima dată în dezvoltarea serviciului de muzică Spotify [1] [2] [3] [4] .
Modelul Spotify a fost rezultatul unui experiment pe termen lung efectuat în cadrul companiei. Sistemul de scalare rezultat pentru dezvoltarea de software nu se bazează pe niciunul dintre cadrele binecunoscute ( SAFe , Disciplined Agile etc.), ci se bazează pe definiții clare ale principiilor, rolurilor și strategiilor de colaborare. Alegerea inițială a rolurilor și principiilor a permis echipei de dezvoltare Spotify să creeze o metodologie de dezvoltare agilă care a rezolvat multe dintre problemele inerente echipelor agile la nivel de întreprindere.
Din punct de vedere organizatoric, Spotify a înlocuit echipele Scrum general acceptate cu „echipe” flexibile ( echipă engleză ), libere să-și determine propriile metode și practici și neconstrânse de „ scrum only ” sau „ kanban only ” impuse de sus . 5] . Odată ce echipa își demonstrează înțelegerea metodologiilor agile și capacitatea de a se autoorganiza, echipa este liberă să aleagă sau să depășească evenimentele sau procesele general acceptate de Scrum sau Extreme Programming: de exemplu, unele echipe pot folosi zilnic „întâlniri permanente”, în timp ce alții – nu. În loc să urmeze practici specifice, echipele sunt obligate să se concentreze pe următoarele principii: autonomie, aliniere la misiunea companiei, motivație ridicată, încredere în ideile comunității. Fiecare dintre „echipe” se concentrează pe o anumită parte a funcționalității produsului, cum ar fi căutarea sau listele de redare, ceea ce le permite să devină experți în domeniile lor [2] .
La următorul nivel de interacțiune, „echipele” Spotify cu o misiune comună sau similară se unesc în „triburi” ( tribul englezesc ). „Triburile” se întâlnesc periodic pentru a discuta și a minimiza dependențele și pentru a se asigura că „echipele” lucrează la aceeași misiune. Majoritatea întâlnirilor comune sunt spontane și nu sunt planificate în prealabil.
Pentru a reuni membrii diferitelor echipe care lucrează în aceeași disciplină (ceea ce se întâmplă adesea când echipele funcționale sunt înlocuite cu echipe interfuncționale), Spotify folosește „departamente” ( ing. capitol ) și „bresle” ( ing. guild ). Un „departament” se referă la un grup de angajați din echipe diferite din cadrul aceleiași discipline, arii de expertiză (de exemplu, testeri sau designeri de layout), care se întâlnesc în mod regulat pentru a se asigura că sunt utilizate cele mai recente tendințe și tehnologii, împărtășesc cunoștințe și reutilizați eficient soluțiile existente. „Breasla” este un grup mai puțin formal și mai incluziv: de exemplu, breasla de testeri este formată nu numai dintr-o gamă largă de testeri (incluzând atât specialiști în automatizare, cât și în testare manuală), ci și din programatori care doresc să înțeleagă mai bine testarea proceselor. și să contribuie la activități în această direcție [2] .
Modelul de scalare utilizat în abordare a fost introdus treptat în Spotify în perioada 2011-2012. Echipa de dezvoltare a crescut rapid în dimensiune - în trei ani de la 30 la 250 de ingineri. În ciuda acestei creșteri, satisfacția angajaților a crescut și ea treptat, iar în aprilie 2012 a fost de 4,4 din 5 puncte [5] [6] .
Spotify nu este singurul loc care folosește acest model. În afara acestuia, modelul Spotify a fost folosit, de exemplu, de Tech Mahindrasă lucreze la un proiect major în sectorul bancar și al asigurărilor [4] .
Există o părere că Modelul Spotify este un cadru pentru scalarea echipelor care dezvoltă software conform principiilor Agile. Cu toate acestea, dat fiind faptul că modelul Spotify nu se bazează pe niciun cadru existent (de exemplu Scaled Agile Framework sau LeSS ), nu are un sistem oficial de certificare și a fost dezvoltat doar ca o modalitate de organizare a dezvoltării software în cadrul Spotify, ținând cont de acesta. caracteristici organizaționale și culturale, atunci este incorect să considerăm acest model ca un cadru de scalare pentru echipele de dezvoltare urmând principiile Agile.
Henrik Knieberg, unul dintre contribuitorii la dezvoltarea organizării muncii în cadrul Spotify, ca răspuns la răspândirea proeminenței modelului Spotify și la copierea acestuia în alte companii, a susținut că modelul Spotify nu este un cadru de scalare a echipei și, de asemenea, că modelul Spotify, strict vorbind, nu este „model” ca atare, ci afișează un exemplu de organizare a muncii într-o anumită companie. [7]
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|