Perché non possiamo fare nulla?

Lavoro in un piccolo team, in un'azienda di medie dimensioni, la maggior parte delle quali non è coinvolta nello sviluppo di software. Sono lo sviluppatore più recente e meno esperto e non ho avuto alcuna esperienza professionale o accademica nel software prima di iniziare, ma sono abbastanza soddisfatto di quanto sia rispettato il mio contributo e sono grato di essere stato preso sul serio in una fase così precoce della mia carriera.

Tuttavia, mi sento come se dovessi fare di più con questa generosa quantità di tempo di trasmissione. Come squadra, sembra che abbiamo problemi a fare le cose. Mi piacerebbe essere in grado di suggerire qualcosa per migliorare la situazione, e penso che sarei ascoltato se fosse una buona idea, ma non so cosa suggerire.

Le cose che posso identificare come problemi includono:

• Le specifiche delle attività da svolgere sono scarse. Questo in parte perché la gestione è un collo di bottiglia e non abbiamo i soldi o le persone per impegnarci a elaborare requisiti dettagliati quanto vorremmo. In parte è anche perché il software che stiamo sviluppando è investigativo e il metodo preciso non è chiaro fino a quando non viene dimostrato e utilizzato per determinarne l'efficacia.
• Il Lead Dev è molto affezionato a ciò che chiama "prototipazione" al punto che ultimamente ha iniziato a insistere sul fatto che tutto è "prototipato", che per il resto di noi sembra scrivere codice errato e darlo ai modellatori con cui giocare. Non è chiaro cosa si aspetti che esca da questo esercizio in molti casi. L'implementazione 'effettiva' soffre quindi a causa della sua insistenza sul fatto che le buone pratiche impiegano troppo tempo a realizzare il prototipo. Non ho nemmeno iniziato a essere in grado di districare questa logica contorta e non sono sicuro di voler provare.
• I modellisti dovrebbero dirci tutto sulla metodologia desiderata in dettaglio preciso, ed è preso la fiducia assoluta che ciò che ne viene fuori è teoricamente impeccabile. Questo non è quasi mai vero, ma non viene intrapresa alcuna azione per correggere questa situazione. Nessuno dal punto di vista della modellistica solleva preoccupazioni in un modo strutturato su cui è probabile che venga attuato, né cercano una guida nell'applicazione delle migliori pratiche. Neanche si fa nulla della loro passività.
• Ho provato a spingere TDD nel team prima, ma ho trovato difficile in quanto è nuovo per me e mentre quelli con la supervisione del mio lavoro erano disposti a tollerarlo, nessun entusiasmo è stato suscitato da nessun altro. Non posso giustificare il tempo che trascorro sguazzando e non finendo le caratteristiche, quindi l'idea è stata - per il momento - abbandonata. Temo che non verrà ripreso di nuovo, perché a nessuno piace sentirsi dire come fare il proprio lavoro.
• Ora disponiamo di un server di integrazione continua, ma viene utilizzato principalmente per eseguire test di regressione di più ore. È stato lasciato aperto il fatto che dovrebbe essere in esecuzione anche unità a copertura totale e test di integrazione, ma al momento nessuno li scrive.
• Ogni volta che sollevo il problema della qualità con lo sviluppatore principale, ottengo una risposta all'effetto di "Testare la funzione A è semplice, la funzione B è molto più importante per l'utente ma è troppo difficile da testare, quindi non dovremmo testare la funzionalità UN'. Ancora una volta non ho fatto progressi nel tentativo di districare questa logica.

.... uff. Quando lo dico così, sembra molto peggio di quanto pensassi. Suppongo, a quanto pare, questo è un grido di aiuto.

Lasciami interpretare l'avvocato del diavolo per un momento:

Le specifiche dei compiti da svolgere sono scarse ... Il Lead Dev è molto affezionato a ciò che chiama "prototipazione"

Il principale sviluppatore ama la prototipazione perché le specifiche sono scarse. Questa è probabilmente una buona cosa; ecco come funzionano i negozi iterativi.

I modellisti dovrebbero dirci tutto sulla metodologia desiderata in dettaglio preciso

Questo non funzionerà in un negozio iterativo. La natura stessa dello sviluppo iterativo è che i requisiti sono spesso incompleti. Le iterazioni sono ciò che è necessario per perfezionare i requisiti.

Ho già provato a inserire TDD nel team, ma ho trovato difficile perché è nuovo per me

Neanche questo funzionerà; devi capire la tecnologia prima di poterla evangelizzare. Inoltre, in un negozio iterativo con requisiti scarsi, il TDD potrebbe essere eccessivo. È meglio incoraggiare un'adeguata copertura dei test unitari.

Ora disponiamo di un server di integrazione continua, ma viene utilizzato principalmente per eseguire test di regressione di più ore.

Ciò può essere appropriato in un piccolo negozio iterativo.

Ogni volta che sollevo il problema della qualità con lo sviluppatore principale, ottengo una risposta all'effetto di "Testare la funzione A è semplice, la funzione B è molto più importante per l'utente ma è troppo difficile da testare, quindi non dovremmo testare la funzionalità UN'

Sembra che il tuo negozio abbia dei limiti di tempo abbastanza stretti; piaccia o no, sei vincolato da questi vincoli.

Sembra anche che tu provenga da una parte dell'industria del software che apprezza il fatto di fare le cose "nel modo giusto" per ottenere le cose sul mercato prima. Non c'è nulla di sbagliato in questo (è ammirevole, in effetti), tranne per il fatto che il primo sul mercato con un software difettoso è spesso il vincitore. Non è giusto, ma è così.

Mi concentrerò sulla prototipazione qui

il problema principale con i prototipi è che sono intesi come prove di concetto

tuttavia, se non è possibile sviluppare ulteriormente il prototipo e è necessario ricostruire il prodotto finale da zero, è possibile che non si sia creato il prototipo e si sia perso tempo a costruirlo

consiglio al tuo team di ottenere qualità e flessibilità in questi prototipi. So che non è possibile creare cose perfette la prima volta, ma cercare di rimanere estensibile per esigenze future

Queste sono buone risposte. Posso solo aggiungere che "cercare di comunicare" è nella migliore delle ipotesi una proposta incerta. I cambiamenti nel modo in cui un'organizzazione funziona non avvengono rapidamente. Quando succede è spesso come una marea, dove lo slancio si sviluppa dal basso e dall'alto. Quindi sarai più felice se mantieni le tue aspettative basse e o aspetti la tua occasione per dire come verranno fatte le cose o non vedi l'ora di lavorare con un'altra organizzazione.

Hai identificato qualcuno in azienda che lo "capisce" in tal caso, aggrappati a questo ragazzo e impara il più possibile da lui. In caso contrario, dedica il tuo tempo, inizia a imparare e crescere da solo (unisciti a un progetto Open Source o avvia il tuo progetto) e cerca un posto che possa favorire la tua crescita.

La cosa peggiore che può succedere è rimanere lì e imparare a fare le cose nel modo sbagliato. Sì, dovrebbe essere preso un po 'di pragmatismo, ma un team veramente competente può fare le cose nel modo giusto ed essere comunque puntuale con un prodotto di qualità. Sembra che la tua squadra attuale non abbia quello che serve e dovresti iniziare a cercarne uno nuovo.