xebir logopsm pspo  cdacda consortium  safe sixsigma yellow belt mini cal1 mtsless cert agileiot logo  ac2 logo

Agile e Robotic Process Automation (RPA), parte 2 – Il ruolo del PO

Ed eccoci arrivati allo start del primo Sprint!

Dopo aver dedicato alcuni incontri a parlare di Agilità, soffermandoci sui Valori e sui Principi, e aver illustrato il framework Scrum (come detto scelto a livello Corp), il team è pronto per iniziare a sperimentare sul campo e costruire il primo draft di Product Backlog.

Bisogna dire che l’obiettivo complessivo era quello di automatizzare tramite RPA 6 processi con diversi livelli di complessità e che, mediamente, essi interessavano almeno 3 sistemi di gestione differenti. Il grande vantaggio nella fase di Inception è stato quello di avere un neo-PO estremamente esperto di ogni singolo processo, in grado di descrivere in modo minuzioso ogni step relativo e il set di dati fondamentali.

[Prima Considerazione] Ecco quindi una prima considerazione rispetto al tradizionale ruolo di PO: essendo l’obiettivo dell’RPA l’automazione della mimica relativa ad un processo, non si ha nella sostanza un utente utilizzatore, ma solo un “committente” che si aspetta un lavoro finito.

po role reponsability

La validazione di quanto realizzato può essere fatta confrontando i risultati di ogni step con quelli analoghi fatti da un operatore umano (subFlow), o valutando l’intero flow.

Il PO, in questo scenario, non si occupa di formalizzare needs funzionali (sotto forma di Storie o altro), ma, più che altro, è un esperto di processo/dominio/data in grado di descrivere una sorta di flow chart (activity diagram) che consente di suddividere adeguatamente i passi costituente del processo.

Potremmo dire che è più un Process Owner che un Product Owner.

po rpa

Tornando al nostro Product Backlog, è stato deciso di identificare ogni processo da automatizzare come “prodotto” differente, dotato quindi di uno specifico Product Backlog. Per ogni prodotto sono state create una serie di Technical Story (lo so, qualcuno storcerà il naso, ma noi abbiamo ritenuto giusto così) in relazione agli step di avanzamento del processo, individuandone gli aspetti caratterizzanti primari:

  • Sottosistemi coinvolti
  • Dati in ingresso attesi (tipologia e set campione per il test)
  • Dati in uscita attesi (tipologia e set campione per il test)
  • Gate di ingresso 
  • Gate di uscita

Quando la prima versione del Product Backlog è stata completata, il team si è trovato difronte alla necessità di scegliere su quali Tech Story ingaggiarsi nel primo Sprint. In questo caso, non avendo una “storia passata”, si è optato per lasciare allo stesso la scelta di un numero di storie che ritenevano “aggredibili”, senza impiegare tempo in stime o pesi che non potevano avvalersi di alcuna esperienza pregressa e rimandando la “prima pesatura” a consuntivo.

Ogni Tech Story è stata suddivisa, durante il successivo Sprint Plannig, in Task di dettaglio, in cui sono state esplicitate le attività di implementazione e le differenti aree di sviluppo tecniche interessate. Quest’ultimo aspetto è stato fondamentale per gestire la pluralità del team (come descritto nel primo post della serie) e calibrare la loro permanenza in-house, non necessariamente di 5gg a settimana.

Completato il tutto, il team ha cominciato a lavorare sulle singole Technical Stories, adottando la strategia Serial-and-Parallel: il team avvia la prima Storia e lavora in parallelo sui Task di dettaglio e solo in caso qualcuno sia scarico si avvia la successiva Storia, altrimenti ci si concentra sul finirne una alla volta. In tal modo si riduce sensibilmente il rischio di avere troppe Storie avviate e finite solo parzialmente a fine Sprint.

Anche qui è stato riscontrato subito un punto dolente: il rispetto delle priorità indicate dal Product Owner (e implicitamente dal processo). I membri del team hanno ritenuto opportuno rivederle più volte per sbloccare situazioni di stallo dovuto a condizioni tecniche abilitati.

[Seconda Considerazione] Da qui una seconda considerazione operativa: la priorità delle Technical Story è implicitamente dettata dal flow del processo e deve essere possibile rivederla liberamente senza vincoli, in funzione delle esigenze di sviluppo. Quindi non è più utile che sia nelle more del PO!

Detto questo, il team ha utilizzato le canoniche due settimane, allineandosi giornalmente nel classico Daily, per completare quante più Technical Story possibili, con una presenza attiva del PO per rispondere a problematiche di processo/sistema/dati.

Volete sapere com’è andata? Beh.. non vi resta che attendere il prossimo post della serie.

Stay tuned J