Consegnato una volta, il rischio di rilavorazione finale è maggiore

La domanda non cambia frequentemente e i tempi di consegna non sono fissi.

Adattati ai cambiamenti dei clienti e consegna una volta

Andare online rapidamente per conquistare il mercato, ma potrebbe richiedere molte rielaborazioni

ovvero il ciclo di vita adattivo

Combinazione dei vantaggi dell'incrementalità e dell'iterazione

Può adattarsi all'ambiente in evoluzione dei clienti e raccogliere il feedback dei clienti in piccole iterazioni

È possibile avviare piccole iterazioni

Adattati rapidamente ai cambiamenti e raggiungi rapidamente il mercato

abbraccia il cambiamento

continuare a migliorare

Come utente, in quel momento/luogo, cosa voglio fare e per quale scopo/valore commerciale?

Quindi, come faccio/come opero?

Come verificare alla fine

Prima dell'inizio del lavoro, non è necessario creare tutte le storie dell'intero progetto, ma solo il contenuto principale del primo piano di rilascio.

L'elenco delle cose da fare cambia e migliora costantemente e può essere aggiornato, aggiunto, eliminato, modificato, modificata la priorità, ecc. in qualsiasi momento

Enormi storie di utenti, chiamate anche storie epiche, sono scritte in fondo al backlog

Definizione di user story completata: 0/1 legale, completata o non completata

Se non sai da dove iniziare con i requisiti, la mappa dell’impatto può essere utilizzata come input efficace per il backlog

Contenuto: ordinare l'elenco dei requisiti attuali del prodotto, inclusa l'assegnazione delle priorità e la suddivisione in schede della storia con granularità moderata, ecc.

Tempo per la riunione di preparazione: discussione di 1 ora per lo sprint di due settimane

La relazione tra il grooming meeting e lo sprintplanning meeting: lo sprint Planning meeting può iniziare solo quando il product backlog grooming meeting è completato

La stima dello story point è una stima multipla;

Velocità del team: la quantità di lavoro completata dal team per unità di tempo

Media dei punti della storia completati per sprint

Gli story point sono un modo per misurare la dimensione e la complessità delle storie degli utenti, non la loro durata

I piani di progetto tradizionali sono misurati in ore, giorni e settimane

Realtà: per evitare stime imprecise o promesse eccessive, lo stimatore alla fine ti fornirà un intervallo di tempo

Non devi preoccuparti dell'accuratezza del preventivo. Mettiti al lavoro velocemente

I team non confondono le stime con gli impegni

Stima del poker

Stima della maglietta

Stima della dimensione dell'affinità

M: Deve farlo

S: dovrebbe andare bene

C: si potrebbe fare

W: non lo farò

Bisogni primari: must (sviluppo prioritario)

Esigenze prestazionali: più sono, meglio è (fare il più possibile)

Bisogni di piacere: elevata soddisfazione

Divisi in 100 punti a persona, potranno utilizzare questi punti per votare per i bisogni più necessari

Sulla base del giudizio del cliente, stima per massimizzare il valore del prodotto

Continua a suddividere le storie degli utenti in attività

I membri del team determinano la divisione delle attività

Cosa ho fatto dopo l'ultimo stand-up?

Cosa dovrei fare dopo questo incontro stand-up?

Quali ostacoli, rischi o problemi ho incontrato sul lavoro?

Scheda attività Srccum

bruciare il grafico

Grafico di accensione

grafico del burndown del rischio

Kanban

Scheda Kanban e scheda attività

Il team dimostra le funzionalità completate durante lo sprint

Tutti i membri del team sono tenuti a partecipare

Tutti possono essere invitati a partecipare

PO è responsabile dell'accettazione o del rifiuto delle storie

Una linea guida generale è quella di presentare il prodotto del lavoro del team almeno una volta ogni due settimane. Questa frequenza è sufficiente per la maggior parte dei team in modo che i membri del team possano ricevere feedback che impediscano loro di andare nella direzione sbagliata.

Cosa hai fatto bene in questo sprint?

Cosa possiamo fare meglio in questo sprint?

Quali aree possiamo migliorare nel prossimo sprint?

Trova dati qualitativi (sentimenti delle persone) e quantitativi (metriche).

Utilizzare questi dati per trovare la causa principale

Progettare contromisure e formulare piani d'azione

Scopo dell'incontro: Non è colpa di questo, il ripasso è permettere alla squadra di continuare a migliorare

Focus: il team discute insieme le priorità e concentra gli sforzi dove sono più necessari (è sufficiente concentrarsi su alcuni miglioramenti)

