Qual è la definizione di Done per i team Agile?

In questi giorni, sembra che tutti siano incentrati sul fare le cose agili. Ciò è in gran parte dovuto alla capacità di Agile di adattarsi ai cambiamenti e incorporare il feedback dei clienti, entrambi elementi essenziali nel mondo di oggi in cui la tecnologia è in continua evoluzione e ampie quantità di informazioni sono a pochi clic di distanza, comprese le recensioni pubbliche dei clienti.

Rispondere e incorporare il feedback dei clienti nei prodotti e nei processi richiede team auto-organizzati che ottimizzano costantemente ciò che fanno per essere più efficienti, dove possono cambiare regolarmente per soddisfare le nuove esigenze che emergono ogni giorno. Quando si tratta di pianificazione del progetto, questo ambiente fluttuante può rendere le cose complicate: scadenze rigide e una serie predeterminata di risultati sono quasi inesistenti.

Quindi, se una base dell'agile funziona velocemente e cambia rapidamente e spesso, pur continuando a ripetere il progetto, qual è la definizione di fatto in agile? Quando puoi veramente dire che hai finito? Questa è una domanda interessante. Ma prima, diamo un'occhiata in più su agile e sui suoi metodi.

Come si lavora in Agile

In poche parole, agile nella gestione dei progetti sta adottando un approccio iterativo alla pianificazione e alla guida dei processi di progetto, in cui il cambiamento è incoraggiato. È dall'altra parte dello spettro rispetto alle tradizionali metodologie di gestione dei progetti, come la cascata, con le loro strutture rigorose.

Agile è un processo impostato per consentire ai piccoli team di lavorare in brevi "sprint", che li aiuta a rispondere rapidamente all'imprevedibilità del cambiamento in un progetto. I team si incontrano regolarmente prima degli sprint e dopo per adattare il modo in cui lavorano per prendere in considerazione i cambiamenti che si sono verificati nel progetto.

Correlati: modello di pianificazione dello sprint agile

È attraverso questo framework che le organizzazioni creano il prodotto che il cliente desidera e non uno che è stato progettato nel vuoto, inconsapevoli delle esigenze e delle correnti del mercato. I team possono trovare percorsi migliori per sviluppare il prodotto giusto durante il progetto perché sono in grado di ruotare secondo necessità. Ciò rende le organizzazioni più competitive, ma rende anche difficile contrassegnare qualcosa come completato quando apparentemente è presente un elenco infinito di attività di aggiornamenti delle funzionalità e altre correzioni.

La definizione di Fatto in Agile

Ora che conosciamo il contesto, affrontiamo la domanda iniziale su come determinare quando hai finito in agile. Una risposta è che hai finito quando hai finito lo sprint, che è una breve durata di lavoro durante il progetto, spesso un giorno o pochi giorni ma non più di un mese. A quel punto, il team si incontra e riflette sul lavoro svolto, su cosa è cambiato e sulla migliore linea d'azione per il futuro. C'è un piano, ma quel piano è adattato per riflettere le realtà del lavoro.

Iterazioni finali

Idealmente, dopo ogni iterazione, il progetto dovrebbe essere completato. Ma non è così spesso. Emergono cose che devono essere affrontate e fanno sì che il progetto risponda rapidamente a tali alterazioni. Pertanto, un rilascio dopo ogni sprint non è consigliabile. Ma è importante che ogni caratteristica sia completata nello sprint per tenere traccia dello stato di avanzamento del progetto.

Pertanto, essere fatto significa assicurarsi che ogni funzionalità sia completamente sviluppata, testata, disegnata e accettata dal proprietario del prodotto. Solo allora è fatto. E ci sono molti "fatti" in agile. Ma se ci sono dubbi su queste attività, allora quello sprint non è fatto e di certo non dovrebbe essere spedito.

Ciascuna funzionalità si basa sul completamento di un'altra funzionalità prima che il prodotto sia effettivamente finito e spedibile. Questo sarebbe il risultato complessivo. Tuttavia, ogni sprint ha una caratteristica che dovrebbe essere fatta dalla sua conclusione. Fatto, ciò significa che la funzione da sola può essere spedita se dovesse essere spedita da sola.

L'intero processo può essere accelerato quando il tuo team opera utilizzando un software agile. Il software agile consente ai team di collaborare quando necessario, senza perdere la concentrazione sul proprio lavoro, assicurando che le cose vengano davvero "finite". Guarda il breve video qui sotto per vedere come il software agile può aiutare il tuo team.

Differisce in base alla squadra

Ma ogni team ha la propria definizione di fatto, che è solo un altro modo per dire che i criteri in tutte le storie degli utenti sono stati accettati. Ma qualunque sia questa definizione, guida la qualità del lavoro e valuta quando una user story è completa.

In termini di sviluppo del software, fatto è quando qualcosa viene codificato secondo standard, rivisto, implementato, testato, integrato e documentato. In un contesto di servizio, ciò significa che ogni attività della storia dell'utente è completa e il proprietario del prodotto l'ha rivista e ha soddisfatto le sue aspettative.

