JAMCHAT AGILE QuestionS &AnSWERS - pmi-nic.org · JAMCHAT AGILE 20 Aprile 2017 – Questions & Answers 2 Topic Product Owner - Ruolo, task, strumenti e perchè è fondamentale! Tutte

20 Aprile 2017

PMI® NOTHEN ITALY CHAPTER – BRANCH LOMBARDIA

JAMCHAT AGILE QUESTIONS &ANSWERS

JAMCHAT AGILE 20 Aprile 2017 – Questions & Answers

1

Sommario Premessa ....................................................................................................................................................... 1

Topic Product Owner - Ruolo, task, strumenti e perchè è fondamentale! Tutte le domande sul Product

Owner, gli strumenti, il Contract Game tra PO e Team. Soprattutto perchè è un ruolo fondamentale e

spesso sottostimato ...................................................................................................................................... 2

Topic Transizione verso Agile! Tutte le domande, opzioni, dubbi, esperienze del diventare Agile ............. 7

Topic PLM/ERP e Sistemi Enterprise! Tutte le domande sull'applicabilità dell'approccio Agile ai sistemi

enterprise .................................................................................................................................................... 15

Topic User Story! ......................................................................................................................................... 16

Premessa

Un grazie a tutti quelli che hanno partecipato a questa prima esperienza di Jam Chat sul tema Agile.

Siamo soddifatti di aver creato un evento che ha consentito a molti di voi, più di quanto non succeda nei

classici eventi, di esprimersi liberamente e di entrare in contatto con i nostri esperti, Dario Morandotti,

Giuio Roggero, Luca Sturaro, Emiliano Soldi e con altri soci in modo diretto e aperto. Ù

Certamente un’esperienza migliorabile, ad esempio, per consentire anche ad altri che hanno partecipato

di potersi inserire nelle conversazioni ma sicuramente a nostro (e, stando ai primi feedback, anche a

vostro) avviso interessante.

Nella foga del dibattito alcune domande erano rimaste senza risposta. Abbiamo cercato di rimendare

rispondendo, pur brevemente, in questo documento.

La JAM CHAT nella sua natura un po' “JAM” non è di facile lettura nel corso della sessione, lo scopo di

questo documento è, quindi, quello valorizzare il patrimonio di scambio, tracciando il dibattito secondo

una sequenza logica che parte dalla domanda principale e si evolve nello sviluppo della questione.

Dario Morandotti e Graziella D’Amico

Direttori PMI Northen Italy Chapter

Branch Lombardia


2

Topic Product Owner - Ruolo, task, strumenti e perchè è

fondamentale! Tutte le domande sul Product Owner, gli strumenti, il

Contract Game tra PO e Team. Soprattutto perchè è un ruolo

fondamentale e spesso sottostimato

1. LI Che differenza c'è tra Product Owner e Business Analyst?

Luca Sturaro: il Business Analyst non è il PO. In ottica Scrum il Business Analyst

dovrebeb essere un team member (so che molte implementaizoni mettono BA=PO)

LI: Uno dei compiti del PO è quello di prioritizzare le feature nel Product Backlog. Le feature

con valore di business più elevato dovrebbero essere sviluppate con precedenza rispetto

alle altre. Ora, la mia domanda è: come il PO dovrebbe misurare il valore in termini di

business che una feature ha rispetto ad un'altra? Cosa si intende esattamente per "valore

di business"?

VC: Il valore di business di una feature nella mia esperienza è sempre stato legato a un

ritorno a breve e medio termine inteso come realizzo o fatturazione. Addirittura

chiamavamo le features "cbo" = Customer Business Opportunity

Emiliano Soldi: Ciao VC, il valore di business può essere diverso da organizzaizone ad

organizzazione da progetto a progetto da prodotto a prodotto Potrebbero essere le

revenue, riduzione dei costi, miglioramento delle share di mercato, ecc. Spesso nella

prioritizzazione delle feature valutiamo business/user value, criticalità temporale, risk

reduction

Dario Morandotti: Aggiungo anche io qualche commento.

Fondamentale stabilire a priori delle metriche come detto da Emiliano (costi, revenue,

ecc) che esplicitino il valore per il business.

2. FE: Cosa succede quando più Product Owner insistono sullo stesso Team e le risorse sono

insufficienti a coprire gli sprint? Suggerimenti per le negoziazioni?

Emiliano Soldi: Normalmente esiste solo un PO per team.

3. DT si può avere una definizione di Product Owner? Grazie


3

Dario Morandotti: La definzione piu' classica e' "il rappresentante del business" e quindi

il "possessore del prodotto"

Giulio Roggero: l Product Owner è responsabile di descrivere il prodotto catturando i

bisogni di business e utente e aiutare il team a tradurli in modo chiaro ed efficace per

l'implementazione

Qui trovi una sintesi https://www.slideshare.net/GiulioRoggero/introduzione-a-scrum-

53424608/5

DT: quindi il PO è l'interfaccia è il responsabile del Prodotto (a tutto tondo) verso il Cliente

(interno o esterno)?

Emiliano Soldi: esattamente il PO è la voce del cliente, raccoglie i needs, li prioritizza,

