Stima dei costi del software nella gestione agile dei progetti

introduzione

Una delle cose più difficili da fare nello sviluppo del software è determinare quanto tempo e quanto ci vorrà per fornire un nuovo prodotto software. Dovrebbe essere così difficile? La risposta non è semplice.

La stima dei costi del software è intrinsecamente difficile e gli esseri umani sono terribilmente pessimi nel prevedere risultati assoluti. Non esistono due progetti uguali; ciascuno è unico in ciò che si propone di raggiungere e unico nella miriade di parametri che ne costituiscono l'esistenza. Spesso, quello che sembra essere un semplice problema in superficie è molto più difficile o tecnicamente impegnativo da implementare nella realtà. E, senza dubbio, ci saranno 'sconosciute' con il progetto che possono essere identificate solo quando si presenteranno.

Inoltre, non esistono due persone uguali, che tu sia un cliente, uno sviluppatore o un utente. Veniamo precaricati con il nostro insieme di conoscenze, esperienze, valori, aspettative, attitudine al rischio e capacità di adattamento.

Scrivere software di buona qualità è pane quotidiano per gli ingegneri senior; creare fantastici prodotti software può essere uno sforzo molto più difficile, per tutti i soggetti coinvolti.

Ma quando si tratta di software, capire la durata e il costo sono fondamentali per prendere decisioni aziendali strategiche e questo è vero sia che tu stia creando una startup, realizzando una nuova opportunità di business o consentendo alla tua azienda di ottenere prestazioni migliori. I tempi, il ritorno sull'investimento e i vantaggi offerti possono creare, scuotere o distruggere la tua attività. Ti starai chiedendo: cosa otteniamo per i nostri soldi? Possiamo prevedere i nostri costi? Quanto costerà creare il prodotto che vogliamo? Quando possiamo lanciare? Otterremo un prodotto di qualità per il nostro investimento? Crescerà con la nostra attività? Fornirà valore aziendale?

Quindi, come si fa a stimare la dimensione, la durata e il costo di un progetto? Esploriamo la stima del progetto Agile e i costi di sviluppo del software e come lo facciamo in Toptal.

Prezzi e stime dei contratti tradizionali

Tradizionalmente, utilizzando pratiche non agili, i progetti software hanno cercato di correggere la funzionalità o l'ambito e di lasciare che il tempo e il costo fossero variabili. Ciò causa problemi:

1. Come fai a sapere che la funzionalità che risolvi all'inizio di un progetto è davvero la funzionalità che serve meglio la tua azienda o i tuoi clienti? Il più delle volte, la funzionalità o l'ambito cambieranno, motivo per cui sentiamo parlare di "scope creep", il risultato dei bisogni desiderati che viene identificato attraverso il ciclo di vita di un progetto e determinato come necessario o obbligatorio

2. Quando il costo 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 identificati o di requisiti mutevoli, il che significa che dobbiamo aggiungere membri del team per svolgere più lavoro nello stesso lasso di tempo o mantenere i membri del team più a lungo. Nessuno dei due è desiderabile

3. Quando il tempo è una variabile, perdiamo il controllo sulla posizione nel nostro mercato. Forse perdiamo una data importante del settore o i nostri concorrenti tirano fuori il loro prodotto prima di noi, perdendo così qualsiasi vantaggio competitivo che il nostro progetto potrebbe aver avuto.

Ci sono molti altri esiti di tempi e costi variabili, che sono spesso negativi e indesiderabili.

Naturalmente, molti clienti e organizzazioni cercano di correggere tutte e tre le componenti di questo "triangolo magico". Sfortunatamente, è quasi impossibile da raggiungere realisticamente. Ci sono troppi elementi che cospirano per sconvolgere questo ideale, che alla fine si traduce in prodotti che non soddisfano un'esigenza, impiegano troppo tempo per avvantaggiare i propri clienti o costano troppo per realizzare valore aziendale.

Contratti agili per progetti software

