Tarin Gamberini

A software engineer and a passionate java programmer

Raccolta di collegamenti su ergonomia, salute e produttività

Elenco dei collegamenti che ho raccolto negli ultimi mesi a seguito di fastidiosi dolorini dovuti all'uso intensivo del computer in posizione seduta per lavorare:

Test di unità o di accettazione?

Come sapere se un comportamento del software debba essere verificato tramite un test di unità o di accettazione? Una storia, che vede come miglior attore non protagonista un'intera razza di capre, ci aiuta a capire alcuni sottili differenze.

Introduzione a Cucumber

Quando un committente (stackeholder) ha una esigenza che vorrebbe fosse soddisfatta da un software deve, in genere, comunicare tale esigenza a qualcuno che lo sappia progettare e sviluppare.

Aldo: “Ci serve un software che faccia questo.”

Barbara: “Sì, a grandi linee mi sembra di aver intuito ciò di cui ha bisogno e penso che si possa fare. Per raccogliere ulteriori informazioni avrei bisogno di sapere con un po' più di dettaglio cosa intende con il termine «questo».”

Aldo: “Bhe, «questo» vuol dire che il software deve portare l'utente lì e là.”

Barbara: “Lì e là sempre?”

Aldo: “No no, deve portare lì quando l'utente si è registrato e poi clicca quiricchicchi, e solo quando l'utente ha nel carrello vari prodotti, e ha nel conto abbastanza lallarallà, deve portarlo là.”

Barbara: “Va bene, e relativamente ai lallarallà come fa il software a sapere quando ne abbiamo «abbastanza»?”

Aldo:

Per ridurre la spiacevole situazione in cui il software sviluppato faccia cose diverse da quelle comunicate i team agili hanno imparato a procedere per piccoli incrementi, al termine di ognuno dei quali si chiede al committente: “È «questo» quello che volevi?”.

Ma che fare quando «questo» non è quello che voleva il committente? Le incomprensioni, si sa, accadono, ma si possono ridurre? Esiste un modo affinché ciò che è stato comunicato guidi ciò che sarà sviluppato?