lavora continuamente in ottica di fare trade-off tra prodotto, performance del team

DT: perfetto, grazie, se è così cosa lo differenzia dal PM? l'orientamento esclusivo al

Prodotto?

Emiliano Soldi: esatto di fatto scrum distribuisce le duties e responsabilità tra PO, Scrum

Master e Team di sviluppo e il PO è completamente orientato al prodotto. Questo evita

sovrapposizioni e conflitti di interesse

Luca Sturaro: Il PO è per definizione orientato al prodotto, tipicamnete è un uomo di

"business" che parla con il cliente e che ha potere decisionale su cosa mettere nel

prodotto....Di solito è un Senior Product Manager a contatto con il cliente (se volessimo

usare la terminologia standard)

4. DB: Relazione tra Customer e Provider: Rischi ed opportunità quando il PO è del Customer

Giulio Roggero: Il PO è del Customer quando il budget del progetto è sotto controllo del

Customer (ad esempio progetto fatto con risorse interne oppure in time and material).

PO è del Fornitore quando il budget è responsabilità del Fornitore (ad esempio in

progetti chiavi in mano). Se il PO è del Customer e il progetto è a prezzo fisso allora ci

sono i problemi...

https://www.slideshare.net/GiulioRoggero/introduzione-a-scrum-53424608/5

https://www.slideshare.net/GiulioRoggero/introduzione-a-scrum-53424608/5


4

5. LI: il PO partecipa allo standup meeting?

VC: si dovrebbe

LI: al fine di? con quale scopo?

Luca Sturaro: Certo, anzi è una buona regola, così il business è sempre in contatto con i

tecnici e può aiutarli, fare mentoring e far capirre perchè quella fetuare è più

importante di un'altra....

Emiliano Roggero: Il PO non è obbligatorio che partecipi, di fatto scrum identifica come

obbligatoria la presenza del development team, lo scrum master non è obbligatorio ma

consigliato

LI: ok, ma può fare domande o è semplicemente un auditor?

Dario Morandotti: In alcuni progetti lo abbiamo fatto partecipare in modalita' "silent"

(solo ascolto), in modo che sia informato

Luca Sturaro: tendenzialmente lo stand-up è per il Team, sincronizzazione replanning.

Può fare domande dopo, ma durante lo stand-up è più facile che il team faccia domande

a lui/lei (PO)

LI: ok, immagino quindi che quindi unica cosa che può fare dopo aver ascoltato è

ripioritizzare il backlog per lo sprint successivo. Mi sembra che il PO non possa cambiare le

priorità durante lo sprint in corso, può farlo solo a fine sprint. corretto? nel caso di soluzioni

complesse, il PO può nominare anche un feature owner ed un component owner?

Dario Morandotti: IL PO puo' avere degli aiuti, dal Busyess Analist o piu'

frequentemente dei Proxy-PO (facenti le veci) o per area o per feature. C'e' flessibilita' a

seconda di cosa permette l'organizzazione e dell'engagement del business

Luca Sturaro: Yes, riprioritizzare il backlog ma anche per esempio vedere le storie su cui

il team fa più fatica (e che magari non completa) per poi aiutarli a tagliarle in maniera un

po' più "smart" (alle volte possono essere spezzate con una differente granularità). Per il

fetaure owner, direi che l'introduzione di ulteriori ruoli potrebbe introdurre conflitti e/o

inibire la "trasparenza"

LI: ottimo, questo chiarisce molto! Ma allora il PO potebbe anche stabilire il "wip limit" del

Kanban/Task Board in modo da individuare i bottleneck ovverossia le feature che risultano

meno chiaro/piu difficili da comprendere/sviluppare da parte del Dev Team? in sostanza, il

PO può stabilire i wip limit o modificarli a suo piacimento o no?

Emiliano Soldi: Il continuous improvement del processo di sviluppo è a carico

primariamente del dev team e sicuramente dello scrum master.


5

LI: condivido in parte con Emiliano in quanto ritengo che in fin dei conto un prodotto

potrebbe essere migliorato continuamente all'infinito, pertanto è il PO che stabilisce

quando il Dev Team deve fermarsi dal CI altrimenti si brucerebbe tempo/budget a

deperimento di altre feature

Emiliano Soldi: Il PO gestisce il budget, effettua i forecast mettendo in relazione la

velocity del team con le stime delle feature/storie del product backlog e quindi è in

grado di guidare lo sviluppo del team in questo modo, non lavora nel limitare

direttamente il wip nella kanban board del team

LI: E’ corretto dire che il PO ha potere decisionale sul prodotto/solution mentre il BA è

privo di qualsiasi potere decisionale?

Emiliano Soldi: Certamente il PO è accountable sulle decisioni di prodotto in termini di

prioritizzazione, raccolta dei bisogni e trade-off, mentre il BA è molto più focalizzato

sull'analisi di come trasformare quel bisogno in processo e facilitare lo sviluppo della

soluzione da parte del team

Dario Morandotti: Si Luca. Il PO ha "the last word" sulle user story e sulla loro priorita'

nel Product Backlog all'ingresso dello Sprint Planning.

Tuttavia il Team sulla base di considerazioni tecniche e di fattibilita' puo' variare questo

