Sourcebook - ca.com · Valutazione delle stories 10 20 modi per suddividere le user stories 11 ......

Costruire un business AgileSourcebook

Team AgileA questo livello un team responsabile, capace di organizzarsi e gestirsi autonomamente, è in

grado di fornire ogni due settimane aggiornamenti incrementali del software di alto livello

e completamente testati.

Riunione quotidiana 4

Pianificazione delle iterazioni 5

Agenda di pianificazione delle iterazioni 6

User stories 8

Valutazione delle stories 10

20 modi per suddividere le user stories 11

Pattern per la suddivisione delle user stories 12

Definizione degli obiettivi 14

ca.com/it3 | CoStruiSCi il tuo buSineSS Agile

Esperienza maturata su Agile

Focus sul valore" Agile fornisce vantaggi a vari livelli, ma la novità più importante è data dal fatto che induce l'intera azienda a concentrarsi sulla delivery di prodotti di valore ai clienti. Anziché affidarsi a metriche indirette per descrivere la qualità e i progressi del software, ci domandiamo 'Qual è la percentuale di funzionalità critiche inclusa in questa release?' L'importanza del valore percepito dal cliente influisce notevolmente sul ciclo di vita dell'intero progetto."Vice Presidente di Infrastructure Management bMC Software

https://www.linkedin.com/company/ca-technologies

http://blogs.ca.com/

https://twitter.com/CAInc

http://www.ca.com/it


Chi? • team di delivery

• responsabile del prodotto

• Scrum master

• le parti interessate

possono osservare ma

non intervenire

• non si tratta di una

riunione sullo stato per il

responsabile del prodotto

Quando?tutti i giorni, alla stessa ora,

nello stesso posto e con le

stesse persone. Costituisce

un impegno fisso nell'agenda

di tutti i partecipanti.

la riunione dura al massimo

15 minuti.

Preparazionei partecipanti riepilogano

i risultati positivi e gli

ostacoli incontrati il giorno

precedente. ricorda di tenere

sempre a disposizione il

grafico con le proiezioni

lineari (burndown)

come riferimento.

Processila riunione deve essere sempre di breve durata. Possono parlare solo i membri del team.

tutti i membri del team devono rispondere a turno alle seguenti domande:

• Che cosa ho fatto ieri?

• Che cosa ho intenzione di fare oggi?

• Che cosa mi impedisce di raggiungere gli obiettivi?

• Che cosa ho imparato da ieri a oggi?

Risultatila riunione quotidiana informale consente ai membri del team di modificare come necessario

i piani della giornata e ottenere aiuto per superare gli eventuali ostacoli. Durante la riunione

quotidiana informale non viene risolto alcun problema. Se ci sono problemi da risolvere, il team

chiude la riunione informale e inizia un'altra riunione espressamente dedicata a tale attività.

Team Agile

Riunione quotidianaOgni giorno i membri del team partecipano a una breve riunione quotidiana informale

(standup) per discutere dei propri impegni. Durante la riunione i membri del team

verificano come procede il lavoro sull'iterazione, adattano i piani e chiedono aiuto

per superare gli eventuali ostacoli.






Team Agile

Pianificazione delle iterazioniDurante la riunione di pianificazione delle iterazioni il team si impegna a completare

le attività prioritarie del backlog di prodotto. Tali impegni definiscono il backlog

dell'iterazione.

Prima di cominciare il team ha valutato gli elementi inclusi nel

backlog di product e ha assegnato gli story

point relativi.

le voci del backlog di prodotto sono ordinate

in base alla priorità stabilite dal responsabile

del prodotto.

i criteri di accettazione di tali voci di backlog

classificate devono essere compresi da tutti.

Determinazione della capacitàla capacità del team viene calcolata a partire

dai seguenti parametri di ciascun membro

del team:

1. numero di ore teoriche nella

giornata lavorativa

2. giorni dell'iterazione per cui saranno

disponibili i singoli membri

3. Percentuale di tempo che ogni persona

intende dedicare al team

Fasi della pianificazione

1. il responsabile del prodotto illustra la voce di backlog.

