Agile (scrum) richiede un ambiente server? [chiuso]

Agile è :

• Individui e interazioni su processi e strumenti
• Software di lavoro su documentazione completa
• Collaborazione con il cliente per la negoziazione del contratto
• Risposta al passaggio successivo a un piano

Imposta il tuo ambiente di sviluppo per riflettere e supportare questi principi.

Scrum è un modo per gestire il tuo lavoro, non il tuo ambiente di sviluppo.

Il responsabile QA potrebbe ottenere la sua idea dall'interpretazione apparentemente comune di Agile, in cui un team consegna un prodotto completamente testato (QA) ogni primavera che può essere distribuito ai clienti e lo estrapola per ottenere la conclusione che può essere ottimizzato con un singolo ambiente di sviluppo / controllo qualità.

E potrebbe essere un modo per implementare le pratiche Agile, ma certamente non è l'unico modo. Ho lavorato con scrum in un ambiente in cui i team di sviluppo e controllo qualità erano in gran parte separati e il team di controllo qualità era il "cliente" del team di sviluppo. In tale ambiente, i team di sviluppo e controllo qualità lavorano naturalmente su server / implementazioni diversi.

Non possiamo davvero consigliare se un singolo ambiente server dev / QA funzionerà per te. Dipende troppo da come sei abituato a lavorare e da quanto le diverse persone riescono a far fronte alle occasionali build distrutte.

Una cosa è certa: Agile non impone nulla per quanto riguarda la configurazione degli ambienti di sviluppo (e relativi).

È ben stabilito in un ambiente a cascata che il rilevamento precoce dei bug riduce il costo di fissarli . Per analogia, puoi pensare a tutte le fasi a cascata che si verificano contemporaneamente.

Pertanto, un modo per supportarlo e ridurre gli sprechi, si potrebbe sostenere che l'utilizzo di un server di sviluppo potrebbe ridurre i costi. Non appena lo sviluppatore ha finito, i tester possono iniziare a fare il loro lavoro. Elimina lo spreco di dover distribuire il software in un nuovo ambiente e lo spreco dei tempi di attesa.

Naturalmente, testare la distribuzione in sé è prezioso. Avere funzionalità in uno stato di sviluppo può causare falsi positivi - le funzionalità non completate possono "funzionare" e successivamente regredire o i tester dicono che non funziona quando non è terminato. Devi fare questa chiamata di giudizio per la nostra squadra. Non abbiamo abbastanza contesto per una risposta definitiva.

E alla fine, il tuo responsabile per la qualità non deve eseguire personalmente la codifica. In questo contesto ha un ruolo di "pollo". Se il tuo team di sviluppatori ritiene di poter lavorare meglio o in modo più produttivo ignorandolo, dovrebbe farlo

Penso che i team possano lavorare in modo più agile se hanno più server ai livelli appropriati ...

Prima alcune ipotesi: due team di sviluppo: Stati Uniti e Pakistan. Il controllo qualità è una squadra separata e utilizza la build notturna. I team di sviluppo sono altamente produttivi e fanno frequenti check-in. Possono utilizzare un controllo versione distribuito, ad es. Git.

Quindi uno sviluppatore del Team USA eseguirà il test unitario sulla sua macchina per le aree effettuate dal suo ultimo check-in al Repository locale e quindi trasferirà le modifiche al Repository del team . Esiste la suite di test unitaria completa insieme ai test funzionali automatizzati * da eseguire sul prodotto A. Se tutto è verde, il codice cambia per essere spinto anatomicamente su Check-Build Repository dove verranno eseguiti i test integrati. Se è ancora verde, le modifiche verranno automaticamente trasferite a Repository principale utilizzato per la compilazione notturna. Quella build notturna che verrà utilizzata dal QA il giorno successivo.

Tutti i repository dispongono di propri server applicazioni / dati / build.

* Se i test funzionali sono di lunga durata, allora possiamo avere due livelli di Repository del team. Uno per i test di breve durata (ad esempio tutti i test unitari, alcuni test funzionali) e il secondo per i test funzionali di lunga durata.

Anche se, come dice Bart, Agile potrebbe non dettare un assetto ambientale, i valori e i principi indicano le migliori pratiche in cui il codice viene aggregato e testato su base continuativa. Questa pratica è in diretta opposizione all'approccio del gatepost negli ambienti tradizionali a cascata. La transizione attraverso i gatepost suggerisce che un approccio è cascata. Elevati livelli di test di integrazione automatizzati suggeriscono l'agilità.

Bottom Line: devi essenzialmente eseguire tutti i test all'interno dei confini dello Sprint per soddisfare qualsiasi definizione di attività Agile. Il modo in cui il codice è rilasciato sul mercato è all'altezza dell'azienda. Possono RTM settimanalmente, mensilmente o trimestralmente e dichiarano di essere ancora Agile, ma devono mantenere un sito di Staging per il codice che è Fatto ma non Rilasciato.