Archivi categoria: agile

Agilità vera e falsa

Agilità vera e falsa. Ora che essere agili è di moda, due riflessioni su cosa implica essere agili davvero.

La prima, stringata e acuta, su The Economist del 5 luglio 2018: The fashion for agile management is spreading, si diffonde la moda del management agile.

Con un commento arguto sull’uso del termine Scrum nel lavorare in gruppi:

Somehow, the teams concept acquired the name “scrum”. This moniker was clearly bestowed by someone who had never seen a real rugby game. An actual scrum involves 16 people pushing hard, getting nowhere and usually ending up collapsing or being penalised by the referee for foul play.

In qualche modo, il concetto di lavoro in gruppo ha acquisito il termine “scrum”. Questo termine è stato chiaramente conferito da qualcuno che non aveva mai visto una vera partita di rugby. Una mischia (scrum) vera coinvolge 16 persone che spingono forte, non arrivano da nessuna parte e di solito finiscono per cascare giù o essere penalizzate dall’arbitro per il gioco scorretto.

La seconda riflessione, più articolata e approfondita, viene da Martin Fowler, uno tra i firmatari del Manifesto Agile del 2001,  nell’intervento The State of Agile Software in 2018 (dove si può leggere la trascrizione di una presentazione effettuata nella conferenza Agile Australia).

On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile’s values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects). Despite the problems, the community’s great strength is its ability to learn and adapt, tackling problems that we original manifesto authors didn’t imagine.

In superficie, il mondo dello sviluppo agile del software è brillante, dal momento che è ormai accettato ovunque. Ma la realtà è preoccupante, perché gran parte di ciò che viene fatto è finto-agile, ed ignora i valori e i principi dell’agile.
Le tre principali sfide su cui dovremmo concentrarci sono: la lotta contro il Complesso Industriale Agile e l’abitudine di imporre dall’esterno i processi ai gruppi di lavoro; aumentare l’importanza dell’eccellenza tecnica; organizzare i nostri team in base ai prodotti (piuttosto che ai progetti).
Nonostante i problemi, la grande forza della comunità è la sua capacità di apprendere e adattarsi, affrontando problemi che noi autori del manifesto originale non immaginavamo.

Da leggere.

Agile, con disciplina

Processi agili e CMMI possono integrarsi? Quando è opportuno farlo? Un numero monografico della rivista sul software dei militari USA discute quando, come e perché: http://www.crosstalkonline.org/storage/flipbooks/2016/201607/index.html (Crosstalk, Jul/Aug 2016).

Dall’articolo introduttivo:

“CMMI and Agile can be used together successfully. CMMI provides the ideal framework for managing and continuously improving our organization’s processes.

Agile Scrum provides a new lifecycle development model that yields a better fit for many of our projects over the traditional waterfall model, driving greater customer interaction and employee investment.

Both frameworks have provided value to the organization when we embraced them intelligently. When the best practices from both models are thought- fully applied to the right project, it is possible to do CMMI the Agile Way.”

Persone, prima dei processi

Crosstalk, rivista software dei militari USA, notevole.

Sul numero Mar/Apr 2016, in “People-driven vs. Process-enabled Software Development: a 21st Century Imperative”, c’è la motivazione più chiara che io abbia letto sul perché è più importante la scelta delle persone rispetto al processo di sviluppo. Che al massimo può evitare di rendere difficile la collaborazione tra chi partecipa al lavoro.

Lo diceva già il Manifesto Agile del 2001, sono più importanti “gli individui e le loro interazioni, più che i processi e gli strumenti”.

E prima ancora l’ottimo “Peopleware” di DeMarco e Lister (mai tradotto in italiano!) aveva spiegato che il fattore più importante nello sviluppo software sono le persone, e il modo in cui interagiscono tra loro.

 

Casi d’uso 2.0

Ivar Jacobson ha pubblicato Use-Case 2.0 White Paper, in cui propone una serie di modifiche alla teoria e alla pratica dei casi d’uso.

Lo scopo è di rendere i casi d’uso più compatibili con lo sviluppo agile, in particolare con Scrum, e con le tecniche lean tipo Kanban.

Tra le proposte, centrale il concetto di “Use Case Slice”, cioè l’idea di poter affettare un caso d’uso per poterne gestire meglio la pianificazione, lo sviluppo e il test.

Quanto costa ricevere feedback

Un concetto chiave della rivoluzione industriale è l’economia di scala: aumentando i volumi, riduco il costo della singola unità prodotta.

Ma quando l’obiettivo è di ottenere informazioni utili per migliorare i propri prodotti o servizi, l’economia di scala non serve – bisogna invece ridurre l’impegno necessario a ricevere il feedback, a imparare dall’esperienza.

Kent Beck (ideatore di eXtreme Programming, uno tra i principali processi agili) contrappone Economy of Scale a Economy of Scope, portando come esempio le pratiche di sperimentazione che Facebook usa per adattare e rendere più efficaci i servizi che offre.

GROWS, anti-fragile e feedback

I metodi agili hanno ormai quindici anni, ed è tempo di riflettere sulla loro applicazione pratica.

In particolare, sostiene Andy Hunt, uno dei firmatari del Manifesto Agile del 2001, è necessario considerare i diversi livelli di skill di chi lavora nei progetti, il contesto in cui si trova ad operare, le caratteristiche del prodotto che si realizza: “one size does not fit all”, non esiste la taglia unica che va bene per tutti.

Anti-fragile and feedback. Trying to make up for the failures of “agile.” – Andy Hunt from NDC Conferences on Vimeo.

In quali casi è opportuno lavorare in coppia

Il pair programming (programmazione in coppia) è una delle tecniche “classiche” di extreme programming.

Ora il principale esponente di quell’approccio agile, Kent Beck, propone una ipotesi in merito a quando la programmazione in coppia funziona, e quando no: Pairing as Pruning.

In sintesi, lavorare in coppia è utile quando ci sono incertezze in merito alla definizione del problema da risolvere, e al modo in cui può essere risolto. I problemi chiari con soluzioni ben definite non necessitano secondo Beck di collaborazione, ma di automazione.