ordine. Il BA e' piu' un consulente del PO e del Team - ruolo fondamentale!

VC: Io quando devo sapere se siamo in linea rispetto alle Roadmap lo chiedo al PO. Se non

partecipa allo standup meeting come può essere aggiornato?

Emiliano Soldi: Il PO dovrebbe lavorare su base giornaliera con il team di sviluppo.

Dovrebbe accettare le storie non appena questa diventano done by team e quindi

essere a conoscenza degli avanzamenti. manifesto e guida scrum consigliano di avere il

PO colocato con il team e questo gli da molta visibilità dei progressi

LI: Qual’è la relazione tipica che un PO ha con lo SCRUM Master?

Emiliano Soldi: Difficile standardizzare. In linea teorica lo Scrum Master fa coaching al

PO per aiutarlo a lavorare sul backlog, a interpretare bene i suo ruolo cerniera con il

business, capire come prioritizzare e lavorare con il team

LI: ottimo, grazie. Ma il PO se ha qualche problema di "comunication" o interazione con il

dev team, potrebbe rivolgersi al Master per eventuale risoluzione di conflitti/gestione delle

aspettative?


6

LI: è compito del PO effettuare il knowledge transfer del prodotto finito? realizzare

materiale di training, sessioni, lecture etc etc insomma fare in modo che utilizzatori finali

sappiano usare la solution (ovviamente parlo di soluzioni complesse, non di App intuitive)

Emiliano Soldi: Solitamente il PO ha la responsabilità di gestire anche la parte di

enablement del prodotto sul mercato. ovviamente è "tanta roba" e potrebbe/dovrebbe

farsi aiuare da marketing e/o HR e/o sales department. Dipende ovviamente dalla

complessità

Luca Sturaro: bella domanda! Direi che questo dovrebbe essere parte della Definition of

Done del Team....Non darei questo incarico al PO....Ma tutto può accadere

LI: wow! questa della definzione del DONE è una ottima idea! Si potrebbe dire che è DONE

quando l'end user sa effettivamente utilizzare la solution in modo corretto. Lanciamo un

ponte con UAT et aldella solution e dell'organizazione di riferimento

Luca Sturaro L'idea è che il Team deve concordare cosa significa "FATTO", una semplice

lista "condivisa ed accettata" che definisce quando una Storia può essere considerata

"fatta", conclusa. Di solito quando si parla di "fatto" non abbiamo tutti la stessa

opinione.

LI: condivido pienamente! se non sbaglio però SCRUM definisce "done" ciò che è

