Agile Project Management, come valutare e stimare i costi del software

Linee guida essenziali per effettuare una stima realistica dei costi del software in attività di Agile Project Management

Agile Project Management: di cosa parliamo?

Una delle cose più difficili nell’Agile Project Management è determinare tempi e costi di consegna per il nuovo software. Ma davvero è così complesso come sembra? La nostra azienda in quanto Software House ti può rispondere facilmente.

La stima dei costi dei software su misura è un lavoro che richiede più considerazioni, e alcuni azzardano nel prevedere risultati assoluti. Non esistono due progetti uguali tra loro: ognuno è unico per gli obiettivi e i parametri che lo compongono. Spesso, quello che appare un problema superficiale è molto più difficile o tecnicamente impegnativo da implementare nella realtà. E, senza dubbio, ci saranno “incognite” che possono essere identificate solo quando si presentano nel corso del progetto.

Scrivere software di qualità è il pane quotidiano degli ingegneri senior, proporre software selezionati è per chi desidera qualcosa di più standardizzato ma la creazione di prodotti software può essere un’impresa molto più difficile per tutti gli altri soggetti coinvolti.

Approccio agile nello sviluppo prodotto: fornire un software eccezionale è una questione di equilibrio

Conoscere tempi e costi è fondamentale per prendere decisioni strategiche nelle attività di Agile Project Management. E questo vale sia per le startup in fase di avvio, sia per chi vuole realizzare una nuova opportunità di business o migliorare le prestazioni aziendali.

Le tempistiche, il ritorno economico sul capitale investito e i successivi vantaggi possono fruttare, danneggiare o distruggere la tua attività. Ti chiederai: cosa otteniamo in cambio dei nostri investimenti? Possiamo prevedere i costi da sostenere? A quanto ammonta il costo sviluppo software? Quando possiamo partire? Riceveremo un prodotto di qualità in cambio del nostro investimento? Crescerà con la nostra attività? Avrà valore commerciale?

Quindi, come si fa a stimare le dimensioni, la durata e il costo di un progetto? Vediamo insieme la valutazione di un progetto Agile, il costo di sviluppo del software, e come avviene in Brain Computing.

Prezzi e stima del contratto tradizionale

Tradizionalmente, con le pratiche non-Agile, i progetti software devono spesso prevedere la correzione di funzionalità o scopi e modificare tempi e costi iniziali in corso d’opera. Questo causa alcuni problemi:

1. Come fai a sapere che la funzionalità che valuti all’inizio di un progetto è davvero quella che serve alla tua azienda o ai tuoi clienti? Più spesso, la funzionalità o lo scopo cambieranno, per cui spesso si parla di “slittamento dell’ambito”. Si tratta del risultato di bisogni iniziali che vengono identificati attraverso il ciclo di vita di un progetto e determinati come necessari o obbligatori
2. Quando il costo sviluppo software diventa una variabile, perdiamo il controllo sul ritorno sull’investimento (ROI) che stiamo cercando di ottenere. L’aumento dei costi è spesso il prodotto di rischi non preventivati, o di variazioni dei requisiti. Questo significa che serviranno nuovi membri del team per svolgere più velocemente il lavoro nello stesso lasso di tempo, o per sostenere il team più a lungo. Nessuna delle due è una buona notizia
3. Quando il periodo di tempo è variabile, perdiamo il controllo della nostra posizione nel mercato. Forse salteremo un evento importante del settore, o i nostri concorrenti ci proporranno il loro prodotto, e così viene meno il vantaggio competitivo del nostro progetto.

Esistono molti elementi legati alla variazione di tempi e costi, che risultano spesso negativi e indesiderabili.

Naturalmente, molti clienti e aziende cercano di porre rimedio ai componenti di questo “triangolo magico”. Sfortunatamente, è un tentativo quasi impossibile da realizzare. Alla fine, tutto si conclude in prodotti che non soddisfano un’esigenza, impiegano troppo tempo a fornire benefici ai clienti o costano troppo per garantire valore commerciale.

