Spesso sento parlare di processi di agilità, ma mi sembra che sia (quasi) sempre legato all'organizzazione del team e ai processi di consegna. Esso (quasi, ancora una volta) non arriva mai in fondo alla bottiglia: lo sviluppo stesso.
Esistono metodi agili che mirano specificamente a problemi tecnici , come metodologie di sviluppo, gestione di bug / errori, pratiche e ideologie durante la codifica? O non riesco a capire di cosa si tratta Agile durante la codifica in una squadra?
Quello che senti è principalmente Scrum. E Scrum non si occupa di pratiche tecniche. E molti considerano che un fallimento di Scrum, come l'adozione di Scrum senza l'adozione di pratiche tecniche appropriate, si traduce in "Flaccid-Scrum".
La programmazione eXtreme, che è molto meno conosciuta e adottata dalla pratica Agile, d'altra parte si occupa molto delle pratiche tecniche. Le pratiche tecniche come test automatici, refactoring, paia di programmazione e distribuzione continua sono alla base di XP. E XP ritiene che siano quelle pratiche che consentono uno sviluppo veloce, sostenibile e prevedibile.
Il manifesto agile definisce 4 valori e 12 principi . Nessuno di loro è tecnico: si tratta solo di mentalità e lavoro di squadra. Tuttavia, ogni valore e principio ha implicazioni tecniche. Questi sono incorporati in varie pratiche che sono state inizialmente promosse dall'uno o dall'altro metodo agile.
Senza entrare in una metodologia specifica, i processi agili sono tutti iterativo e incrementale :
Implicazioni tecniche generali:
I processi di sviluppo iterativo e incrementale richiedono ovviamente input che consentano di identificare gli incrementi. Solitamente questo è ottenuto con storie di utenti o casi d'uso . Mappatura story User o use case 2.0 sono pratiche efficaci che suddividono i requisiti in blocchi implementabili.
Potresti obiettare che alcune delle pratiche sopra menzionate non sono necessariamente legate all'agile. E avrai ragione: Agile non si tratta di pratiche tecniche. Ma sono necessarie pratiche tecniche per abilitare l'agilità.
Un problema fondamentale nello sviluppo del software è che i requisiti effettivi per i sistemi sono, nell'istanza generale, non chiari e che, peggio, cambiano (per un numero qualsiasi di ragioni). Ci sono casi in cui questo non è vero ma sono l'eccezione, non la regola.
Le persone non sanno quello che vogliono (anche se di solito capiscono quale problema stanno cercando di risolvere / risolvere) e tutti spesso vengono a conoscenza del divario tra ciò che vogliono e ciò che chiedono quando il prodotto viene consegnato.
Gli approcci "Agili" allo sviluppo del software mirano ad accorciare il ciclo di feedback fornendo poco e spesso per poter imparare dal feedback e adattare i requisiti per adattarsi. Un sacco di discussioni in questo settore sono intorno a fornire valore.
Così agile non si tratta di tecnologia (lo stesso vale per i processi di produzione "Lean" che hanno molto in comune). Detto questo, ci sono un certo numero di pratiche tecniche che facilitano l'agilità indipendentemente dalla metodologia - le cose che rendono il cambiamento gestibile, che lo rendono facile da consegnare ad alta cadenza, e così via - quindi è ragionevole voler parlare di problemi tecnici in un contesto agile.
Un'ultima cosa che nasce dall'obiettivo di essere agili (o snelli) è il valore della comunicazione e dello sviluppo delle persone: la mischia (per esempio) è, o almeno può essere, un mezzo per facilitare la comunicazione tra ingegneri e, fatto giusto, per esporre problemi che ostacolano la consegna
Leggi altre domande sui tag development-process programming-practices agile development-methodologies