Per gli sviluppatori non software: in qualità di sviluppatore di software, in genere scrivi codice che esiste solo sulla tua macchina e poi, quando pensi che vada bene, invii una "richiesta pull" e qualcuno lo esamina e per apportare modifiche o combinarlo nel prodotto della tua azienda. Finché la "richiesta pull" non viene gestita, è come se il lavoro non fosse mai stato svolto. Inoltre, altri sviluppatori non possono costruire su quel lavoro. E il controllo qualità è bloccato perché non hanno la possibilità di testare il tuo lavoro.

Le richieste pull devono essere gestite lo stesso o il giorno successivo, tranne in circostanze eccezionali. 50 richieste pull in attesa sono assolutamente ridicole. Se il tuo manager non ha tempo, deve occuparsene o occuparsi del lavoro con te e il tuo collega, oppure andarsene e l'azienda trova un sostituto per lui. Quello che succede in questo momento è semplicemente inaccettabile.

Ti suggerisco di non offrirti di aiutarlo, ma di offrire che queste recensioni siano il tuo lavoro e il lavoro del tuo collega. Se questo non viene accettato, sali di un livello e lamentati di lui.

Potrebbe essere utile fare un passo indietro rispetto al problema immediato e considerare la natura "meta" di questo. Le richieste pull sono solo un sintomo.

Quello che hai è un manager che vuole mantenere tutto il potere (anche piccolo come rivedere / approvazione delle modifiche al codice), non desidera delegare, ma non può o non vuole svolgere il lavoro da solo.

Ciò può accadere in qualsiasi aspetto del lavoro, sia si tratta di richieste pull, progettazione del software, discussione sulle funzionalità, decisione e approvazione dell'uso di componenti di terze parti ...

E può anche accadere in società non di software, in qualsiasi area di attività.

Quindi, l'essenza del problema è: il manager dovrebbe o fare il lavoro che non ha delegato, farlo in tempo e in modo appropriato - o autorizzare qualcun altro a farlo. Ecco fatto.

Il problema è più grande della disponibilità / volontà del tuo manager di esaminare e accettare / rifiutare la richiesta di pull - se una richiesta di pull può essere in coda da 6 mesi a 1 anno, ciò indica che il lavoro non è realmente rilevante / utile e le priorità sono sbagliate.

Nessun lavoro, abbastanza importante e abbastanza breve da essere contenuto in una pull request, avrà una scadenza di un anno o più. Qualcuno deve avere il lavoro adeguatamente pianificato e prioritario.

Detto questo, assicurati

• di affidare correttamente l'onere al revisore. Chiedi loro di informarli tramite e-mail su un PR che hai fatto e di ricontattarli con promemoria per almeno 2-3 volte.
• Cerchi di identificare una persona alternativa per esaminare la modifica.

Organizza una discussione aperta e onesta tra il tuo team e il tuo manager. Parla delle preoccupazioni aziendali: le funzionalità che sviluppi non vengono presentate ai clienti.

Questo è un costo reale: l'azienda sta pagando per queste funzionalità, ma i clienti le ricevono solo mesi dopo che sono state completate. Ciò costa all'azienda sia denaro che quote di mercato, poiché i loro (buoni) concorrenti non commetteranno lo stesso errore e si posizioneranno come leader nel mercato. Non è una buona situazione.

L'obiettivo della riunione dovrebbe essere quello di ottenere alcune azioni che i partecipanti possono intraprendere per mettere quelle caratteristiche davanti ai clienti il ​​prima possibile. Tutti dovrebbero dare suggerimenti per il miglioramento e nessuno dovrebbe incolpare una persona in particolare per la situazione attuale.

Il tuo capo potrebbe essere lento nel rivedere le richieste di pull, ma suona come il processo è ciò che deve essere cambiato. Non aiuterai il tuo capo a migliorare il processo se si sente come se fosse sotto attacco.

C'è l'approvazione di un PR e poi c'è la fusione di un PR. La regola generale è che nessuno sviluppatore può approvare il proprio PR.

L'unione è un'altra storia. Penso che gli sviluppatori dovrebbero essere in grado di unire i propri PR. So che in alcuni negozi solo manager o lead possono fondersi, ma per me questo è solo un collo di bottiglia. L'unione è sempre controllata dall'approvazione, quindi se i revisori prendono sul serio il loro ruolo, chiunque dovrebbe essere in grado di eseguire l'unione.

Sembra che tu sia in una situazione in cui solo il tuo capo può fondersi e il tuo capo non riesce a farlo molto spesso. Suggerisco di chiedere al tuo manager se lui o lei può configurare il repository in modo da poter unire i tuoi PR. Questo dovrebbe eliminare il problema. Da quello che descrivi, non riesco a immaginare che tu sia in un negozio con un vero sistema CI / CD in cui i cambiamenti entrano nella produzione, quindi questo non è chiedere troppo.

Supponendo che tu stia usando Git e abbia un ramo principale e diversi rami di funzionalità, crea semplicemente un altro ramo in cui mantieni le funzionalità unite, magari chiamalo integrazione. Ogni volta che il tuo capo riesce a unire alcune richieste pull nel master, unisci il master nei tuoi rami con tutte le funzionalità. In questo modo puoi essere certo che funzionino ancora insieme e che non ci siano conflitti.

Quanto sforzo è necessario unirli quando vengono approvati? Apprezzo che qualcosa di piccolo senza conflitti sarà minimo, ma quando hai conflitti di unione? Qual è il costo dell'opportunità? (cosa avresti potuto fare invece).