Agile Management: contratti agile per progetti software

Il costo sviluppo software è il prodotto del tempo e delle risorse umane (membri del team). Puoi aumentare tempi e costi per utilizzare più a lungo le risorse umane. Oppure puoi aggiungere risorse umane e aumentare i costi per offrire lo stesso valore commerciale. Ma queste sono prospettive da evitare. Questo è il motivo per cui la metodologia agile project management mira a definire i tempi e le risorse coinvolte, e a permettere che solo l’ambito possa diventare la componente variabile.

Quale di queste opzioni suona meglio e aumenta la fiducia degli stakeholder: il costo fisso o il costo variabile?

Naturalmente, è importante che il prodotto software mantenga le sue promesse e le esigenze dei clienti. Non è bene impiegare una quantità esatta di tempo e di denaro se, alla fine, hai un prodotto che nessuno vuole o può usare in modo efficace.

Quindi, i contratti Agile si focalizzano su quanto segue:

• Pacchetti di lavoro a prezzo fisso – L’intero progetto è suddiviso in “mini” release che contribuiscono al risultato completo del prodotto. Ogni release è un pacchetto di lavoro che viene pagato come da accordi. Una volta completato un “pacchetto di lavoro”, i successivi pacchetti di lavoro vengono rivalutati in base a quanto appreso dal precedente. Questo elimina inutili emergenze e consente al cliente di ridefinire le priorità e le funzionalità nuove o riviste.
• Conclusione anticipata – Un accorgimento che consente al cliente di terminare il progetto in anticipo, se è stato consegnata una buona parte del prodotto software e non è possibile ottenere un ulteriore ROI da un team di progetto che continuerà a fornire guadagni marginali. Questa clausola è generalmente sempre valida, almeno quando il team di progetto e il cliente hanno un rapporto di collaborazione forte, affidabile e di stretta collaborazione. Il vantaggio per il cliente è che il progetto può finire presto, dopo aver già fornito tutte le preziose funzionalità necessarie per rendere il prodotto utilizzabile. In cambio, al fornitore viene pagato il 20% del valore del contratto rimanente, in modo che possa compensare il rischio di impiegare risorse umane.
• Modifiche flessibili – Il cambiamento è un tema che scorre forte nelle vene della consegna dell’agile software. Ci aspettiamo già di non sapere tutto ciò di cui abbiamo bisogno per ottenere un prodotto sin dall’inizio. Quindi, restiamo disponibili al cambiamento, sulla base di dati e feedback pertinenti, per garantire che venga consegnato il prodotto giusto. Al termine di un processo, è possibile apportare modifiche alle vecchie funzionalità non più necessarie o prioritarie. Finché la modifica ha lo stesso valore, non ci sono ulteriori costi. Se la modifica ha un valore inferiore, ulteriori attività saranno identificate o anticipate dal lavoro rimanente. Questa clausola vale finché il team di progetto e il cliente hanno un rapporto di forte fiducia e stretta collaborazione durante il progetto.
• Lavoro extra – Nel corso di un progetto, possono essere identificate nuove funzionalità che non sarebbero realizzabili in base al contratto a prezzo fisso già esistente. Per questo, è possibile aggiungere ulteriori pacchetti di lavoro alla fine del progetto, o mantenere gli stessi tempi e materiali previsti.
• Stime circoscritte – Le stime nei contratti di Agile Project Management si distinguono in due tipologie: range di tempo o di funzionalità. Il range di tempo consente di affermare che il progetto o il pacchetto di lavoro richiederà da 12 a 16 settimane per un determinato ambito di applicazione. Tuttavia, l’ampliamento della durata aumenterà i costi, ogni volta che i membri del team vengono impiegati più a lungo del previsto, perché non possono essere utilizzati per lavorare su altri progetti di sviluppo. In Brain Computing preferiamo distribuire le funzionalità attraverso una serie di mini-attività, mantenendo l’ambito del progetto come unica variabile, ma garantendo un livello minimo di valore entro il periodo di tempo fissato dal pacchetto di lavoro o dal progetto complessivo.