Il costo è un prodotto del tempo e delle persone (membri del team). Aggiungi più tempo e aggiungi i costi per assumere persone più a lungo. Aggiungi più membri del team e aumenterai i costi per offrire lo stesso valore aziendale. Le cose che vogliamo davvero evitare. Questo è il motivo per cui i principi Agile credono nel fissare tempo e membri del team e lasciare che l'ambito sia la componente variabile.

Quale suona meglio e aumenta la fiducia degli stakeholder, il costo fisso o il costo variabile?

Naturalmente, è importante che un prodotto mantenga le sue promesse e le esigenze dei suoi clienti. Non serve spendere un'esatta quantità di tempo e un'esatta somma di denaro se, alla fine, hai un prodotto che nessuno vuole o può usare in modo efficace.

Quindi i contratti Agile si concentrano su quanto segue:

• Pacchetti di lavoro a prezzo fisso - L'intero progetto è suddiviso in "mini" rilasci logici che contribuiscono al risultato completo del prodotto. Ogni versione è un pacchetto di lavoro con un prezzo adeguato. Quando un pacchetto di lavoro viene completato, i pacchetti di lavoro futuri vengono rivalutati in base a ciò che abbiamo appreso dal precedente. Ciò evita inutili imprevisti e consente al cliente di definire un livello di ridefinizione delle priorità e di funzionalità nuove/riviste.

• Terminazione anticipata - Ciò consente al cliente di cercare di terminare il progetto in anticipo se è stata consegnata una quantità sufficiente di prodotto e non ci sono ulteriori ROI da raggiungere mantenendo un team di progetto che continuerà a fornire solo guadagni marginali. Questa clausola è generalmente consentita in qualsiasi momento ed è valida fintanto che il team di progetto e il cliente hanno mantenuto un rapporto di collaborazione di lavoro forte, fiducioso e stretto. Il vantaggio per il cliente è che il progetto finirà presto, avendo fornito tutte le preziose caratteristiche necessarie per rendere il prodotto fattibile. In cambio, il fornitore riceve il 20 percento del valore residuo del contratto e compensa il rischio di trattenere il personale.

• Modifiche flessibili - Il cambiamento è un tema che scorre forte nelle vene della distribuzione del software Agile. Ci aspettiamo di non sapere tutto ciò di cui abbiamo bisogno per rendere un prodotto di successo fin dall'inizio. Pertanto, promuoviamo il cambiamento, sulla base di dati e feedback pertinenti, per garantire che venga consegnato il prodotto giusto. Al termine di un'iterazione, le modifiche possono essere sostituite con vecchie funzionalità non più ritenute necessarie o prioritarie. Finché la modifica è di uguale valore, non ci sono ulteriori costi. Se la modifica è di valore inferiore, è possibile identificare o ritirare il lavoro aggiuntivo dall'arretrato rimanente. Questa clausola è valida fintanto che il team di progetto e il cliente hanno mantenuto un rapporto di collaborazione di lavoro forte, fiducioso e stretto durante tutto il progetto.

• Lavoro aggiuntivo - Nel corso della vita di un progetto, possono essere identificate più caratteristiche che non sarebbero realizzabili nell'ambito del contratto a prezzo fisso esistente. Per questo scenario, è possibile aggiungere ulteriori pacchetti di lavoro a nuovo prezzo alla fine del progetto o ripristinare tempo e materiali.

• Stime a intervalli - Esistono due modi in cui le stime possono essere variate in un contratto di progetto Agile: un intervallo di durata o un intervallo di funzionalità. Un intervallo di durata consente a una stima di dire che il progetto o il pacchetto di lavoro richiederà dalle 12 alle 16 settimane per un determinato ambito. Tuttavia, l'aggiunta della durata aumenta i costi poiché mantieni i membri del team di progetto più a lungo o significa che non possono essere rilasciati per lavorare su altri progetti di sviluppo. In Toptal, preferiamo distribuire le caratteristiche su una gamma di punti della storia, mantenendo l'ambito come variabile ma promettendo di fornire un livello minimo di valore al cliente entro il periodo di tempo fisso del pacchetto di lavoro o del progetto generale.

