Lean Inception – impostazione di un progetto agile

Lean inception: come impostare un progetto da condurre con approcci agili, senza rischiare di trascurare le basi essenziali per il suo successo.

Il Big Design Up Front (BDUF) è una pratica con molti aspetti negativi, ma una totale assenza di impostazione iniziale del progetto può essere ancora più rischiosa.

Qual è il minimo di impostazione iniziale necessaria per ridurre i rischi senza spendere troppo in una fase iniziale di durata eccessiva? Questa domanda ha originato la proposta di Lean Inception, formulata da Paulo Caroli e pubblicata qui: https://martinfowler.com/articles/lean-inception/ .

Aggiornamento codice etico ACM

L’ACM (Association for Computing Machinery) è la principale associazione internazionale di professionisti IT.

Ha deciso di aggiornare il proprio Codice etico e di condotta professionale, per tenere in considerazione il sempre maggior peso che il software ha nella nostra vita quodidiana, a livello personale e sociale.

La proposta del nuovo Codice è stata pubblicata con richiesta di commenti entro gennaio 2017:

La si può confrontare con la precedente versione 1992 che avevo tradotto in italiano con la collaborazione di Anna Pegna:

Nomi adeguati per le funzioni

Che nomi dare alle funzioni in un programma? Nomi che facciano capire cosa fanno, non il modo in cui lo fanno.

Separare l’obiettivo dall’implementazione, come spiega Fowler in Function Length.

Il nome deve spiegare immediatamente cosa si vuole ottenere con la funzione (l’intenzione), senza dover mettere il naso negli statement che la implementano. Anche quando l’implementazione consiste in un unico statement.

I remember people objecting to having an isEmpty method for a list when the common idiom is to use aList.length == 0. But here using the intention-revealing name on a function may also support better performance if it’s faster to figure out if a collection is empty than to determine its length.

Outsourcing: come ridurne i rischi

Il “Business of Software”, cioè il rapporto cliente – fornitore nello sviluppo software, è il tema del numero di settembre – ottobre 2016 su IEEE Software.

Tra gli articoli, cosa si può imparare sui risparmi effettivi dell’offshoring, ossia dal rapporto con un fornitore estero, sulla base dell’esperienza di un cliente in Olanda con una software house in India: “What’s the True Hourly Cost of Offshoring?“.

Altro spunto interessante, anche se non nuovo, la pratica di affidare un mini-progetto preliminare ad una serie di potenziali fornitori, per valutare nella pratica le capacità e i limiti: “Better Selection of Software Providers through Trialsourcing“.

I rischi delle auto a guida assistita

L’automazione marcia sempre più rapida nel campo dell’automobile. Ma il passaggio dalle auto a guida “manuale” a quelle completamente autonome non avviene con l’interruttore, non si passa di botto dal nulla (guida tutta “umana”) al tutto (nessun intervento umano nella guida).

Ci sono diversi passaggi intermedi, in cui operazioni svolte abitualmente dal guidatore umano vengono progressivamente delegate al software.  Lo spiega un articolo su Communications of the ACM di maggio 2016, The Challenges of Partially Automated Driving (tra gli autori Donald Norman,  famoso esperto di usabilità).

Mantenere costante la velocità di crociera, o far sì che il percorso dell’auto non superi i limiti della corsia in cui viaggia. Operazioni non complesse, che si possono normalmente lasciar compiere alla macchina, mentre si fa altro.

Il problema, spiegano gli autori dell’articolo, sta nel fatto che quando si verificano situazioni anomale bisogna riprendere il controllo. E se si sta facendo altro, riprendere davvero il controllo in tempo utile può essere molto, troppo difficile.

 

Casi d’uso infrastrutturali

Proseguendo nell’opera di adeguamento della tecnica dei casi d’uso (Use-cases 2.0) Jacobson propone la definizione di casi d’uso infrastrutturali, per integrare gli aspetti non funzionali – essenziali per la gestione di ogni sistema, ma “interni” – che non trovavano posto nelle versioni iniziali della sua teoria.

Dall’articolo Use-Case 2.0, apparso su Communications of the ACM, maggio 2016:

Handling all types of requirements

Although they are one of the most popular techniques for describing systems’ functionality, use cases are also used to explore non-functional characteristics. The simplest way of doing this is to capture them as part of the use cases themselves—for example, relating performance requirements to the time taken between specific steps of a use case or listing the expected service levels for a use case as part of the use case itself.

Some non-functional characteristics are subtler than this and apply to many, if not all, of the use cases. This is particularly true when building layered architectures, including infrastructure components such as security, transaction management, messaging services, and data management. The requirements in these areas can still be expressed as use cases—separate use cases focused on the technical usage of the system. These additional use cases are called infrastructure use cases, as the requirements they contain will drive the creation of the infrastructure on which the application will run.