Vale la pena ricordare che è sempre possibile aggiungere nuovi scopi progettuali in seguito. Forse hai iniziato a guadagnare, hai aumentato gli utenti o ridotto i costi. In entrambi i casi, è molto più semplice chiedere più tempo e denaro se hai già dimostrato un reale rendimento e stai offrendo valore commerciale.

LEGGI ANCHE: 3 motivi per cui dovresti implementare un CRM

---

Software stima: il nostro approccio ai costi e ai prezzi del software

In Brain Computing lavoriamo a stretto contatto con i nostri clienti e ingegneri per impiegare tecniche che promuovono la fiducia delle parti interessate per la durata e i costi del progetto. Lavoriamo per elaborare e adattare continuamente la pianificazione da un livello base a una serie di dettagli più specifici, quando è necessario per evitare sprechi e consentire variazioni controllate. Qualche esempio? Qui trovi i prodotti software che abbiamo progettato.

Per elaborare un progetto dotato di stime e costi definiti adottiamo le seguenti misure:

1. Portata iniziale di alto livello.

All’inizio di un progetto, sappiamo poco del suo eventuale risultato. È folle immaginare di sapere esattamente quali caratteristiche sono necessarie ai clienti e agli utenti finali già all’inizio. Quindi, iniziamo con una carta del progetto e un insieme di alto livello di funzionalità “epiche” che guidano la direzione del progetto, sulla base di una visione e obiettivi solidi.

• Visione e definizione dell’obiettivo: cosa dobbiamo costruire? Cosa devi raggiungere e quali sono i tuoi obiettivi aziendali? La comprensione di queste domande ci consente di impostare la scala del progetto. Hai bisogno di un prototipo per testare un’idea, un concetto o una tecnologia iniziale? Hai identificato una proposta chiara, già testata con il tuo mercato, e sei pronto a costruire il tuo primo prodotto minimo sostenibile (MVP)? Oppure, stai ridimensionando la tua attività o prodotto esistente per portarlo al livello successivo?
• Funzionalità “epiche” di alto livello: senza scendere troppo nei dettagli, ti consigliamo di definire le funzionalità che il tuo prodotto ha per soddisfare le esigenze dei tuoi clienti. Questa è una “lista della spesa” strutturata, che descrive lo “scheletro” del tuo prodotto; spesso questi sono indicati come “User Story”.
• Analisi MoSCoW: l’analisi MoSCoW è una tecnica che, in parole povere, aiuta a identificare ciò che è veramente necessario per rendere fattibile il prodotto e ciò che vuoi avere. Quelli che sono identificati come “Must” soddisfano ciò che incoraggerà gli utenti ad adottare il tuo prodotto. Le funzionalità identificate come “Should” sorprenderanno e delizieranno i tuoi clienti, ma potrebbero essere costruite in un secondo momento. Le voci “Could” spesso non aggiungono un valore commerciale significativo, possono non aumentare il rendimento, e sono le priorità più basse. Le funzionalità “Won’t” potrebbero essere importanti un giorno, ma non rientrano nell’ambito di questa iterazione del progetto. Tuttavia, identificarle ora può aiutare a ricordare la scalabilità e le dimensioni potenziali del prodotto in futuro.

---

2. Project Management Agile: proposta

Per decidere se procedere con un progetto, è necessario valutare dati precisi: costo sviluppo software e durata. Questi sono i quesiti minimi da valutare: cosa serve per creare il prodotto che vogliamo? Quando possiamo partire? Il progetto è in linea con la nostra strategia aziendale e le nostre finanze?

