I team Agile dovrebbero offrire nuove funzionalità ogni giorno?

La mia azienda è nel mezzo di una transizione dallo sviluppo a cascata ad Agile / Scrum. Tra le altre cose, ci viene detto che l'aspettativa è per noi di avere nuove funzionalità funzionanti, testabili (dal QA) alla fine di ogni giornata.

La maggior parte dei nostri sviluppatori perde circa 2 ore al giorno a causa di riunioni e altre spese generali aziendali. Ciò significa che in ogni dato periodo di 6 ore (nella migliore delle ipotesi), dobbiamo progettare, scrivere, testare l'unità, costruire e distribuire (con le note di rilascio) un codice sufficiente per produrre una funzionalità completa con cui il QA possa giocare. Comprendo che le note di build / deploy / release potrebbero essere automatizzate con un'adeguata configurazione CI ma non siamo ancora arrivati.

Abbiamo anche un grande contingente offshore che scrive il nostro codice lato server e la differenza di 12 ore rende questo ancora più difficile.

Cerchiamo di distribuire le storie in sezioni verticali strette e profonde al fine di completare le funzionalità end-to-end il più rapidamente possibile, ma la maggior parte dei giorni mi sembra piuttosto frenetica e spesso sorprendo le persone a prendere scorciatoie stupide e fragili per garantire che il QA abbia la loro costruzione. Questo problema si aggrava dopo uno sprint in corso da un paio di giorni, quando gli inevitabili difetti iniziano a comparire e devono rientrare nella stessa finestra di 6 ore.

È un ritmo normale per i team Agile? Anche se riusciamo a implementare una configurazione CI, non riesco a vedere come saremo in grado di sostenere questo ritmo e creare comunque software di qualità.

Modifica: ci sono diverse buone risposte qui. Mi ha fatto capire che quello che stavo davvero chiedendo è che i team Agile dovrebbero offrire nuove funzionalità ogni giorno. Ho aggiornato il titolo di conseguenza.

I crimini commessi in nome di Agile in questi giorni mi rendono triste. Molte persone fanno fatica a fare questa transizione.

Manifesto agile: "Apprezziamo le persone e le interazioni rispetto a processi e strumenti". Quando le persone sono chiaramente ferite, 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 repository condiviso che è rotto in modo da perdere tempo per il resto del team. Solo in questo senso, mi sforzo di "consegnare il codice di lavoro ogni giorno". Non interrompere il controllo qualità. Non bloccare altri sviluppatori. Idealmente, non controllo mai alcun bug. (ah ah).

L'implicazione non è che devi impegnare qualcosa ogni giorno. L'implicazione è che dovresti commettere solo cose buone, in modo che ogni giorno puoi ottenere una build di tutte le cose buone che chiunque ha commesso. In questo modo il team continua a sparare su tutti i cilindri.

Nei miei team il controllo qualità è costante. Costruisco prodotti commerciali, quindi il progetto non finisce mai fino a quando il prodotto non sarà obsoleto. Gli ingegneri del QA testano le funzionalità disponibili per il test. Gli ingegneri QA hanno sempre un backlog. Non c'è mai abbastanza tempo per il 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 correzione, va bene, incoraggiato se li aiuta a ottenere il codice giusto prima di rischiare il nostro tempo. Gli sviluppatori possono eseguire il commit del codice nel repository privato o nella filiale senza influire sul team o sul QA. Gli sviluppatori possono eseguire unit test o automazione della regressione sul codice creato dal repository o dalla filiale privata di uno sviluppatore. In casi particolarmente rischiosi un ingegnere addetto al controllo qualità collaborerà con lo sviluppatore per testare prima della fusione, per proteggere il team dai ritardi.

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

Il Manifesto Agile, per me, riassume il meglio del nuovo pensiero sul processo di sviluppo emerso negli anni '90. Sono un vero sostenitore di questi principi, ma i dettagli del processo possono variare. A mio avviso, il punto di Agile è di adattare il processo alle esigenze del prodotto e dei clienti, non di essere schiavo del processo.

