Fondamentalmente hai bisogno che l'organizzazione la valuti nel suo insieme.

Ero con te alcuni mesi fa. Ora sono uno di quegli sviluppatori con cui sei frustrato.

La realtà è che le persone hanno in mente determinate tempistiche e quelle non cambiano mai. Demo qualcosa a loro e poi sono "dov'è? Dov'è?" E lo faranno ogni volta. Questo è in cima alle persone che si preoccupano di mantenere le cose in movimento. Le organizzazioni tendono anche a dare valore a certe cose e quei valori guidano il modo in cui le cose vengono fatte.

La conversazione di solito va così:

Persona: "Ehi, dov'è quella caratteristica che mi hai mostrato ieri ? "

Io:" È in attesa di revisione del codice. "

Persona:" Bene, ne abbiamo bisogno per eseguire il QA / risolvere il problema di produzione / averlo nella demo sprint / per il cliente incontro domani "

Io:" È dietro la cosa che mi hai chiesto ieri in coda. "

Persona:" Bene, ne abbiamo bisogno per il QA / risolvere il problema di produzione / averlo nella demo sprint / per la riunione del cliente domani "

Io:" Vedrò cosa si può fare. "

Persona (un'ora dopo):" Qualche aggiornamento? Noi ne hai bisogno per il QA / risolvere il problema di produzione / averlo nella demo sprint / per la riunione del cliente domani. "

Dopo mesi e mesi, git push è un diavolo di un molto più facile da fare. Soprattutto perché per loro è urgente, quindi sono altamente motivati ​​a ottenerlo. Per molti versi hanno ragione perché le scadenze sono reali e non qualcosa che possono controllare. Quindi, anche dal punto di vista dell'essere un'unità aziendale, è probabilmente la decisione corretta.

Affinché i processi sopravvivano, l'organizzazione nel suo insieme (o almeno l'intera unità aziendale) deve valutarli. La tua organizzazione chiaramente no. Risulta in più bug? Probabilmente. Ma le persone al di fuori del software sono arrivate ad accettare i bug solo come qualcosa che accade, quindi prevenirli spesso non è la priorità principale.

È una questione di compromessi, sia per l'organizzazione che per i singoli sviluppatori.

Se vuoi risolvere questo problema, devi fondamentalmente convincere le vendite, Scrum master e il product owner che è utile non aggirare questo processo. Probabilmente la vedono come burocrazia.

Il nostro capo concorda sul fatto che non dovremmo farlo, ma non vuole dover litigare costantemente con le persone, quindi lascia perdere e mi dice di dire agli altri sviluppatori di respingere. L'80% del codice ora esce senza

Ti sta chiedendo te di fare il suo lavoro. Completamente poco professionale. Questa non dovrebbe essere una lotta costante. Questa dovrebbe essere una legge assoluta e il combattimento si fermerebbe dopo uno o due rimproveri scritti.

Non c'è davvero molto che puoi fare in questa situazione. Tu e gli altri sviluppatori a cui importa potreste provare la pressione dei pari, ma non sembra che ci sia abbastanza che si preoccupi abbastanza, o che non abbiano (comprensibilmente) rinunciato, per fare la differenza.

Io inizia onestamente a cercare un altro lavoro

MODIFICA:

Un'altra opzione, se ritieni di aver provato di tutto con il tuo capo, sarebbe quella di andare sopra la testa del tuo capo al loro capo e cercano di affrontare questo problema più in alto nella catena. Questo dovrebbe essere fatto con attenzione e possibilmente in modo anonimo, poiché esaminare la testa del tuo capo può avere gravi ripercussioni.

In questo momento: non fare nulla. Va tutto bene, niente è rotto.

La prossima volta che si verifica un bug che interrompe la produzione: urla dalla cima dei tuoi polmoni (non letteralmente) su come questo bug avrebbe potuto essere evitato se avessimo dovuto testare esso. Spiega in che modo testare attentamente e prendere tempo è inteso specificamente per evitare questo tipo di situazione. Quantificare quanti soldi l'azienda ha perso e quanto tempo di inattività ha avuto il servizio a causa di un bug che non è stato rilevato ma che avrebbe potuto esserlo se agli sviluppatori fosse stato concesso più tempo per essere più attenti.