potenzialmente deliverabile al cliente (unica differenza è che effettivamente non lo

deliveriamo...ma "è come se lo fosse"

6. FE: Relazioni tra PO e Team Leader?

Dario Morandotti: FE per Team Leader intendi lo Scrum Master?

FE: in azienda stiamo sperimentando una metodologia Agile chiamata DAD che prevede

Product Owner e Team Leader

Emiliano Soldi: DAD, interessante! come la state applicando?

LI: DAD sta per?

FE: Disciplined Agile Delivery: è un pelo più "strutturato", un pò process driven, ma

completamente devoto ad agile

FE: Come la stiamo applicando? Siamo appena agli inizi...abbiamo ridefinito ruoli e team

per applicare in maniera estesa l'Agile....Per questo chiedevo se qualcuno ha già esperienze

di questo genere


7

Emiliano Soldi: DAD norma piuttosto bene non solo la fase di construction (delivery) ma

molto bene anche le fasi di envisioning, inception e transition...tutto sempre in ottica

Agile

7. AM: Quale è la relazione/differenza tra Product Owner e Product Manager?

Luca Sturaro: Il PO potrebbe essere un Senior Product Manager con responsabilità di

budget, prodotto, delivery e con contatto con il cliente... Qualche guru di agile dice:

<<PO is a MiniCEO>>

8. CT: C'e' sovrapposizione tra ruolo di SM e PM o collaborazione?

9. FA Cosa deve fare e cosa NON deve fare il PO durante l'esecuzione degli sprint? cosa può invece

fare?

Topic Transizione verso Agile! Tutte le domande, opzioni, dubbi,

esperienze del diventare Agile

10. VC: Agile nello sviluppo software. Nella mia azienda da alcuni anni è stata introdotta la

metodologia Agile nella software factory, per le gestione dello sviluppo del codice. L'impressione

che ho riscontrato è una maggiore velocità nei rilasci di nuove release o patch (dato positivo) ma

anche il moltiplicarsi dei livelli di patch, per cui non fai in tempo a installare presso il cliente una

release che è già obsoleta (dato negativo). Avete avuto esperienze simili?

Giulio Roggero: quando si sviluppa a incrementi automatizzare è fondamentale.

Altrimenti incorri nel problema che hai riscontrato. Continuous integration, delivery e

deploy sono importanti.

Luca Sturaro: Sei fortunato ad avere questo problema! Direi che il fatto di avere a

stretto giro (Sprint) software funzionante non significa che deve essere rilasciato al

cliente ogni iterazione. Se non si è interessati alla "continuous delivery", si può tagliare la

relase ogni X Sprint.

VC: é vero che non devi rilasciare al cliente il risultato di ogni sprint, ma se devo dare retta

al mio cliente "non si installa nessuna patch se non ci sono problemi" se invece devo dare

retta al mio R&D "occorre mantenere aggiornato il livello di patching per facilitare la

maintenance scusate se parlo da PM frustrato dalle iterations


8

11. SZ: Collegato alle tematiche di valutazioni e budget qual è il ruolo del portfolio manager

nell'ottica Agile ?

Giulio Roggero: é quello di ridurre il numero di progetti in parallelo

12. MV: All'interno dell'azienda collaboro con fornitori esterni per l'ottimizzazione di sistemi già in

essere: l'applicazione della metodologia Agile è sottintesa, ma spesso non applicata in modo

corretto. Volevo sapere se qualcuno ha esperienza nell'organizzazione di workshop dedicati per

l'high management, per averli a bordo anche nell'approccio progettuale, spiegando i principi

base della metodologia.

Giulio Roggero: Ciao M, è possibile organizzare workshop da 1 giornata o mezza

giornata per far toccare con mano i problemi tipici delle organizzazioni di progetto e

come questi possano essere affrontati con metodi agili

13. GP: Agile al di fuori dello sviluppo software. Esistono esperienze di transizione verso metodologie

Agile di aziende di servizi TLC sia per progetti/programmi gestiti per clienti che internamente per

sviluppo nuovi prodotti ?

Luca Sturaro: certo esistono implementazioni di Scrum per esempio in ambito Hardware

(Scrum for Hardware: Joe Justice è uno dei guru), applicazioni in ambito marketing ed

HR (Kanban più che Scrum). Nel caso di servizi per TLC potrebbe essere utile dare un

occhio a Kanban, soprattutto se hai fornitori esterni, stakeholders non co-locati...

Emilio Roggero: di che tipo di prodotti stai parlando? Per esperienza il software è

pervasivo e spesso è quello che da problemi. Esistono anche tansizioni agili su progetti

puramente hardware.

14. CM: Agile nello sviluppo software. Lavoro presso un System Integrator e stiamo aiutando un

cliente a lavorare in Agile (Scrum). Uno dei punti fondamentali che non siamo ancora riusciti a

sciogliere in modo adeguato è: come definire il budget necessario per un progetto? Da approccio

"purista" le stime dei backlog item possono essere fatte in Story Point; ma prima di aver definito

in modo accurato ed adeguato tutti i backlog item quale approccio può essere utilizzato per

determinare quanto costerà un progetto o quanti Story Point totali servono per realizzare quanto

viene richiesto in un progetto?


9

Giulio Roggero: usa due metodi di stima: stima della velocità in storypoint e confrontala

con una stima in giornate con PERT.

CM: Ok, quindi se ho ben inteso, prima devo avere una stima in giornate; quindi

determinare un rapporto tra ggu/story point e quindi ottenere il numero di sprint e il

budget. Mi chiedo allora quale sia l'approccio AGILE nel determinare la stima in giornate

(penso di poter escludere approccio Bottom-Up) e mi chiedo anche in che modo posso

determinare un rapporto tra ggu/story point se ancora non ho una storia (se sto

determinando il budget non ho ancora fatto degli sprint)?

Giulio Roggero: No aspetta, non fare una relazione tra giornate e story points

"L'approccio Agile" è non stimare ma misurare il valore man mano che rilascio. Però se

devi definire un budget vuol dire che devi fare un'ipotesi e su quella ti basi facendo una

stima in giornate e in euro del progetto. Una volta che hai il budget inizi lo sviluppo e

capisci, man mano che vai avanti, se stai nel budget o devi fare delle modifiche al

backlog semplificando o togliendo.

CM: Ok, chiaro. Al momento ci stiamo muovendo proprio in questo modo; mi chiedevo se

esistesse qualche altro approccio. Ma quando dici "misurare il valore man mano che

rilascio" ci stiamo riferendo al valore di business o agli story point? Mi sembrano 2

dimensioni differenti o sbaglio? Gli story point non determinano una sorta di "complessità"

di quello che realizzerò nello sprint?

Giulio Roggero: mi riferisco al valore di business. Come scrivi tu gli SP sono misura della

complessità. Potresti anche non usare gli story point e contare semplicemente le storie.

Gli story point e la velocità sono un supporto per capire come sta andando il progetto e

capire se quello che mi sto prendendo in carico riesco a farlo. Non prenderli come dei

KPI. La cosa più semplice è: definisci un budget, descrivi un backlog, fai una roadmap e

capisci se ci stai dentro. Se gli SP ti aiutano usali, se non ti servono non usarli. Fino a

quando non inizi a riliasciare valore verso l'utente è difficile capire se effittavemente stai

rispettando il budget.

CM: Ok. Ma ancora qualcosa non mi è chiaro. Definisco budget: fatto; descrivo backlog:

fatto (iterativamente, raffinandolo man mano che mi avvicino allo sprint in cui affronterò le

storie); fai una roadmap: fatta ma in realtà non so quanto sia accurata; abbiamo provato a

buttare degli SP sulle epiche e provato ad immaginare gli n sprint futuri; capisci se ci stai

dentro: se la roadmap è giusta allora ok; ma se ho sottostimato un epica? Soprattutto

all'inizio la nebulosità è elevatissima...Paradossalmente potresti aver fatto il progetto

perfetto ma il prodotto più inutile del mondo


10

Giulio Roggero: CM se è nebulosa è nebulosa. Hai due opzioni: chiarirla prima di partire

oppure partire con la consapevolezza che man mano chiarirai la cosa. L'opzione 1 è

come chiedere se pioverà fra 1 mese. Molto probabilmente non lo sai oggi, però ti sforzi

di stimarlo perchè il cliente te lo chiede. L'opzione 2 è: non so quanto costi, però ho

capito i benefici che vuoi ottenere facendola. Fissiamo un budget e vediamo con quel

budget dove arriviamo. Più piccolo è il budget più piccolo è il rischio. Quando l'ho

chiarita allora posso dirti quanto costa

CM: Ok grazie. La difficoltà ovviamente sta nel definire il minimo budget (per mantenerlo

piccolo) sufficiente a realizzare quel tot di prodotto che abilita il cliente ad ottenere i

benefici sperati. Ero alla ricerca della "bacchetta magica" Speravo nell'esistenza di un

qualche tipo di approccio strutturato (o almeno più strutturato di quello che stiamo

utilizzando) nell'arrivare a definire questo budget.

Dario Morandotti: CM, Ti metto qualche commento sulla mia esperienza, non pretendo

sia generalizzabile. Un metodo e' quello di fare budget per release, listare tutte le user

story in ordine di priorita' e, sulla base della velocita' predicibile da esperienze passate

con un certo team, predirre con quel budget quanti points di rilasceranno. Non c'e'

certezza ma ho osservato che c'e' buona indicazione e con l'accumularsi di esperienze si

possono fare previsioni affidabili.

Giulio Roggero: Dario, funziona se hai progetti paragonabili e lo stesso team. Gli Story

Point non sono una stima assoluta

Giulio Roggero: CM se hai progetti ricorrenti è facile, ma se hai progetti nuovi la

soluzione è partire con un range di stima e poi ridurre man mano il range di incertezza. Il

messaggio che deve passare è: il budget lo spendiamo per massimizzare il risultato. Ho

fatto diversi progetti chiavi in mano con penali da diversi anni uomo con questo

approccio e il risultato è stato positivo perchè ha portato il cliente a bordo facendogli

capire che lui ha in mano il budget.

CM: Si infatti, seguo 2 team su 2 progetti diversi, stesso cliente, tecnologia simile ma

architettura differente e vedo 2 passi abbastanza diversi.

Giulio Roggero: in molti casi io non uso gli story point e conto le storie. La velocity la uso

come indicazione e mi interessa più lo scostamento tra quanto nello sprint mi sono

impegnato di fare e quanto completo come done. Una regola del pollice è: se lo

scostamento è più del 20% allora il processo è fuori controllo e non stiamo capendo

cosa fare o ci sono dei problemi di interruzioni impreviste elevate o di bassa qualità in

produzione. Con questa indicazione puoi fare delle stime a capienza di sprint

mettendoci dentro le epiche e contare: N sprint per X FTE a Sprint e hai un budget.


11

CM: Uhm, però diciamo che ci sono storie un pò più semplici e storie un pò più

complesse...dal mio punto di vista gli SP mi aiutano a "normalizzare" un pò queste

differenze tra storie. E' anche vero che il numero di storie da sprint a sprint non varia poi

così tanto. Poi sulla formula "N sprint per X FTE a Sprint" siamo perfettamente allineati.

Ovviamente significa avere già tutte le storie scritte ad un certo tempo t.

Giulio Roggero: fai una prova e verifica lo scostamento in % degli sprint passati dei tuoi

team tra commited e done. Fai il calcolo sia con gli SP sia con il numero di storie. Ti

accorgerai che la differenza tra le due è sotto il 10%, molto probabilmente sotto il 5%

Giulio Roggero: La dimensione delle storie incide non tanto. Ovviamente

tendenzialmente si fanno storie piccole. Se metti dentro epiche non funziona

15. PM: Mi potete consigliare tre argomenti/concetti/slogan ad effetto da utilizzare per convincere il

management che il modello di sviluppo Agile è meglio dal classico Waterfall? Grazie

Giulio Roggero: non è necessario convincere con uno slogan ma con numeri alla mano.

Sarebbe interessante capire perchè consideri Agile meglio di Waterfall nel tuo contesto?

Quali vantaggi vedi? Sono traducibili in numeri di business?

GS: Dai un'occhiata al Manifesto for Agile Software Development, lì troverai l'essenza dei

principi e degli slogan, scegli poi tu quali usare che si adattano Matteo posso indicarti

direttamente http://agilemanifesto.org

PM: Purtroppo nella nostra organizzazione lo sviluppo software è visto come un fardello(lo

sviluppo è relativo al software utilizzato in-house) ed il management non è particolarmente

attento a queste problematiche; abbiamo già fatto documenti/note ma senza attirare

l'attenzione. Da qui la mia richiesta di slogan che possono catturare l'attenzione.

MV: Ciao GS, ottime slides

PM: Vero, anche se alcuni punti sono pericolosi da dichiarare al Business Mi riferisco

principalmente all'accogliere cambiamenti in fase avanzata di sviluppo che in caso di grandi

organizzazioni fortemente burocratizzate è tutto da dimostrare.

GS: No Matteo, l'accogliere cambiamenti in fase avanzata sottosta comunque a delle

regole. Ed in ogni caso è meglio un cambiamento necessario in fase avanzata che seguire

un piano di sviluppo che porta ad avere un prodotto non funzionantea.

MV: Matteo, mi sono trovato spesso nella situazione opposta. Avere i cliente sempre così

assetati di novità, spesso fa perdere di vista i benefici relativi all'implementazione. Per

quello che credo che sia fondamentale diffondere la cultura Agile in modo quasi pervasivo,

potrebbe essere un vantaggio per tutta l'aziend

16. FA: Qualcuno ha esperienze di Agile nello sviluppo hardware?


12

Giulio Roggero: Si Francesco, ho lavorato in aziende meccaniche per lo sviluppo di

prodotti hardaware

FA: come gestivate i tempi di sviluppo dell'HW rispetto alla durata degli sprint che

dovrebbe essere limitata?

Giulio Roggero: Con due flussi: firmware e software sprint da 2 settimane e

sincronizzazione con gli sprint per la parte hw e meccanica

Dario Morandotti: Ciao F. Si ci sono delle esperienze, limitate, sullo sviluppo di ASIC.

Qualche buon successo ed qualche lezione appresa su impedimenti. Le trovi facilmente

su internet oppure mando io link - appena lo trovo

17. DB: L’agile nelle grandi organizzazione finanziarie, dove il Change Management è “tarato” su un

approccio tradizionale waterfall.

Come può un progetto Agile essere efficace considerata le diverse regole stringenti su “processi”

correlati allo sviluppo? (Eg Release Management)

Dario Morandotti: Occorre analizzare caso per caso – come per ERP – e stabilire se nel

processo o applicazione c’è del valore in rilasci iterativi sia dal punto di vista delle

funzionalita’ sia dal punto di estensione utenti (es. si inizia con una regione e poi si

estende). La domanda chiave da porsi è: come posso sviluppare e rilascare del valore in

modo rapido e poi incrementalmente? Il Release Management merita discorso a sé

stante, ci sono varie tecniche per renderlo rapido ma cerrtamente occorre considerare

regole esterne o finestre di opportunità

18. EL: Aggiungo una domanda correlata ad esperienza lavorative: com'è possibile far coesistere

l'agile in progetti che devono sottostare alle regole del Nuovo Codice degli Appalti?

GS: Il progetto Agile può essere efficace all'interno della struttura tradizionale waterfall,

con quest'ultima si definiscono i macro obiettivi ma la modalità con cui perseguirli diventa

agile e quindi permette di dare enfasi all'ottenimento del risultato e meno al formalismo

GS: In ogni caso temo che in organizzazioni fortemente burocratizzate e formalizzate sia

difficile applicare metodologie agili in modo semplice e diretto. Penso che sia comunque da

definire una struttura di progetto tradizionale all'interno della quale si applicano

metodologie agili negli ambiti più creativi o dove il raggiungimento dei progetti non è

formalizzabile in modo chiaro e preciso a priori. Vi ricordo che le metodologie agili sono

nate principalmente dalla consapevolezza che il waterfall falliva perché cercava di applicare

i concetti della catena di montaggio (dove tutto è chiaro e predefinito a priori) ai processi


13

creativi come lo sviluppo software dove invece le cose si evolvono, si chiariscono, si

scoprono, ecc. in modo molto più flessibile e meno definito

EL: Concordo. In effetti non capisco se sia corretto considerare come agile il continuous

improvement, come alcuni fanno..

Dario Morandotti: GS, Agile piu' focalizzato ma certamente con le iterazioni si rifa' alla

filosofia di continuo improvement

Sergio Cuniolo: GS, Verissimo. Questa è una "confusione" che ho trovato anch'io,

soprattutto in grandi aziende

Luca Sturaro: GS, è vero che organizzazioni molto burocratizzate ma soprattutto con

una struttura organizzativa complessa hanno più difficoltà ad applicare Agile. Detto

questo, dipende come si vuole implementarlo, nel senso che non è obbligatorio (e

sarebbe molto difficile) provare ad applicarlo sull'organizzazione intera....Tenderei a

partire da una struttura più piccola (un dipartimento, una BU...)

Giulio Roggero: EL come mai ti poni la questione sulla correttezza di considerare agile

continuo miglioramento?

Sergio Cuniolo: Se ho capito bene EL, il problema è l'opposto ovvero considerare il

continuo miglioramento come agile

EF forse sbaglio, ma non è l'unica prerogativa dell'agile, ovvero il continuous improvement

sussiste anche nella gestione dei progetti normali...

Giulio Roggero: EL, non è condizione sufficiente ma è necessaria. Senza continuo

miglioramento (e continuo non è la Lesson Learned a fine progetto ma è regolare

durante il progetto) non parlerei di agile. Miglioramento continuo dei processi e dei

prodotti grazie a piccoli passi

GS: Suggerisco la lettura di "The New Methodology"

https://www.martinfowler.com/articles/newMethodology.html di Martin Fowler, uno dei

fondatori delle metodologie agili, in cui è ben descritto il percorso che ha portato a queste

metodologie, e lì si capisce meglio come dev Emilio LanfranchiThu 7:15pm

EF: grazie del consiglio, a prima occhiata sembra un articolo ben fatto. grazie!

19. GA Qualcuno ha esperienze di introduzione di Agile methodology per SW e per Process

development in grandi multinazionali?

Emiliano Soldi: si ho lavorato in multi-nazionali che hanno introdotto approcci di

sviluppo prodotto lean-agile, qual'è la tua esperienza ?

Luca Sturaro: sì io in ambito TLC, ora medicale.....


14

Giulio Roggero: Si puo dire che negli ultimi anni è più difficile trovare chi non fa Agile nel

SW che viceversa

Luca Suraro: verissimo Giulio!

GS: Occhio, bisogna poi vedere se applica davvero metodologie agili o se fa finta

Giulio Roggero: GS dove sta la "verità" dell'applicare o meno agile? Eviterei di parlare di

vero agile e falso agile. Se si cerca di migliorare i propri processi e prodotti per me è

agile

GS: No Giulio, migliorare i propri processi è... migliorare i propri processi. Già da un po' di

affermazioni che si vedono qui si capisce che si cerca di piegare o interpretare la

metodologia agile con metodologie di project management. Le metodologie agili volevano

dare maggiore importanza alla relazione tra cliente e programmatori con l'obiettivo di

consegnare software funzionante, dando meno enfasi alla documentazione e ai formalismi

FA: GS quali sono i segni che ci dicono che si sta lavorando Agile? come ne possiamo

esserne consapevoli?

Giulio Roggero: GS, Agile per me non è una metodologia ma un cambio culturale,

orientato al continuo miglioramento. Cambio culturale che coinvolge sia i processi ma

anche come i prodotti sono realizzati. Attenzione ai bisogni dell'utente finale

mettendolo al centro del processo di sviluppo, attenzione alla relazioni tra i colleghi e

l'obiettivo di massimizzare il valore di tutto il ciclo e non solo di quello di sviluppo

software. Non semplificherei agile con il solo secondo valore dell'agile manifesto. La

documentazione è importante, è come la documentazione viene fatta che cambia: ad

esempio spostandosi dai documenti di desgin tecnico al clean code

GA noi lo stiamo introducendo in società di TLC (Orange) solo molto recentemente e

stiamo riscontrando molti problemi dal punto di vista "culturale", perchè richiede un

cambio di mentalità "notevole..."

Emiliano Soldi: Avete un approccio alla gestione del cambiamento Change Management

per lavorare su cultura, comunicazione, training e coaching?

GA: si e ci stiamo muovendo sopratutto in questo senso che su grossi progetti veri e propri

avete consigli su quale tipo di training sarebbe consigliabile per chi si approccia a queste

tematiche?

20. RP: Quanto deve essere di dettaglio un Project Plan in Agile? E' possibile determinare il percorso

critico?


15

Luca Sturaro: il critical path è un concetto molto legato al PM tradizionale nel senso che

hai bisogno di una timeline (WBS, GANTT) definita upfront (a priori)....Il convcetto non è

mappabile banalmente in Agile

21. GP: Sono praticamente nuovo all' Agile avresti dei riferimenti da darmi?

Dario Morandotti: vari riferimenti, articoli e libri ampiamente disponibili in internet, tra

cui segnalo “Agile Principles, Agile people - GAMA-Tech.pdf”

22. A: l'Agile Scrum previene lo "Scope creep"? se si, in che modo?

Dario Morandotti: certamente, data la natura iterativa ed di continua redifinizione

dell’approccio. Lo scope in Agile può ineretemente cambiare (all’interno di un’area di

scopo definita) se i Product Onwer ed il Team definiscono che alcune user story (vecchie

o nuove) hanno più valore e quinid maggiore priorità.

23. GP: Esistono metodologie per la stima dei labor costs di un progetto in Agile?

Dario Morandotti: la domanda nasconde diversi aspetti. Se intende la stima dell’effort ci

sono diverse metodologie. Occorre tenere presente che in Agile spesso, o quando

possibile, i costi di sviluppo/test/rilascio sono noti a priori perche’ si tede a lavorare con

team stabili che quindi hanno un costo stabile predicibile nel tempo (es. per mese).

Mentre e’ lo scopo – cioe’ la quantita’ di user story e rilasci che il team riuscira’ a

produrre – che all’inizio non e’ facilmente predicibile ma lo diventa dopo alcune

iterazioni , osservando la velocita’ di sviluppo/rilascio.

Topic PLM/ERP e Sistemi Enterprise! Tutte le domande sull'applicabilità

dell'approccio Agile ai sistemi enterprise

24. VC: Quando i clienti per cui lavoro sono grandi aziende, specialmente se straniere, ormai l'unico

modo per essere operativi anche come PM di servizi/tecnologia è attraverso i loro sistemi ERP.

Per lavorare sul progetto in corso presso un importante operatore telefonico tedesco, mi hanno

dato un computer (con tastiera tedesca!) con gli applicativi integrati nei loro sistemi. L'approccio

non è Agile in senso stretto, ma piuttosto basato su workflows predefiniti, dipendentemente dal

tipo di attività


16

25. La domanda è se altri PM di aziende che forniscono servizi/tecnologia hanno la stessa esperienza

di dover essere parte integrante (e integrata!) dei loro sistemi ERP.

Dario Morandotti: la domanda non e’ del tutto chiara.

Topic User Story!

26. MF: per le user story si segue uno schema formalizzato?

Dario Morandotti: Questo e' un costrutto classico su cui si possono fare variazioni

As a ... Role

I want ... Function

So that ... Value

Acceptance ... Criteria

27. MF: Qual è il livello di dettaglio o altro criterio con cui puoi giudicare una user story ben

formalizzata?

Dario Morandotti: Si Massimo, ci sono dei criteri usabili. Alla fine e' il Team che

risponde se la user story e' completa e chiara

Emiliano Soldi: le user story hanno livelli di dettagli diversi a seconda del momento in

cui sono raccolte, introdotte nel backlog e vengono "masticate" in corso d'opera con

apoproccio iterativo e incrementale.

Una story deve essere INVEST. Link per dettagli su INVEST www.ideato.it/technical-

articles/user-stories-una-guida-pratica

Indipendente dalle altre, negoziabile in termini di fattibilità tecnica, valuable che abbia

valore, estimable (stimabile), Size properly sufficientemente piccola per essere

introdotta in uno sprint e testable

Infine una user story deve essere "specchiata", accompagnata da criteri di accettazione

che permettano al team di sapere come svilupparla e come quella storia verrà poi

testata e approvata dal PO

Dario Morandotti: Fondamentale la "specchiatura" cioe' la definizione dei criteri di

accettazione - spesso chiariscono alcuni dettagli stessi della user story

http://www.ideato.it/technical-articles/user-stories-una-guida-pratica

http://www.ideato.it/technical-articles/user-stories-una-guida-pratica


17

28. PL: Qual'e' la relazione e la differenza tra User Story e Scenario?

Emiliano Soldi: Intendi Scenari di Test ?

PL: Ciao Emiliano, forse ricordo male, ma oltre alle user stories vengono sviluppati anche

degli Scenari che raccontano casi reali, non da una prospettiva di ruolo. Almeno questa era

la mia interpretazione.

Emiliano Soldi: Esistono diverse tecniche che aiutano ad approfondire la journey che gli

utenti dovranno sviluppare nell'uso del prodotto. Vengono create le personas che

rappresentano le tipologie di utenti che approcceranno al sistema, con le personas

applica una tecnica chiamata user Story mapping che permette di verificare quali attività

e task l'utente dovrà eseguire quando utilizza l'applicazione

PL: Forse è solo un problema di termini (mapping). Ho cercato adeso in rete e ho trovato

questo con delle indicazioni:

https://softwareengineering.stackexchange.com/questions/113381/whats-the-difference-

between-use-case-user-story-and-usage-scenario/113384 . Probabilmente mi manca

qualche elemento per capire le entità e la relazione tra di loro. La sento ancora fumosa

Giulio Roggero: Hai visto DDD e Event Storming ?

PL: Francamente non mi ricordano nulla. Grazie per il suggerimento

29. AM: The user stories also can be used while creating test scenarios?

Emiliano Soldi: Usually the user storY and its acceptance criteria guide the creation of

test scenario

AM: thank you for the answer, then with the user stories, every sprint have acceptance

criterias and test scenarios.

Emiliano soldi: Exactly every user story is mirrored by acceptance critera which guide

the development itself and also the development of the test scenarios and the test

automation too

30. CT come avviene il backlog refinement, chi lo scrive e lo aggiorna?

Dario Morandotti: Come noto il backlog iniziale, cioè le user story ben definite (vd.

“costrutto” citato qualche domanda sopra sopra) e messe in ordine di priorità, è compito

del Product Owner. Può avvalersi per costruirlo di Business Analyst, esperti, rappresentanti

del business e degli utenti. Tuttavia le user story vanno presentate discusse con il Team (dis

viluppo, test, rilascio) e raffinate per le parti che non sono chiare, che non hanno valore ben

definite, che non hanno criteri di approvazione, o che hanno impatti tecnici che il team vede


18

(caso comune) ma non il PO, ecc.

Il refinement è quindi fatto sia del PO sia del Team.

Alla fine però le user story sono sempre nella mani del Product Owner che ne è il

responsabile – perchè sono dei very requirement s e descivono come deve essere il

prodotto finale. Certamente il PO può avvalersi anche del Team per scriverle, e può dare

anche ampia delega, ma la responsabiità è del PO. Da cui la difficoltà del ruolo.

JAMCHAT AGILE QuestionS &AnSWERS - pmi-nic.org · JAMCHAT AGILE 20 Aprile 2017 – Questions & Answers 2 Topic Product Owner - Ruolo, task, strumenti e perchè è fondamentale! Tutte

Documents