Vale la pena ricordare che puoi sempre aggiungere più ambito in un secondo momento. Forse hai iniziato a guadagnare, hai aumentato gli utenti o ridotto i costi. In ogni caso, è molto più facile chiedere più tempo e denaro se hai già dimostrato un ritorno o un miglioramento e stai offrendo valore aziendale.

Il nostro approccio ai costi e ai prezzi del software

In Toptal lavoriamo a stretto contatto con i nostri clienti e ingegneri per impiegare tecniche che promuovano la fiducia delle parti interessate nella durata e nei costi del progetto. Lavoriamo per elaborare e adattare continuamente la pianificazione da un livello elevato iniziale fino a dettagli più dettagliati quando è opportuno e necessario per evitare sprechi e consentire il cambiamento gestito.

Nell'elaborazione di un preventivo e di un progetto a prezzo fisso vengono effettuati i seguenti passaggi:

1. Ambito iniziale di alto livello

All'inizio di un progetto, sappiamo meno del suo esito finale. È una follia immaginare che sia possibile sapere esattamente di quali caratteristiche hanno bisogno i nostri clienti e utenti fin dall'inizio.

Quindi, iniziamo con una carta del progetto e un insieme di caratteristiche "epiche" di alto livello che guidano la direzione del progetto, sulla base di una solida visione e obiettivi

un. Visione e definizione degli obiettivi Cosa dobbiamo costruire? Cosa devi raggiungere e quali sono i tuoi obiettivi di business? Comprendere 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 che è stata testata con il tuo mercato e sei pronto per costruire il tuo primo prodotto minimo vitale (MVP)? Oppure stai ridimensionando la tua attività o prodotto esistente per portarlo al livello successivo?

B. Funzionalità “epiche” di alto livello Senza entrare troppo nei dettagli, vorrai definire le caratteristiche che il tuo prodotto ha per soddisfare le esigenze dei tuoi clienti. Questa è una "lista della spesa" strutturata che descrive le ossa nude del tuo prodotto; spesso questi sono indicati come "Storie utente" o epiche

C. 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 è bello avere. Quelli che sono identificati come un "must" soddisfano ciò che incoraggerà gli utenti a coinvolgere e adottare il tuo prodotto. Quelle caratteristiche identificate come "Dovrebbero" sorprenderanno e delizieranno i tuoi clienti, ma potrebbero essere sviluppate in seguito. Gli articoli "Potrebbero" spesso non aggiungono un valore commerciale significativo, potrebbero non aumentare il rendimento e sono le tue priorità più basse. Le funzionalità "Non lo farò" potrebbero essere importanti un giorno, ma non sono nell'ambito di questa iterazione del progetto. Tuttavia, identificarli ora può aiutare a tenere a mente le dimensioni e le dimensioni potenziali del prodotto per il futuro.

2. Proposta

Per decidere se procedere con un progetto, è necessario basare tale decisione su dati ben informati: costo e durata. Questi sono i minimi che devi chiederti: cosa ci vorrà per creare il prodotto che vogliamo? Quando possiamo lanciare? Questo è in linea con la nostra strategia aziendale e le nostre finanze?

Con i dettagli di cui sopra, 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 derivare almeno una soluzione tecnica, una durata stimata che fornisca l'ambito noto e un costo stimato per completare il progetto.

Come accennato in precedenza, all'inizio di un progetto sappiamo meno di ciò che verrà consegnato. Manteniamo volutamente vaghi le caratteristiche e la portata, poiché agire diversamente suggerisce di sapere esattamente cosa è richiesto. Una stima in questa fase sarebbe la meno accurata, ma fornisce indicazioni sull'opportunità di procedere con il progetto.

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

3. Pianificazione del rilascio