Se ieri avessi un software funzionante, perché non dovrebbe funzionare oggi? Se non hai completato alcuna attività oggi, la build di oggi sarà la stessa di ieri. Le build quotidiane e il ritmo dello sviluppo sono cose separate. Solo perché hai build giornaliere, ciò non significa che hai nuove funzionalità in ogni build.

Quando finalmente alcune funzionalità vengono completate e archiviate nella filiale principale, è necessario disporre di un processo automatizzato che crea il software ed esegue i test. In caso di problemi con la costruzione o l'esecuzione dei test, il team viene avvisato e concentrano i loro sforzi per farlo funzionare di nuovo. Ecco come funziona CI e come ti aiuta a rilasciare continuamente software funzionante.

Risposta breve: No . Semplicemente non può essere realizzato quotidianamente.

Tuttavia, il team agile dovrebbe fornire pezzi di software funzionanti o storie utente in ogni sprint . Di solito, gli incontri di stato si tengono ogni giorno per vedere i progressi e gli impedimenti.

Per quanto riguarda il software di qualità , i processi di integrazione continua (CI) in atto assicureranno che il controllo di qualità venga applicato a piccoli sforzi (check-in) e effettuato con la stessa frequenza configurata. Si prefigge inoltre di migliorare quality of softwaree ridurre i tempi di consegna, sostituendo la pratica tradizionale di applicare il controllo di qualità dopo aver completato tutto lo sviluppo.

No, non ci si dovrebbe aspettare di offrire nuove funzionalità ogni singolo giorno. Non tutte le funzionalità possono essere suddivise in dimensioni così ridotte da consentire a uno sviluppatore di completare la funzione in circa 6 ore di tempo di sviluppo.

Se stai eseguendo una mischia, dovresti farlo con gli sprint di almeno 2 settimane, con funzionalità dimensionate per richiedere da 0 a 8 giorni per essere completate. La promessa al proprietario del prodotto è di fornire un nuovo 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 essere se lo si desidera)

Una buona metodologia ha suggerito di configurare un server CI (integrazione continua) in cui è stata automatizzata la creazione di almeno una build giornaliera di software funzionante. L'idea è di controllare il tuo codice non appena finisci la funzionalità in modo che possa essere nel prossimo ciclo di generazione e quindi nelle mani del QA per i test.

Ricorda che l'obiettivo è far eseguire e testare le funzionalità entro la fine dello sprint! Non dovresti far aspettare il QA fino all'ultimo giorno dello sprint per farti costruire e poi farli testare tutte le funzionalità. Non avranno tempo per testarlo tutto e non avrai tempo per correggere eventuali bug ...

Se non è possibile configurare un server CI, la pratica dovrebbe essere quella di creare manualmente una nuova build per il QA ogni volta che uno sviluppatore controlla il suo codice finito e afferma di aver finito con una funzionalità e pronto a passare al QA.

In realtà dipende dalle dimensioni del progetto; se il progetto è grande, non esiste un modo fattibile per raggiungere questo obiettivo.

Build quotidiani (o anche più spesso) che escono da strumenti di integrazione continua, non significano software funzionante; a malapena significa codice compilabile.

Ci sono molti progetti là fuori che offrono build giornaliere, che grazie alla continua integrazione, funzionano software. Almeno in teoria.

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

In teoria, se non si è in grado di fornire quotidianamente più lavoro al proprio QA, è necessario aumentare il numero di sviluppatori o ridurre il numero di tester. Terribile idea!

Il tuo compito è fare le cose.

Di 'al QA che avranno qualcosa da testare una volta fatto. Devi spiegare loro perché.

Penso che tu sia confuso sull'idea di "CI". Potresti visitare questo eccellente articolo di Martin Fowler su come funziona la CI in pratica, che dovrebbe rispondere correttamente alla tua domanda.