In che modo SCRUM gestisce diversi progetti sullo stesso prodotto con team diversi?

Leggi di nuovo il Agile Manifesto . La clausola chiave è alla fine "mentre c'è valore negli articoli a destra". La parola Agile viene utilizzata più e più volte per giustificare la mancanza di documentazione. Questo non è mai stato l'intento dei firmatari.

Uncle Bob lo mette al meglio. "Produrre nessun documento a meno che non sia necessario è immediato e significativo." Ma di nuovo il "meno" di questa clausola viene spesso ignorato.

Gli sviluppatori non amano la documentazione, quindi queste sono ottime fonti per riportare in modo errato.

Quindi non incolpare Agile per questo problema, incolpiamo la squadra originale. Ancor più fondamentalmente, incolpare la direzione per la richiesta di documentazione "immediata e significativa" sulla loro partenza.

Tuttavia, la colpa non risolve il tuo problema. Ho paura che l'unica soluzione sia scavare nel codice, guardare il software, parlare con i tuoi utenti. Impara dagli errori dei tuoi predecessori e crea una documentazione immediata e significativa che il resto del team può leggere, in modo che tu possa imparare gli uni dagli altri.

Non penso che questo sia un "problema agile". Scrum è considerato un processo a bassa documentazione. Ma allo stesso tempo è un processo basato sul valore aziendale . Quindi, se la gestione è focalizzata sul valore del business, essi concideranno il trasferimento della conoscenza tecnica - inclusa la documentazione - come un alto valore commerciale alla chiusura di qualsiasi progetto, se ci sono buone probabilità che il progetto venga riaperto in una fase successiva.

Tuttavia, di tanto in tanto accade (leggi: quasi ogni volta) che il management perde l'attenzione quando un progetto viene consegnato a un cliente. La loro attenzione tende a vagare verso altri progetti generatori di entrate. In tal caso, l'unica opzione è utilizzare i primi sprint del nuovo progetto per fornire le conoscenze necessarie per riaprire il progetto. Ciò significa molto controllo del codice, colloqui con i programmatori, architetti, utenti, ecc. Più tempo che documentazione se c'era già, ma temo che questo sia solo un dato di fatto.

Questo non è un problema agile come ho detto all'inizio. Prima di agile dovrai affrontare gli stessi problemi o anche peggio: una documentazione che non è aggiornata. Almeno questo non è un problema nei progetti Agile, perché si crea solo la documentazione QUANDO E SE è necessario.

Saluti, Morten

Ho sentito da persone che sono solo tangenzialmente "Agili" che Agile non tratta di pianificazione / test / documentazione. Vedi La risposta di Pidr per altro.

Anche se la documentazione potrebbe non essere presente, mi auguro che ci siano test, si spera espressi in termini di requisiti aziendali. La prima cosa che voglio fare quando passo in un nuovo codebase è guardare i test. Tanto meglio se sono qualcosa sulla falsariga dell'uscita di Cucumber. Questo ti consentirebbe almeno di accedere al dominio e iniziare a capire come modificare il dominio.

Per me sembra un po 'stupido cambiare il team di sviluppo completo e sostituirlo con un nuovo team di sviluppo. Almeno molte persone di base dovrebbero rimanere per trasferire le conoscenze. Altrimenti compaiono rischi aggiuntivi non necessari.

Sfortunatamente, succede così. Questo è il caso dei progetti realizzati per tesi in università, ad esempio. Le persone si diplomano con questi progetti che impiegano 8 mesi. Una volta laureati, iniziano a lavorare e non hanno molto tempo per darti informazioni specifiche sul progetto stesso, e questo è il caso dei capi progetto, risorse come i programmatori è il caso peggiore. Diventano capi progetto un anno dopo e non ricordano cosa hanno sviluppato.

In altre parole: un modello in cui personale per ogni progetto cambierà sempre e dove le risorse vengono condivise di volta in volta. Bothersome, sì. Ma questo è quello che abbiamo.