Archivi categoria: agile

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.

Intervista a Grady Booch su UML

InfoQ ha pubblicato un’intervista a Grady Booch, uno dei principali autori di UML (Unified Modeling Language – la notazione standard per rappresentare i sistemi software).

L’intervista tocca vari temi, tra cui lo sviluppo iterativo e agile, UP, XP, Scrum, linguaggi di programmazione – ma buona parte è dedicata a UML, alla sua diffusione, ai suoi vantaggi e limiti, alla sua evoluzione nel corso dei due decenni trascorsi dall’idea iniziale a oggi.

Tra le osservazioni di Booch, il fatto che il 20% di UML è sufficiente nell’80% dei casi; che la diffusione di UML non ha mai superato il 20% delle realtà che sviluppano software (a parte il mondo real time, dove le percentuali sono superiori); che l’uso di UML come linguaggio di programmazione è molto diverso da ciò che i suoi autori intendevano.

Per i curiosi, può essere interessante confrontare l’intervista del 2014 con le risposte che mi diede nel 1998, poco dopo la pubblicazione di UML.