Archivi categoria: organizzazione

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.

Spirito di gruppo

Il lavoro in gruppi multidisciplinari si sta diffondendo in nuovi settori, ma gestire i team può essere difficile, e entrare in conflitto con la cultura organizzativa.

The Economist, Team spirit, Mar 19th 2016: http://www.economist.com/news/business-and-finance/21694962-managing-them-hard-businesses-are-embracing-idea-working-teams

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.

 

L’importanza del supporto utente

Mettere al centro il cliente, uno slogan che è di moda da anni, ormai un classico. Ma per passare dalle parole ai fatti bisogna fornire un ottimo supporto utente.

In molte aziende, invece, l’attenzione è centrata sul marketing e sulla vendita, e il supporto viene considerato un male necessario, se possibile da esternalizzare a terze parti. Grave errore, come spiega Gerry McGovern in If the customer really was king.

Product manager – responsabile di prodotto

Quali sono le responsabilità di un Product Manager? Cosa lo differenzia da un responsabile di progetto? In quale posizione della gerarchia organizzativa dovrebbe trovarsi?

E soprattutto, quali caratteristiche, quali competenze bisogna possedere per essere un buon responsabile di prodotto? Serve una formazione appropriata, sostiene Ellen Chisa in “Evolution of the Product Manager“, ACM Queue, october 2014.

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.