Scrum e Extreme Programming (XP) sono decisamente molto allineati. Infatti, se sei entrato in una squadra facendo uno di questi processi potresti avere difficoltà a decidere rapidamente se sei entrato in una squadra Scrum o in una squadra XP. Le differenze sono spesso piuttosto sottili, ma sono importanti. Penso che ci siano quattro differenze principali tra Scrum e XP:
- I team Scrum in genere lavorano in iterazioni (chiamate sprint) che durano da due settimane a un mese., I team XP in genere lavorano in iterazioni lunghe una o due settimane.
- I team Scrum non consentono modifiche nei loro sprint. Una volta completata la riunione di pianificazione sprint e assunto l’impegno di fornire un set di elementi del product backlog, tale set di elementi rimane invariato fino alla fine dello sprint. I team XP sono molto più suscettibili di cambiare all’interno delle loro iterazioni. Finché il team non ha iniziato a lavorare su una particolare funzionalità, una nuova funzionalità di dimensioni equivalenti può essere scambiata nell’iterazione del team XP in cambio della funzionalità non avviata.,
- I team di programmazione Extreme lavorano in un rigoroso ordine di priorità. Le caratteristiche da sviluppare sono prioritarie dal cliente (proprietario del prodotto di Scrum) e il team è tenuto a lavorare su di esse in quell’ordine. Al contrario, il proprietario del prodotto Scrum dà la priorità al backlog del prodotto, ma il team determina la sequenza in cui svilupperà gli elementi del backlog. Non ho mai visto un team Scrum non scegliere di lavorare sull’elemento con la priorità più alta. E un team Scrum molto probabilmente sceglierà di lavorare sul secondo più importante., Tuttavia, ad un certo punto uno degli elementi ad alta priorità potrebbe non essere una buona misura per lo sprint in programma—forse una persona chiave che dovrebbe lavorare su di esso sarà sommersa dal lavoro su elementi a priorità più alta. O forse ha senso lavorare su un elemento di priorità leggermente inferiore (diciamo #10 sul product backlog invece di #6) perché il team lavorerà nel codice in cui verrà implementato #10.
- Scrum non prescrive alcuna pratica ingegneristica; XP lo fa., Amo le pratiche di ingegneria XP, in particolare cose come lo sviluppo guidato dai test, l’attenzione per i test automatizzati, la programmazione delle coppie, il design semplice, il refactoring e così via. Tuttavia, penso che sia un errore dire alla squadra ” sei auto-organizzante, ci fidiamo di te, ma devi fare queste pratiche ingegneristiche specifiche….”Questo invia un messaggio misto alla squadra che causa confusione. Amo le pratiche XP ma non mi piace mandarle. Voglio che le squadre scoprano il valore da sole.
Queste sono piccole e spesso sottili differenze tra Scrum e XP., Tuttavia, possono avere un profondo impatto sulla squadra. Il mio tipico consiglio ai team è ” inizia con Scrum e poi inventa la tua versione di XP.”Le pratiche XP sono meravigliose, ma funzionano meglio e le squadre si impegnano a loro in modo più stridente se le scoprono da sole piuttosto che averle mandate. Aiuto i team a farlo nel mio coaching facendo domande come: “Sarebbe successo questo bug se avessimo fatto uno sviluppo basato sui test?”e” Avremmo fatto quell’errore se fossimo stati in coppia?”Trovo che il vero XP sia un piccolo bersaglio in lontananza., Se una squadra può mirare a questo e colpire l’occhio del toro, meraviglioso. In caso contrario, tuttavia, sono probabilmente hacking (ad esempio, refactoring senza alcun test automatico o TDD). Scrum è un grande occhio di bue che da solo porta grandi miglioramenti semplicemente attraverso la messa a fuoco aggiuntiva e le iterazioni timeboxed. Questo è un buon punto di partenza per aggiungere le pratiche XP.