Diferențele dintre Scrum și programarea extremă

Scrum și programarea extremă (XP) sunt cu siguranță foarte aliniate. De fapt, dacă ați intrat într-o echipă care face unul dintre aceste procese, s-ar putea să vă fie greu să decideți rapid dacă ați intrat într-o echipă Scrum sau o echipă XP. Diferențele sunt adesea destul de subtile, dar ele sunt importante. Cred că există patru diferențe principale între Scrum și XP:

1. echipele Scrum lucrează de obicei în iterații (numite sprinturi) care durează de la două săptămâni la o lună., Echipele XP lucrează de obicei în iterații care durează una sau două săptămâni.
2. echipele Scrum nu permit modificări în sprinturile lor. Odată ce întâlnirea de planificare a sprintului este finalizată și un angajament asumat pentru livrarea unui set de elemente de întârziere a produsului, acel set de articole rămâne neschimbat până la sfârșitul sprintului. Echipele XP sunt mult mai susceptibile de a se schimba în iterațiile lor. Atâta timp cât echipa nu a început să lucreze la o anumită caracteristică, o nouă caracteristică de dimensiune echivalentă poate fi schimbată în iterația echipei XP în schimbul caracteristicii unstarted.,
3. echipele de programare extremă lucrează într-o ordine strictă de prioritate. Caracteristicile care urmează să fie dezvoltate sunt prioritizate de client (Proprietarul Produsului Scrum), iar echipa trebuie să lucreze la ele în această ordine. În schimb, proprietarul produsului Scrum prioritizează întârzierea produsului, dar echipa determină secvența în care vor dezvolta elementele restante. Nu am văzut niciodată o echipă Scrum care să nu aleagă să lucreze la elementul cu cea mai mare prioritate. Și o echipă Scrum va alege foarte probabil să lucreze la al doilea cel mai important., Cu toate acestea, la un moment dat, unul dintre elementele cu prioritate ridicată poate să nu fie potrivit pentru sprintul planificat—poate că o persoană cheie care ar trebui să lucreze la acesta va fi inundată de lucrul la elemente cu prioritate mai mare. Sau poate că are sens să lucrați la un element prioritar ușor mai mic (să zicem #10 pe lista de produse în loc de #6), deoarece echipa va lucra în codul în care ar fi implementat #10.
4. Scrum nu prescrie nicio practică de inginerie; XP face., Îmi place practicile de inginerie XP, în special lucruri cum ar fi dezvoltarea bazată pe test, accentul pe testarea automată, programarea perechilor, designul simplu, refactorizarea și așa mai departe. Cu toate acestea, cred că este o greșeală să spun echipei „te auto-organizezi, avem încredere în tine, dar trebuie să faci aceste practici de inginerie specifice….”Acest lucru trimite un mesaj mixt echipei care provoacă confuzie. Îmi plac practicile XP, dar nu le place să le mandatez. Vreau ca echipele să descopere valoarea pe cont propriu.acestea sunt diferențe mici și adesea subtile între Scrum și XP., Cu toate acestea, ele pot avea un impact profund asupra echipei. Sfatul meu tipic pentru echipe este ” începeți cu Scrum și apoi inventați propria versiune de XP.”Practicile XP sunt minunate, dar funcționează cel mai bine și echipele se angajează să le facă cel mai strident dacă le descoperă mai degrabă decât să le mandateze. Ajut echipele să facă acest lucru în coaching-ul meu, punând întrebări de genul: „s-ar fi întâmplat această eroare dacă am fi făcut o dezvoltare bazată pe teste?”și” am fi făcut această greșeală dacă am fi împerecheat?”○Mi se pare adevărat XP să fie o țintă mică în depărtare., În cazul în care o echipă poate tinti la care și a lovit ochiul taurului, minunat. Dacă nu, cu toate acestea, acestea sunt probabil hacking (de exemplu, refactoring fără nici o testare automată sau TDD). Scrum este un ochi de taur mare care, pe cont propriu, aduce îmbunătățiri mari pur și simplu prin focalizarea suplimentară și iterațiile timeboxed. Acesta este un bun punct de plecare pentru adăugarea practicilor XP.