Con questi dettagli, siamo in grado di fornire una proposta. I nostri ingegneri vengono selezionati con cura per i requisiti specifici del progetto e collaborano con un project manager per ricavare almeno una soluzione tecnica, una durata stimata che fornisce l’ambito noto e un costo stimato per completare il progetto.

Come già accennato, all’inizio di un progetto sappiamo poco su cosa otterremo. Manteniamo deliberatamente le funzionalità e l’ambito vaghi, poiché il contrario può suggerire che sappiamo esattamente cosa viene richiesto. Una stima in questa fase è la meno accurata, ma fornisce indicazioni sul fatto che valga la pena procedere con il progetto.

La proposta è il primo strumento per elaborare la durata e il costo del progetto. Una volta accettata, possiamo procedere e fornire un preventivo sviluppo software a prezzo fisso.

3. Software agile: pianificazione del rilascio

Il livello successivo per l’elaborazione delle stime è la creazione del piano di rilascio, che offre una gamma di funzionalità in un determinato periodo di tempo. Da un elenco di funzionalità definiamo le dimensioni del progetto e la rapidità con cui il team può sviluppare un software agile in grado di soddisfare le aspettative e la gestione del rischio di incertezza.

• Backlog del prodotto. Il backlog del prodotto è semplicemente un elenco ordinato di “Epics” o “User Story” che rappresenta le funzionalità richieste per un prodotto. Questo elenco inizia come i precedenti, ma tra il team di progetto assegnato, il project manager e il cliente, ora li suddividiamo in elementi più significativi. Ciascuno degli articoli rappresenta una parte del valore aziendale per il cliente. Non entriamo nel dettaglio in questa fase, non abbiamo bisogno di conoscere i criteri di accettazione, non abbiamo bisogno di sapere se un pulsante è blu o verde, dobbiamo solo sapere che c’è un pulsante che consente alcune attività da eseguire.
• Stime di massima. Ora che abbiamo il nostro elenco di funzionalità descritte come user story, il team stima queste discrete voci di funzionalità usando una tecnica chiamata “Planning Poker”. Questa è una tecnica utile che garantisce risultati rapidi e affidabili basati sull’opinione di esperti e su un dimensionamento analogo. Planning Poker assegna un numero concordato a ciascun oggetto che ne rappresenta le dimensioni e la complessità. Questo si chiama punto della storia. Sono disponibili altre tecniche e dimensioni di stima Agile, come i “giorni ideali”. La fine di questo processo determinerà la dimensione del progetto e le dipendenze tra le funzionalità. La dimensione viene determinata sommando tutti i punti della storia dagli articoli nel portafoglio ordini del prodotto. Se quel numero è uguale a 120, la dimensione del nostro progetto è di 120 punti trama.
• Definizione delle priorità. Ora che abbiamo un backlog e una dimensione per il progetto, siamo in grado di stabilire le priorità con il cliente. Si tratta davvero di identificare ciò che è più prezioso per il cliente al fine di ottenere i risultati desiderati. L’elemento in cima all’elenco è considerato il più importante, il secondo è meno importante del primo e così via attraverso l’elenco. Non ci sono due elementi importanti quanto un altro, la priorità di ciascun articolo è di importanza o valore relativo a ciascuno degli altri elementi. Questo approccio alla definizione delle priorità è una pietra miliare importante nella pianificazione di un progetto software. Ora sappiamo cosa è importante per il cliente e in quale ordine per completare il lavoro, prendersi cura delle dipendenze, consegnare un prodotto che soddisfi le aspettative.
• Pianificazione del rilascio. Ad oggi, abbiamo definito quello che dovrebbe essere il prodotto e quanto sarà esteso il progetto.

Ora, determiniamo quanto tempo ci vorrà per consegnare un prodotto rilasciabile. Il cliente e il team, inclusi progettisti, ingegneri, tester e agile project manager lavorano insieme per identificare cosa possiamo realizzare e in quanto tempo, per creare un piano di rilascio.

