Per quanto riguarda il punto due della lista ossia la definizione del calendario delle date di consegna (il commitment), il tempo di calendario dipende in modo lineare dallo sforzo richiesto dal progetto come determinato dalla stima e dalla percentuale di tempo dedicata al progetto (es. tempo piento o metà al progetto e metà ad un altro progetto). In XP il dato storico della velocità del team (quanti story point o pomodori vengono prodotti al giorno - ciao RiccardoM -) permette di passare facilmente dalla stima in giorni ideali alla stima in giorni di calendario.
La cosa è nota e resta sempre sorprendente: il tempo di calendario non dipende dal numero di persone che vi lavorano, cioè allocare più persone ad un progetto che è in ritardo non porta ad anticipare la consegna:
- col crescere del numero di persone il costo della comunicazione necessaria cresce esponenzialmente
- come spiega la teoria dei vincoli è il passo più lento del flusso di lavoro a determinare la velocità di produzione del team (ad esempio il tempo di accettazione dell'utente o il tempo di definizione del disegno) e quindi la velocità si aumenta se si individua e si interviene nel punto critico
In sostanza è il processo (metodo) impiegato e la fase del progetto in cui ci si trova che determina gli skill e il numero di persone utile al progetto e non viceversa come mostra questa figura di esempio:
Per ridurre i tempi di consegna di un progetto quindi più che aumentare il numero di persone del team serve aumentare:
- la qualità delle persone coinvolte (competenza, esperienza, capacità) in modo che sappiano riconoscere le inefficienze ed individurne le soluzioni
- la capacità delle persone di lavorare in modo coordinato (la coesione del team)
- il processo di sviluppo effettivamente applicato dal team
Come ci si accorge allora che le persone coinvolte id un progetto sono meno di quelle che realmente servivano?
Personalmente lo avverto quando durante un progetto noto che le attività di un certo tipo/ruolo non vengono fatte perché sono assenti questi skill nel team (cosa facile da prevedere in fase di stima) o le persono che hanno gli skill sono troppo impegnate per esercitarli (anche questo è possibile prevedere) e questo crea delle conseguenze negative sui tempi e sulla qualità. Ecco alcuni esempi:
- le stime sono spesso sottovalutate perché non c'è tempo ne di racogliere e organizzare adeguatamente i requisiti ne di abbozzare il progetto della soluzione ne di fare una stima su basi certe
- il reale stato di avanzamento del progetto è sconosciuto e parti che si pensavano finite e funzionanti sono incomplete o non funzionano perché nessuno ha il tempo di definire i rilasci e controllare i risultati
- durante lo sviluppo di nuove funzionalità emergono problemi nel codice che non erano stati considerati e che impattano grosse parti del sistema e ogni volta ch un programmatore utilizza una libreria scritta da un suo collega emergono problemi di integrazione perché nessuno ha tempo di considerare l'architettura complessiva del sistema
- quando l'utente prova la funzionalità rilascita sul suo PC avvendono numerosi errori run-time dai controlli, dal db, dal framework perché i programmatori non hanno avuto tempo di documentarsi sulla tecnonogia impiegata.
Tags : Team Work | Agile | Pratiche |