Ogni team ha una definizione diversa di cosa significa "fatto", ma è importante averne una e assicurarsi che una storia soddisfi i criteri definiti prima di essere accettata.
Alcuni criteri comunemente specificati dai team includono:
Senza un DoD ben definito, è facile trovarsi in una situazione in cui molte cose sono fatte a metà e nulla è veramente completo.
Cose come i livelli di rientro e lo spazio vuoto possono non sembrare importanti, ma avere un codice formattato correttamente va molto avanti verso la leggibilità e la manutenibilità. Le convenzioni dovrebbero essere discusse e concordate in team e poi seguite nel codice.
Le dimensioni dell’implementazione di un progetto aumentano, così come il tempo necessario per testarla. Senza una buona copertura dei test, il team di test non può scalare e gli sviluppatori alla fine vengono sepolti nei bug.
Gli sviluppatori devono provare lo sviluppo basato su test (TDD, Test Driven Development), scrivendo test di unità non riusciti prima del codice di produzione che soddisfa i loro requisiti. Il controllo qualità dovrebbe creare una serie automatizzata di test di accettazione per garantire che il sistema funzioni come previsto da un livello elevato.
Sono disponibili framework personalizzati, come Jackalope e Prosper, per semplificare l’ironia sulle API JCR al fine di garantire la produttività degli sviluppatori durante la scrittura di unit test.
Il sistema deve essere disponibile per la dimostrazione all’azienda alla fine di ogni iterazione. Mantenendo il sistema in stato demo-ready, il team sarà sempre all'interno di un'iterazione di essere pronto per la produzione e il debito tecnico può essere mantenuto a un livello manutenibile.
L’implementazione di un ambiente di integrazione continua consente di eseguire in modo semplice e ripetuto unit test e integration test. Separa inoltre le distribuzioni dal team di sviluppo, consentendo alle altre parti del team di essere più efficienti e di effettuare distribuzioni più stabili e prevedibili.
Se l’esecuzione degli unit test richiede molto tempo, gli sviluppatori eviteranno di eseguirli e perderanno il loro valore. Se la generazione e la distribuzione del codice richiedono molto tempo, le persone lo faranno meno spesso. La priorità è data ai tempi di realizzazione brevi, per garantire che il tempo investito nella copertura dei test e nell’infrastruttura CI continui a rendere il team più produttivo.
Gli strumenti di analisi del codice possono essere utili, ma solo se i loro rapporti portano ad azioni da parte del team di sviluppo. Senza ottimizzare l’analisi fornita da questi strumenti, i consigli che generano diventano irrilevanti e perdono valore.
Gli Scout di ragazzi hanno una regola: "Lascialo meglio di come l'hai trovato." Se tutti i membri del team di sviluppo si attengono a questa regola e fanno pulizia quando si imbattono in un casino, il codice migliorerà costantemente.
Le funzionalità YAGNI (You Aren Gonna Need It) sono implementate quando ci aspettiamo che avremo bisogno di qualcosa in futuro, anche se non ne abbiamo bisogno ora. Idealmente, dovremmo implementare la cosa più semplice che funzionerà oggi e utilizzare il refactoring continuo per garantire che l'architettura del sistema evolva con i requisiti nel tempo. Questo ci permette di concentrarci su ciò che conta e prevenire l’eccesso di codice e il creep delle funzioni.