I team Agile dovrebbero offrire nuove funzionalità quotidianamente?

I crimini commessi in nome di Agile in questi giorni mi rendono triste. Molte persone hanno difficoltà a effettuare questa transizione.

Manifesto Agile: "Diamo valore alle persone e alle interazioni su processi e strumenti.". Quando le persone stanno chiaramente soffrendo, il processo è sbagliato. Non voglio dirti come farlo, ma condividerò come lo faccio.

Nei miei team, la parte importante è evitare di impegnarsi in un codice repo condiviso che viene spezzato in modi che sprecheranno il resto del tempo del team. Solo in questo senso, mi sforzo di "consegnare il codice di lavoro ogni giorno". Non rompere il QA. Non bloccare altri sviluppatori. Idealmente non controllo mai eventuali errori. (ha ha).

L'implicazione non è che devi commettere qualcosa ogni giorno. L'implicazione è che dovresti solo commettere cose buone, in modo che ogni giorno tu possa ottenere una build di tutte le cose buone che qualcuno ha commesso. In questo modo la squadra continua a sparare su tutti i cilindri.

Nelle mie squadre il controllo qualità è costante. Costruisco prodotti commerciali, quindi il progetto non finirà mai fino a quando il prodotto non sarà obsoleto. Gli ingegneri del controllo qualità testano le funzionalità disponibili per il test. Gli ingegneri del QA hanno sempre un backlog. Non c'è mai abbastanza tempo di QA per testare o automatizzare tutto ciò che vorremmo idealisticamente.

Se gli sviluppatori hanno bisogno di più giorni prima di unire le modifiche per una funzionalità o una correzione, va bene, incoraggiato se aiuta a ottenere il codice giusto prima di rischiare il nostro tempo. Gli sviluppatori possono eseguire il commit del codice nel repository o nella filiale privata senza influire sul team o sul controllo qualità. Gli sviluppatori possono eseguire test di unità o automazione di regressione sul codice generato dal repository o dal ramo privato di uno sviluppatore. In casi particolarmente rischiosi, un ingegnere della qualità del lavoro collaborerà con lo sviluppatore per testare prima della fusione, per proteggere la squadra dal ritardo.

In questo senso, pratico ciò che vogliono i tuoi manager. Quasi ogni giorno negli ultimi 12 anni i miei team di sviluppo hanno avuto codice che funziona nel repository condiviso. Siamo sempre quasi pronti per la spedizione. Occasionalmente non raggiungiamo questo obiettivo, ma non ci preoccupiamo troppo. A volte è intenzionale, per soddisfare importanti cambiamenti di strumenti o difficili fusioni.

Il Manifesto Agile, per me, riassume il meglio del nuovo modo di pensare sul processo di sviluppo emerso negli anni '90. Sono praticamente un vero sostenitore di questi principi, ma i dettagli del processo possono variare. Per come la vedo io, il punto di Agile è di adattare il tuo processo alle esigenze del tuo prodotto e dei tuoi clienti, non di essere uno schiavo da elaborare.

Se ieri avevi un software funzionante, perché non funzionerebbe oggi? Se non hai terminato nessuna attività oggi, la build di oggi sarà la stessa di ieri. Le build giornaliere e il ritmo di sviluppo sono cose separate. Solo perché hai build giornaliere non significa che hai nuove funzionalità in ogni build.

Quando finalmente alcune funzionalità vengono completate e il check-in nel ramo principale, è necessario disporre di un processo automatizzato che crea il software ed esegue i test. Se c'è un problema con la creazione o l'esecuzione di test, il team viene informato e si concentra sui loro sforzi per farlo funzionare di nuovo. Ecco come funziona CI e come ti aiuta a rilasciare il software di lavoro tutto il tempo.

Risposta breve: No . Semplicemente non può essere compiuto ogni giorno.

Tuttavia, il team agile doveva consegnare pezzi di lavoro o storie di utenti in ogni sprint . Di solito, si tengono riunioni di stato ogni giorno per vedere i progressi e gli impedimenti.

Riguardo al software di qualità , i processi di integrazione continua (CI) assicurano che il controllo di qualità sia applicato a piccoli sforzi (check-in) e fatto con la frequenza necessaria. Mira anche a migliorare il quality of software ea ridurre il tempo necessario per consegnarlo, sostituendo la pratica tradizionale di applicare il controllo di qualità dopo aver completato tutto lo sviluppo.

No, non ci dovrebbero essere aspettative di offrire nuove funzionalità ogni giorno. Non tutte le funzionalità possono essere scomposte in dimensioni così ridotte da consentire a uno sviluppatore di completare la funzionalità in circa 6 ore di sviluppo.

Se stai facendo la mischia, dovresti farlo agli sprint di minimo 2 settimane, con caratteristiche dimensionate in modo da impiegare all'incirca da 0 a 8 giorni. La promessa al proprietario del prodotto è quella di fornire un codice di lavoro corretto, testato e verificato che possa essere messo in produzione alla fine dello sprint. (NOTA: non è necessario metterlo effettivamente in produzione ma l'obiettivo è che potrebbe esserlo se lo si volesse)

Una buona metodologia suggeriva di installare un server CI (Continuous Integration) in cui si automatizzava la creazione di almeno una build giornaliera di software funzionante. L'idea è di controllare il codice non appena finisci la funzione in modo che possa essere nel prossimo ciclo di sviluppo e poi nelle mani del QA per i test.

Ricorda che l'obiettivo è quello di avere funzioni fatte e testate entro la fine dello sprint! Non vorrai fare in modo che il QA attenda fino all'ultimo giorno dello sprint per costruirti la build e poi farli testare tutte le funzionalità. Non avranno il tempo di testare tutto e non avrai tempo per correggere eventuali bug ...

Se non riesci a configurare un server CI, la pratica dovrebbe essere che devi creare manualmente una nuova build per il QA ogni volta che uno sviluppatore controlla il suo codice finito e afferma che ha finito con una funzione e pronto a consegnare al QA .

In realtà dipende dalla dimensione del progetto; se il progetto è di grandi dimensioni non esiste un modo fattibile per raggiungere questo obiettivo.

Le build giornaliere (o anche più spesso) che escono da strumenti di integrazione continui, non significano software funzionante; significa a malapena codice compilabile.

Ci sono molti progetti là fuori che forniscono build giornaliere, che grazie all'integrazione continua, sono software funzionanti. Almeno in teoria.

Significa che non necessariamente contiene nuove funzionalità. Forse alcune correzioni di bug minori, o niente del tutto.

In teoria, se non riesci a fornire più lavoro al tuo QA ogni giorno, devi aumentare il numero di sviluppatori o ridurre il numero di tester. Un'idea terribile!

Il tuo compito è di portare a termine le cose.

Dì al responsabile della qualità che avranno qualcosa da testare una volta terminato. Devi spiegare loro perché.

Penso che tu sia confuso dall'idea di "CI". Potresti voler visitare questo eccellente articolo di Martin Fowler su come l'IC funziona nella pratica . Dovrebbe rispondere correttamente alla tua domanda.