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    

Nei due precedenti post sull’argomento (post1, post2) si è parlato dell’opportunità di avere un Basketche consenta di raccogliere in modo “informale” le diverse richieste provenienti dagli stakeholder. 

Lo scopo ultimo è quello avere un Healthy Product Backlog, ovvero un Product Backlog in salute. 

In questo ultimo post dedicato all’argomento si farà riferimento ad una possibile implementazione del tutto tramite tool digitali, nello specifico: Azure DevOps (ex TFS) e la suite Office 365

Con Azure DevOps è possibile supportare l’intero ciclo di sviluppo di un prodotto, e in particolare il Product Backlog che rappresenta l’elemento di riferimento per gestire cosa realizzare in funzione del Valore del prodotto specifico.

basket azure 1

Azure DevOps Product Backlog

Quello che però interessa nello specifico è, ovviamente, come implementare fattivamente il Basket. Se si decide di utilizzare esclusivamente Azure DevOps, è possibile sfruttare il concetto di Area Pathper crearne una nuova specifica che rappresenti proprio il nostro Basket. 

basket azure 2

Creare una nuova Area Path

In tal modo, i Basket Item(che possono essere creati sfruttando gli item generici già forniti dallo specifico template oppure creandone di personalizzati) sono gestiti all’interno della stessa piattaforma a cui si è affidiato il Product Backlog, e dopo il necessario refinement possono essere spostati con un semplice ricollocamento nella specifica area di riferimento. 

basket azure 2b

 Spostamento degli Item

Questa scelta, però, porta con sé alcune limitazioni, tra cui quella più evidente è la difficolta nel raccogliere informazioni non strutturate, spesso quelle primarie con cui ci si confronta quando si comincia a parlare con gli stakeholder delle nuove funzionalità. A questa si lega anche un possibile side-effect metodologico: si rischia di non gestire correttamente la fase di promotion (si veda qui) da Basket Item a Product Backlog Item, spostando frettolosamente un basket item nel Product Backlog solo perché “è facile farlo”.

Una possibile alternativa è quella di utilizzare per il Basket una serie di strumenti di Office 365OneNote/Teams/Planner, per effettuare il gathering delle informazioni(OneNote), discuterne e arricchirle costantementedi dettagli al fine di renderle consistenti (Teams) e avere un primo raggruppamento con annessa priorità(Planner).

basket azure 3

 

OneNote

basket azure 4

 Teams

basket azure 5

Planner

Solo a questo punto il Basket Item, convalidata la Definiton of Ready(DoR), può essere effettivamente promosso a Backlog Item in Azure DevOps, con la creazione (manuale o, eventualmente, automatizzata attraverso un tool custom) del relativo PBI, generalmente EpicFeature.

Ovviamente, in questo caso è necessario interagire con strumenti diversi, creando eventualmente connettori per trasferire informazioni tra di loro per evitare di duplicarne l’inserimento.

Si conclude qui questa miniserie di post in cui si è dato uno sguardo all’opportunità di avere un Basket per gestire in modo proficuo le decine di richieste che possono costantemente provenire dagli stakeholder, dedicando loro la dovuta attenzione ma preservando la “salute” del Product Backlog.

 

Stay tuned J

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

@ing. Felice Pescatore