Le conclusioni dell'incontro dovrebbero essere tracciate in un ciclo chiuso: possono essere inserite nel backlog del prodotto, determinare i risultati della misurazione di ogni miglioramento e verificare se ogni miglioramento ha successo.

Integra spesso il lavoro nel tutto

Le informazioni end-to-end utilizzano test a livello di sistema: un test dell'intero sistema

Utilizza il test unitario per gli elementi costitutivi: ispeziona e verifica la più piccola unità testabile nel tuo software

Test di integrazione del sistema: sulla base dei test unitari, tutti i moduli vengono assemblati in sottosistemi o sistemi in base ai requisiti di progettazione

Test del fumo: una strategia di test e verifica funzionale di base rapida per i pacchetti di versioni software durante il processo di sviluppo del software

Test di regressione: dopo aver modificato il vecchio codice, ripetere il test per confermare che la modifica non abbia introdotto nuovi errori o causato la generazione di errori da parte di altro codice.

Test automatizzati: automazione dei test del software

Il team discute insieme i criteri di accettazione per il prodotto di lavoro

Il team crea test automatizzati per soddisfare i requisiti standard

TDD: prima di sviluppare il codice funzionale, scrivere prima il codice del caso di test unitario. Il codice di test determina quale codice di prodotto scrivere.

BDD: utilizzare il linguaggio naturale o un linguaggio simil-naturale per descrivere e scrivere casi di test dal punto di vista degli utenti funzionali scrivendo storie di utenti o casi d'uso degli utenti.

Rileva situazioni sconosciute in sistemi, tecnologie e aree di applicazione

Utile per l'apprendimento, utilizzato quando il team ha bisogno di apprendere alcuni elementi tecnici o funzionali chiave

Il debito tecnico è causato da team che prendono intenzionalmente decisioni tecniche inadeguate per un guadagno di progetto a breve termine.

La soluzione è il refactoring e la modellazione agile

Due programmatori lavorano insieme su un computer, uno digita il codice mentre l'altro rivede ogni riga di codice che inserisce. La persona che inserisce il codice è chiamata conducente e la persona che rivede il codice è chiamata osservatore (o navigatore). Due programmatori spesso si scambiano i ruoli

Qualsiasi membro del team ha il permesso di modificare qualsiasi codice, proprietà e responsabilità dell'intero team

Vengono fornite diverse opzioni di metodo agile in base alle due dimensioni della dimensione del progetto e della criticità del progetto. Ad esempio: C6, D6

Stabilire un elenco di funzionalità, scalare e progettare in base alle funzionalità

Stabilisci costi, qualità ed eventi fin dall'inizio, quindi sfrutta la definizione delle priorità formali nell'ambito per soddisfare questi vincoli

Prendendo l'architettura come nucleo centrale, concentrandosi sulla progettazione del database ed enfatizzando la comunicazione con gli utenti

Una tecnica utilizzata da due o più Scrum Team anziché da un unico Scrum Team di grandi dimensioni, in cui un team contiene da 3 a 9 membri per coordinare il proprio lavoro

Concentrarsi sul dettaglio di pratiche, ruoli e attività a livello di portfolio, progetto e team. Enfasi sull'organizzazione dell'azienda focalizzata sulla fornitura di un flusso continuo di valore ai clienti

Un framework Scrum multi-team che può essere applicato a team agili composti da 20, 100 o addirittura migliaia di persone, che lavorano tutte insieme su uno specifico prodotto condiviso

Un framework progettato per applicare la metodologia Scrum attraverso un'organizzazione più olistica piuttosto che attraverso singoli livelli di sviluppo prodotto

Un quadro decisionale di processo che integra molteplici best practice agili in un modello completo

Fattori che influenzano il cambiamento

Come creare una cultura organizzativa agile

PMO agile

fornitore

Consegna rapida e riuscita

Una squadra che ha già caratteristiche agili

posizione geografica

Struttura funzionale

Dimensioni del successo dei deliverable del progetto

Assegnazione del personale di progetto

Organizzazione pesante per gli acquisti

Caratteristiche della disponibilità al cambiamento: volontà del management, consapevolezza dei dipendenti, capacità di talento, ecc.

Caratteristiche delle rimanenti barriere al cambiamento

Supporto gestionale attivo e chiaro

Utilizza l'esperienza di gestione del cambiamento per guidare

Promuovere pratiche agili progetto per progetto

Introduzione incrementale

Dimostrare e guidare tecniche e pratiche agili

Realizzare la consegna del valore del progetto

Aiuta i clienti a realizzare valore in modo rapido ed efficiente pensando e mettendo in pratica alcune idee e prospettive innovative

Acquisire familiarità con conoscenze che vanno oltre la gestione stessa del progetto per soddisfare le diverse esigenze di supporto del progetto