Distribuzione in fase di sviluppo per progetti Agile

1. Chiedi al tuo cliente di creare un ambiente di test che mima quello di produzione. Non installare, in nessun caso, un nuovo aggiornamento sul sistema vivente, prima di testarlo e dimostrarlo al cliente, perché se rovini il tuo traguardo, rovini anche le operazioni del cliente;
2. Fai in modo che il tuo team di QA utilizzi questo ambiente di test;
3. Il processo agile presuppone la consegna il prima possibile, quindi non raccogliere le modifiche nell'ambiente di test. Invece, distribuire piccole modifiche non appena vengono verificati dal client. È molto meglio quindi distribuire il risultato del lavoro di un anno;
4. Esegui il backup dei dati in tempo reale prima di ogni aggiornamento

Di Scrum significa che il Team esegue iterazioni per produrre incrementi, che non sono di default rilasciabili ma sono fatti . Se il cliente desidera qa stalle testate durante l'intero processo, tutto deve essere fatto prima nelle iterazioni. I team Scrum possono farlo ma non sono effienti ... Il proprietario del prodotto che hai citato riflette le preferenze dei clienti. Scrum non dice mai nulla su cosa o quando codificare e testare . Il Team e l'OP decidono di farlo al fine di soddisfare le esigenze dei clienti come un progresso visibile. È bene avere un feedback immediato. Nel tuo caso è un po 'come sprecare risorse ...

Quando sei in un progetto di test guidato, potresti essere già a metà strada per qa a causa di test obbligatori.

Ho paura di dire che non esiste il modo agile per fermare i clienti che hanno richieste di attività da offrire ...

La mia opinione è che il Product Owner abbia solo bisogno di un modo per verificare che il pezzo di lavoro sia fatto, sia che si trovi in un ambiente di test o su una macchina di sviluppo. Non è necessario rilasciare un aggiornamento ogni iterazione. Puoi passare 3 iterazioni inserendo funzionalità in QA e poi fare un rilascio alla produzione.