Il piano di rilascio fornisce inoltre informazioni su come il progetto si allinea con i piani strategici di un cliente. Infine, garantisce al team di progetto una linea guida che apre la strada e definisce un termine per lo sviluppo.

Prima di iniziare, ci assicuriamo di comprendere la definizione concordata di “fatto”. Si tratta di un determinato insieme di criteri che un cliente accetterà come completo e soddisfa anche tutti i requisiti tecnici per essere considerati rilasciabili.

Per prendere uno scenario di base, prendiamo il numero totale di punti della storia che abbiamo ottenuto dal dimensionamento del nostro arretrato e lo dividiamo per la velocità anticipata dei nostri team. (La velocità è normalmente espressa come un intervallo, ma per semplicità, qui useremo un singolo numero).

Lavoriamo in iterazioni di due settimane, quindi la nostra velocità si rifletterà su quanto possiamo completare in un ciclo di due settimane con il disponibile capacità della squadra. Se i punti della nostra storia sono stati 120 e prevediamo di completare 20 punti per iterazione, la durata totale dello sviluppo sarebbe di 12 settimane o 6 iterazioni. Aggiungiamo a questo uno sprint 0 di 2 settimane e uno sprint di preparazione al rilascio di due settimane. In totale, la durata del nostro progetto è di 16 settimane.

Esistono tecniche che possono aiutare a creare un adeguato buffer di rischio nella nostra pianificazione, di cui parleremo più avanti. Ma in breve, utilizziamo il buffer per gestire il rischio, l’incertezza e per raggiungere un accordo minimo sui punti previsti da consegnare. Il risultato potrebbe essere un intervallo di 90-150 punti consegnati, 90 è il minimo accettabile per creare un prodotto valido.

Pianificazione Agile

In alternativa, se il progetto deve essere completato entro una certa data, ad esempio 10 settimane, il team determinerebbe la quantità di arretrato che può essere completata in quel momento. Se prevediamo 20 punti per sprint, più Sprint 0 e uno sprint di rilascio, avremo come target 60 punti completati entro la fine del progetto.

Ancora una volta, dobbiamo cercare di gestire il rischio aggiungendo un buffer appropriato, che potrebbe portare a un obiettivo da 45 a 75 punti completati e pronti per il rilascio. I 45 punti si allineano al minimo accettabile per fornire un prodotto valido. Questo è uno scenario in cui puoi aspettarti di aggiungere un membro al team per aumentare la velocità, se necessario.

Naturalmente, tutto è supportato da una comunicazione e collaborazione di qualità tra tutte le parti per ottenere un piano di rilascio realizzabile, realistico e accettabile.

4. Agile Management: contratto a prezzo fisso

Una volta concordato un piano di rilascio, siamo in grado di creare un preventivo sviluppo software per un contratto di progetto a prezzo fisso. Come accennato in precedenza, è consigliabile mantenere la durata del progetto, il team fissi e la portata variabile.

Il preventivo per un contratto a prezzo fisso viene consegnato insieme a una dichiarazione di lavoro e un programma di pagamento concordato.

Finché c’è fiducia, comunicazione, collaborazione e disponibilità a entrare nello spirito di un progetto software Agile, tutti i passaggi precedenti ci consentono di consegnare un preventivo con un grado realistico di fiducia che un progetto verrà consegnato in tempo e nel budget. Naturalmente, ci saranno occasioni in cui un progetto viene consegnato in anticipo o in ritardo e trattiamo queste variazioni con la massima trasparenza.

Metodologia Agile Project Management: tecniche di stima

La pianificazione e le stime nell’Agile Project Management sono supportate da una serie di tecniche mirate per acquisire certezze in termini di estensione, impegno, durata e costi. Ecco alcune di quelle che preferiamo per stimare dimensioni e costi dei progetti software.

Valutazione delle dimensioni

