Come convincere i team di sviluppo a passare a una nuova versione del middleware? [chiuso]

I prodotti o le strutture obsoleti o obsoleti sono di solito categorizzati (e "venduti") come Debito tecnico .

Se la nuova versione offre fantastici miglioramenti o vantaggi, allora il tuo lavoro è più facile. Ma anche se così non fosse, rimanere su una versione precedente comporta diversi rischi:

• Mancanza di supporto per gli sviluppatori. Questo non è mai un problema finché non si verifica un problema: capito?
• Mancanza di supporto della comunità. Con il passare del tempo, i forum, i siti di Q & A, le mailing list, ecc. Su cui sei arrivato a fare affidamento inizieranno a ignorare le tue domande perché nessuno usa più la tua versione.
• Rev-lock. Gli aggiornamenti diventano progressivamente più dolorosi, più versioni sei indietro. L'aggiornamento da 1.0 a 1.1 o da 1.9 a 2.0 di solito non è un grosso problema, ma l'aggiornamento da 1.0 a 2.0 potrebbe richiedere settimane o mesi per risolvere tutti i problemi. Paradossalmente per i manager, il più frequentemente si aggiorna, il tempo complessivo che si spende per gli aggiornamenti, perché l'ambito delle modifiche è piccolo per ciascuno e i problemi sono facili da risolvere .
• Perdita di produttività (costo opportunità AKA). "Alcune" prestazioni e vantaggi funzionali potrebbero non sembrare molto interessanti, ma tale aumento del 10% è aggravato su ogni funzionalità / sprint / rilascio e ammortizzato in un periodo di diverse settimane o mesi. Se potessi completare un progetto di 12 mesi stimato in 10 mesi spendendo 1 settimana per l'aggiornamento, non sarebbe un investimento saggio?
• Problemi del codice legacy. Una volta che una nuova versione ha una distribuzione abbastanza ampia, lo sviluppatore di solito smetterà di correggere bug, vulnerabilità della sicurezza e altri seri problemi nelle versioni precedenti. Ciò aumenta in modo significativo le possibilità di incontrare un errore critico o un sistema compromesso oi dati rubati. Esistono vulnerabilità zero-day, ma il loro sfruttamento non è affatto comune come quelli dei vecchi sistemi privi di patch.

Questo non significa che devi sempre essere nella versione più recente e più grande di tutto , poiché ci sono anche problemi associati a questo. Ma nella mia squadra ho intenzione di aggiornare almeno un framework all'ultima versione all'inizio di ogni sprint. Se causa problemi, risolverli o ripristinarli. Non è un passo difficile da mantenere, e significa che di solito non più di un mese o due dietro su un singolo prodotto o framework, eccetto a volte dove è necessario coinvolgere IT o aziende.

In breve: ci sono approcci abbastanza diversi su come convincere gli sviluppatori di software e / oi project manager a introdurre qualcosa di nuovo o aggiornare l'applicazione.

Pertanto, gli sviluppatori di software sono interessati a risparmiare tempo e funzioni utili mentre svolgono alcune attività comuni e impegnative con gusti diversi, mentre i PM sono interessati ai costi di risparmio dei operazioni in corso mediante proposta di implementazione nuova / aggiornamento.

Solo il principale e importante svantaggio viene dai membri del team QA, quando il test dell'applicazione corrente non è automatizzato da script. Il team addetto al controllo qualità potrebbe naturalmente opporsi a questi cambiamenti.

Ci sono domande SE correlate su How to convince del tuo posto di lavoro per apportare alcune modifiche con argomenti:

• Come convincere la gestione ad eseguire l'aggiornamento a .Net 4.0
• Come convincere un collega che la duplicazione del codice è errata?
• Come convincere il management che il QA è importante?
• Come convincere le persone a commentare il loro codice