disaster recovery del software quando un tecnico è improvvisamente non disponibile

Dipende dalla durata prevedibile dell'indisponibilità, dalla durata residua del progetto, dal modo in cui i compiti sono distribuiti e dalle conseguenze della mancanza delle scadenze.

Gli sviluppatori di software non sono intercambiabili a volontà. Gli sviluppatori sviluppano le conoscenze sul sistema man mano che il sistema cresce e l'aggiunta di una nuova risorsa richiede di far fronte alla conoscenza contestuale mancante delle nuove risorse.

Diverse buone pratiche riducono i rischi associati all'improvvisa indisponibilità:

• le revisioni tra pari garantiscono che le conoscenze sullo sviluppo siano condivise tra diversi sviluppatori. In caso di indisponibilità, il resto del team potrebbe riorganizzarsi per subentrare, o nel peggiore dei casi portare un nuovo codificatore e organizzare un trasferimento di conoscenze.
• team integrati e coordinati che collaborano strettamente per prendere decisioni di progettazione possono mitigare l'indisponibilità allo stesso modo. La conoscenza condivisa sul design generale facilita la redistribuzione del lavoro e il briefing dei nuovi arrivati.
• la documentazione formale potrebbe eventualmente aiutare. Tuttavia in pratica funziona bene solo se la documentazione prodotta da uno sviluppatore viene utilizzata da un altro sviluppatore (o dai modelli utilizzati negli strumenti di generazione del codice). La documentazione che viene letta solo da sé sembra essere molto più ambigua. Se un nuovo sviluppatore deve subentrare a questo lavoro, l'autodichiarazione potrebbe sollevare il maggior numero di domande a cui risponde.

Avvicinare nuovi sviluppatori quando ci sono scadenze ravvicinate è molto difficile, perché informare i nuovi arrivati richiede tempo alla squadra, in un periodo in cui non c'è tempo libero. Se sei malato per 1 settimana, non ha senso. È da prevedere se il costo del briefing dei nuovi arrivati è compensato dai benefici della nuova risorsa, in genere se ci sono alti costi di ritardo, o se non è possibile posticipare, o se l'indisponibilità è in un periodo di tempo più lungo.

I soliti piani per questo è di costruire un contingency nella scadenza. Le cose accadono, spesso non raggiungi mai le scadenze. Essere indisponibili era solo un altro inconveniente nei piani accuratamente pianificati che non vanno mai secondo i piani!

Questo è chiamato il "fattore-bus". Fondamentalmente, il rischio posto al progetto se uno sviluppatore viene investito da un autobus. Avere uno sviluppatore non disponibile per una settimana è un piccolo inconveniente rispetto alla perdita permanente di uno sviluppatore. Potrebbe essere un incidente o una malattia improvvisa, ma meno drammaticamente potrebbe essere solo un lavoro di commutazione di base dello sviluppatore con breve preavviso o essere licenziato. O uno sviluppatore principale che ottiene trasferito in un'altra attività ad alta priorità in diversi reparti.

In breve, devi pianificare la riduzione del fattore di bus o devi essere pronto a mitigarlo, ad es. avendo buffer in termini di tempo o semplicemente essere abbastanza flessibile per essere in grado di spingere la scadenza. Quello che di solito non può fare è semplicemente esternalizzare un'attività complessa con breve preavviso, o assumere un nuovo sviluppatore - ci vorrebbe quasi sempre più tempo per introdurre un nuovo sviluppatore in un sistema esistente piuttosto che aspettare una settimana per uno sviluppatore principale da restituire. Se una piccola squadra perde un membro, ovviamente saranno più lenti, ma se anche devono presentare un nuovo membro, saranno ancora più lenti .

È possibile ridurre il fattore bus avendo una condivisione della conoscenza continua del gruppo e revisioni tra pari (o persino la programmazione della coppia). Ma ovviamente questo è qualcosa che deve accadere prima che l'autobus colpisca.

Qualsiasi dipendente potrebbe non essere disponibile per una settimana, o un mese o per sempre, senza preavviso, in qualsiasi momento. Incidente, malattia, avendo avuto abbastanza di questo lavoro, molte altre ragioni. Spetta al management assicurarsi che una tale occasione sia noiosa, forse costosa, ma non un disastro.

