Stiamo avendo una disconnessione tra lo sviluppo e le esigenze aziendali.
Le aziende mi chiedono di produrre un elenco accurato di deliverable per una data fissa e uno sviluppo difficile da prevedere spinge indietro dicendo che può solo produrre un elenco accurato dell'80 o del 90%.
Quindi la mia domanda è, come possiamo risolvere questo problema? Come fornire un elenco accurato di risultati finali settimane prima che siano completati e completamente testati?
La disconnessione è che nessuno dei due lati capisce la situazione; il business vuole ciò che vuole quando lo vuole e pensa che l'IT può solo fornire magicamente indipendentemente dalle caratteristiche e dai tempi.
Sebbene sia piacevole per gli operatori avere tanta fiducia nell'IT, è una "fiaba della madrina" in azione. Non è Babbo Natale, non ci sono elfi magici, tutto richiede pianificazione e lavoro, tempo ed esperienza, e non è mai perfetto.
Il tempo è incomprimibile. Non può essere creato. Può certamente essere sprecato però.
La precisione può essere misurata solo dopo aver terminato .
La confidenza è una misura statistica basata su stime e matematica magia nera .
Se dici "possiamo avere queste 10 funzionalità fatte in 3 mesi con un livello di confidenza dell'80%" questo implica un livello di confidenza migliore del 97,79% per ciascuna caratteristica [si moltiplicano, non è una media]. Quello che probabilmente intendi è "8 su 10 di noi pensano che possiamo farlo in 3 mesi", che non è la stessa cosa.
Tutto questo a parte, questo è un problema fondamentale di gestione del progetto, non limitato all'IT. Non ha nulla a che fare con Agile. Non esiste una sfera di cristallo che garantisca un elenco accurato di risultati con mesi di anticipo. Le aziende devono comprendere le variabili, ma soprattutto i rischi coinvolti. L'IT deve fornire le stime insieme ai rischi.
Esistono metodi per aiutare a misurare e migliorare, ma gnat's commentare sul miglioramento costante è il consiglio immediato più pratico - se il lato economico lo farà.
Se no, allora indovina, prometti, fallisci, chiedi scusa, misura e migliora, come tutti gli altri. E proprio quando i tuoi numeri iniziano ad allinearsi, la dinamica del team cambierà e li rimanderà di nuovo, o il business cambierà direzione in nuovi domini, riavviando la curva di apprendimento.
Questa è la natura della gestione del progetto.
Joel Spolsky ha scritto un buon blog sulla creazione di orari - Pianificazione basata sull'evidenza
Software developers don’t really like to make schedules. Usually, they try to get away without one. “It’ll be done when it’s done!” they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten...
Le idee principali sono -
Suddividi il lavoro in compiti veramente piccoli che possono essere stimati in ore (suggerisce un massimo di 16 ore).
Assicurati che tutti gli sviluppatori registrino il loro tempo rispetto alle attività e utilizzino la differenza tra il tempo registrato e il tempo stimato per correggere le stime future.
Ricalcola regolarmente la tua pianificazione sulla base dei dati dell'ultima stima / ora registrata, in modo che tu possa vedere con largo anticipo che la data della tua nave sta scivolando e aggiustare di conseguenza la tua data / serie di funzioni.
È il tipo di processo che probabilmente richiederà alcune versioni prima che diventasse veramente accurato, quindi potrebbe non aiutarti in questo momento. Potrebbe tuttavia essere qualcosa da prendere in considerazione e potrebbe aiutarti a respingere le richieste di una data di rilascio definitiva per questa versione.
Se non altro è una lettura interessante come la maggior parte del blog di Joel.
Ottieni l'80% delle funzionalità e assegna un livello di confidenza del 99% in base al periodo di tempo originale.
Ad esempio:
Se c'è una fiducia dell'80% per 10 funzionalità in 3 mesi, allora fornisci loro un elenco di 8 caratteristiche (80% di 10) per un periodo di tempo di 3 mesi con una confidenza del 99%.
Dovresti anche mostrare quali sono i rischi, come li mitigherai e cosa succede se si verifica il rischio.
Aggiorna
Molte volte il lato commerciale chiede stime e livelli di fiducia per prendere le giuste decisioni di marketing.
Adoro i blog di Joel . Vorrei che più aziende lo leggessero e capissero i principi dietro la corretta gestione del progetto di sviluppo e le stime temporali. Purtroppo molte aziende sono ancora bloccate in una mentalità di produzione: "Se riesci a creare 1 parte in 1 ora, perché non puoi costruire 10 parti in 10 ore?"
Come veri ingegneri, leggiamo libri, andiamo in siti come lo scambio di libri e partecipiamo alla comunità. La corretta stima del tempo riguarda tanto la matematica quanto la gestione delle persone. Devi gestire i tuoi stakeholder (boss, clienti, project manager, ecc.) Senza sovraccaricare il tuo staff tecnico con programmi e elenchi di funzionalità poco pratici.
Troppo spesso la direzione vede l'obiettivo finale e vuole capire il tempo e gli sforzi per arrivare al traguardo. È qui che i progetti si disgregano e le stime diventano finzione. Costruisci un piano di progetto in cui il tuo livello di fiducia inizia alto e finisce basso.
Se ci sono 5 funzioni e 6 mesi, la tua scala di confidenza potrebbe essere simile a questa:
Caratteristica 1: 90%
Caratteristica 2: 80%
Caratteristica 3: 60%
Caratteristica 4: 30%
Caratteristica 5: 5%
Ti senti molto sicuro di poter completare la caratteristica 1 in 6 mesi. Tuttavia, man mano che le funzionalità iniziano ad aggiungerti, ti senti sempre meno sicuro di riuscire a superare tutte e 5 le funzionalità di 6 mesi. Mentre il progetto progredisce e le funzionalità sono completate, questa scala di confidenza viene adattata. Come puoi vedere, l'unico modo per essere ragionevolmente sicuri nel completamento del progetto in tempo è quello di rilasciare solo la caratteristica 1.
Per ottenere un livello di confidenza significativamente elevato nel completamento di una serie di funzionalità, la scala di confidenza deve estendersi fino a quando ciascuna delle funzionalità richieste si trova entro un intervallo desiderabile e solo all'ultima caratteristica la fiducia inizia a scivolare. Questo porta comunque le proprie difficoltà. Più a lungo un progetto assume il massimo rischio. Questo è il motivo per cui mi piace l'idea di SCRUM.
Disclaimer Tutti i numeri che ho dato sono costituiti sulla base dell'analisi di una società fittizia. Ogni gruppo di ingegneri è diverso. I numeri sono qui solo per illustrare che quando le caratteristiche aumentano, il livello di confidenza cala in modo significativo.
C'è una matematica reale che dovrebbe essere usata quando si eseguono queste scale. Ho deliberatamente e vergognosamente deciso di non usare la matematica per garantire che i miei numeri si sommino.
La risposta a una riga
Probabilmente non c'è nulla che tu possa fare ora, ma puoi pianificare di migliorare nel tempo.
Un'analogia
Chiedi ai tuoi partner commerciali quanto tempo impiegheranno loro come squadra per falciare l'erba che circonda uno degli hotel della tua città. Molto probabilmente non saranno in grado di farlo, perché non hanno mai falciato il prato di un hotel prima. Tuttavia, se tagliano quel prato, e poi chiedi loro di stimare quanto falciare il cantiere di un altro hotel, saranno in grado di darti una stima leggermente migliore.
Continua così nel corso di tutta l'estate, e dopo qualche mese probabilmente ti potranno dire con un livello abbastanza alto di precisione quanto tempo ci vorrà per un hotel, dopo aver visto e misurato l'hotel in persona. Anche se ogni hotel è diverso, sarà in grado di suddividere il lavoro in pezzi ("falciare attorno alla piscina", "falciare attorno all'ingresso", ecc.), Stimare ogni pezzo in modo ragionevolmente accurato, e quindi stimare l'intero lavoro. / p>
Pianifica di fare meglio
Non c'è modo di guardare una specifica o un'idea e stimare quanto ci vorrà. Tuttavia, se sei in grado di suddividere un progetto in una serie di storie e di stimare con precisione la quantità di tempo che occorrerà per fare ogni storia, puoi quindi utilizzare la velocità storica delle tue squadre per prevedere quando quelle storie saranno essere fatto. Con una squadra matura questo può dare risultati abbastanza precisi. Non sarai ancora corretto al 100%, ma la probabilità è alta che sarai molto vicino.
Il trucco qui è che funziona solo per team esperti e maturi. Ci sono due variabili in gioco che sono difficili da stabilizzare. Primo, la tua squadra ha bisogno di una velocità stabile. Cioè, devono essere in grado di produrre regolarmente unità di lavoro X in un determinato periodo di tempo. Una volta che sono in grado di farlo, diventa molto, molto più facile stimare nuove storie perché hanno un quadro di riferimento ("abbiamo trascorso il tempo Y su feature A il mese scorso, e la caratteristica B è tanto difficile quanto la caratteristica A, quindi ci aspettiamo di passare il tempo Y anche sulla funzione B ").
Quando hai quella velocità stabile, devi usare quello che hai imparato per stimare le storie. Ciò significa che le storie devono essere piccole, non più di pochi giorni di lavoro. Una volta che sei in grado di dimensionare accuratamente le tue storie, le scadenze diventano in gran parte un esercizio di matematica.
Tutto ciò detto, anche i migliori team non possono prevedere cosa accadrà nel corso di diversi mesi. Assicurati che i tuoi rilasci (anche se solo le pietre miliari interne) siano relativamente brevi. Lavora per un paio di mesi. Raggiungi questo obiettivo, quindi utilizza i dati per capire quanto puoi fare nei prossimi mesi o due. Colpisci quel goall, poi schiocca, risciacqua, ripeti.
Riepilogo
Un ultimo pensiero
Questo non è un problema di ingegneria del software e questo non è un problema del team aziendale. Questo è un problema organizzativo. L'organizzazione deve imparare a collaborare per determinare quanto può essere fatto in base a quale data. Non sei contro di loro, è noi .
Questo commento è di gran lunga troppo breve per spiegare correttamente perché la stima è difficile e come farlo meglio.
Stima del software: Demistificare la Black Art di Steve McConnell è la lunghezza giusta.
Often referred to as the “black art” because of its complexity and uncertainty, software estimation is not as difficult or puzzling as people think. In fact, generating accurate estimates is straightforward—once you understand the art of creating them. In his highly anticipated book, acclaimed author Steve McConnell unravels the mystery to successful software estimation—distilling academic information and real-world experience into a practical guide for working software professionals. Instead of arcane treatises and rigid modeling techniques, this guide highlights a proven set of procedures, understandable formulas, and heuristics that individuals and development teams can apply to their projects to help achieve estimation proficiency.
Discover how to:
- Estimate schedule and cost—or estimate the functionality that can be delivered within a given time frame
- Avoid common software estimation mistakes
- Learn estimation techniques for you, your team, and your organization * Estimate specific project activities—including development, management, and defect correction
- Apply estimation approaches to any type of project—small or large, agile or traditional
- Navigate the shark-infested political waters that surround project estimates...
Ricorda che nella maggior parte delle organizzazioni, la data di consegna stimata tende ad essere la prima data in cui nessuno può dimostrare che non verrà eseguita. Questo fa parte del motivo per cui la maggior parte delle organizzazioni tende a sottostimare le pianificazioni di un fattore 2 e riescono a raggiungere tale programma solo perché eliminano una media della metà delle caratteristiche promesse.
Leggi altre domande sui tag code-quality release-management agile time-estimation