Cosa fare con un team di sviluppo affamato? [chiuso]

Fa schifo essere sul percorso critico come normale sviluppatore, soprattutto se sei in ritardo. Quando sei lo sviluppatore senior, che il team sta cercando per la leadership, è ancora peggio.

Quando il lavoro per la maggior parte della squadra è bloccato in attesa di un pezzo critico, cosa dovrebbe fare il resto della squadra? Abbiamo un accesso limitato al pezzo critico, quindi gli altri semplicemente aspetteranno qualunque cosa facciamo. Quando gli altri sono in cerca di consigli su cosa fare, qual è una buona risposta?

Migliorare i test unitari, i test funzionali, la documentazione, gli strumenti, ecc. Esistono moltissime cose che possono essere fatte in tempi di fermo mentre si attende il raggiungimento del percorso critico.

Mentre mi piace la risposta su come migliorare i test, la documentazione, ecc., Ed è buona puoi anche guardare:

• Aiutando il componente percorso critico, sarebbe più veloce con la programmazione di team / amico?
• Ristrutturazione del componente critico in diversi sottocomponenti su cui tutti possono lavorare.
• Manichino il componente critico con qualcosa, forse approssimativo, che fa sostanzialmente lo stesso lavoro ma forse non abbastanza veloce per la produzione.
• Stabilire un'API per il componente critico, risolverlo più o meno in pietra e aiutare a ottenere le funzionalità di base per quel componente implementato (soggetto a cambiamenti nell'implementazione ma non API).
• Vedi se riesci a prendere le prime versioni problematiche note del componente critico per lavorare sul resto del sistema in cui la funzionalità è "abbastanza buona per ora".

È anche una buona idea iniziare ora la fase di "lezioni apprese" registrando che tali componenti critici devono essere avviati prima nel processo di sviluppo, possibilmente prima dell'assemblaggio del resto del team.

È necessario un piano di backup per la consegna in ritardo

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

Costruisci un simulatore

Un modo per gestire il rischio è iniziare a lavorare su un simulatore (imbracatura, spessore, troncone, come si desidera 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 sfuggono di nuovo al programma ...

In questo modo, quando cambiano di nuovo il programma, hai un asso nella tasca posteriore per colmare il divario. Non solo il tuo team verrà sbloccato (potranno integrarsi con il simulatore), ma otterrai anche una preziosa risorsa software.

Se scivolano ancora di più sul programma, usa il tempo per scrivere test di integrazione automatizzati (per il tuo simulatore, per ora). In questo modo, quando consegnano la cosa reale, puoi semplicemente eseguire i tuoi test e rilevare eventuali differenze comportamentali tra il modello e il prodotto. Questo ti consentirà di concentrarti sui punti che devi rivedere. Come bonus, avrai rapidamente un'idea di quanto hanno tagliato gli angoli mentre il loro tempo è scaduto.

Se il componente critico ha un'interfaccia nota e se non c'è speranza di farlo in breve tempo, perché non creare un doppio di test (ad esempio un modello )?

Ciò consentirebbe al team di continuare a programmare, anche se i risultati dei test sarebbero leggermente meno significativi.

A parte l'ovvio "fai tutte quelle cose che non hai fatto finora", sembra che tu e il tuo team non abbiate la tranquillità di fare qualcosa di estraneo al progetto in ritardo. Il che è comprensibile ma non utile.

Quindi il vero problema potrebbe essere quello di essere rilassato al riguardo. Non sto dicendo indifferente. Sii consapevole della tua responsabilità, di ciò che puoi fare per aiutare e se ciò ti lascia con il tempo a disposizione, goditelo. Non puoi né devi essere 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 usando che rende difficile consigliare esattamente.

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

Considera se ci potrebbe essere un problema più ampio con te perché il lead sta assumendo troppo. Sì, le persone cercheranno la tua leadership tecnica, ma ciò non significa che alcuni dei membri del tuo team più capaci non possano condividere il carico di lavoro se sono guidati.

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

Se davvero non c'è nulla, dai loro qualcosa - passa attraverso registri, build, documenti, piani di test, progetti, diagrammi, scrivi programmi, organizza riunioni, organizza sessioni in borsa marrone, condividi conoscenze ecc. C'è sempre qualcosa da fare. Se le persone sono volentieri semplicemente sedute in giro a non fare nulla sulla moneta della compagnia che dovrebbe essere intensificata in quanto chiaramente non sono giocatori di squadra.