2. il team identifica i task necessari per completarla.

3. i membri del team si propongono come responsabili dei task.

4. i responsabili dei task stimano il numero di ore teoricamente necessario per completarli.

5. la pianificazione continua finché il team non raggiunge la capacità necessaria.

Se in fase di pianificazione una determinata persona supera la propria capacità, il team collabora per ottimizzare la distribuzione del carico.






Team Agile

Agenda di pianificazione delle iterazioni

1. Apertura Scrum master

2. roadmap e visione del prodotto Scrum master

3. Stato dello sviluppo, stato dell'architettura in uso e risultati delle

iterazioni precedenti

responsabile

del prodotto

4. nome e scopo dell'iterazione team Agile

5. Velocità delle iterazioni precedenti Scrum master

6. tempistiche dell'iterazione (date e giorni lavorativi) Scrum master

7. Capacità del team (disponibilità) Scrum master

8. Problemi e perplessità team Agile

9. revisione del lavoro svolto e aggiornamento sulla situazione Scrum master

10. Stories/elementi del backlog di prodotto da considerare team Agile

11. Assegnazione dei task: task, stime, responsabili responsabile

del prodotto

12. nuovi problemi e perplessità team Agile

13. Dipendenze e presupposti Scrum master

14. impegno Scrum master

15. Pianificazione di comunicazioni e logistica team Agile

16. Area di parcheggio Scrum master

17. Pianificazione delle attività Scrum master

18. riepilogo dei punti salienti Scrum master

Chiusura (congratulazioni per il buon esito della riunione

di pianificazione)team Agile







La collaborazione dà buoni frutti" Il passaggio ad Agile è estremamente gratificante per i membri del team, nel senso più genuino della parola, perché la collaborazione e il lavoro che svolgono insieme conducono alla realizzazione di un prodotto di qualità superiore, dotato di funzionalità appropriate."Vice Presidente per lo sviluppo McKesson






Team Agile

Storie degli utentiLe user stories sono unità di delivery incentrate sul valore, che vengono tipicamente

utilizzate nei progetti Agile. Le user stories spiegano cosa è necessario fare e perché,

nell'ottica del cliente o delle parti interessate.

Chi? il protagonista (chi) di una

user story è in genere una

persona con un ruolo o titolo

specifico, oppure un utente

ipotetico di cui vengono

illustrati in dettaglio

i comportamenti

e le esigenze.

Cosa?l'argomento (cosa) di una

user story specifica

l'esigenza da soddisfare

oppure la caratteristica o la

funzionalità desiderata dal

protagonista (chi), che il

team dovrà integrare nel

software o nel servizio.

Perché?la motivazione (perché) di

una user story ne specifica

il valore, attribuendo la

massima priorità alle

esigenze di utenti e clienti.

"Sono un utente registrato e desidero avere la possibilità di reimpostare la mia password, per accedere di nuovo al sito anche se me la dimentico."

"Sono un utente non registrato, ma voglio iscrivermi al sito perché desidero un'esperienza personalizzata."

"Sono Tom, e desidero visualizzare solo gli aggiornamenti degli amici più intimi, in modo da leggere solo le novità più interessanti quando mi connetto."

Modelloun modello di user story deve aiutare i responsabili di prodotto e tutte le altre figure coinvolte

a scrivere stories con protagonisti (chi), argomento (cosa) e motivazioni (perché) ben chiari:







Lasciarsi guidare" Non trascurare la formazione. Assicurati che i membri del tuo team seguano i corsi di formazione appropriati e acquisiscano familiarità con l'ambiente Agile, per partire subito con il piede giusto."Coach Agile Avaya






Perché valutare le stories?la valutazione delle stories offre l'opportuni-

tà di raccogliere le opinioni del team in

merito agli elementi inseriti nel backlog

di prodotto.

le valutazioni delle stories:

• Forniscono al responsabile del backlog di

prodotto le informazioni necessarie per

aumentare e ridurre come necessario

la priorità delle voci del backlog.

• Permettono ai membri del team di

continuare a migliorare la pianificazione

e di prevedere cosa potrebbero essere in

