come convincere team e project manager che le distribuzioni post-lancio sono a posto per le nuove funzionalità

Mentre quello che hai fatto è sicuro che sia una buona cosa, il project manager deve preoccuparsi di una serie di cose:

• test - cosa succede se rompi qualcosa. O qualcosa nella home page, o qualche altra conseguenza non intenzionale? Il sistema deve essere ritestato. A seconda di quanto può spingersi la tua azienda, questo potrebbe essere un grosso costo.
• Pianificazione dei tempi di inattività degli utenti. Può essere banale, può essere costoso.
• Il PM può preoccuparsi di qualsiasi ragione politica per farlo al di fuori di una normale versione. Dicendo al cliente così presto dopo il rilascio che vuoi fare un aggiornamento esclusivamente per problemi di prestazioni che NON sono stati sollevati dagli utenti, potrebbe diminuire la fiducia nel sistema. Forse preferirebbe che venisse inserito in un normale ciclo di rilascio.

Inoltre, se nessuno ha segnalato le prestazioni come un problema, perché il progetto dovrebbe sprecare denaro per risolvere un problema che non esiste?

Beh, prima di tutto, deve passare tutti i normali passaggi Q / A e mostrare un reale miglioramento delle prestazioni.

Ora ti trovi di fronte a un problema aziendale: il cliente ha ciò che ha pagato. L'hanno accettato e lo stanno usando in produzione. Pensano che il progetto sia finito.

È possibile che non vogliano rischiare di "scuotere la barca" per un aggiornamento che porterebbe modifiche minime o nessuna visibile a loro (questo è il motivo per cui i cambiamenti di refactoring a volte sono ostacolati dal business).

È anche possibile che i tuoi addetti alle vendite desiderino essere pagati per questo miglioramento.

Vecchio scherzo: un addetto alle vendite e amp; un programmatore si incontra con il cliente. Il cliente richiede una funzionalità difficile & il ragazzo delle vendite lo promette immediatamente. Il programmatore calcia il ragazzo delle vendite sotto il tavolo. Il cliente chiede quindi di cambiare il colore della pagina principale. Quando il programmatore dice 'nessun problema', il ragazzo delle vendite lo calcia sotto il tavolo. Più tardi, dice, "sei un idiota: il cliente avrebbe pagato $ 10.000 per quel cambiamento".

TL; DR

Verifica le tue modifiche per assicurarti che siano veramente miglioramenti. Eseguili attraverso il tuo processo Q / A. Dopodiché, presenta i miglioramenti al responsabile del progetto e fallo accompagnare dagli uomini d'affari. Forse i cambiamenti saranno promossi, forse non lo faranno. In ogni caso hai fatto un buon lavoro.

• Il client ha approvato il periodo di scadenza della cache?
• Hai eseguito gli stessi test dell'ultima versione contro il tuo ramo?
• Il risultato della ridistribuzione del sito non sarà disponibile? In caso affermativo, il cliente fornirà una variazione al contratto del livello di servizio relativo al tempo di attività?

Se la risposta a uno di questi è "No", non è pronta per la distribuzione. Se la risposta a tutti è "Sì", allora dovrebbe essere una chiara vittoria per l'integrazione nel tronco / ramo principale.

In genere si farebbe riferimento a una mini-release intermedia come patch. La linea tra una patch e una versione completa del software, tuttavia, non è una questione risolta da alcun tratto dell'immaginazione. A volte è difficile fare questa determinazione.

Quanto lavoro di sviluppo è andato alla patch?

Non si tratta sempre di quanto lavoro di sviluppo è andato nella patch. Una patch può comprendere meno di un'ora di facile sviluppo, ma gli impatti che queste modifiche rendono possono essere monumentali.

Quanto rischio sto introducendo?

Sopra ogni altra cosa una patch deve essere stabile. La stabilità di una patch è direttamente correlata al numero di componenti, caratteristiche e complessità di implementazione che sono influenzate dalle modifiche alle patch. Esistono diversi sistemi di valutazione del rischio tra cui scegliere, ma tendono tutti a ruotare attorno al numero di impatti e all'importanza di queste funzionalità per il cliente.

L'alto rischio va bene fintanto che viene soddisfatta una quantità altrettanto elevata di garanzia della qualità e sforzo di test.

• Il sistema ha test unitari ripetibili che coprono componenti o funzionalità che potrebbero essere interessati dalla memorizzazione nella cache?

• Esiste un qualsiasi tipo di interfaccia utente automatizzata o test di front end (ad esempio Selenium )

• Disponi di script di test del carico in grado di verificare che la cache mantenga il livello di produzione + le richieste?

Questi sono tutti requisiti minimi nella mia mente solo per considerare qualcosa come la cache che viene introdotta nel software sotto forma di patch.

I cache non sono una cosa da poco. Piccoli errori possono avere problemi di interruzione dello show, quindi devi essere sicuro di aver capito bene.

I can't very well tell future employers that I implemented caching and saw an increase in performance without actually deploying it and capturing the improvement (through google analytics or Page Speed or some other method), or can I?

Puoi e dovresti. È importante disporre di un ambiente di test separato per il proprio sito Web autonomo, con dati di qualità e tentativi di imitare l'ambiente di produzione nel modo più completo possibile. Come si può fare?

• Separa l'hosting pubblico per il tuo ambiente di test, o non utilizzato o inutilizzato nel server di casa che può essere utilizzato per ospitare la tua applicazione web.

• Il database può essere stabilito con lo stesso schema esatto e un'istantanea dei dati di produzione reali (De-identificato, naturalmente, se contiene informazioni sensibili dell'utente).

Ora con strumenti di test dell'interfaccia utente automatizzati e strumenti di test di carico per l'ambiente di test, dovresti essere in grado di simulare il carico del visitatore di 50k su un ambiente di test che è una copia della produzione. Ciò contribuirà a chiarire eventuali problemi nascosti che altrimenti dovresti scoprire in fase di distribuzione post produzione.