Il livello successivo di elaborazione della stima consiste nel creare un piano di rilascio che fornirà una gamma di funzionalità in un determinato periodo di tempo. Deduciamo questo da un elenco di caratteristiche, la dimensione del progetto, la velocità con cui il nostro team può sviluppare software di qualità che soddisfi le aspettative del cliente e le tecniche per gestire il rischio di incertezza.

un. Product Backlog Il product backlog è semplicemente un elenco ordinato di “Epics” o “User Story” che rappresenta le caratteristiche richieste per un prodotto. Questo elenco prende vita come l'epopea discussa in precedenza, 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 più 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.

B. Stima Ora che abbiamo il nostro elenco di funzionalità descritte come storie degli utenti, il team stima questi elementi distinti di funzionalità utilizzando 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 è chiamato un 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 è determinata sommando tutti i punti della storia dagli articoli nel backlog del prodotto. Se quel numero è uguale a 120, la dimensione del nostro progetto è di 120 story point.

C. Priorità Ora che abbiamo un backlog e una dimensione per il progetto, siamo in grado di dare priorità al 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 elemento è meno importante del primo e così via nell'elenco. Non esistono due elementi importanti quanto un altro, la priorità di ogni elemento è di importanza o valore relativo per 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 completare il lavoro, prendendoci cura delle dipendenze, per consegnare un prodotto che soddisfi le aspettative.

D. Pianificazione del rilascio Ad oggi, abbiamo determinato quale riteniamo sia il prodotto e quanto sia grande.

Ora, determiniamo quanto tempo ci vorrà per consegnare un prodotto rilasciabile. Il cliente e il team, inclusi designer, ingegneri, tester, Scrum Master e Project Manager, lavorano insieme per identificare ciò che può essere ottenuto e quanto velocemente è possibile lavorare per creare un piano di rilascio.

Il piano di rilascio fornisce anche informazioni su come il progetto si allineerà ai piani strategici di un cliente.

Infine, questo piano garantisce al team di progetto una luce guida che apre la strada e definisce un punto finale logico per lo sviluppo.

Prima di iniziare, ci assicuriamo di aver compreso la definizione concordata di "fatto". Questo è un determinato insieme di criteri che un cliente accetterà come completo e soddisfa anche tutti i requisiti ingegneristici per essere considerato rilasciabile.

Per prendere uno scenario di base, prendiamo il numero totale di story point che abbiamo ottenuto dal dimensionamento del nostro backlog e lo dividiamo per la velocità prevista dai nostri team. (NB la velocità è normalmente espressa come un intervallo, ma per semplicità useremo un singolo numero qui.) Lavoriamo in iterazioni di due settimane, quindi la nostra velocità si rifletterà su quanto possiamo completare in un ciclo di due settimane con il capacità della squadra. Se i nostri punti storia totalizzassero 120 e prevediamo di completare 20 punti per iterazione, la durata totale dello sviluppo sarebbe di 12 settimane o 6 iterazioni. A ciò aggiungiamo 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. Ci sono tecniche che possiamo utilizzare che aiuterebbero a creare un adeguato cuscinetto di rischio nella nostra pianificazione, di cui parleremo in seguito. Ma in breve, utilizziamo il buffer per gestire il rischio di incertezza e per raggiungere un accordo minimo sugli story point previsti da consegnare. Il risultato potrebbe essere una gamma da 90 a 150 story point consegnati, 90 è il minimo accettabile per creare un prodotto valido.

In alternativa, se il progetto deve essere completato entro una determinata data, ad esempio 10 settimane, il team determinerebbe quanto del backlog può essere completato in quel tempo. Se anticipiamo 20 story point per sprint, più Sprint 0 e uno sprint di rilascio, punteremmo a 60 punti completati entro la fine del progetto. Anche in questo caso, cercheremo di gestire il rischio aggiungendo un buffer appropriato, che potrebbe comportare un obiettivo da 45 a 75 story point completato e pronto per il rilascio. I 45 punti della storia si allineerebbero al minimo accettabile per fornire un prodotto valido e di valore. Questo è uno scenario in cui potresti aspettarti di aggiungere un membro del team per aumentare la velocità, se appropriato.

