Visto che mi sembra ci sia un po' di confusione nell'aere, parliamo di Agile Method e come si usa nella vita reale (non solo con la teoria).
Il post è un'epica (capirete dopo) e scritto in maniera agile
quindi non vi lamentate. Quello che c'è su Wikipedia non è esaustivo.
In principio era la
Toyota, che dopo la seconda guerra mondiale dovette scontrarsi con la produzione su larga scala della Ford.
Dato che questa metodologia di lavoro ebbe successo (si ok, negli ultimi anni la Toyota ha fatto anche qualche cazzata), perchè non adattarla ad altri ambiti, tipo lo sviluppo del software?
In particolare dopo anni di analisi i top manager delle grandi aziende sono arrivati alla considerazione che ci vuole troppo tento a rilasciare una certa versione di prodotto o una libreria oppure una minchia di hotfix. Che le stime sono sbagliate e che i programmatori sono dei farabutti.
A qualcuno piacque l'idea: "analizziamo bene le attività, usiamo dei
time slot ben definiti e per ogni sessione di lavoro cerchiamo di produrre
qualcosa di "
finito" tenendo traccia dei problemi che abbiamo avuto nel realizzare tutto ciò."
Agile Manifesto che spiega alcuni principi fondamentali della filosofia
Agile- La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
- Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
- Il software funzionante è il principale metro di misura di progresso.
Ora vi descriverò nel dettaglio
Scrum, che è quello con cui il nostro team lavora attualmente
"Per dirla con le parole di
Ken Schwaber(tra i fondatori di Scrum), Scrum non è una metodologia, è un framework. Ciò significa che scrum non vi dice esattamente cosa fare."
"Tali iterazioni sono fatte per essere brevi e “timeboxed”. Questa attenzione nel rilasciare codice funzionante in un breve intervallo di tempo significa che i team Scrum e XP non danno spazio alle teorie. Non si perdono nel progettare un perfetto modello UML in un case-tool, nello scrivere dei perfetti documenti dei requisiti, o codice in grado di assecondare ogni immaginabile cambiamento futuro. Al contrario, Scrum ed XP si focalizzano sul fare in modo che le cose vengano portate a termine."
NB Alcuni dicono che Scrum siamo uno strumento...I Ruoli nello Scrum
- Product Owner (PO), è il tramite tra il team ed il "cliente". Analizza i requisiti e da le priorità.
- Scrum Master, fa in modo che tutto funzioni. Difende il team dagli attacchi del PO
- Team (composto da 7+-2 persone). Deve essere cross-funzionale, si auto-organizza, realizza le attività dello sprint
Le cose da fare per lavorare con Scrum:
Sprint
Arco temporale (non troppo breve ne troppo lungo, in media 2/3 settimane) in cui bisogna realizzare qualcosa di
potenzialmente distribuibile. Alla fine dello sprint si realizza un
demo
Sprint Backlogè il diario delle cose da fare, dei requisiti e dei
nice-to-haveLe user stories (As a
, I want so that .) si suddividono in singoli task con priorità e stima sui tempi di realizzazione
Daily Standup meeting
ogni mattina si fa riunione in piedi analizzando cosa si è fatto il giorno prima e cosa si farà il giorno stesso. DEVE ESSERE BREVE (al max 15/20 minuti)
Taskboard e Burndown Chart
tengono traccia delle attività e degli impediments durante lo sprint
Sprint Planning
Lo Sprint planning è un meeting critico, probabilmente il più importante evento in Scrum (secondo la mia personale opinione naturalmente). Uno sprint planning meeting fatto male può compromettere l'intero sprint.
le storie si votano con lo scrum poker (si, esistono anche le app iPhone e Android...)
Sprint Review e retrospective
Si analizza cosa sia stato rilasciato, i problemi riscontrati e si tiene traccia dei fattori positivi e di quelli negative.
Oltre a Scrum esistono altre metodologie di lavoro, tra questi:
Kanban
Visualize the workflow (è il suo motto)
- Split the work into pieces, write each item on a card and put on the wall
- Use named columns to illustrate where each item is in the workflow.
- Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
- · Measure the lead time (average time to complete one item, sometimes called “cycle time”),optimize the process to make lead time as small and predictable as possible.
Fondamentalmente ha meno regole di Scrum, non ha ruoli e le iterazioni non sono time-boxed.
XP (Extreme Programming)
"Scrum si focalizza sul management e sulle pratiche organizzative mentre XP si focalizza per lo più sulle pratiche concrete della programmazione. È questo il motivo per cui funzionano bene insieme - affrontano ambiti differenti e si completano a vicenda."
- Il pair programming è faticoso e non dovrebbe essere fatto tutto il giorno.
- È bene cambiare le coppie di frequente.
- Il pair programming aumenta la diffusione delle conoscenze nel
- gruppo. Ciò che sorprende è che questo processo è anche rapido.
- Alcuni non si sentono a proprio agio facendo pair programming.
- Non rinunciare ad un eccellente programmatore solo perché il pair programming lo mette a disagio.
- Il code review è una alternativa accettabile al pair programming.
- Il “navigatore” (quello che non è alla tastiera) dovrebbe avere sotto mano anche lui un computer, non per lo sviluppo, ma per fare alcune spike se necessario, o per dare una occhiata alla documentazione quando il “guidatore” (quello che sta alla tastiera) resta bloccato, etc.
Impressioni personali (dopo circa un anno di utilizzo di Scrum e Scrumban)
Poichè lavoro in GRANDE multinazionale, nota per non essere precisamente agile, vi trascrivo alcune impressioni sul come nella realtà dei fatti si possano adottare queste tecniche.
Tutto funziona bene fino a che gli impediments non distruggono troppo le storie
Le storie non devono essere enormi (ovvero delle epiche)
Nella teoria è il team che comanda, nella VITA VERA è il colui che ti paga che COMANDA.
Quindi se una cosa deve essere fatta entro il giorno X, deve essere fatta entro il giorno X. Questo lo sottolineo perchè in Scrum si parla di no-overtime
Se perdi troppo tempo a discutere come fare una cosa e non a farla, hai perso. E poi:
- le priorità in azienda cambiano
- ognuno da stime diverse sulle singole attività
- la gente si sposta
- potrebbe piovere merda
Non è sempre facile realizzare team cross-functional:
In generale poichè tutti NON sanno fare tutto (non parlo solo di skill, ma anche di predisposizione alle attività) un team deve essere avere più figure per tipologia (sviluppatori, testatori, documentatori)
Tenere traccia dei lavori su una lavagnona sempre visibile ha una sua utilità.
Certo un lavagnone digitale alla surface sarebbe più comodo...
E per finire come scritto su alcuni libri di Agile: "Se il waterfall funziona, continuate ad usarlo."
PS. Quando avrete finito di leggere questo post, è probabile che le regole di Scrum o Kanban siano già vecchie, o che ci sia un nuovo-fantastico-framework-agile
Fonti
