giovedì, giugno 02, 2011

Agile for Dummies (Xp,Scrum, Kanban, ScrumBan e Lean)

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:
  1. le priorità in azienda cambiano
  2. ognuno da stime diverse sulle singole attività
  3. la gente si sposta
  4. 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

5 commenti:

  1. All'università avevo apprezzato molto la teoria di XP e affini, perchè sembravano opporsi a quei mostri inutili che sono UML e affini.

    Però dopo un po' di anni a lavorare sul serio, con clienti che MAI sono facili da addomesticare, ho imparato che (e prendo spunto da uno dei tuoi schemi):

    1) rinunciare al "contract negotiation" in cambio del "customer collaboration" è SUICIDA. Ripeto: S-U-I-C-I-D-A. A volte se si è fortunati capita di avere clienti in cui la collaborazione riesce, e riesce bene. Ma nel momento in cui c'è un casino, un ritardo, qualcuno a cui dover dare la colpa, anche il più buono dei clienti te lo metterà nel culo. "Sicuro come le tasse e la morte". Se hai in mano qualcosa che testimonia un accordo chiaro col cliente, dei documenti che certificano chiaro gli accordi, ti salvi. Altrimenti sono notti sulla tastiera e bastonate da ogni dove.

    2) progettazione del software: se si parla di progetti brevi, o fix a progetti esistenti, lavorare senza una progettazione seria alle spalle e fattibile a anche vantaggioso. In caso contrario, si rischia di ritrovarsi più avanti con dei bellissimi accrocchi che stanno in piedi per miracolo e fanno molto "voodoo magic" nel loro modo di funzionare (quindi mantenibilità sotto i piedi). Ma quel che è peggio, allo scopo di risparmiare tempo subito si perderà tempo dopo, perchè solitamente una cosa costruita male è tendenzialmente anche una cosa difficilmente espandibile.

    3) Rilasciare versioni funzionanti di continuo è un target buono solo per certi tipi di progetti. Per lo pù in progetti di espansione e mantenimento. In sviluppi da zero di nuovi applicativi, quel che conta è il risultato finale, e rilasci "di test" intermedi possono benissimo avere più buchi che il gruviera. Fare mille rilasci stabili di test rallenta inutilmente e obbliga anche a sviluppare in maniera non ottimale per il prodotto finale


    Detto questo, sicuramente queste tecniche hanno anche i loro lati positivi. Sicuramente applicati a certi tipi di progetti rendono anche meglio di molti altri approcci, ma nei casi che io trovo più comuni (almeno per me) mi sembrano più pericolosi che altro.

    Poi ci sono altri dettagli indubbiamente interessanti.. ad esempi il pair programming è davvero utile per spargere la conoscenza nel team, anche se in realtà diminuisce chiaramente la velocità di sviluppo del team. Ottimo nei (rari) casi in cui si è avanti con i tempi e si può dedicare tempo al training delle risorse.

    RispondiElimina
  2. Confermo le tue impressioni. Tra l'altro proprio nella tua azienda mi pare abbiano hanno fatto seminari su Scrum e pensavo già lo utilizzassi.

    RispondiElimina
  3. Non nel mio gruppo, ma il gruppo "dall'altra parte del vetro" si è lanciato a capofitto e li vedo girare con lavagne e fogliettini.. se mi arrivano all'orecchio commenti ed impressioni vi faccio sapere!

    RispondiElimina
  4. Quanto sei alla quarta iterazione su questo post dimmelo, perché al momento è un ammasso di cose senza un collegamento o senso che non ho voglia di leggere :|

    RispondiElimina
  5. Correttore di bozze, guarda se ora ti aggrada. Altrimenti ti faccio un workflow del post (che non deve per forza essere lineare)

    RispondiElimina

Ricordatevi che i commenti vengono moderati!!!