Se hai una squadra di dieci, potresti perdere il 10% della tua squadra. L'azienda dovrebbe essere in grado di gestirla se il resto del team è motivato (pagare gli straordinari è altamente motivante). Se sei una squadra di uno, allora il lavoro non sarà fatto. Se hai altri dipendenti che possono intervenire, il ritardo potrebbe essere ridotto al minimo. Assumere qualcuno dall'esterno sarebbe difficile, anche se probabilmente troverai un appaltatore che può iniziare con un preavviso di qualche settimana per alcune settimane ad un alto tasso orario molto .

La cosa migliore da fare è avere contratti, ecc., in modo che un ritardo nella finitura di un prodotto non sia un disastro finanziario. E per avere una data di finitura pianificata e realizzabile in anticipo rispetto alla scadenza. Avere dipendenti che possono intervenire l'uno per l'altro aiuta (ma può essere problematico da raggiungere).

E se hai una scadenza che deve essere raggiunta, allora forse lo scopo del lavoro è più flessibile. In altre parole, rilascia funzionalità per rispettare la scadenza.

Un modo fondamentale per ridurre il "Fattore di bus" che @JacquesB menziona sopra è programmazione di coppie come tecnica principale. (La mia pratica è quella di usare il termine "Fattore della lotteria" poiché è meno morboso ma l'effetto è lo stesso.)

Molti sviluppatori odiano la programmazione delle coppie; molti manager lo odiano anche, per ragioni completamente diverse (alcuni sviluppatori odiano essere costretti a comunicare con altri umani per lunghi periodi, alcuni manager spesso si sentono male come se pagassero il doppio del denaro per un singolo output).

Ma la programmazione delle coppie elimina completamente il rischio di un singolo punto di errore umano, garantendo che qualsiasi attività di sviluppo venga eseguita e compresa da almeno due sviluppatori.

Ci sono diversi modi in cui ho visto questo genere di cose gestite:

Condividi l'allenamento

La cosa più ovvia da fare è condividere il lavoro tra le risorse esistenti (supponendo che ciò sia possibile). Come assicurarsi che gli sviluppatori entrino in pista è quasi una risposta in sé, ma alla fine si riduce a registrare correttamente requisiti, progetti e progressi. Cose come programmazione coppie possono anche essere di grande aiuto qui.

Ripristina la scadenza o prova a recuperare il tempo

Verifica con il cliente per vedere se la scadenza può essere estesa. In alternativa, potrebbe essere possibile ottenere ulteriori tempi di sviluppo lavorando serate, fine settimana e giorni festivi.

Elimina altre attività

Ci sono altre attività non critiche che possono essere temporaneamente abbandonate per fare spazio?

Avanti

C'è del lavoro pianificato dopo lo sviluppo che può essere portato avanti come documentazione, script di test e configurazione?

Ammetti che potrebbe essere in ritardo

Parla presto con il cliente. Potrebbe essere possibile consegnare in parte - o per lo meno, si potrebbe ottenere una guida decente sulle priorità relative di altre cose.

Risorsa aggiuntiva

Una possibilità - ma questo comporta rischi. Ci vorrà del tempo per aggiornarli e, dato che sono temporanei, potrebbero semplicemente andarsene lasciandoti ancora peggio.

Controlla il percorso critico

Se sono coinvolte altre parti, verifica che siano ancora sul bersaglio. Non ha molto senso spostare il cielo e la terra per ottenere qualcosa di finito se diciamo che il team di test è indietro di un mese nel testare le cose.

Accettazione delle realtà di rischio

C'è una frase comune nella professione legale che afferma che i problemi difficili creano soluzioni scadenti. Può essere allettante cercare di convincere tutti a capire tutto per coprire tutte le eventualità. Questo comunque, è una commissione stupida.

Gli sviluppatori dovrebbero spendere tempo di qualità per i propri sviluppi. Consumare una quantità sempre maggiore di tempo per diventare al corrente con altri sviluppi è un'attività altamente discutibile. Una ragionevole via di mezzo potrebbe essere quella di avere un esperto in materia e un sostituto.