La gestione è sempre più aperta a un cambiamento nel processo quando vedono il valore in prima persona e immediatamente. Se parli in astratto, come "beh, dovremmo davvero fare dei test, perché un giorno potremmo avere un problema da qualche parte che potrebbe mettere fuori uso i nostri server", a nessuno importa, perché per quanto probabile possa accadere, potrebbe anche non accadere, e in questo momento non sta succedendo quindi a nessuno importa. Tuttavia, alla fine accadrà sicuramente, ed è allora che puoi indicarlo come un punto dolente e mostrare il valore immediatamente, non in astratto.

Ovviamente, la direzione potrebbe tornare e dire "bene, se voi ragazzi foste sviluppatori migliori, non creereste bug e non avreste bisogno di test ". Questo è il punto in cui rispolverai il tuo curriculum e trovi un altro lavoro. Ogni sviluppatore commette errori; non c'è sviluppatore che non abbia mai fornito codice con bug ed è responsabilità dell'azienda dare agli sviluppatori il tempo per assicurarsi che il loro codice sia il più possibile privo di bug.

Hai diagnosticato erroneamente il tuo problema.

Cosa stai vedendo con il bypass di standard / recensioni / ecc.? Questo è un sintomo del tuo problema.

Il tuo vero problema è la combinazione di due cose:

• Il tuo capo non vuole essere conflittuale sulle cose
• I tuoi colleghi vedono il lavoro come temporaneo e fanno solo il minimo

Il tuo capo ha delegato efficacemente il confronto dell'area commerciale ai tuoi colleghi ... e i tuoi colleghi sono solo seguendo il flusso finché non trovano un altro lavoro. Sarei molto sorpreso se gli standard fossero l ' unico sintomo di ciò. Le tue priorità sono dettate da qualsiasi cosa più in alto urla più forte, non da ciò che effettivamente aiuta di più l'azienda? Non è un problema separato dalla tua domanda: è qualcosa che anche deriva da quella combinazione. Ecc. Sono probabili dozzine di problemi, grandi e piccoli, che derivano da questi due fattori.

Realisticamente, non puoi risolvere questo problema. I tuoi scatti migliori sarebbero:

• Fare in modo che il tuo capo inizi a fare il suo lavoro, o farlo sostituire da qualcuno che lo farà.
• Rendere l'atmosfera lavorativa abbastanza piacevole da far sì che i tuoi colleghi visto come una carriera.

Per i venditori che necessitano di una funzionalità nella loro demo, puoi configurare un ramo demo e un server demo. Basta spingere tutto ciò di cui hanno urgentemente bisogno e quindi unirlo di nuovo al ramo dev e infine al ramo master una volta che i test unitari e la revisione del codice sono stati completati.

Saltare il processo per ottenere qualcosa prima della fine dello sprint o stare in piedi è sciocco ei guadagni a breve termine saranno compensati dalla necessità di aggiustare qualcosa in produzione. Il tuo team ha bisogno di comprendere il valore dei test e della revisione del codice e potresti anche dover rivedere le stime del tuo story point se c'è fretta di impegnare cose non finite prima della fine dello sprint.

Nei casi in cui gli estranei iniziano a immischiarsi nel tuo processo, smetti semplicemente di spiegare loro il tuo processo. Ogni frammento di informazione che dai loro, fornisce loro un nuovo gancio per discutere perché dovresti / non dovresti fare qualcosa.

In un'azienda in cui il refactoring veniva costantemente saltato a causa di scadenze "urgenti" (io uso le virgolette perché tutto era sempre la massima priorità senza eccezioni), ho semplicemente smesso di menzionare il refactoring come passaggio separato (e quindi ignorabile individualmente) e ho iniziato a contare il refactoring come lavoro di sviluppo che faceva parte della stima.

Invece di " 2 giorni di sviluppo, 1 giorno di revisione / refactoring ", che avrebbe sempre ottenuto la stessa reazione da parte del management (" Ho bisogno che tu rilasci dopo 2 giorni, non abbiamo tempo per il refactoring "), ho invece detto" 3 giorni di sviluppo " e non l'ha scomposto ulteriormente. La direzione ha perso la capacità di discutere su quali parti del mio lavoro potevo saltare solo perché a loro personalmente non interessa.