Naturalmente, tutto quanto sopra è supportato da una comunicazione di buona qualità e dalla collaborazione tra tutte le parti per ricavare un piano di rilascio che sia realizzabile, realistico e accettabile per il cliente.

4. Contratto a prezzo fisso

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

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

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

Tecniche di stima

La pianificazione e la stima agili sono supportate da una serie di tecniche che un team di sviluppo può utilizzare per acquisire fiducia in termini di dimensioni, impegno, durata e costi. Ecco alcuni di quelli utilizzati dai nostri team per stimare le dimensioni e il costo di un progetto software.

Dimensioni stimate

La dimensione del progetto è davvero un apprezzamento della sua portata, complessità, dimensioni, rischio e grandezza. 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 copre molte miglia di terreno ondulato.

Anche se sarebbero entrambi grandi progetti da realizzare, la loro portata, complessità, dimensioni, grandezza e quindi dimensioni sono differenti.

È importante gestire le aspettative con i preventivi. Non sono mai previsioni, impegni o garanzie. Quando si discute di dimensione totale, durata totale e costo totale, 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 utilizzando story point o giorni ideali. Il numero totale di queste unità definisce la dimensione totale del progetto.

Punti Storia

I punti della storia 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.

Ogni dimensione di una storia è relativa a un'altra storia. Quindi, ad esempio, la Storia A può essere dimensionata come un punto, la Storia B come due punti e la Storia C come tre punti. Qui, la Storia C è almeno tre volte più grande della Storia A e almeno la metà di quella B.

Se le seguenti storie nel nostro product backlog hanno le dimensioni associate:

La dimensione totale del progetto è di 12 story point.

Giorni ideali

Questa è una misura della dimensione espressa in giorni. Rimuove il concetto di spese generali come interruzioni, attività di pianificazione agile, lettura di e-mail e altre attività non di progetto. Si concentra solo su quanto tempo ci vorrebbe se dovessi lavorare su qualcosa continuamente senza interruzioni, piuttosto che sul tempo trascorso dall'inizio alla fine.

In genere, quando stimiamo ad un livello elevato quando sappiamo meno di un progetto, stimiamo in giorni ideali poiché questo è un concetto più facile da correlare con la storia e l'esperienza passate rispetto a un numero astratto come un punto della storia. Soprattutto quando le storie di alto livello sono di natura più epica con pochi dettagli e possibilmente contengono elementi aggiuntivi se scomposte in un secondo momento.

Quando si effettua una stima a un livello più dettagliato, ad esempio una storia in un arretrato di prodotti stabilito, è possibile utilizzare entrambi gli approcci e sarebbero decisi dal team di ingegneri. Ci sono vantaggi per entrambi gli approcci e ogni squadra avrà la sua preferenza.

Tecniche di stima

Stime condivise Le stime non sono effettuate isolatamente. Vengono eseguiti in collaborazione dall'intero team di ingegneri insieme e includono design, database, server, interfaccia utente front-end, QA e altri esperti interfunzionali. Ciò evita i problemi di non considerare tutti gli aspetti del lavoro necessario per completare una funzione e garantisce che nessuno abbia l'onere o la sfortuna di sopra o sottovalutare la dimensione di una caratteristica. Il team combinato avrà tutti una visione che può essere discussa e concordata.

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 sul fatto che è di piccole dimensioni e, se si utilizzano i punti della storia, potremmo assegnarle una dimensione di due. La storia successiva potrebbe essere considerata più grande rispetto alla prima e gli daremmo una dimensione di cinque. Ciò suggerisce che un elemento grande è almeno il doppio di un elemento piccolo.

Vorremmo continuare questo esercizio con tutte le storie. Una volta completato, possiamo quindi affiancare tutti i piani piccola, media, grande ed extra grande e verificare il nostro dimensionamento per garantire che vi sia un livello di uniformità nella nostra stima.