grado di fare in futuro.

Perché usare le stimegli esseri umani non hanno problemi

a confrontare le dimensioni, ma stimare

i valori assoluti risulta molto più difficile.

Sapresti calcolare la differenza fra 1 e 2?

e fra 33 e 34?

• le stime relative non cambiano

• Sono più rapide

• Aiutano a concordare una

valutazione accurata

• l'aritmetica è sempre una certezza:

3 + 3 = 6

Un consiglio utile: stimare per analogia"la story di richard è simile a quella di Anne, quindi la valutazione della story di richard

è uguale a quella di Anne."

Team Agile

Valutazione delle storiesGli utenti Agile utilizzano gli story point per valutare le stories. Si tratta di stime relative, che

forniscono indicazioni importanti per l'iterazione efficace e la pianificazione delle release.

164 82






Team Agile

20 modi per suddividere le user storiesdi bill Wake

Facile Difficile Perché?

Quadro generale

ricerca implementazione Cosa hanno fatto gli altri?

Spike implementazione esplorare una soluzione rapida

Manuale Automatizzato Spesso è necessario mantenere comunque una soluzione manuale

Acquisto Costruzione È possibile scegliere liberamente, confrontando il costo della personalizzazione

Costruzione Acquisto ...con quello dell'implementazione autonoma

utente singolo Più utenti Meno problemi di scalabilità, numero di account utente inferiore

Solo APi interfaccia il test può funzionare anche senza interfacce utente

interfaccia utente a caratteri o di script

interfaccia utente grafica un'interfaccia semplice permette di dimostrare i concetti

interfaccia utente generica

interfaccia utente personalizzata

l'approccio basato su "naked objects" può essere più economico

Caratteristiche

Statico Dinamico il lavoro viene svolto una volta sola e non richiede aggiornamenti

ignorare gli errori gestire gli errori il codice di errore è minimo (le eccezioni non vengono ignorate)

temporaneo Permanente Permette di concentrarsi sul comportamento anziché sulla persistenza

bassa fedeltà Alta fedeltà Qualità dei risultati (ad esempio, profondità di pixel)

inaffidabile Affidabile "l'operatività totale è molto costosa." Wm. Pietri

Piccola scala Vasta scala la capacità di carico può essere aumentata nel tempo

Meno caratteristiche Più caratteristiche i requisiti reali vengono soddisfatti in un secondo tempo

Funzioni

Poche funzioni Molte funzioni Creare poche funzioni è più semplice

Flusso principale Flussi alternativi un solo percorso facile anziché tutti i percorsi possibili

0 1 non fare nulla è più facile che fare qualcosa

1 Molti Fare una cosa è più facile che farne tante

un livello tutti i livelli un singolo livello fornisce il caso base per tutti i livelli

Caso base Caso generale il caso base è da creare, gli altri no

Per gentile concessione di bill Wake, "twenty Ways to Split Stories"http://xp123.com/xplor/xp0512






Team Agile

Pattern per la suddivisione delle user stories

Fasi del workflow Sono il responsabile dei contenuti e devo pubblicare articoli di cronaca sul sito web aziendale.

Possono pubblicare un articolo di cronaca… direttamente nel sito web aziendale con la revisione dell'editor o dell'ufficio legale.

Pattern esempio

Variazione delle regole di business Sono un utente e voglio cercare voli con date flessibili.

Compito impegnativo Sono un utente e voglio pagare il volo con la mia carta ViSA, MasterCard, Diners Club o American express.

Semplicità/Complessità Sono un utente e voglio cercare voli tra due destinazioni.

Variazioni nei dati Sono il responsabile dei contenuti e devo creare articoli di cronaca.

Metodi di immissione dati Sono un utente e voglio cercare voli tra due destinazioni.

Performance differite Sono un utente e voglio cercare voli tra due destinazioni.

operations (ad esempio, CruD) Sono un utente e voglio gestire il mio account.

Suddivisione di una spike Sono un utente e voglio pagare con carta di credito.

...ad esempio "n giorni tra x e y". ...ad esempio "un weekend di dicembre". ...ad esempio "± n giorni tra x e y".

