Cosa fare con un team di sviluppo che sta morendo di fame? [chiuso]

Migliora i test unitari, i test funzionali, la documentazione, gli strumenti, ecc. C'è una moltitudine di cose che possono essere fatte in down-time mentre aspetti il percorso critico da raggiungere.

Anche se mi piace la risposta sul miglioramento dei test, della documentazione, ecc., ed è una buona cosa puoi anche guardare:

• Assistere il componente del percorso critico, sarebbe più veloce con la programmazione team / buddy?
• Ristrutturazione del componente critico in diversi sottocomponenti su cui tutti possono lavorare.
• Espellere il componente critico con qualcosa, possibilmente grezzo, che fondamentalmente fa lo stesso lavoro ma probabilmente non abbastanza veloce per la produzione.
• Stabilisci un'API per il componente critico, correggi il problema più o meno nella pietra e aiuta a ottenere le funzionalità di base per quel componente implementato, (soggetto a modifiche nell'implementazione ma non all'API).
• Verifica se puoi utilizzare in anticipo le versioni problematiche, note del componente critico, sul resto del sistema in cui la funzionalità è "abbastanza buona per ora".

È anche una buona idea iniziare subito la fase delle "lezioni apprese" registrando che tali componenti critici devono essere avviati prima nel processo di sviluppo, probabilmente prima che il resto del team sia assemblato.

Hai bisogno di un piano di backup per il tuo prodotto consegnato in ritardo

Se un pezzo critico è già in ritardo, non c'è alcuna garanzia che non scivoli ancora di più. Cosa poi? Aspetti per sempre? Questo non è il tipo di risposta che vuoi dire al top management.

Costruisci un simulatore

Un modo per gestire il rischio è iniziare a lavorare su un simulatore (imbrago, shim, stub, qualsiasi cosa tu voglia chiamarlo) per prendere il posto del pezzo critico mancante.

Ha un'interfaccia definita? Implementalo.

Ha una documentazione dettagliata? Imitalo nel miglior modo possibile.

È solo un'idea di qualcuno? Vedi se riesci a ottenere un prototipo.

Quindi, quando slittano di nuovo il programma ....

In questo modo, quando scivolano di nuovo in programma, hai un asso nella tasca posteriore per colmare il divario. Non solo la tua squadra sarà sbloccata (possono integrarsi con il simulatore), ma otterrai una preziosa risorsa software.

Se la schedulazione è ancora più lunga, utilizza il tempo per scrivere test di integrazione automatici (per il tuo simulatore, per ora). In questo modo, quando consegnano la cosa reale, puoi semplicemente eseguire i test e rilevare eventuali differenze comportamentali tra il modello e il deliverable. Questo ti permetterà di azzerare gli spot che devi rivedere. Come bonus, avrai presto un'idea di quanto hanno tagliato gli angoli mentre il loro tempo si è esaurito.

Se il componente critico ha un'interfaccia conosciuta e se non ci sono speranze di farlo in breve tempo, perché non creare un test double (ad esempio un simulato )?

Ciò consentirebbe al team di continuare la codifica, anche se i risultati del test sarebbero leggermente meno significativi.

A parte l'ovvio "fai tutte quelle cose che non hai mai fatto fino ad ora", sembra che tu e il tuo team manchi la tranquillità di fare qualsiasi cosa non sia collegata al progetto in ritardo. Che è comprensibile ma non utile.

Quindi il vero problema potrebbe essere essere rilassati al riguardo. Non sto dicendo indifferente. Sii consapevole della tua responsabilità, di ciò che puoi fare per aiutare e se questo ti lascia con il tempo a disposizione, divertiti. Non puoi e non devi stare sempre in punta di piedi. Se sei un leader, direi che questo dovrebbe essere il tuo messaggio. Trasferire il tuo nervosismo nella squadra non renderà una squadra più produttiva quando è importante.

Non dici quale metodologia stai utilizzando, il che rende difficile consigliarlo esattamente.

Dove lavoro se c'è un blocco, è una mano per la pompa che fa tutto il possibile per accelerare lo sviluppo.

Considera se potrebbe esserci un problema più ampio con te, dato che il ruolo principale sta assumendo troppo. Sì, le persone ti cercheranno per la leadership tecnica, ma ciò non significa che alcuni dei tuoi membri del team più capaci non possano condividere il carico di lavoro se sono mentori.

A parte questo, c'è qualche altro lavoro non critico su cui possono andare avanti? Inoltre, c'è del lavoro che hanno completato che potrebbe essere ulteriormente perfezionato (refactoring, rimozione del debito tecnico, documentazione, aggiunta di test, ecc.).

Se davvero non c'è niente, dai loro qualcosa - passa registri, creazioni, documenti, piani di test, disegni, diagrammi, ordini del giorno, organizza incontri, organizza sessioni di borse marroni, condividi conoscenze ecc. C'è sempre qualcosa da fare. Se le persone sono semplicemente disposte a non fare nulla sulla moneta aziendale che dovrebbero essere aumentate perché chiaramente non sono i giocatori della squadra.