Il controllo della versione di lettura del gestore si impegna

18

Il nostro manager sta monitorando il Git impegnato su tutti i nostri progetti; di solito questo non è un problema, e adoro il fatto che il controllo della versione fornisca un registro di tutto il lavoro che sta accadendo, specialmente per il controllo e l'analisi successivi (nel caso qualcosa vada storto).

Tuttavia, il gestore ha fatto alcuni commenti chiedendo a cosa stanno lavorando le persone quando vede un commit che legge "correzioni di stile" o qualsiasi messaggio di commit che non fa riferimento a un numero di ticket nel nostro sistema di gestione delle attività.

C'è una soluzione sociale o tecnica a questo?

Ulteriori informazioni: questo è un progetto di manutenzione, quindi ci sono un sacco di "dovevano fare A poi B poi C e poi D e poi finalmente implementare X" attività in corso.

Ulteriori informazioni: il particolare messaggio di commit che ha generato un flag con il manager era vicino a "incluso un modo migliore per X, Y e Z", che è più un messaggio di refactoring piuttosto che una semplice correzione stilistica.

    
posta Peter Mortensen 31.03.2015 - 17:07
fonte

3 risposte

42

Is there a social or technical solution to this?

Suppongo, ma questo non è un problema .

Il tuo manager dovrebbe sapere cosa stai facendo. Dovrebbero assicurarsi che non stai facendo un sacco di lavoro che non fornisce alcun valore, o perché il lavoro senza biglietto è stato prioritario. Non c'è niente di male in questo. In un mondo ideale, fornirà un vantaggio, perché il tuo manager può impostare le aspettative con il business in modo da poter svolgere tutto il lavoro senza pressioni o interruzioni.

Diventa un problema solo se il tuo manager pensa che dovrebbe essere fatto solo il lavoro del ticket e impedisce che i lavori di pulizia tecnica siano biglietti. C'è sempre un debito tecnico da ripulire. Sempre cose da modificare perché dovresti, anche se non forniscono alcun chiaro vantaggio aziendale immediato.

    
risposta data 31.03.2015 - 17:17
fonte
14

Se la correzione stilistica fa parte del ticket su cui stai lavorando ed è correlata, non c'è niente di sbagliato nel controllarlo separatamente con lo stesso numero di ticket su cui stavi lavorando per una migliore identificazione.

Se stai solo scoprendo le modifiche che devono essere apportate e non sono correlate al ticket su cui stai lavorando, ti suggerisco di creare ticket correlati al debito tecnologico e metterli sul tuo backlog per un successivo rehashing.

Durante la pianificazione puoi quindi passare attraverso i ticket relativi al debito tecnologico e allegarli a ticket di manutenzione effettivi su cui stai pianificando di lavorare in questo modo rendendolo più facilmente riconoscibile.

Questo ti aiuterà a eliminare quelle correzioni "dal nulla" e a tenere tutto incapsulato sotto la categoria di problemi / biglietti specifici su cui stai lavorando.

    
risposta data 31.03.2015 - 17:18
fonte
1

Anche questo mi infastidisce (nessun gioco di parole previsto:).

I check-in più utili contengono commenti unici e specifici non solo per ciò che è cambiato, ma perché. A volte finisco per inserire commenti al paragrafo.

Di tanto in tanto mi capita in situazioni in cui un requisito dell'interfaccia utente rimbalza avanti e indietro una volta avviato lo sviluppo, richiedendomi essenzialmente di rimbalzare il codice (sì, il mondo reale a volte fa schifo). In questi casi, ritengo sia ancora più importante che i miei commenti forniscano chiarezza sul motivo del rimbalzo e, soprattutto, sul perché il codice finisca dove lo fa. Quindi, quando la direzione ritorna dopo aver parlato con i clienti e vuole sapere il perché, posso mostrarli senza dover ricordare l'intera esperienza, svolta dopo svolta.

    
risposta data 06.04.2015 - 22:14
fonte

Leggi altre domande sui tag