Quando la documentazione, il test unitario, il controllo qualità e il refactoring devono essere eseguiti in uno sprint agile di 2 settimane?

Ci sono alcuni approcci che puoi prendere.

Sembra l'ultimo problema che vorrei affrontare la parte "work like madmen". Dovresti sforzarti per un ritmo sostenibile , che è un livello di sforzo che puoi sostenere indefinitamente. L'idea che hai bisogno di "lavorare come pazzi", ma non sono in grado di produrre un prodotto di qualità sembra essere un problema.

Come crei un ritmo sostenibile?

Dal punto di vista del processo, dai un'occhiata alla tua organizzazione del team. Sembra che la garanzia della qualità stia accadendo alla fine. Considera l'idea di un team interfunzionale che funzioni insieme. Non mettere la qualità alla fine, ma coinvolgere la qualità in ogni fase del percorso. Potresti voler sfruttare l'integrazione continua per raggiungere questo obiettivo - se hai tester dedicati, regolarmente (di notte?) Messi cambia nelle loro mani e ottenere un feedback. Utilizza i test automatici per assicurarti che ciò che hanno sia quasi corretto, almeno sulla base delle interpretazioni degli sviluppatori sui risultati attesi. Se riscontra problemi, aggiorna i test automatici per evitare che si ripetano.

Dal punto di vista del team, dai un'occhiata alla lunghezza dello sprint . La lunghezza è quasi sempre presentata in 1-4 settimane. 2 settimane si trova nella parte più breve dello spettro. Forse starai meglio con sprint più lunghi - aggiungendo una settimana o due in più.

Da una prospettiva di stima, considera la tua definizione di fatto . Quando è stata fatta una storia? Quando è implementato e testato sull'unità? Quando è integrato? Quando è stato integrato e superato i criteri di accettazione? Sembra che tu abbia bisogno di una solida definizione di fatto e stimare i punti della storia contro lo sforzo completo. Questo sforzo completo dovrebbe includere probabilmente il refactoring, i test unitari, i test di integrazione e lo sforzo di test di accettazione. Fai tutta la squadra parte dello sforzo.

La prima cosa da fare è riconoscere che il tuo attuale approccio non funziona. La quantità di compiti assegnati a ogni sprint sta causando la necessità di tagliare gli angoli e incorrere in debiti tecnici (ad es. Bug rilasciati ai clienti). Tale debito tecnico deve quindi essere ripagato negli sprint successivi, rallentando lo sviluppo futuro.

Hai chiaramente riconosciuto che hai un problema. Il tuo prossimo compito è quindi spiegare questo problema alla gestione. Si aspettano più di quanto possano essere consegnati e di conseguenza stanno danneggiando la compagnia. Comunicalo a loro.

Finalmente hai bisogno di una soluzione. Questa soluzione è di ridefinire quando un'attività è fatta . Ogni attività ha bisogno di tempo per il refactoring, unit test, test "QA" e documentazione. Pertanto, concorda con il team e la direzione che tutte queste attività devono essere svolte prima che un compito venga svolto. Quindi aggiusta le stime delle attività per consentire queste attività. Ciò significa che sono programmate meno attività in uno sprint. O accetta (come organizzazione) che meno può essere raggiunto in due settimane, o aumentare la durata dello sprint.