Il refactoring e la revisione del codice, da una prospettiva di gestione a breve termine, sono uno "spreco" di tempo che potrebbe essere speso per l'elemento fatturabile successivo. Ma migliora notevolmente la qualità della vita degli sviluppatori, riducendo il burnout degli sviluppatori e le persone che smettono di funzionare, il che migliora notevolmente la produzione a lungo termine del team di sviluppo.

Nelle aziende in cui la qualità del codice e gli sviluppatori che lasciano in meno di un anno è un problema costante, è (nella mia esperienza) quasi sempre attribuito al management che si immischia in processi di sviluppo di cui non apprezzano o non comprendono il valore. Ho lavorato in diverse aziende come queste.

Alcuni manager comprendono l'importanza della qualità della vita dei loro dipendenti, e alcuni manager non se ne curano o se ne fregano: in entrambi stesso. Quando ho a che fare con manager che rientrano in quest'ultima categoria, sono sempre parsimonioso con le specifiche in modo che non si intromettano dove non dovrebbero intromettersi.

Questa battaglia deve essere combattuta solo una volta se convinci il tuo capo e un numero sufficiente di colleghi a impostare un sistema di autorizzazioni che semplicemente non lo consente.

Usiamo GitHub, ma altri servizi hanno opzioni simili per consentire l'unione al ramo principale solo dopo che il codice è stato approvato da un proprietario del codice. Naturalmente, solo coloro che prendono sul serio il processo dovrebbero essere i proprietari del codice.

Una volta stabilito, questo diventerà una nuova normalità. Certi processi è meglio non lasciare al caso.

Gli argomenti principali che vorrei fare a un manager sul motivo per cui le revisioni del codice dovrebbero essere applicate:

• la revisione del codice è tra le misure efficaci per prevenire i bug. Personalmente li trovo più efficaci dei test (anche se si dovrebbero avere entrambi!). Un buon sviluppatore può prevenire il peggio da un numero di sviluppatori meno esperti o motivati ​​
• basta un solo bug serio per causare una perdita potenzialmente grave di funzionalità e / o dati. Ancora peggio, in un certo senso, è la corruzione dei dati, che può passare inosservata per un po 'e rendere praticamente inutili le procedure di ripristino come i backup. Questo ovviamente dipende dal prodotto.
• È probabile che i bug comporteranno un costo diretto per l'azienda in termini di perdita di entrate e / o di clienti (di nuovo, dipende dal prodotto, ma pochi possono "permettersi" di essere crivellato da bug)
• come bonus, le recensioni sono un ottimo strumento di formazione