Qual è il costo probabile per l'azienda di trovare l'unica funzione di cui hanno bisogno improvvisamente in fretta e non può essere completata per settimane a causa del backlog?

Questo per dire che devi presentare questo problema come qualcosa che il manager possa capire: il costo in $$ e la perdita di flessibilità.

Concordo con @sourav Ghosh sul fatto che questo non è il tuo reale problema.

Per confronto, abbiamo uno SLA (informale) per i revisori per iniziare la revisione di 60 minuti. Ci vuole il tempo che ci vuole.

Per le persone non IT, una PR (pull request / peer review) è un elenco di tutte le modifiche apportate da uno sviluppatore (l'OP). Potrebbero essercene uno o due, come cambiare semplicemente il nome di qualcosa, o centinaia di cambiamenti in dozzine di posti. Abbiamo strumenti che evidenziano esplicitamente le modifiche, quindi come revisore sono davvero ovvie. Non è come giocare a individuare la differenza tra due edizioni di un libro.

Lo scopo di questo è controllare eventuali errori che lo sviluppatore ha mancato o chiedere come o perché qualcosa è stato fatto. È un controllo di integrità.

Di solito gli strumenti possono facilmente unire le modifiche con la versione principale, ma a volte non possono, ad esempio quando 2 sviluppatori hanno apportato modifiche diverse alla stessa cosa. Questo è chiamato "conflitto di unione" e deve essere risolto manualmente (costa tempo e denaro).

È ora di trovare un altro lavoro, e non per il motivo per cui potresti pensare.

L'ovvia ragione è che chiaramente il tuo lavoro non è apprezzato, il che è demotivante. E questo è certamente un legittimo motivo di preoccupazione.

Ma il rovescio della medaglia è, e mi dispiace dirlo, ma chiaramente il tuo lavoro non è prezioso .

Se lo fosse, il tuo capo sarebbe sotto un'enorme pressione per ottenere funzionalità / correzioni spinte fuori dalla porta e non avresti un arretrato di 50 PR.

Le persone sono intelligenti [citazione necessaria]. Se avere un arretrato di 50 PR stava causando problemi di carriera al tuo capo, il tuo capo esaminerebbe le richieste di pull in modo tempestivo. Dato che il tuo capo non lo fa, il software non deve essere particolarmente importante per l'azienda. E in modo transitorio, implicitamente nemmeno tu .

Ora certamente è possibile che il software sia importante, ma la tua azienda è un pantano così criminalmente mal gestito che nessuno capisce quel punto. Che è anche una grande bandiera rossa a sé stante, quindi nessun aiuto.

Consiglierei di trovare un lavoro in cui fai parte del sistema portando la proverbiale pancetta, perché i programmatori sono abbastanza ben pagati per singoli contributori [citazione necessaria] e non far parte (o almeno adiacente) alla macchina che genera entrate ti rende in qualche modo spendibile.

In ogni caso, buona fortuna.

Come ingegnere capo di un team abbastanza grande, almeno, andando verso i limiti di ciò che penso che una persona possa gestire, ho permesso a una parte del nostro team (3 ingegneri) di operare in modo più autonomo. Parte di ciò è che mi fido di loro per rivedere le proprie PR e non richiedono troppo coinvolgimento da parte mia. L'avvertenza è che spetta a me garantire che la direzione di quel team più piccolo sia valida, lo faccio controllando le PR dispari, non necessariamente commentando / rifiutando / approvando e più ampie revisioni "sul posto" della base di codice. >

Penso che tu abbia bisogno di fare una chat privata onesta con il tuo manager (una conversazione ideale per il tuo incontro 1 a 1 con lui / lei, se li hai) iniziando esaminando tutte le altre potenziali cause di questo comportamento. Sii modesto poiché questo spesso ha l'effetto di far emergere pensieri più onesti dalle persone nella mia esperienza, puoi spesso avere un'idea di ciò con cui hanno a che fare, ad esempio, la conversazione potrebbe essere qualcosa del tipo ...

Abbiamo questo grande arretrato di PR e la velocità con cui siamo in grado di unirli e rilasciarli sta danneggiando il business e la produttività dei nostri utenti (elabora quanto vuoi qui). Voglio capire perché non possiamo muoverci più velocemente su di loro e sono preoccupato che sia perché il mio codice [e qualche altro codice dello sviluppatore] non è abbastanza buono.

A questo punto il tuo manager potrebbe semplicemente confessare di essere sovraccarico.

Forse ci sono altre aree in cui il tuo manager potrebbe usare un po 'di aiuto ma per qualsiasi motivo non ha chiesto o delegato. Potrebbe valere la pena chiedere se c'è qualcosa che tu o il resto della squadra potete prendere dal suo piatto.

Forse fai un passo indietro e prenditi un po 'di tempo per migliorare la capacità di revisione dei PR esistenti, cerca di renderlo il più semplice possibile da rivedere. Il PR è troppo grande? Troppe parti in movimento? Potrebbe essere suddiviso? Posso aggiungere altre spiegazioni? Diagrammi? GIF che mostrano la funzionalità in fase di test? Questo potrebbe essere utile: https://medium.com/arnoldclarkdpd/better-github-pull-requests-87b2ef4f06c8

Questo manager forse sente un senso di obbligo nei confronti dell'azienda che devono controllare tutto prima che esca dalla porta. Se è così, varrebbe la pena affermare che come squadra, per crescere e apprendere (il business case lo consente) devi essere autorizzato a commettere errori. Per quanto ti sforzerai di mantenerlo al minimo, le persone del team dovrebbero essere autorizzate a farsi avanti, assumersi la responsabilità e imparare dai propri errori.