La dimensione del progetto è davvero un apprezzamento per portata, complessità, dimensioni, rischio e entità. Per usare un’analogia, si tratta di capire se stiamo costruendo la Torre Eiffel o la Grande Muraglia cinese. La torre Eiffel è una struttura alta, pesante e complessa costruita in un ambiente urbano stretto. La Grande Muraglia Cinese è una struttura relativamente semplice, ma lunga e robusta che si estende su molte miglia di terreno ondulato.

Mentre entrambi sarebbero grandi progetti da realizzare, la loro portata, complessità, dimensioni, grandezza e quindi dimensione sono diverse.

È importante gestire le aspettative con stime. Non sono mai previsioni, impegni o garanzie. Quando discutiamo di dimensioni totali, durata totale e costi totali, lavoriamo sempre entro intervalli, in modo da mitigare il rischio, l’incertezza e le incognite.

Le storie che rappresentano le caratteristiche del tuo prodotto sono dimensionate individualmente e stimate usando i punti della storia o i giorni ideali. Il numero totale di queste unità definisce la dimensione totale del progetto.

Story Points

Gli “story points” sono un’unità di misura che esprime la dimensione complessiva di una storia utente. La dimensione di una storia, quando stimata, include tutti gli aspetti di progettazione, ingegneria, test, revisione del codice, integrazione, ecc.

La dimensione di ciascuna storia è relativa ad un’altra storia. Ad esempio, la Storia A può essere dimensionata come 1 punto, la Storia B come 2 punti e la Storia C come 3 punti. Qui, la Storia C è almeno 3 volte più grande della Storia A e almeno la metà della Storia B.

Se le seguenti storie nel nostro backlog di prodotto hanno le dimensioni associate, la dimensione totale del progetto è di 12 punti.

Quantità di giorni ideale

Questa è una misura dell’estensione espressa in giorni. Non calcola le interruzioni, attività di pianificazione, lettura di email e altre attività non progettuali. La stima si concentra solo su quanto tempo serve al netto di un lavoro senza interruzioni, più che sul tempo trascorso complessivamente.

In genere, facciamo una stima di alto livello quando sappiamo poco di un progetto, oppure utilizziamo la quantità di giorni ideale perché è un concetto più facile da correlare con il progetto e l’esperienza precedente.

Quando si effettua una stima a un livello più dettagliato, entrambi gli approcci possono essere utilizzati e decisi dal team di progettazione. Esistono vantaggi per entrambi gli approcci e ogni squadra avrà la sua preferenza.

Tecniche per effettuare stime

• Stime condivise. Le stime non vengono eseguite separatamente. Vengono eseguiti in collaborazione dall’intero team di ingegneri e comprendono progettazione, database, server, interfaccia utente front-end, QA e altri esperti interfunzionali. Ciò evita problemi di non considerare tutti gli aspetti del lavoro coinvolti per completare una funzione e garantisce che nessuno abbia l’onere o la sfortuna di sovrastimare o sottovalutare la dimensione di una caratteristica. Il team combinato avrà tutti un punto di vista che può essere discusso e concordato.
• Stime analoghe. Qui è dove consideriamo due caratteristiche discrete e decidiamo che una è relativamente più piccola o più grande dell’altra. Possiamo guardare una determinata storia e concordare che è di piccole dimensioni e, se si usano i punti della storia, potremmo dargli una dimensione di due. La prossima storia potrebbe essere considerata grande rispetto alla prima, e le daremmo una dimensione di cinque. Ciò suggerisce che una dimensione grande è almeno il doppio di una funzione piccola. Continueremo questo esercizio con tutte le storie. Una volta completato, possiamo quindi affiancare tutte le storie di piccole, medie, grandi ed extra-grandi e fare un controllo incrociato del nostro dimensionamento per garantire che ci sia un livello di uniformità nella nostra stima.
• Planning Poker. Molto è stato scritto su Planning Poker. In sostanza, combina l’opinione degli esperti, l’analogia e la collaborazione del team in un processo semplice, rapido e affidabile. Riunisce più esperti che sono più adatti a costruire una stima basata sull’esperienza tecnica e di dominio, un dialogo vivace e una valida giustificazione.