Posso pagare con …un solo tipo di carta di credito (ViSA, MC, DC, AMeX).… tutti e quattro i tipi di carta di credito (ViSA, MC, DC, AMeX).

…specificando un numero massimo di scali.…includendo gli aeroporti vicini.…utilizzando date flessibili.

…in inglese. …in giapponese. …in arabo.

...semplicemente digitando le date.

... tramite un pratico calendario integrato nell'interfaccia utente.

… lente (l'importante è completare l'operazione, mostrando un'animazione che rappresenta la ricerca.

…in meno di 5 secondi.

…creando o annullando il mio account. …modificando le impostazioni dell'account.

… analizzando i metodi di elaborazione delle carte di credito.

… implementando un metodo di elaborazione delle carte di credito (sotto forma di una o più stories).

Per gentile concessione di richard lawrence, "Patterns for Splitting user Stories"http://agileforall.com/resources/how-to-split-a-user-story/







Prodotti pronti per la consegna" Abbiamo sempre avuto a disposizione un prodotto funzionante, e questo ci ha permesso di risparmiare moltissimo tempo. A mano a mano che ci avvicinavamo alla scadenza, aggiungevamo gradualmente al prodotto le altre funzionalità necessarie."Project manager ufficio del Censimento degli Stati uniti






Team Agile

Definizione degli obiettiviI membri del team Agile concordano le caratteristiche del software potenzialmente

commerciabile, ovvero, definiscono l'obiettivo. Tale definizione costituisce un contratto

stipulato fra il team di delivery e le parti interessate, oltre che lo standard di eccellenza

del team.

Come arrivare alla definizione degli obiettivi

1. Scrivi tutto il lavoro da svolgere per creare la release. Scrivi le singole voci su Post-it separati.

2. Disegna sulla lavagna tre aree che rappresentano l'obiettivo di una user story, l'obiettivo di

un'iterazione e l'obiettivo di una release.

3. ogni elemento deve essere inserito nella sezione appropriata, dopo aver stabilito se il team

è in grado di ultimare il lavoro entro i termini stabiliti.

Attività che non è possibile completare insieme alla story

4. Discuti gli ostacoli che impediscono al team di completare il lavoro insieme alla story.

5. Pensa in modo creativo per individuare possibili soluzioni incrementali ai problemi.

6. Se non è possibile rimuovere l'ostacolo, né eliminarlo gradualmente, registralo in un

backlog prioritario degli ostacoli.

Impegno ed esposizione dell'obiettivo

7. Metti ai voti la proposta.

8. esponi bene in vista la definizione dell'obiettivo, che dovrà costituire un promemoria

dell'impegno assunto per tutti i membri del team.

9. Continua a tornare sulla definizione dell'obiettivo, utilizzando il Kaizen (miglioramento)

e continuando ad aumentare l'eccellenza operativa del team, astraendo il lavoro dai

vincoli della release.







Condividere le competenze" Per sopravvivere dovevamo cambiare mentalità. Certo, ci vuole tempo. Ma se investi un paio di sprint in un team e riesci a raggiungere il ritmo desiderato su una determinata area del prodotto, tutti i membri potranno utilizzare anche in futuro le competenze maturate e lavorare insieme sul prodotto."Responsabile delle metodologie Agile gXS





Programmi AgileA questo livello i membri del team Agile, capaci di organizzarsi e gestirsi autonomamente,

si impegnano per la delivery continua del valore. Si organizzano in base ai flussi di valore

aziendali e si allineano per raggiungere un obiettivo comune.

Scaled Agile Framework® 17

Definizioni a livello di programma 18

Agile Release Train 19

Agenda di pianificazione delle release che coinvolgono più team 20

Ruoli a livello di programma 22

17 | CoStruiSCi il tuo buSineSS Agile ca.com/it

Scaled Agile Framework è una comprovata Knowledge base per l'implementazione delle procedure Agile su scala aziendale. l'interfaccia utente principale è costituita da un'immagine del quadro generale, in cui sono evidenziati i singoli ruoli, team, attività e artefatti necessari per scalare le procedure Agile dal team, ai team di team fino all'intera azienda.

Per ulteriori informazioni, visita il sito scaledagileframework.com

Programmi Agile

Informazioni su Scaled Agile Framework

Fonte: Scaled Agile Framework®, scaledagileframework.com





http://scaledagileframework.com



Programmi Agile

Definizioni a livello di programma

Flusso di valoreSequenza di attività con lo scopo di produrre una serie coerente di deliverable di valore per

i clienti. Questa strategia genera i massimi vantaggi economici per i clienti.

FunzionalitàA un livello superiore a quello delle stories, le funzionalità sono servizi forniti dal sistema allo

scopo di soddisfare una o più esigenze delle parti interessate. le funzionalità vengono gestite

nel backlog di programma e hanno dimensioni tali da poter essere inserite in PSi o release.

Backlog di programmaSingolo repository definitivo per tutto il lavoro che si prevede di svolgere per portare

a termina le soluzione Agile release train. Contiene tutte le attività prese in considerazione.

Potentially Shippable Increment (PSI)un PSi corrisponde a un'attività cardine, come l'integrazione e il test delle risorse software,

condiviso fra tutti i team di un programma. rappresenta una tempistica di sviluppo utilizzata

per semplificare la pianificazione, le considerazioni a livello di portfolio e la definizione

delle roadmap.

PSI/releasele release possono essere pubblicate in qualunque momento. l'azienda può decidere

di pubblicare le release con una frequenza superiore o inferiore a quella degli PSi,

o semplicemente in corrispondenza di livelli specifici degli PSi.

Architettura di massima o architectural runwaySi parla di architettura di massima quando le piattaforme dell'azienda dispongono di

un'infrastruttura tecnologica sufficiente per supportare l'implementazione degli epic di

business con la massima priorità nel backlog del portfolio, senza una riprogettazione

eccessiva che introdurrebbe un ritardo.








Programmi Agile

Agile Release TrainSviluppo cadenzato, delivery on demand

l'Agile release train (letteralmente, "treno delle release Agile") fornisce una serie continua di

release di valore incrementali in un flusso di valore, in cui lo sviluppo ottimizzato e la

strategia di delivery producono il massimo vantaggio economico.

le date sono fisse.

la qualità è fissa.

l'ambito è variabile.

1. il treno parte dalla stazione e arriva alla

destinazione successiva in base a una

pianificazione affidabile.

2. Consegna il carico ai clienti (release)

o viene utilizzato per la valutazione

interna e la verifica dei livelli

incrementali di solidità e qualità

del sistema (PSi/release).

3. Se un team Agile desidera spedire un

carico (codice, documentazione e così

via), deve caricarlo puntualmente. il

treno non va dal team, né rimane in

attesa del contenuto.

Dimensioni del treno: le dimensioni ottimali sono di 50-100 persone

backlog: include funzionalità e requisiti non funzionali

intervallo di tempo: scalabile fino a 8-10 settimane

team: include nuovi ruoli (vedi la sezione "ruoli del programma")

Principi dell'Agile Release Train








una delivery di successo include:

† una serie di obiettivi "SMArt" per i ogni singolo team.

† un piano PSi, in cui sono evidenziate le nuove funzionalità, le date di delivery previste

e altre attività cardine rilevanti.

† un voto di fiducia o l'assunzione dell'impegno da parte dell'intero programma per

questi obiettivi.

Programmi Agile

Agenda di pianificazione delle release che coinvolgono più team

Agenda: Giorno 1

8.00 - 9.00 Contesto di business Senior executive

9.00 - 10.30 Visione del prodotto o soluzione Product manager

10.30 - 11.30Visione dell'architettura e procedure di sviluppo

Cto, architetti aziendali o architetti di sistema

11.30 - 1.00 Contesto di pianificazione e pranzo ingegnere Agile release train

1.00 - 4.00 Sessioni di approfondimento per i team team

4.00 - 5.00 revisione del piano provvisorioMembri dei team, responsabili di business, parti interessate

5.00 - 6.00revisione della gestione e risoluzione dei problemi

gestione

Agenda: Giorno 2

8.00 - 9.00 Correzione della pianificazione team di gestione

9.00 - 11.00 Sessioni di approfondimento per i team team

11.00 - 1.00 revisione finale del piano e pranzo team

1.00 - 2.00 rischi del programma team

2.00 - 2.15 Voto di fiducia per lo PSi team

2.15 - ? rifacimento del piano? team

Conclusioneriepilogo della pianificazione e passi successivi

Facilitatore Agile release train/facilitatore









Scegliere i progetti giusti" Un progetto di vasta portata comporta un certo livello di rischio, ma spinge anche le persone giuste a spiegare perché occorre adottare la metodologia Agile nell'intera azienda. Volevamo dare vita a un progetto in grado di coinvolgere veramente i dipendenti. Avevamo bisogno di questo livello di interesse e dell'investimento dell'azienda. La metodologia Scrum evidenzia i problemi presenti nell'azienda, pertanto desideravamo prestare la massima attenzione a tutti gli aspetti da migliorare."Direttore, Piani e progetti speciali ChoiceHotels.com






Product Managergode di autorità sui contenuti dell'Agile

release train, oltre che sulla definizione

e l'assegnazione delle priorità nel backlog di

programma. Collabora con i responsabili di

prodotto al fine di ottimizzare la delivery

delle funzionalità ai clienti.

Architetto di sistemagode di autorità di progettazione per le

decisioni tecnologiche. Comprende le

esigenze delle parti interessate e aiuta

i team a definire e implementare una

soluzione tecnologica appropriata per

l'hosting delle funzionalità attuali e future.

Designer dell'esperienza utente

È responsabile di implementare

un'esperienza utente coerente per tutti

i team. opera a livello di programma per

fornire indicazioni di progettazione

applicabili a tutti i componenti

e all'intero programma.

Ingegnere Agile Release Train

Svolge il ruolo di uber Scrum Master a livello

di programma. gestisce lo Scrum delle

riunioni Scrum. Coordina tutte le attività

dell'Agile release train, oltre a gestire

i processi a livello di programma

e l'esecuzione del programma.

Team di sistemaÈ responsabile di fornire assistenza durante

la realizzazione e l'utilizzo dell'infrastruttura

dell'ambiente di sviluppo, oltre che durante

l'integrazione del codice prodotto dai vari

team Agile.

Gestione releaseÈ un team interfunzionale responsabile di

pianificare, gestire e regolamentare le

release sincronizzate (PSi) per tutti

i programmi o le linee di prodotti. Coordina

la delivery del software tramite il proprio

Agile release train associato.

Programmi Agile

Ruoli a livello di programma





PortfolioA questo livello, i team responsabili della strategia di business e quelli di sviluppo sono allineati.

Questi team collaborano alla stesura di roadmap realistiche e assegnano le priorità al lavoro da

svolgere, in base al relativo valore e alla misura in cui supportano la visione strategica.

Pianificazione di un portfolio strategico 25

Gestione del portfolio 27

Progettazione di un Kanban di portfoilo 29



Diventare un partner di fiducia" Ora cerchiamo di capire come collaborare più efficacemente con i clienti e aiutarli a diventare più competitivi grazie alle nostre soluzioni. Attraverso la collaborazione, possiamo comprendere più chiaramente gli interessi dei nostri clienti, e questo ci permette di costruire relazioni a lungo termine."Scrum master DevOps ge Healthcare






Portfolio

Pianificazione di un portfolio strategico per l'innovazione: Sei domande chiave

1. Pianificazione del portfolioDove desideri arrivare nei prossimi

3-5 anni? la creazione di un portfolio

equilibrato comincia con una visione.

nel mondo di oggi, una visione indica il

percorso da seguire e aiuta a concentrare

gli sforzi verso il valore. l'identificazione dei

rischi di investimento accettabili per

l'innovazione costituisce un primo passo

fondamentale, ma molte aziende non

dispongono di visibilità sull'intero portfolio,

necessaria per analizzare correttamente il

rischio, il rendimento e il valore.

2. Gestione finanziariaQuali investimenti prevedi di finanziare?

Considerando una strategia di 3-5, quali

investimenti pensi di affrontare quest'anno

per raggiungere gradualmente gli obiettivi

della strategia? identificare correttamente

le aree in cui investire, ma soprattutto quelle

in cui non investire, non è certo facile, ma

è fondamentale per lasciare fondi sufficienti

da destinare all'innovazione.

3. Gestione della capacitàDisponi di tutte le risorse necessarie per

tali investimenti? Disponi del personale,

delle competenze tecniche e degli strumenti

necessari per affrontare gli investimenti?

in caso contrario, come pensi di procurarli?

4. Gestione del valoreQuale valore prevedi di ottenere dagli

investimenti? Quando le condizioni

cambiano, ripeti la valutazione del ritorno

previsto sull'investimento? una

comprensione chiara dei risultati che

desideri ottenere ti permette di mantenere

la situazione sotto controllo. Prevedi

di accelerare, rallentare o fermati

completamente?

5. Gestione del lavoroQuali sono le attività attualmente in

corso? la comprensione delle attività

attualmente in corso e la previsione del

relativo completamento permette di

delineare la sequenza delle attività future,

al fine di ridurre al minimo gli inefficienti

cambiamenti di contesto, gli sprechi

e i disservizi.

6. Performance del portfolioLe tue pianificazioni di portfolio sono

state definite tenendo conto delle

performance precedenti? la conoscenza

empirica del lavoro svolto in passato

costituisce il miglior indicatore di

prevedibilità per il lavoro futuro in condizioni

analoghe. Conoscendo la produttività

dell'azienda, hai maggiori probabilità di

creare pianificazioni di portfolio realistiche.







Garantire la visibilità del lavoro" È fondamentale che le previsioni delle release siano visibili al responsabile del prodotto perché in questo modo, quando aggiungiamo funzionalità a una release, sappiamo cosa fare per aggiungerla o a cosa dobbiamo rinunciare per includerla. Queste decisioni sono fondamentali per il nostro business e, soprattutto, ora sono determinate da una discussione in gruppo nella fase iniziale del processo."Project Manager Market Force






Portfolio

Trasformare la gestione del portfolio con il Lean thinking

gestione del valore • i modelli finanziari tradizionali ostacolano l'innovazione

• i budget troppo elevati determinano comportamenti eccessivamente prudenziali

•i vantaggi si concretizzano in ritardo •le priorità vengono attribuite in modo soggettivo ed emotivo

gestione del valore • i modelli di valore economico sostengono l'innovazione • Assumendosi alcuni piccoli rischi è possibile favorire la creazione del valore • i vantaggi si concretizzano più rapidamente, in modo graduale • le priorità vengono attribuite in modo obiettivo ed esplicito

Vecchio metodo Nuovo metodo

gestione della capacità • Vengono assegnati dipendenti full-time specializzati ai progetti al fine di massimizzare l'utilizzo delle risorse • la continua riorganizzazione dei team di progetto determina una perdita di competenze • Pianificazione decisamente scorretta della capacità, basata sulla disponibilità oraria dei dipendenti full-time

Pianificazione del portfolio • Processi di approvazione per grandi blocchi • Finanziamento ad-hoc degli investimenti • Cicli di pianificazione infrequenti e a compartimenti stagni

Performance del portfolio • Metriche basate su tempi e budget • ritardi di delivery scoperti a posteriori • Stato di avanzamento soggettivo • revisioni infrequenti e soggettive

gestione della capacità • il lavoro viene incanalato attraverso team interfunzionali per massimizzare la delivery del valore • i team permanenti conservano le competenze acquisite • la pianificazione della capacità è abbastanza corretta, grazie ai team interfunzionali

Pianificazione del portfolio • Flusso continuo con blocchi più piccoli • Finanziamento degli investimenti allineato alla strategia • Assegnazione delle priorità secondo modalità collaborative e iterative

Performance del portfolio • Metriche di valore del cliente • informazioni basate sui fatti, ottenute dallo stato dei lavori in tempo reale • livello dimostrabile di incrementi di valore e alta qualità • Feedback frequente e obiettivo

gestione del lavoro • Documenti estesi per i requisiti • release eclatanti ad alto rischio • Struttura di suddivisione del lavoro • Modifiche divergenti dalla strategia

gestione del lavoro • realizzazione puntuale delle funzionalità indispensabili • Prodotto minimo funzionante (MVP, Minimal Viable Product) • Apprendimento convalidato • Allineamento alla strategia in evoluzione

gestione finanziaria • l'ambito, la pianificazione e il budget fissi inibiscono la creatività • Cicli di finanziamento lunghi • Sforamento dei costi

gestione finanziaria • Privilegiando gli ambiti di massimo valore, è possibile ottenere proiezioni più precise di costi e pianificazioni • Cicli di finanziamento incrementali • Controllo dei costi tramite ambiti minimi







Essere flessibili" Dimentica per un attimo quello che stai facendo, prenditi del tempo e preparati a lasciarti stupire dai risultati ottenuti da un team di professionisti esperti impegnati in una sessione di pianificazione. Ti sentirai pieno di energia, nuove idee ed entusiasmo, che potrai trasmettere alla tua azienda."Responsabile della gestione dei progetti leica






Portfolio

Come progettare un Kanban di portfolioLe aziende Agile possono utilizzare i sistemi Kanban a molti livelli diversi. Ad esempio,

un Kanban di iniziative può fornire i presupposti per un Kanban di funzionalità, che a sua

volta viene utilizzato da un Kanban a livello di story per il team.

ecco alcune opzioni:

Kanban di iniziative o progettiConsigliato per i team che utilizzano per la prima volta un

Kanban di portfolio. un'iniziativa è una serie di attività con

criteri di riuscita chiaramente definiti, che uno o più team

può completare in pochi mesi.

Kanban di funzionalità o miglioramentiConsigliato per le aziende con release frequenti. Fornisce un

livello di Kanban aggiuntivo sotto quello dell'iniziativa.

Kanban di implementazione, contenuto o progetti di servizi professionaliConsigliato per accelerare il completamento di contenuti

o studi e ridurre l'overhead di coordinamento.

KANBAN DI INIZIATIVE

KANBAN DI FUNZIONALITÀ

KANBAN DI TEAM (STORY)

Per ulteriori informazioni sulla realizzazione di un business Agile,consulta i toolkit Agile all'indirizzo ca.com/agile





http://www.ca.com/it/why-ca/agile-management.html

CA technologies (nASDAQ: CA) crea software che promuove l'innovazione all'interno delle aziende, consentendo loro di cogliere le opportunità offerte dalla application economy. il software rappresenta il cuore di qualsiasi business, in ogni settore. Dalla pianificazione allo sviluppo, fino alla gestione e alla sicurezza, CA technologies lavora con le aziende di tutto il mondo per cambiare il nostro modo di vivere, interagire e comunicare, in ambienti mobile, cloud pubblici e privati, distribuiti e mainframe. Per ulteriori informazioni, visita il sito ca.com/it.

Copyright © 2015 CA technologies. tutti i diritti riservati. tutti i marchi, i nomi commerciali, i marchi di servizio e i logo citati nel presente documento sono di proprietà delle rispettive società. CS200-161610

1 bill Wake, "twenty Ways to Split Stories", http://xp123.com/xplor/xp0512

2 richard lawrence, "Patterns for Splitting user Stories", richardlawrence.info/splitting-user-stories

3 Scaled Agile Framework®, scaledagileframework.com

Entra in contatto con CA Technologies all'indirizzo ca.com/it

www.slideshare.net/cainc


https://plus.google.com/+CATechnologies/posts


https://www.youtube.com/user/catechnologies

https://www.facebook.com/CATechnologies


www.ca.com/it

www.ca.com/it

http://xp123.com/xplor/xp0512

http://richardlawrence.info/splitting-user-stories/



Sourcebook - ca.com · Valutazione delle stories 10 20 modi per suddividere le user stories 11 ......

Documents

Transcript of Sourcebook - ca.com · Valutazione delle stories 10 20 modi per suddividere le user stories 11 ......