Planning Poker Molto è stato scritto su Planning Poker; Ne ho parlato anche nel mio blog precedente. Una delle migliori risorse per capirlo è qui.

In sostanza, combina l'opinione di esperti, l'analogia e la collaborazione in team in un processo facile, veloce e affidabile.

Riunisce più esperti che sono più adatti per costruire un preventivo basato sull'esperienza tecnica e di dominio, un dialogo vivace e una solida giustificazione.

Velocità

La velocità è una misura della capacità di un team di portare a termine il lavoro in una determinata iterazione (o sprint).

Viene espresso come un intervallo, ad esempio, da 23 a 32 story point per sprint, soprattutto all'inizio della vita di un progetto. In genere, ciò è dovuto al fatto che, a meno che la stessa squadra non abbia lavorato in precedenza sullo stesso problema, è difficile descrivere esattamente quale sarà la velocità della squadra. Nota, ci riferiamo alla velocità di una squadra e non a quella di un individuo!

Usiamo la velocità per pianificare i nostri rilasci e adattare i nostri piani e pacchetti di lavoro mentre avanziamo in un progetto, consentendoci così di adattare le nostre previsioni per il completamento regolarmente e accuratamente durante l'esecuzione.

Quando iniziamo, siamo costretti a definire un intervallo di velocità con pochissimi dati. Possiamo usare valori storici se la squadra e lo spazio problematico sono gli stessi, il che spesso è meno probabile. Possiamo eseguire un'iterazione per avere un'idea della velocità da un team che sta effettivamente lavorando al progetto, ma questo è costoso e non funziona se devono ancora essere prese decisioni sull'accettazione di avviare un progetto. Oppure possiamo fare una previsione.

La previsione di una velocità implica prendere il valore di uno sprint di storie e dividerle in attività che vengono eseguite per completare la storia. Stimiamo il numero di ore che ogni attività richiederà, che include progettazione, sviluppo, test e così via, e valuteremo quanta capacità avrebbe il team in un dato sprint. Una capacità del 70 percento per una squadra libera è una buona base. Quindi, in una situazione semplice, se le ore totali a disposizione del team sono:

• 4 membri del team * due settimane * 40 ore a settimana = 320 ore
• Moltiplicato per la nostra capacità del 70% = 224 ore
• Somma tutte le attività delle funzionalità e smetti di contare a 224
• Prendi tutte le funzionalità completate, somma i loro punti storia e ottieni la tua velocità, diciamo 36
• Applicare il 20 percento 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 storia.

La velocità di solito varia nelle prime due o quattro iterazioni e quindi si stabilizza entro un piccolo intervallo di punti. Quindi, dove il nostro intervallo iniziale prima dello sprint uno era compreso tra 29 e 43, per lo sprint quattro potrebbe stabilizzarsi da 34 a 38. Questo ci dà quindi maggiore fiducia nella previsione della data di completamento finale.

Piani di buffering per rischio e incertezza

Tutti i progetti software sono caratterizzati da un livello di incertezza. Tale incertezza diminuisce man mano che avanzi nel progetto e si conosce sempre di più la nostra tecnologia, l'ambiente, le prestazioni e le esigenze del cliente e degli utenti.

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

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

Questo approccio ci offre una strategia credibile di mitigazione del rischio e dà al cliente fiducia in ciò che dovrebbe aspettarsi di vedere come risultato una volta completato il progetto.

Buffer di funzionalità

Con un buffer di funzionalità, prevediamo di fornire un determinato set di funzionalità, ma idealmente completeremo un ulteriore set di funzionalità. Ciò dovrebbe riflettere almeno l'insieme minimo di funzionalità che il cliente ritiene necessario per lanciare un prodotto valido, ma se tutte le varie influenze interne ed esterne lo consentono, è possibile che ne vengano fornite altre entro i tempi.

