Il primo problema che vedo è che il processo di stima sta andando un po 'largo. Sì, gli sviluppatori dovrebbero avere voce in capitolo su quanto lavoro dovrebbero aspettarsi. No, questo non significa che l'aggiunta di un singolo pulsante a un modulo Web sia ora una storia di due sviluppatori-settimana (ma molti punti equivalgono al processo di stima della tua azienda). Se questo è lo stato attuale delle cose, allora tu, come project manager, dovresti fare un secondo tentativo.
In secondo luogo, sento "dall'inizio (progettazione) alla fine (implementazione e test delle unità)" e il primo pensiero che viene in mente è "stai sbagliando". I tuoi test unitari fanno parte del tuo lavoro di progettazione come team di sviluppo / sviluppo e dovrebbero accadere per primi; prendi i requisiti di base, distillali in una semplice "lista di controllo" di "If ... When ... Then ..." - digita le frasi e poi converti quelle frasi in una serie di test di base che affermano che il programma incontra quelli asserzioni e quindi i requisiti. Ciò accade prima di scrivere una riga del codice di produzione che soddisfi le asserzioni dei test. Se i tuoi test unitari arrivano per ultimi, dopo che hai già implementato il software, perdi diversi aspetti chiave del test dell'unità; in generale, i tuoi sviluppatori non possono "programmare in verde", fornendo così una definizione minimalista di "fatto" che incoraggia implementazioni più leggere (ma mantenibili) che fanno ciò che il cliente vuole senza sprecare lavoro facendo più cose che il cliente non vuole ancora (e potrebbe anche non essere disposto a pagare T & M perché, non è quello che ti ha chiesto di fare).
Per quanto gli sviluppatori "possiedono" le loro funzionalità, c'è un sì e un no. Prima di tutto, uno scossone piuttosto comune da parte di "team auto-organizzanti" è una tendenza per gli sviluppatori di andare in coppia o in tre e lavorare su cose che sanno meglio. Supponendo che tu abbia un buon set completo di competenze sviluppatore in modo tale che il team possa coprire tutto il lavoro da svolgere in ogni iterazione in questo modo, puoi semplicemente lasciare che questo accada; è una buona cosa per velocità, dato che gli sviluppatori restano concentrati e hanno familiarità con le aree del codebase in cui hanno lavorato dall'iterazione all'iterazione.
Tuttavia, uno sviluppatore che possiede una caratteristica per la vita è una mentalità pericolosa, perché abbassa il "numero di camion" della tua squadra (definito francamente come "quante persone potrebbero essere investite da un camion prima che la squadra non potesse funzionare , visto lo scenario peggiore di persone specifiche colpite e la conseguente perdita di conoscenza.) Se il tipo a cui è stata assegnata la funzionalità "File Import" del software e lo ha posseduto per 2 anni va in vacanza per tre settimane, prende FMLA estesa vattene, cambia lavoro o, in caso estremo, viene investito da un camion e muore, ora non hai nessun altro che conosca quella funzione perché quell'area del codebase è stata l'esclusiva per un ragazzo da anni. altrimenti si familiarizza con questo particolare pezzo del codebase, perderai velocità significativa e ti aprirai anche ad altri problemi con i difetti, dato che il nuovo ragazzo che ha appena familiarità con il funzionamento del codice base ora può rimanere ignobilmente igno Una sfuriata di cose che può e non può cambiare al suo interno.
Invece, dovresti cercare di coltivare una divisione del lavoro che mantenga il tuo numero di camion almeno 2 o superiore, e in una squadra più grande (una dozzina o più) più vicina a 3 o 4. In questo modo se un ragazzo non può fare il lavoro, per qualsiasi motivo, ci sono molte altre persone che possono entrare. A volte, i team si scuotono naturalmente in questo modo, specialmente se si introducono alcune tecniche XP come la programmazione in coppia o in stile dojo (un ragazzo scrive in un nuova asserzione basata su requisiti che il codice non soddisfa, il prossimo ragazzo poi codifica per passare quel test, quindi aggiunge un'altra richiesta di requisito che fallisce e la trasmette). Per definizione, in queste situazioni, hai più occhi che guardano il codice, lo sviluppano, familiarizzano con esso.
Nel complesso, l'idea di Agile è promuovere lo sviluppo "leggero". La tua squadra sembra impantanarsi in minuzie di processi e documentazione, quando l'attenzione principale, come per il Manifesto Agile, dovrebbe essere sui membri del team e le loro interazioni e, naturalmente, sul funzionamento, codice funzionale. I processi inerenti ad Agile sono un mezzo per un fine e non c'è un modo per seguire Agile; anche i framework Agile primari come SCRUM sono malleabili in base alle esigenze di un'azienda, di un team e persino di giorno in giorno (assicuratevi solo di tenere a mente le idee di base dei valori forniti da questi processi quando apportate tali modifiche).