Agile Management: velocità

La velocità è una misura della capacità di una squadra di svolgere il lavoro in una data iterazione (o “sprint”).

È espresso come un intervallo, ad esempio, da 23 a 32 punti per sprint, in particolare all’inizio della vita di un progetto. In generale, questo perché, a meno che la stessa squadra non abbia già lavorato sullo stesso problema, è difficile descrivere esattamente quale sarà la velocità della squadra. Nota che ci riferiamo alla velocità di una squadra, non a quella di un individuo!

Usiamo la velocità per pianificare le nostre release e adattare i nostri piani e pacchetti di lavoro mentre progrediamo attraverso un progetto, permettendoci così di adattare le nostre previsioni per il completamento regolarmente e accuratamente attraverso l’esecuzione.

Quando iniziamo, siamo costretti a definire un intervallo di velocità con pochissimi dati. Possiamo usare valori storici, se il team e lo spazio d’azione sono gli stessi, ma è poco probabile. Possiamo eseguire un’iterazione per avere un’idea della velocità da un team che sta lavorando al progetto, ma questo è costoso e non funziona se ci sono decisioni da prendere sull’avvio un progetto. Oppure possiamo fare una previsione.

La previsione di velocità implica prendere uno “sprint di storie” e suddividerle in attività che vengono eseguite per completare il percorso. Stimiamo il numero di ore che richiede ciascuna attività (progettazione, sviluppo, test ecc.), e valutiamo la capacità del team avrebbe in una determinata fase. Una capacità del 70% per una squadra inattiva è una buona base. Quindi, in una situazione di base, se le ore disponibili per il team sono:

• 4 membri del team * due settimane * 40 ore settimanali = 320 ore
• Moltiplicato per la nostra capacità del 70 percento = 224 ore
• Sommare tutte le attività delle funzioni e interrompere il conteggio a 224
• Prendi tutte le funzionalità completate, aggiungi i loro punti della storia e ottieni la tua velocità, diciamo 36
• Applicare il 20% su entrambi i lati, per ottenere un intervallo tra il più basso e il più alto, per arrivare a una velocità stimata da 29 a 43 punti trama.

La velocità di solito varia nelle prime due o quattro iterazioni, e quindi si stabilizza in una piccola gamma di punti. Pertanto, laddove il nostro intervallo iniziale, prima dello sprint, era compreso tra 29 e 43, con lo sprint quattro potrebbe raggiungere da 34 a 38 punti. Questo ci dà maggiore fiducia nel prevedere la data di completamento.

Management Agile: piani di buffering per rischi e incertezze

Tutti i progetti software presentano un livello di incertezza. L’incertezza diminuisce man mano che procediamo nel progetto e scopriamo di più sulla tecnologia, prestazioni ed esigenze del cliente.

Possiamo ridurre questa incertezza o rischio con un buffer, che rappresenta un margine di errore nella nostra stima, e con le incognite che non possiamo determinare prima dell’inizio dello sviluppo.

In genere, esistono due tipi di buffer: Feature e Schedule. Poiché spesso abbiamo un prezzo fisso per una data di consegna fissa, è preferibile utilizzare il buffer delle funzionalità.

Questo approccio ci fornisce una strategia credibile, per limitare il rischio e far avere al cliente fiducia in ciò che dovrebbe aspettarsi al termine del progetto.

Project Management Agile: Buffer di funzionalità

Con un buffer delle funzionalità, prevediamo che forniremo un determinato set di funzionalità, ma idealmente ne completeremo un altro. Quest’altro dovrebbe riflettere almeno il set minimo di funzionalità che il cliente considera necessario per il lancio di un prodotto, ma possono esserci anche altre variazioni entro i termini, se consentito.

