In un commento, hai chiarito la tua domanda come,

quali opzioni potrebbero esistere per correggere le prospettive a breve termine degli sviluppatori che si stanno facendo strada nel codice?

Piuttosto che affrontare direttamente le sfide specifiche che stai descrivendo (cioè come affrontare il tuo frustrante Scrum Master), penso che sia più prezioso fare un passo indietro, rimpicciolire e considerare una struttura per risolvere ciò che percepisci come problemi di qualità sul posto di lavoro, in generale.

Il problema con la qualità sul posto di lavoro è che, in molte situazioni, è arbitrario e altamente personale. Hai accennato a questo tu stesso in un altro commento quando hai detto,

Sono il tipo di persona che risolve i problemi molto tempo dopo che gli altri li considerano non degni di essere risolti

Questo mi dice che probabilmente hai una valutazione della qualità più rigorosa rispetto ad altri con cui stai lavorando. Le differenze nella percezione della qualità o del processo porteranno quasi sempre al tipo di conflitto che stai avendo. È facile che si trasformi in una spirale di argomenti, senza concentrarsi su ciò che stai effettivamente cercando di ottenere.

Quindi, prima di provare a risolvere uno qualsiasi dei tuoi problemi specifici, fai un passo indietro. Procedi come segue:

• Determina, ad alto livello, quali sono gli obiettivi della tua azienda.
• Determina come o perché questi obiettivi sono rilevanti per il tuo progetto.
• Ri-inquadra i tuoi problemi attraverso la lente di questi obiettivi, man mano che si applicano al tuo progetto
• Considera se i tuoi problemi devono ancora essere risolti e, in tal caso, sviluppa una soluzione che rimanda chiaramente ai tuoi obiettivi identificati.

Lo sviluppo del software è (quasi sempre) un mezzo per raggiungere un fine. La qualità del software e / o il tipo di problemi che i tuoi sviluppatori a breve termine stanno introducendo possono essere davvero frustranti per un perfezionista. Può sembrare un problema insormontabile. Tuttavia, seguendo i passaggi precedenti, puoi aiutare te stesso a vedere questi problemi dal punto di vista dell'azienda, invece che dal tuo punto di vista personale.

Questo è importante perché potrebbe comportare uno dei due risultati:

• Potresti renderti conto che le cose che vedi come problemi non sono realmente problemi. Questo è un momento di epifania comune per sviluppatori di software e responsabili dello sviluppo di software che sono abituati a perseguire un senso di perfezione. La maggior parte degli sviluppatori di software con formazione formale è stata addestrata all'idea che ci sia sempre una risposta migliore, o una soluzione migliore, e questa è l'unica che conta. Nel mondo reale, abbastanza buono è abbastanza buono. Se un team di software genera output che soddisfano le esigenze dell'azienda e si adattano agli obiettivi dell'azienda, questo è tutto ciò che conta.

Se non riesci a trovare un modo per creare un "file React.jsx di grandi dimensioni" rilevante per gli obiettivi dell'azienda, devi smetterla di preoccuparti. Ma se puoi dimostrare che il fatturato ha una correlazione diretta con la capacità della tua azienda di raggiungere i suoi obiettivi, potresti ottenere una certa trazione.

D'altra parte, il fatto che un campo di immissione di un numero di telefono non avere la funzionalità desiderata sembra essere un problema serio e facile da inquadrare in un contesto che l'azienda capirà. Ma sembra che sia più un problema di requisiti errati piuttosto che di turnover tra sviluppatori.

In definitiva, le aziende non assumono team di sviluppo software perché vogliono creare il miglior software al mondo. Assumono team di sviluppo software perché vedono il software personalizzato come un modo per risolvere i loro problemi aziendali. Pertanto, quando tu, in qualità di leader del team, incontri cose che ritieni siano problemi, l'approccio migliore è quello di controllare te stesso rispetto agli obiettivi dell'azienda e a quei problemi di business.

E poi se tu sei ancora sicuro che sia un problema, assicurati di inquadrarlo dal punto di vista del business invece che dal punto di vista dello sviluppo del software puro. Un'azienda che vede lo sviluppo del software come una merce - un mezzo per un fine - non considererà facilmente il fatturato un problema serio a meno che tu non le aiuti a capire perché, in termini che capiranno e con una soluzione che abbia senso all'interno della loro struttura.

Il comportamento dei tuoi colleghi si basa sui loro incentivi. I loro incentivi sono fissati a un livello molto alto.

Non so quale sia la tua esperienza o il tuo posto nell'organizzazione, ma dal momento che non hai nemmeno voce in capitolo nei processi utilizzati per lo sviluppo , Non credo che tu occupi un posto di significativo potere organizzativo. (E a proposito, voi ragazzi state facendo la forma più oscura di Dark Scrum di cui abbia mai sentito parlare). Sei super nuovo. Non hai alleati. Il tuo manager o è fatalista su questo o non gliene importa davvero. La tua organizzazione è organizzata in modo così disfunzionale che le risorse umane (ovvero il personale amministrativo) sono quelli che decidono come vengono trattati gli sviluppatori.