Gli utenti finali (vendite, assistenza clienti, clienti / clienti / partner, ecc.) non dovrebbero avere accesso diretto al team di sviluppo in generale. (Se la segretaria, i venditori o il triage dell'assistenza clienti chiama / invia un'e-mail direttamente agli sviluppatori, questo dovrebbe essere risolto e questi dovrebbero contattare l'interfaccia lato aziendale per il team ... aka il gatekeeper.)

Il team di sviluppo dovrebbe indirizzare qualsiasi richiesta sullo stato di una correzione / modifica / funzionalità al gatekeeper del team (responsabile tecnico / team, BA, PM, PO, qualunque cosa).

Poiché è impossibile per isolare del tutto un team di sviluppo dal resto dell'organizzazione, è importante che il gatekeeper non sia un "yes man", sia orgoglioso del proprio lavoro e comprenda il concetto di "la fretta fa spreco".

Se stai adottando un approccio agile allo sviluppo con sprint / retrospettive, come parte del team di sviluppo puoi sollevare questo argomento nella retrospettiva. "Abbiamo fatto passare un sacco di PR senza test e verifiche sufficienti, dobbiamo lavorare su questo." Questo è precisamente il motivo per cui le retrospettive sono importanti: "Cosa è andato bene, cosa è andato male, cosa possiamo fare per risolvere il problema?"

Se uno di questi PR provoca la segnalazione di un difetto, non appena vedi che il bug è stato segnalato, se puoi collegarlo al ticket originale, fallo. Assicurati anche che sia assegnato alla persona che lo ha introdotto (solo perché ha l'esperienza più recente in quell'area del codice e molto probabilmente risolverà il problema rapidamente, ovviamente, non perché "l'hai rotto, tu risolverlo ").

Ci sono molti modi per risolvere questo problema: alcuni avranno più successo di altri e molto dipende dai processi della tua organizzazione, così come dalla personalità del tuo team ( compreso il tuo supervisore).

I processi dovrebbero essere progettati per portare a termine il lavoro in modo accurato e tempestivo. Se le persone aggirano regolarmente il sistema e il sistema è ben progettato, dovresti essere in grado di citare una serie di problemi che sono stati generati dall'elusione. Tu e / o il tuo capo (forse il tuo capo armato di dati da te) dovete fare un elenco specifico di questi problemi, il che ha molto più peso del semplice lamentarsi dell'elusione. Se l'elusione è comune come dici e non puoi fare un elenco del genere, i processi sono sbagliati. In effetti stanno ostacolando il buon lavoro svolto. È tempo per un'attenta revisione del processo. I passaggi di revisione elusi non creano problemi, quindi eliminali. Guarda quali problemi sarebbero stati individuati da quali recensioni. L'organizzazione deve quindi definire quali revisioni sono obbligatorie, applicare tali norme e rendere le revisioni una priorità in modo che avvengano in modo tempestivo in modo da non rallentare troppo il lavoro.

Il tuo input è inutile se non viene scritto. Pertanto proporrei di impostare un sistema di registrazione, che registra tutte le azioni, eseguite su una determinata attività:

Una volta che qualcuno ha implementato qualcosa, l'hash del commit viene aggiunto al report di bug e ogni attività aggiuntiva (revisione del codice, test di unità, ...) viene anche aggiunto alla segnalazione di bug, in modo tale che tu possa facilmente trovare le seguenti domande:

• Quale percentuale delle segnalazioni di bug effettivamente ha superato la revisione del codice?
• Quale percentuale delle segnalazioni di bug ha effettivamente superato l'intera catena di sviluppo?
• ...

Inoltre, deve essere possibile registrare il motivo per cui qualcosa non è stato fatto:

• revisione del codice non superata a causa della definizione delle priorità aziendali.
• Test unitario incompleto (viene eseguito solo il 20% dei test)
• ...

Senza tale registrazione, stai solo gridando nel buio.

Hai ragione. Tutti gli altri in questa situazione si sbagliano.

Sembra che tu debba continuare a essere "quel ragazzo" che infastidisce tutti insistendo sul processo . Il tuo capo non sta assumendo la leadership su questo, quindi devi farlo invece. Spingere direttamente al master significa che è solo una questione di tempo prima che il tuo prodotto abbia una via di fuga di qualità che abbia un impatto sui tuoi clienti e sul tuo team.

Vuoi farlo essere la persona che dice "te l'avevo detto" in questo caso e ha la comunicazione (e-mail, ecc.) a sostegno. Questo dovrebbe metterti in una posizione migliore: potresti persino finire con il lavoro del tuo capo.

Un'altra cosa da considerare è chiedere strumenti migliori che rendano più facile per le persone seguire il processo e più difficile forzare la spinta a padroneggiare. GitHub e GitLab hanno una funzione di branch protetta che consente solo ai proprietari del progetto di eseguire il push al master. Puoi persino bloccare il tuo repository in modo che le richieste di unione debbano essere approvate da un altro sviluppatore e da un addetto al QA prima di essere unite. Puoi anche ottenere un server di compilazione che esegua gli unit test automaticamente su una richiesta di unione / pull. Sembra che il tuo capo sia d'accordo con questo anche se, quindi non dovrebbe essere troppo difficile convincerlo a iniziare a utilizzare strumenti migliori.

Non aspettare solo che le cose cambino dopo che qualcuno ha notato un grosso errore. Non hai il controllo su cosa succede se la direzione nota che il team di sviluppo sta commettendo grossi errori. Chiama i problemi presto e spesso per il tuo bene tanto quanto per il resto della squadra.

Ovviamente, se sei stanco di combattere, hai sempre la possibilità di andartene, ma questo potrebbe essere un'opportunità di carriera per te se scegli di rimanere.

Ho avuto il piacere di frequentare un corso di Agile tenuto da Bob Martin ("Uncle Bob"). Se non lo conosci, è uno dei fondatori di ciò che chiamiamo Agile.

Lo scopo di Agile è di mettere "quella funzionalità che il cliente vuole vedere il 1 ° ottobre" di fronte al cliente il 1 ° ottobre, OPPURE, chiarisci alla tua direzione il 1 ° luglio che non finirai mai quella funzione entro il 1 ° ottobre. A sua volta, la tua direzione chiarisce ai tuoi clienti il ​​2 luglio che non vedranno quella funzione il 1 ° ottobre. A meno che non vengano concordati alcuni tipi di modifiche / compromessi. Questo è ciò che dovrebbe fare il management.

Quindi, nonostante abbia tutte le trappole tecniche di Agile in atto, è chiaro per me che la tua azienda non sta davvero facendo la parte importante. La direzione deve sapere cosa vuole il cliente e quando lo vuole. Hanno bisogno di visibilità (una metrica quantitativa affidabile) su dove si trovano gli sviluppatori. Queste informazioni devono essere discusse e adattate continuamente con il cliente col passare del tempo. Questo è Agile.

Le revisioni del codice, il TDD, la programmazione in coppia e il refactoring sono attività tecniche che consentono una buona qualità del software e abilità. Tuttavia, queste cose da sole non significano che l'azienda stia utilizzando un processo Agile. I dirigenti devono gestire utilizzando i dati ottenuti da questi processi incorporare il feedback dei clienti per regolare le tempistiche come richiesto. È così semplice.

La situazione che hai è che gli sviluppatori stanno cercando di utilizzare buone tecniche di artigianato del software in un'azienda che non utilizza un processo di gestione Agile. Sembra il caos, dove varie persone fanno varie promesse in modo scoordinato. In qualità di sviluppatore, non puoi farci niente.

L'opinione degli altri sviluppatori della situazione è che probabilmente saranno qui per un altro anno al massimo, quindi lasciare che il codice marcisca è più economico delle discussioni quotidiane sul processo con varie persone che non apprezzano un'ingegneria attenta.

Penso che questo sia il problema principale. Se gli sviluppatori ritengono che rimarranno con l'azienda solo per un breve periodo di tempo, saltare le best practice per Get Stuff Done non sembra un grosso problema.

Perché gli sviluppatori si sentono come se lo fossero resterà in azienda solo un "anno al massimo"? Sembra un periodo piuttosto breve per chiunque intenda lavorare per un'azienda.

Esistono diversi modi per eseguire lo sviluppo organizzato, a seconda del team e del prodotto. Il flusso che ora viene tipicamente spinto presuppone che tutti lavorino su tutto e apportino modifiche frequenti ma piccole allo stesso ramo principale, ma attraverso la revisione del codice e le richieste pull.

Questo non è l'unico modo per fare il sviluppo. Se "i processi non vengono seguiti" ma lo sviluppo va bene, forse vengono effettivamente seguite alcune altre regole e processi: programmazione in coppia, proprietà del codice, rami di rilascio, rami di funzionalità, ramo di sviluppo, sviluppo basato su test o qualcosa di simile.

In tal caso, potrebbe essere meglio scoprire e acquisire i processi effettivi piuttosto che tentare di risolverli che probabilmente non sono guasti.

Cosa posso fare al riguardo?

Il tuo capo ti ha detto che puoi respingere in modo da evitare di sentirmi sotto pressione ignorando la comunicazione progettato per metterti sotto pressione mentre stai già lavorando su un oggetto. Questo insegnerà agli altri a smettere di cercare di farti pressione.

Dopo aver letto alcuni altri commenti che si occupavano della cultura aziendale: puoi migliorare la cultura aziendale solo se ti trovi in ​​una posizione di gate keeper (non necessariamente manageriale) puoi bloccare la distribuzione di qualcosa e il tuo capo ti sosterrà. Ciò implica che il nonno sosterrà il tuo capo ... che il capo del nonno lo sosterrà e così via.

Riconosco il commento di Gregory Currie che: "C'è una differenza ragionevolmente grande tra il dire qualcuno qualcosa e convincere qualcuno. Dire a qualcuno si basa sull'autorità, convincere può essere fatto in molti modi "

Ho lavorato in luoghi in cui il valore di fare le cose nel modo giusto non poteva essere dimostrato perché la gestione continuava a consentire programmi non realistici. Non l'ho visto funzionare dove le persone sono convinte senza un'autorità che supporti buoni processi.

Di solito se le cose vanno in un certo modo è perché è esattamente ciò che vuole la direzione, indipendentemente da ciò che dicono tu. Quel ragazzo con cui lavori e che non ha nessuna cura per la qualità è stato assunto da qualcuno che sapeva di essere in quel modo o non gli importava che fosse così. Se hai una scadenza irragionevole è perché più persone sopra di te concordano con quella. Se non riesci a immaginare il motivo per cui viene rilasciato codice scadente, il tuo capo può immaginare perché e capisce perché.

In definitiva tutto ciò che facciamo come sviluppatori (in un'azienda) è guidato dalle esigenze aziendali. Il lato aziendale potrebbe avere una ragione legittima per costringerti a affrettare il codice come se sapessero che l'azienda fallirà in un breve periodo di tempo se ai clienti non possono essere mostrate nuove funzionalità e ci vorrebbe anche aspettare che le funzionalità siano di qualità superiore lungo.

Ho visto aziende in cui hanno avuto le difficoltà che descrivi. E poi entro 1-2 anni tutti vengono licenziati. La direzione sapeva che sarebbe successo molto prima degli sviluppatori.

Parla di nuovo con il tuo capo. Il tuo capo deve dichiarare che questa è legge d'ora in poi. Se non vuole litigi continui, stabilisci regole sufficientemente rigide per le eccezioni in modo che le persone non le prendano alla leggera.

Se questo va avanti per troppo tempo, le persone si abitueranno ad esso e sarà sempre più difficile cambiare. Forse il capo deve coinvolgere il suo capo.

Non puoi fare molto senza il sostegno. Potresti provare a persuadere i tuoi colleghi che seguire il processo fa bene al loro CV e la capacità di dire cortesemente di non promuovere la loro carriera da nessuna parte. Questo è vero e anche difficile da vendere.

Concordo con le altre risposte che il processo dovrebbe essere in atto per una ragione e seguito.

Concordo anche che è compito del tuo capo combattere questa lotta con gli stakeholder aziendali e dovrebbe essere fino a spiegare loro che il rilascio a velocità vertiginosa aumenta drasticamente il rischio che i numeri che interrompono lo spettacolo (fine dell'attività?) vengano pubblicati.

Detto questo, un modo per porre fine a questo salto del processo consiste nell'implementare una correzione tecnica. Puoi "proteggere" il ramo principale e disabilitare la possibilità per le persone di inviarlo senza un processo di revisione appropriato:

https://docs.github.com/en/github/administering- a-repository / defining-the-mergeability-of-pull-requests

Questo può essere fatto anche in altre soluzioni di gestione del repository come TFS.

Se tu togliere agli sviluppatori la possibilità di accelerare la produzione del codice, quindi viene rimossa anche la pressione su di loro per farlo. Questo sposta la pressione lungo la catena fino al tuo capo (dove dovrebbe essere) e spetta a lui avere questi argomenti.

Per cominciare, non è tua responsabilità risolverlo, ma è comunque una buona cosa essere orientati al processo.

Potresti suggerire di utilizzare un sistema CI / CD che consentirà la distribuzione solo quando tutti i criteri (test, ...) saranno soddisfatti. Altrimenti la pipeline fallisce e la modifica viene rifiutata.

Se hai un controllo abbastanza stretto della pipe, allora tali scorciatoie falliranno. Vorrei anche documentare chiaramente il processo di eccezione in modo che ci sia qualcosa da indicare quando il venditore o chiunque ne abbia bisogno urgente.

• I tuoi colleghi non vedono prospettive a lungo termine in azienda, quindi non hanno alcun interesse a seguire il processo.
• Il tuo capo si limita a sostenere a parole il processo e non ha interesse a far rispettare .
• I reparti dipendenti dal software non si preoccupano dei difetti, solo delle cose che possono mostrare ai clienti ieri, quindi non si preoccupano nemmeno del processo.

Questo è uno scenario estremamente comune nelle aziende che non capiscono che il loro prodotto più importante non è la merce o il prodotto che vendono, ma il software dietro di esso. Tali aziende non daranno mai la priorità al software "giusto" perché non vedono alcun valore in esso.

A meno che tu non sia in una posizione di potere in un'azienda del genere, non c'è niente che puoi fare per correggere questo percezione. In quanto tale, la tua unica opzione - se desideri mantenere la tua sanità mentale - è trovare un lavoro altrove, con un'azienda che comprende che il software di qualità è la base del loro successo, e in effetti l'esistenza, andando avanti.

Una cosa scadente da considerare, in risposta a questa citazione dalla domanda.

Il mio team ha una varietà di processi di sviluppo che il codice tecnicamente dovrebbe passare per arrivare al ramo principale. Cose come test unitari e revisione del codice.

No, non lo fai. Il processo che si verifica è il processo che hai e il processo che il team, l ' intero team (dai manager in giù), in realtà valuta.

Se c'è un documento da qualche parte o un insieme nebuloso di ideali nelle teste di alcuni sviluppatori, va bene, ma non è il tuo processo. Una cosa che puoi fare è prendere confidenza con il tuo processo attuale, rendersi conto che non è l'ideale e conviverci (e comunicare le conseguenze) o convincere il team di sviluppo a implementare cambiamenti strutturali che rafforzino in modo più tangibile i processi come: l'unione non può avvenire fisicamente al di fuori di una richiesta pull approvata, pipeline di build automatizzate, ecc ...

Buona fortuna - questa è una situazione schifosa in cui trovarsi come sviluppatore

Non sono un esperto in questo, ma il mio 2 ¢ sarebbe questo:

Ogni volta che i test / processi vengono respinti, fai una stima del numero di bug che questo equivale a, più , il danno che equivale in termini di perdita di denaro per l'azienda, più le ore di lavoro che saranno richieste se questa diventa una soluzione legacy (che è tipicamente molto più grande del tempo impiegato per seguire lo sviluppo guidato dai test in il primo posto). Sfortunatamente, questo ovviamente richiede un po 'di compiti da parte tua, che probabilmente va oltre la descrizione del tuo lavoro, ma allo stesso tempo, i calcoli approssimativi vanno bene, e probabilmente puoi avere qualche una sorta di idea per questo da precedenti segnalazioni di bug relative a test mancati, ecc.

Assicurati di attenersi a queste cifre e aggiornale ogni volta che i test vengono saltati. Quindi, alla fine di ogni incontro, in un tono come al solito (ma non passivo-aggressivo), annota con disinvoltura "il debito tecnico accumulato finora", come da quei numeri. All'inizio le persone ridaccheranno, poi forse si stancheranno di sentirlo, ma una volta che questo numero inizia a salire, potrebbe far sì che le persone se ne accorgano. Ad un certo punto, si spera, raggiungerà un punto critico e la discussione potrebbe andare così:

Capo: aggiornami sulla spinta di ieri alla produzione.

Tu: certo. Ieri abbiamo inviato 5000 righe di codice a git. A causa dell'urgenza, abbiamo saltato i test come da richiesta, stimati in circa 30 unit test per questo commit. Dall'esperienza precedente, abbiamo scoperto che 1 test unitario saltato su 3 si manifesta come una segnalazione di bug dell'utente 2-3 mesi dopo, con un costo stimato di circa $ 10.000 in vendite e 40 ore-persona di correzioni legacy per bug , quindi l'impegno di ieri costa circa $ 100.000 in perdite e 400 PH di debito tecnico. Data la nostra precedente stima del debito tecnico di 470 bug, meno 30 bug specificamente correlati ai test mancanti che abbiamo risolto nell'ultimo mese (abbiamo speso circa 1200PH per farlo), più il debito tecnico stimato di oggi di 10 bug, questo porta il nostro accumulato tecnico debito oggi fino a circa 450 bug, che, a una stima di $ 10.000 / 40PH per bug, questo porta a una perdita stimata di $ 4.500.000 per l'azienda più 18.000PH di debito tecnico fino ad ora .

Capo: ... Wtf. Ok, bene, pensiamo a questo. Spingere in anticipo senza test ha generato per noi $ X in più rispetto a se avessimo spinto in ritardo ... ma se quello che dici sui test è vero, ci è costato anche $ Y. Forse dovremmo riflettere sul fatto che il costo del debito tecnico $ Y compensi effettivamente il profitto di spedizione anticipata $ X in questo caso ... di quanto tempo in più hai bisogno per applicare quei test comunque?