In effetti, un cliente può decidere che le funzionalità con la massima priorità dal backlog del prodotto, aggiungendo fino a 100 punti, siano le più importanti. Potrebbe quindi prendere in considerazione funzionalità aggiuntive, che si sommano ad altri 30 punti. Il team, pertanto, pianificherà in base alla consegna di 130 punti, con un minimo di 100 completati entro la data di completamento prevista dal contratto a prezzo fisso indicato.

Considerazioni finali sull’Agile Project Management

L’Agile Project Management può essere un concetto difficile da comprendere e adottare. Questo è evidente quando si gestiscono argomenti delicati come costi, ambito e durata. A volte, i clienti più esigenti vogliono che tutto sia risolto in anticipo e incolpano il fornitore quando tutto inizia a disfarsi. Allo stesso modo, esistono fornitori che hanno difficoltà e non riescono a rispondere alle esigenze dei clienti. Percorrere una strada Agile è una scelta basato sulla fiducia, una buona relazione e una comunicazione eccezionale. Questi devono essere valori offerti da entrambe le parti, in modo da mantenere un progetto sano a parità di benefici, soddisfazione e successo per tutti i soggetti coinvolti. Mantenere una mente aperta e un atteggiamento costruttivo nei confronti della collaborazione e della negoziazione è il modo migliore per evitare uno stop.

È difficile lasciarsi andare e riporre tutta la tua fiducia in un team che non conosci. Spesso, il cliente vuole organizzare tutti i requisiti in anticipo, come garanzia di ciò che otterranno. Così hanno la sensazione di essere certi che l’ambito del progetto sia ben definito. Ma questo non è un approccio di successo. Se siamo bloccati con scopi e richieste non realistiche nel contratto, i problemi nascono molto rapidamente.

Sappiamo che, adottando l’approccio tradizionale, la variazione dell’ambito e le incognite impreviste sono lontane dalla realtà dei fatti. Adottare, invece, un approccio che si adatta ai prezzi, alla pianificazione e alla portata del progetto consente ai clienti di identificare davvero il prodotto, in modo che sia esattamente ciò di cui il mercato ha bisogno. E consente a un fornitore di essere reattivo, fantasioso ed efficiente. È fondamentale sfruttare la collaborazione tra cliente e fornitore per la negoziazione del contratto.

I venditori devono essere onesti, e i clienti devono essere realistici su ciò che può essere ottenuto fin dall’inizio. Un fornitore che promette obiettivi poco realistici e aumenta i costi può ottenere il contratto iniziale, ma presto renderà il cliente scontento. La fiducia deve essere costruita fin dall’inizio, e coltivata nel corso di un progetto. Il fornitore deve essere flessibile e collaborare con il variare delle esigenze. I clienti vogliono sempre di più, è una conseguenza naturale del business. Deve esserci uno scambio di valore uguale e benefico tra le due parti. Da un lato, i clienti stanno cercando di creare valore per la loro attività. Dall’altra, i venditori cercano di creare valore costruendo relazioni durature con i clienti. Osservare i valori e i principi guida del Manifesto Agile è una solida base per formare relazioni forti, equilibrate e durature.

Agile software project Management: una sintesi

Speriamo di averti aiutato ad avere un’idea più precisa sulla pianificazione e definizione di costi per attività di Agile Project Management. Tutti questi approcci e tecniche sono ideali per generare fiducia in un team e nelle menti dei clienti per la realizzazione di un prodotto software su misura o selezionato. E anche per acquisire consapevolezza in fase di avvio.

Segui queste linee guida e sarai sicuro di trovare un percorso soddisfacente per dare vita al tuo prodotto software. Per individuare il tuo partner di sviluppo ideale, prova questi semplici passaggi.

Hai bisogno di un software su misura? Contatta ora Brain Computing!