Pertanto, un cliente può decidere che le caratteristiche con la priorità più alta dal product backlog, sommando fino a 100 story point, sono le più importanti. Possono quindi prendere in considerazione funzionalità aggiuntive che si sommano a ulteriori 30 punti storia. Il team, quindi, pianificherà la consegna di 130 story point, con un minimo di 100 completati entro la fine della data di completamento prevista per il contratto a prezzo fisso indicato.

Alcuni pensieri di chiusura

Agile può essere un concetto molto difficile da cogliere e adottare pienamente. Questo non è meno vero quando si gestiscono argomenti sensibili come prezzo, ambito e durata. Sfortunatamente, so in prima persona che i clienti esigenti vogliono che tutte le cose vengano riparate in anticipo e sono ansiosi di incolpare il fornitore quando tutto inizia a disfarsi. Allo stesso modo, sono a conoscenza di fornitori che si impegnano, non rispondono e non rispondono alle esigenze dei clienti. Seguire un percorso Agile è fondamentalmente costruito su fiducia, buone relazioni e comunicazione stellare. Questi devono essere valori sostenuti da entrambe le parti al fine di mantenere un progetto sano con pari beneficio, 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 che le relazioni vadano male.

Ho lavorato con clienti che hanno avuto difficoltà ad abbracciare la natura adattiva di Agile e ad abbandonare un atteggiamento di comando e controllo. È difficile lasciarsi andare e riporre tutta la tua fiducia e fiducia in una squadra che non conosci. Spesso, i clienti potrebbero voler creare tutti i requisiti in anticipo come specifica di ciò che verrà consegnato. Questo dà loro una sensazione di fiducia che l'ambito di un progetto sia ben definito. Ma alla fine, questo non riesce a concretizzarsi come un approccio di successo. Se siamo vincolati all'ambito e alle richieste non realistiche in un contratto, i problemi sorgono molto rapidamente.

Sappiamo, quando adottiamo questo approccio con i metodi tradizionali, che la portata cambia, le incognite vengono scoperte o ciò che pensavamo che il cliente volesse non è più vero o fuori luogo. L'adozione di un approccio adattivo ai prezzi, alla pianificazione e all'ambito consente ai clienti di identificare veramente il proprio prodotto in modo che sia esattamente ciò di cui il mercato ha bisogno. Consente a un fornitore di essere anche reattivo, fantasioso ed efficiente. Sfruttare la collaborazione tra cliente e fornitore nella negoziazione del contratto è fondamentale.

I fornitori devono essere onesti e i clienti devono essere realistici su ciò che può essere ottenuto sin dall'inizio. Un venditore che promette obiettivi non realistici e poi aumenta i costi può vincere il contratto iniziale, ma perderà presto il favore di un cliente scontento. Troppo spesso le relazioni si interrompono a causa della mancanza di fiducia o confidenza tra le parti. La fiducia deve essere costruita fin dall'inizio e mantenuta per tutto il corso di un progetto. Un venditore deve essere flessibile e collaborare con le esigenze in mutamento. I clienti vogliono sempre di più; è una conseguenza naturale del fare affari. Ci deve essere uno scambio di valore uguale e vantaggioso tra le due parti. Per i clienti, stanno cercando di creare valore per la loro attività. Per i fornitori, dovrebbero cercare di creare valore creando relazioni durature con i clienti. L'osservanza dei valori e dei principi guida del Manifesto Agile è una solida base per formare relazioni forti, equilibrate e durature.

Sommario

Spero che questo ti abbia dato un'idea della pianificazione, della stima e della definizione di un prezzo per un progetto software Agile. Tutti gli approcci e le tecniche di cui sopra sono progettati per creare fiducia in un team e per creare fiducia nelle menti dei clienti su quanto tempo e quanto ci vorrà per costruire un prodotto software. E, in definitiva, per creare fiducia nel prendere la decisione di procedere.

Segui queste linee guida e sarai sicuro di trovare un percorso soddisfacente per dare vita al tuo prodotto software.