Come dovrebbe funzionare il team semi-agile durante la fase di test "a cascata" imposto dalla gestione

Non penso che riuscirai davvero ad andare da nessuna parte senza rielaborare il modo in cui sono fatte le cose in questo momento.

One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs.

Sono abbastanza certo che questo è un grave errore. Cerca di spiegare che la risoluzione dei bug diventa più difficile e più costosa più a lungo viene posticipata. Non credo ci sia una nessuna scusa per posticipare le correzioni dei bug per così tanto tempo.

Tutti i metodi agili che conosco sottolineano che il software dovrebbe essere tecnicamente pronto per essere spedito alla fine di ogni ciclo / iterazione (o anche in modo continuo). Ciò significa che tutti i bug che non vorresti spedire devono essere corretti prima di iniziare qualsiasi nuova funzionalità.

Cerca di lavorare con le persone e spiega le tue preoccupazioni.

Infine, se non è possibile ottenere alcun tipo di accordo su tali principi di base, potrebbe essere meglio andare avanti.

Modifica

In base alla tua domanda modificata: sono d'accordo che la risoluzione dei bug debba essere gestita proprio come le nuove funzionalità. Normalmente avrei compiti singoli per bug "piccoli" (fino a poche ore) e storie con sottoattività per bachi "grandi" (più giorni, possibile dividere in attività). Se i tuoi colleghi non sono d'accordo, fai notare che i vantaggi dei metodi agili si applicano alla correzione dei bug proprio come alle nuove funzionalità.

Per utilizzare uno strumento di tracciamento agile o un database di bug: Idealmente, i due sono integrati. Se non lo sono, allora sì, dovrai tenere traccia del lavoro in entrambi. È fastidioso, ma l'ho fatto da solo, e non ho trovato un grosso problema. Tieni traccia dei bug come al solito e copia e incolla l'id del bug nel titolo di un'attività / storia quando pianifichi un bug su cui lavorare. L'attività è solo un collegamento al bugtracker (si verifica se entrambi sono basati sul web) e tutta la discussione è nel db del bug. Se ci si collega in modo coerente, probabilmente si potrebbero anche eseguire report su entrambi i sistemi.

Infine, credi di non poter cambiare il modo in cui lo sviluppo è organizzato, dovrai lavorare all'interno di questi limiti. Cose come l'introduzione di alcuni metodi agili nella fase di risoluzione dei bug probabilmente aiuteranno.

Tuttavia, sono convinto che dividere lo sviluppo in una "fase caratteristica" e una "fase di correzione del bug" sia un errore grave, forse fatale. Potrebbe non essere così grave per la tua azienda (ogni situazione è diversa), ma se lo è, e se la tua organizzazione non è in grado di cambiarla, allora la tua organizzazione potrebbe essere così disfunzionale che staresti meglio altrove. Ma questa è la tua chiamata da fare ... buona fortuna!

Modifica 2

Infine, se le politiche aziendali impongono prima "funzionalità, risoluzione dei bug più tardi", forse puoi eluderle, ad es. ridefinendo le correzioni dei bug come nuove funzionalità (la differenza è spesso una questione di opinione comunque). In una certa misura, puoi provare a introdurre nuove idee "dal basso" in questo modo. Sai, "se non puoi batterli, unisciti a loro".

One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs.

Questa è una brutta cosa. Una cosa molto brutta.

Non sei "semi-agile" se stai introducendo bug durante un'iterazione. Avresti dovuto far funzionare le cose e spostato le cose nel backlog perché non erano state completate.

Se impieghi altri sei mesi per costruire bene le cose, non spendere 6 mesi per testare e correggere bug.

Dovrebbe essere semplice. Smetti di correre e chiama il brutto codice "fatto".

Se la direzione insiste nell'affrontare il codice errato in uno stato "finito", è cieco per lo spreco di tempo che 6 mesi di correzione del bug chiamato "testing" è. Informali.

Also some bugs are definitely the size of a medium size story, while other bugs would take 5 min to fix. Should 5-min bugs also become stories if we were to continue with iterations?

Non hai davvero altra scelta che inserire gli errori nel backlog e provare a ripetere correttamente. La roba non viene "completata" finché non è priva di errori.

Se non riesci a liberarlo senza errori, torna nel backlog per la successiva iterazione. Quindi, sarai in grado di renderlo privo di bug.

