fp logo

linkedintwitterfacebookslideshare

Martedì, 12 Ottobre 2021 10:06

L'impedenza (impedance), in elettrotecnica, è una grandezza fisica che rappresenta la forza di opposizione di un circuito al passaggio di una corrente elettrica alternata, o, più in generale, di una corrente variabile. Il...

Mercoledì, 29 Settembre 2021 12:44

Continuando nell’esplorazione della fase di Workout , siamo giunti alla Bill of Materials per la quale, come si è visto, si è passati attraverso una serie di rifinimenti che hanno permesso di superare il Quality Gate ed...

Venerdì, 10 Settembre 2021 15:03

Nel precedente articolo abbiamo iniziato a vedere la fase di Workout che ha lo scopo di finalizzare l’ingegnerizzazione di prodotto, avviando la produzione manifatturiera e preparandosi a supportare adeguatamente i clienti....

Venerdì, 03 Settembre 2021 08:16

Come più volte sottolineato, l’output primario sviluppato da un’azione di ingegneria di sistema è composto da diversi elementi afferenti a diverse discipline (ingegneristiche), molto spesso anche fortemente diverse tra...

Lunedì, 26 Luglio 2021 09:54

Con questo nuovo appuntamento relativo ad AgileEngineering concludiamo l’overview relativo alla fase di Engineering, e lo facciamo affrontando due tematiche troppo spesso penalizzate nell’operatività quotidiana per far...

Martedì, 29 Giugno 2021 11:55

Continuiamo l’esplorazione della fase di Engineering nell’ambito dell’agile applicato all’ ingegneria di sistema . Andremo a parlare dell’efficientamento dell’impiego delle risorse dando uno sguardo più di dettaglio alla...


xebir logo dac dac dac dac 

psmii psmii  safe  cal1 less cert  azure fundamentals mvp reconnect    

Per quanto si possa eccellere nella scrittura di codice, esiste una triste verità: nessun programma sarà mai privo di bug! Questo porta a riflettere sul come gestire i bug durante una Iterazione, evitando che il team ecceda la normale capacity prevista e risponda in maniera strutturata ad essi.

Per affrontare la questione, è necessario definire cosa si intende per bug: 

un bug è un funzionamento anomalo che si verifica durante il normale utilizzo del software.

Ora questo porta ad alcune considerazioni fondamentali:

  • Se i test di unità e funzionali evidenziano un problema durate l’iterazione di sviluppo del Product Backlog Item, non si tratta di un bug, ma di un’azione di “correzione” intrinseca all’attività di sviluppo stessa
  • Se il nostro Product Backlog Item è stato validato da Product Owner (e dal key stakeholder), una successiva richiesta di modifica è una “change request” non un bug, e per accoglierla deve essere creato un regolare Product Backlog Item da prioritizzare nel backlog
  • I bug hanno sempre alta priorità di risoluzione, in modo da costruire e mantenere una main-line di sviluppo di qualità, ridurre il costo di risoluzione relativo, e poter ottenere una build affidabile in ogni istante (second way di DevOps)

bugs remove asap

Fatte queste precisazioni, è utile, in fase di Iteration Planning, tenere sempre presente dell’andamento medio dei bug (tre/quattro iterazioni possono essere sufficienti) in modo da riservare una parte della capacity del team proprio per la loro risoluzione. Chiaro che se non si ha un trend decrescente del numero di bug, è necessario individuare un’opportuna azione di riduzione del debito tecnico e approfondire la tematica della Built-In Quality in retrospettiva, decidendo con il Product Owner un opportuno bilanciamento tra nuove funzionalità aumento della qualità.

A tal proposito, Martin Fowler raccomanda il mantra del “Refactoring forever”, ovvero risolvere immediatamente i bug (critici) intervenendo in modo strutturato per pulire il codice (clean code), senza dimenticarsi di aggiungere gli opportuni test di unità funzionali (ma non solo) necessari a irrobustire il codice e supportare adeguatamente la pipeline di deploy a partire dalla Continuous Integration.

La cosa importante è quella di non ricadere nella trappola del Team di Supporto (Support Team): non bisogna istituire un team che si occupa esclusivamente di bug a cui si demandano le relative responsabilità di risoluzione. Ciò ha alcune implicazioni molto evidenti, soprattutto dal punto di vista della Cultura Agile:

  • Il Support Team si sentirà presto un team di serie-B, perché non coinvolto nelle nuove attività ed iniziative
  • Il costo di risoluzione è decisamente più alto visto che il problema non sarà risolto dal team che lo ha (involontariamente) generato
  • Il know-how relativo ai problemi scoperti e risolti dovrà essere condiviso con il team originale che ha sviluppato la funzionalità specifica, causando un ping-pong di informazioni e ulteriori perdite di tempo

Il consiglio è quello di prevedere sempre, per ogni team, una gestione in stile Kanban dei bug, riservando una opportuna capacity dello stesso (la regola 80-20 è un buon punto di partenza se non si hanno dati storici del team)) per gestire i bug e occuparsi del refactoring e irrobustimento del codice: Do it your self!

 

Stay tuned J

creativecommons Contents licensed under a Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported License

@ing. Felice Pescatore