Perché non possiamo fare qualcosa?

9

Lavoro in una piccola squadra, in un'azienda di medie dimensioni, la maggior parte delle quali non è coinvolta nello sviluppo di software. Sono lo sviluppatore più nuovo 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, sento che dovrei fare di più con questa generosa quantità di tempo di trasmissione. Come squadra, sembra che abbiamo difficoltà 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 saprei cosa suggerire.

Le cose che posso identificare come problemi includono:

  • La specificazione dei compiti a portata di mano è scarsa. Ciò è in parte dovuto al fatto che 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 finché non viene dimostrato e utilizzato per determinarne l'efficacia.
  • Il Lead Dev è molto affezionato a ciò che definisce "prototipazione" al punto che recentemente ha iniziato a insistere sul fatto che tutto sia "prototipato", che al resto di noi sembra scrivere codice cattivo e darlo ai modellisti per giocare con. Non è chiaro cosa si aspetti di uscire da questo esercizio in molti casi. L'implementazione "effettiva" soffre poi a causa della sua insistenza sul fatto che le buone pratiche impiegano troppo tempo dalla prototipazione. Non ho nemmeno iniziato a essere in grado di districare questa logica distorta e non sono sicuro di voler provare.
  • Ci si aspetta che i modellisti ci raccontino tutto sulla metodologia desiderata con dettagli precisi, e ci si è fidati completamente che ciò che hanno scoperto è teoricamente impeccabile. Questo non è quasi mai vero, ma non viene intrapresa alcuna azione per correggere questa situazione. Nessuno dal lato della modellistica solleva preoccupazioni in modo strutturato su cui è probabile che si agisca, né cerca indicazioni nell'applicare le migliori pratiche. Nulla è fatto anche per la loro passività.
  • Ho cercato di spingere TDD nella squadra prima, ma ho trovato difficile perché è nuovo per me e mentre quelli con la supervisione del mio lavoro erano disposti a tollerarlo, nessun entusiasmo è arrivato da nessun altro. Non riesco a giustificare la quantità di tempo che dedico a spendere e non a rifinire le funzioni, quindi l'idea - per il momento - è stata abbandonata. Sono preoccupato che non verrà ripreso, perché a nessuno piace essere detto come fare il loro lavoro.
  • Ora disponiamo di un server di integrazione continuo, ma è in gran parte utilizzato solo per eseguire test di regressione di più ore. È stato lasciato aperto il fatto che dovrebbe essere in esecuzione anche test di integrazione e di piena copertura, ma al momento nessuno li scrive.
  • Ogni volta che sollevo il problema della qualità con lo sviluppo principale, ottengo una risposta all'effetto di "La funzionalità di test A è semplice, la funzionalità B è molto più importante per l'utente ma troppo difficile da testare, quindi non dovremmo t funzione di prova A '. Ancora una volta non ho fatto progressi nel tentativo di districare questa logica.

.... uff. Quando lo esprimo in questo modo, sembra molto peggio di quanto pensassi. Suppongo che, a quanto pare, questa è una richiesta di aiuto.

    
posta Tom W 06.11.2011 - 18:49
fonte

4 risposte

19

Lasciami fare l'avvocato del diavolo per un momento:

Specification of the tasks at hand is sparse... The Lead Dev is very fond of what he calls 'prototyping'

Lo sviluppatore principale è appassionato di prototipazione perché le specifiche sono sparse. Questa è probabilmente una buona cosa; questo è il modo in cui i negozi iterativi funzionano.

The modellers are expected to tell us everything about the desired methodology in precise detail

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 concretizzare i requisiti.

I've tried to push TDD in the team before, but found it difficult as it's new to me

Anche questo non funzionerà; hai bisogno di capire la tecnologia prima di poterla evangelizzare. Inoltre, in un negozio iterativo con scarse esigenze, il TDD potrebbe essere troppo sovraccarico. È meglio incoraggiare un'adeguata copertura dei test unitari.

We now have a continuous integration server, but it's mostly only being used to run multiple-hour regression tests.

Potrebbe essere appropriato in un piccolo negozio iterativo.

Every time I raise the issue of quality with the lead dev, I get an answer to the effect of 'Testing feature A is straightforward, feature B is much more important to the user but too difficult to test, therefore we shouldn't test feature A'

Sembra che il tuo negozio abbia dei vincoli temporali piuttosto stretti; piaccia o no, sei vincolato da quei vincoli.

Sembra anche che tu sia venuto da una parte dell'industria del software che apprezza il fare le cose "nel modo giusto" prima di introdurre le cose sul mercato. Non c'è niente di sbagliato in questo (è ammirevole, infatti), tranne che il primo a commercializzare con un software buggato è spesso il vincitore. Non è giusto, ma è così.

    
risposta data 06.11.2011 - 19:07
fonte
2

Mi concentrerò sulla prototipazione qui

il problema principale con i prototipi è che sono intesi come proof of concept

tuttavia, se non riesci a sviluppare ulteriormente il prototipo e hai bisogno di ricostruire il prodotto finale da zero, potresti anche non costruire il prototipo e hai perso tempo a costruirlo

il mio consiglio al team è di ottenere una certa qualità e flessibilità in quei prototipi. So che non è possibile creare cose perfette per la prima volta, ma cercare di rimanere estensibili per i requisiti futuri

    
risposta data 06.11.2011 - 20:58
fonte
1

Queste sono buone risposte. Posso solo aggiungere che "provare a comunicare" è nel migliore dei casi una proposta incerta. I cambiamenti nel modo in cui un'organizzazione funziona non avvengono rapidamente. Quando succede spesso è come una marea, dove la quantità di moto cresce dal basso e dall'alto. Quindi sarai più felice se manterrai basse le tue aspettative e attendi la tua possibilità di dire come andranno le cose o non vedi l'ora di lavorare con un'altra organizzazione.

    
risposta data 06.11.2011 - 21:31
fonte
1

Hai identificato qualcuno della compagnia che lo "prende" in questo caso, attaccati a questo tizio e impara il più possibile da lui. In caso contrario, dedica il tuo tempo, inizia a imparare e cresce da solo (partecipa a un progetto Open Source o avvia il tuo progetto) e cerca un luogo che possa favorire la tua crescita.

La cosa peggiore che può succedere è che tu resti lì e impari come fare le cose nel modo sbagliato. Sì, ci dovrebbe essere un po 'di pragmatismo, ma una squadra veramente competente può fare le cose nel modo giusto ed essere sempre in tempo con un prodotto di qualità. Sembra che il tuo team attuale non abbia quello che serve e dovresti iniziare a cercarne uno nuovo.

    
risposta data 06.11.2011 - 21:33
fonte

Leggi altre domande sui tag