Prova questo: riduci le tue iterazioni a una dimensione che puoi ottenere e testare nella Coding Phase. La tua fase di test sarà terminata in anticipo (IE: per quanto tempo impieghi i test dell'unità per l'esecuzione.)

In alternativa: Ignora le porte. La definizione della tua azienda di Code Complete è comunque priva di significato. Se non hai scritto alcun codice per una funzionalità dalla fase di test, dichiara che la funzione è "completata" e segnala un bug per il fatto che non funziona ancora.

Come sai che il tuo codice è completo senza alcun test? Come convalidare che puoi attraversare il Gate 2?

Il mio modo di fare Agile in a Waterfall come sviluppatore è di fare TDD nascosto dietro una tenda di debug.

In questo modo, so quando il mio codice è completo e sono fiducioso sulla sua stabilità.

Naturalmente la codifica richiede più di 2 mesi, ma la codifica + test richiede meno di 8 mesi.

A proposito di nuove funzionalità / correzione dei bug, sono sicuro che puoi provare che la nuova funzione non può essere introdotta se quell'errore non è stato risolto prima.

Hm. Non che l'abbia fatto davvero, ma mi sembra che uno dei modelli più ideali per questa situazione sia basato sulla tecnica agile di "giocare e poi buttare via l'esperimento". Tratta tutto il codice che hai creato durante due mesi di non aver avuto l'opportunità di creare un buon codice come un lungo esperimento - ora sei chiaro che cosa vuoi ottenere e anche più o meno come. Buttalo fuori e comincia a fare le cose per bene. Ogni volta che finisci con successo una funzione, segnalala come "bug risolto". Dopotutto, fare tutto bene da zero è il modo migliore per correggere i bug di un codice legacy intrinsecamente imperfetto. Tratta lo sforzo di due mesi come codice legacy errato che deve essere completamente refactored, segnalalo come correzione dei bug.

Ci sono problemi nel mappare processi puramente agili (come SCRUM) su un'impostazione di progetto. Il problema più grosso è che nell'approccio agile esiste una costante negoziazione e rivalutazione dell'ambito per ogni iterazione. In un progetto, tuttavia, si avrà una scadenza fissa, un budget fisso e un'aspettativa di ciò che dovrebbe essere consegnato in tale data. Per me, SCRUM riguarda la manutenzione del software più di una metodologia di progetto.

Il mio suggerimento (che ho assunto io stesso) è di restringere i tuoi cancelli. Se stai cercando di mantenere, per esempio, 4 settimane di iterazioni allora i tuoi cancelli dovrebbero essere di 4 settimane. Stabilire risultati e "definizioni di fatto" per ogni porta. Se al termine di un'iterazione / gate si verificano ancora errori nel codice, il gate non è completo e deve essere contrassegnato come scaduto. Questa è la mentalità che sia voi che i vostri stakeholder aziendali dovreste cercare di entrare. Alla fine di ogni iterazione dovrebbe esserci una serie di obiettivi completati e non ci sono funzioni a metà o non funzionanti.

Lavoravi con la mia vecchia società? Le somiglianze sono spaventose ...

Alcune parole di consiglio ... niente di ciò che dici o fai cambierà il processo in alcun modo significativo. Non sei un PM, prolly non hai cerimonie PM o alcuna importanza politica per effettuare il cambiamento su un'operazione così grande. Esporre il modo in cui stanno facendo le cose sbagliate equivale inevitabilmente a puntare il dito contro qualcuno di maggiore importanza politica di te e ti farà licenziare. Ho visto accadere anche questo.

Le tue opzioni sono chiare, convivono e accettano, perché il progetto ha probabilmente un budget enorme e clienti che soffrono di lock-in dei fornitori o contratti governativi, quindi ci sono letteralmente dei dis-incentivi per il completamento del lavoro in meno tempo. Inoltre perché concentrarsi sulla qualità se non influisce sul risultato finale?

Se la situazione di cui sopra non descrive la posizione di mercato della tua azienda, è solo una questione di tempo prima che una startup snella e agile prenda il suo pranzo e metta fuori mercato. Se lo fa, puoi decidere di conviverci e continuare o partire per una società che è effettivamente focalizzata sulla produzione di software, e non una società che trova modi per giustificare un budget enorme consumandolo.