Essere fatto in modo agile significa che il team è consapevole di ciò che ci si aspetta da loro di fornire e lo ha consegnato. Fatto è un mezzo di trasparenza. Si assicura che la qualità del lavoro si adatti allo scopo del prodotto e dell'organizzazione.

La definizione di fatto può variare?

Agile è la metodologia prevalente e il processo agile può essere eseguito con una varietà di framework. Alcuni di questi sono Scrum, Extreme Programming, Adaptive System Development, DSDM, Feature Driven Development, Kanban, Crystal e altri.

Questi processi sono modi per lavorare all'interno di un framework agile, ma hanno approcci e caratteristiche diversi che possono essere applicati al meglio a un tipo di progetto oa un altro. Sta a te decidere quale di loro è il migliore quando lavori al tuo progetto. Ciò non significa che devi sceglierne solo uno. Una combinazione di alcuni o molti potrebbe funzionare al meglio con le esigenze del tuo progetto. Questa flessibilità dell'agile e del suo processo è uno dei fattori trainanti del suo ampio e crescente appeal. Sebbene siano processi diversi all'interno di agile, aderiscono tutti alla stessa definizione di fatto.

I principi sono costanti

Agile esiste dal 2001, quando un piccolo gruppo ha creato il Manifesto Agile in risposta agli approcci tradizionali alla gestione dello sviluppo del software. Il manifesto ha delineato le idee di base che sono presenti in ogni quadro agile. I quattro pilastri principali del manifesto sono:

1. Concentrati sugli individui e sulle interazioni piuttosto che su processi e strumenti
2. La creazione di un software che funzioni è più importante della documentazione completa
3. La collaborazione con i clienti è più importante della negoziazione del contratto
4. Il processo segue il cambiamento invece di un piano

Ci sono anche 12 principi di sviluppo software agile. Questi principi alimentano la nostra comprensione di quando un'attività o un progetto è veramente svolto:

1. La soddisfazione del cliente viene fornita fornendo costantemente software di valore
2. Le modifiche ai requisiti sono sempre accettate, indipendentemente dall'inizio o dalla fine del progetto
3. Il software che funziona viene consegnato in tempi più brevi
4. Sviluppatori e professionisti aziendali devono collaborare quotidianamente durante tutto il progetto
5. La comunicazione faccia a faccia è la cosa migliore
6. I team motivati ​​derivano dalla creazione di una cultura di apprezzamento, fiducia e responsabilizzazione
7. Il progresso è misurato dal software funzionante
8. Il processo agile promuove lo sviluppo sostenibile
9. L'agilità è supportata dall'attenzione alla qualità nello sviluppo tecnico e nel design
10. La gestione agile si basa sulla semplicità
11. La migliore architettura, requisiti e design provengono da team auto-organizzati
12. Le squadre sono più efficaci quando riflettono e si adattano

Agile al di fuori dello sviluppo software

Sebbene Agile sia nato nel mondo dello sviluppo software, di recente si è esteso al più ampio mondo degli affari. Le idee di apprendimento agile, snello e organizzativo si sono spostate al di fuori della ristretta cerchia dello sviluppo software, con aziende di ogni tipo che utilizzano la definizione delle priorità delle riunioni stand-up e la gestione visiva.

Agile non è mai stato inteso semplicemente come uno strumento di gestione dei progetti IT. Le tecniche di agile possono cambiare il processo di gestione in altri progetti aziendali. Usare il pensiero agile per cambiare i progetti di gestione è un esempio che funziona molto bene.

Alcuni aspetti dell'agile che possono essere utilizzati nei progetti aziendali includono i backlog, che sono le funzioni e le caratteristiche che faranno parte del progetto finale consegnato. I progetti primaverili o brevi all'interno del progetto sono un altro modo per applicare la velocità e l'adattabilità di Agile ad altri progetti.

Un altro è il concetto di team interfunzionali, che consentono la comunicazione per una migliore efficienza. L'integrazione continua aiuta anche con la trasparenza tra i diversi aspetti del progetto, il che porta a una maggiore efficienza. Ci sono anche radiatori di informazioni, sviluppo iterativo e incrementale, riunioni Scrum, timeboxing, casi d'uso, storie di utenti e molto altro ancora. Tutte queste cose aiutano le aziende a fare le cose in un modo diverso dalla tradizionale metodologia a cascata.

Per avere la trasparenza e la collaborazione necessarie per lavorare in un ambiente agile, dove tutti sanno cosa significa fatto e quando il team è effettivamente fatto, sono necessari gli strumenti giusti. ProjectManager ha una dashboard in tempo reale e funzionalità di pianificazione che vengono alimentate con le metriche man mano che si verificano, quindi tutti i membri del team sono sulla stessa pagina. Scopri come può aiutarti a fare le cose in modo più efficiente utilizzando questa prova gratuita di 30 giorni.