Quindi, in realtà, hai un'opzione:

Continua a lavorare qui fino a hai le capacità e l'esperienza per lavorare meglio da qualche parte, allora fallo. E forse seleziona meglio le aziende.

Che è esattamente quello che ha detto il tuo "star temp dev", perché è una reazione intelligente all'ambiente in cui si trovano.

Mi sembra che tu stia giocando una mano perdente:

• il tuo manager non sente di avere il capitale politico per spingere per il cambiamento (che subito è una bandiera rossa che è lì per imporre semplicemente lo status quo)
• i superiori non capiscono che la loro nave è diretta verso il disastro (un'altra bandiera rossa)
• lo scrum master non ha idea che il il lavoro che sta spingendo a portare a termine è inutile, o peggio, danneggia la tua base di codice (l'ennesima bandiera rossa)
• i dipendenti stanno giocando con il sistema per ottenere bonus (nessuna azienda è riuscita a incoraggiare la mancanza di coinvolgimento con le esigenze e gli obiettivi dell'azienda)
• sebbene tu veda il disastro imminente, le tue mani sono legate

La cosa più semplice da fare sarebbe iniziare a cercare un nuovo lavoro e lascia che queste persone (pazzi?) gestiscano il loro circo nel modo che preferiscono.

Se, tuttavia, stai cercando di restare in giro per un po ', potresti voler impostare un po' di tempo obiettivi a termine su ciò che si desidera migliorare e st l'arte che spinge piccoli cambiamenti incrementali.

Ad esempio, lottare per avere un paio di tecnici nello staff (a tempo pieno) e inviarli alle riunioni di raccolta dei requisiti, in modo che gli sviluppatori temporanei ottengano specifiche migliori. Oppure rivedi tu stesso i requisiti prima che il lavoro venga svolto (questa potrebbe essere una buona soluzione temporanea).

Spingi lentamente per più sviluppatori a tempo pieno o ottieni quelli su cui devi concentrarti sulla revisione dei temp qualità del codice. Fai in modo che chiunque effettui le revisioni per iniziare a includere la qualità del codice nei criteri, ecc.

Un elemento fondamentale è che dovresti stabilire linee di comunicazione molto forti con chiunque sia lo scrum master e convincerlo a renditi conto che devi essere coinvolto in ciò che viene fatto (discutere la revisione dei requisiti prima degli sprint, ecc.). Voi due dovete essere alleati, assicurandovi che il lavoro svolto sia pertinente e a prova di futuro, non semplicemente che uno sviluppatore soddisfi il suo obiettivo mal definito.

Col ​​tempo, potresti creare una situazione "abbastanza buona" che ti consenta di affrontare il debito tecnico che hai accumulato.

Mi sento come se la maggior parte (se non tutti) gli sviluppatori fossero lavoratori temporanei, questo avrebbe dovuto essere una bandiera rossa da prima che tu ti unissi.

Come suggerito da @AndreiROM (non sono abituato all'etichetta di etichettatura StackOverflow), la migliore alternativa sarebbe "lasciare che queste persone gestiscano il loro circo come preferiscono".

Il problema sembra essere la cultura aziendale. Se non c'è un gruppo forte e definito di sviluppatori in grado di imporre pratiche standard e aspettative di codifica definite, significa che la barca non è ancorata correttamente ed è una questione di tempo prima che finisca a riva.

O:

Ottieni un buon progetto da aggiungere al tuo portafoglio e uscirne a breve termine

o ...

Prova ad apportare modifiche sostanziali a tutta l'azienda

L'opzione A è probabilmente l'opzione migliore in generale e ti renderebbe libero di cercare facilmente altre opzioni.

L'opzione B, d'altra parte, significa che sei disposto e in grado di andare controcorrente e cercare di ottenere sviluppatori permanenti e sbarazzarti del tuo debito tecnologico già esistente. Questa opzione può creare una buona storia dell'eroe per provare a salire la scala, se è quello che stai cercando. Ma ti consiglio di non farlo.

Non ci sono vantaggi per gli sviluppatori nel fare le cose bene. C'è tuttavia un vantaggio per fare le cose velocemente: il bonus. Non ho riscontrato alcuna penalizzazione per il lavoro scadente e ho aggiunto il fatto che il loro contratto potrebbe o meno essere rinnovato in x mesi e hai praticamente eliminato l'incentivo agli sviluppatori a fare le cose bene.

cosa è importante per te / azienda e struttura il tuo sistema di ricompensa di conseguenza. Il tuo attuale sistema di ricompensa valuta la velocità di consegna, non la sua qualità.