Archivi categoria: software engineering

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.

Misurare la produttività dello sviluppo software

Produttività = Output / Input . Bello, se fosse davvero così semplice.

Nel webinar Measuring Software Productivity, diffuso da ACM (Association for Computer Machinery, la maggiore organizzazione professionale di informatici), Steve McConnell enuncia questa semplice equazione per poi smontarla, pezzo a pezzo.

Come misurare l’output? Come misurare l’input? Quali sono le unità di misura? E qual è l’ambito di misurazione?

McConnell prende in esame tre ambiti possibili in cui misurare la produttività:

  • il singolo sviluppatore
  • il team
  • tutta l’organizzazione

e in una rapida analisi evidenzia i limiti di applicabilità delle diverse unità di misura.

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.

L’illusione del controllo

Lo stile da pubblicità comparativa, inaugurato nel software design dal Manifesto Agile (è meglio X rispetto a Y, è meglio W rispetto a Z, …) è ancora attuale.

Un uso recente in I Prefer This Over That di Elizabeth Endrickson:

I prefer:

  • – Recovery over Perfection
  • – Predictability over Commitment
  • – Safety Nets over Change Control
  • – Collaboration over Handoffs

Endrickson spiega che la realtà dello sviluppo, del rilascio e dell’uso dei prodotti è sempre più dinamica di quanto pensiamo, anche quando ci illudiamo di controllarla tramite processi ben definiti e che riteniamo affidabili. Le sorprese sono comunque dietro l’angolo.

“When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.

We can’t control the surprises. But we can be ready for them.”

Miglioramento: processo o strumenti?

Come migliorare lo sviluppo software? Con strumenti migliori? O rivedendo il proprio processo di sviluppo?

Molti sostengono che partire dagli strumenti è una scelta perdente: prima bisogna definire un processo adeguato, e solo in seguito passare alla scelta degli strumenti. Affermazione di buon senso, messa però in discussione da un articolo di Jitka e Michael West: “Through These Fields of Destruction: The Tools Versus Process Wars”, contenuta nel numero monografico di Crosstalk dedicato al rapporto tra tecnologie e processi. Secondo gli autori, è meglio se la definizione di processo e strumenti viene pensata insieme.

CrossTalk è il bimestrale online e gratuito sul software engineering pubblicato dalle organizzazioni militari USA.

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.