Archivi categoria: software engineering

Microservices

Introduzione ai Microservices di Martin Fowler. Questi gli spunti più interessanti:

  1. Rapporto tra microservices e SOA (Service Oriented Architecture). I microservices sono solo uno dei modi in cui la SOA può essere organizzata: senza bus centrale (Enterprise Service Bus), autonomi ed indipendenti.
  2. Organizzare lo sviluppo per microservices significa, prima di tutto, definire e attuale un modello organizzativo in cui ogni team lavora in modo indipendente. A occhio, maggiori sono le dimensioni del team di sviluppo, più questo modello organizzativo è sensato.
  3. I microservices hanno senso per fornire servizi di business completi. Avrebbe meno senso definire microservices puramente infrastrutturali.
  4. Per lavorare a microservices bisogna avere già una forte competenza sulla materia, sul dominio applicativo. Se questa manca, meglio sviluppare prima un monolite e poi, se opportuno, ristrutturarlo estrapolandone i microservizi.

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.”