Il commit quotidiano e spingere necessario per manager e supervisori per controllare i miei progressi e la produttività?

Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

Bene, è buona prassi impegnare il codice almeno una volta al giorno, per assicurarti di non mantenere ore di lavoro prezioso ostaggio sulla tua workstation!

Ma, per "vera agilità?" No.

Per i manager "controllare i tuoi progressi?" Non proprio. Una migliore verifica dei progressi e dell'etica del lavoro è velocità nel tempo e dialoghi 1-a-1.

Detto questo, non conosciamo la tua squadra dinamica. E, uno dei principi base dello sviluppo "Agile" è "fai ciò che funziona per te". Il tuo team deve discutere queste politiche internamente (con il tuo manager) per determinare perché o se questa procedura è utile.

E dalla mia stessa esperienza sia come gestore di un che di gestore, di uno sviluppatore non sono necessariamente un prodotto di un manager prepotente. Possono anche essere un segno di un manager (o di un team) che è realmente interessato al tuo lavoro o al tuo benessere. O un manager che è interessato a non perdere giorni del tuo lavoro se lo ottieni con un autobus .. .

Dovrei anche notare, dalla mia esperienza alle due estremità, che quando qualcuno - me compreso - non fa spinte regolari, di solito si "fa check out". Cioè, in realtà non stanno funzionando. E, ancora più importante, hanno smesso di preoccuparsi.

Quindi, finché lavori effettivamente e fintanto che scrivere codice è una tua responsabilità quotidiana, non dovresti aver paura di spingere il codice ogni giorno. Se lo trovi difficile, potresti essere nel posto sbagliato! E questo è qualcosa che sia il tuo manager che tu dovrebbero voler vedere i primi segni di!

E intendo sul serio. Quando sono in modalità sviluppo su un progetto, se arrivo alla fine della giornata e non posso spingere il mio codice, non è mai perché il mio codice non viene compilato o sono imbarazzato. È perché non ho funzionato. ... Quindi, o mi avvicino a qualcuno in ufficio e mi impegno con loro ¹ , che è un grande motivatore, o inizio a cercare un altro lavoro. (O entrambi.)

^{1. Cioè, vado da uno stakeholder o il mio manager e dico "Ehi, vorrei che esaminassi il mio lavoro alla fine della giornata di domani". E per essere onesti, dopo alcuni giorni di questa routine, di solito smetto cercando un altro lavoro, perché sono di nuovo fidanzato. Mi interessa di nuovo, perché non sto più lavorando per una vaga entità aziendale. Sto servendo i miei colleghi.}

Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

No. Assolutamente no (vedi Quando eseguire il commit del codice e Il commit / verifica del codice ogni giorno è una buona pratica? ) . Questo è ciò che è per il tuo Scrum / Stand Up quotidiano. Dovrebbero anche guardare i grafici di burndown giornalieri. Guarda gli sprint passati per valutare la velocità della squadra. Se la gestione ha bisogno di più prove del tuo operato, allora devono:

1. Vieni o chiama il tuo Scrum giornaliero o alzati

2. In realtà vieni dove si trovano gli sviluppatori e vai in giro

3. Divieto di telelavoro (impopolare come sarebbe)

4. Tutti i precedenti

Penso che la domanda reale sia: perché i manager hanno bisogno di un flusso costante di modifiche al codice per credere che gli sviluppatori stiano facendo qualcosa?

Ma questa è una domanda a parte: How posso dimostrare la mia produttività alla gestione?

Potresti fare la stessa domanda di qualsiasi processo. È necessario:

• utilizza i ticket jira per tenere traccia delle funzioni
• partecipa allo stand up giornaliero
• stimare le attività in termini di punti della storia

No! non se lo stai facendo in un altro modo.

Non controllare il codice almeno una volta al giorno è inusuale.

Così facendo darai ai tuoi manager molti bei grafici e dimostrerai che hai fatto almeno un po 'di digitazione quel giorno.

Git non ti punisce per aver verificato il codice non funzionante. Puoi utilizzare le filiali locali, i tag, i rebase (urg) ecc per gestire le tue preferenze personali, ma non c'è motivo per non controllare il codice se rende felice il tuo capo

Se non è ancora chiaro per te, dovresti chiedere al tuo manager / mentore o ad altri membri del team qual è la modalità di funzionamento del tuo team (in senso del commit) e dovresti allinearti con esso.

Il consiglio di altre risposte può essere buono se la squadra funziona in quel modo o se la squadra no.

Ad esempio:

• se il team sta lavorando su una diramazione condivisa con molti / tutti gli altri team che lavorano sullo stesso prodotto (vero CI), potrebbe essere più importante integrare più velocemente i pezzi più piccoli per ridurre al minimo le possibilità di conflitti di unione che potrebbero forzare rivalutare e verificare nuovamente le modifiche, forse più volte. È preferibile utilizzare prima uno scheletro di funzione e seguire uno dei commit più addizionati di carne, purché non si rompano altre cose, anche se le tue cose non sono ancora funzionanti. Ovviamente, se tali commitzioni di funzionalità parziali sono accettate (e probabilmente si trovano in un ambiente così dinamico).

• se il team lavora in un ambiente in cui è previsto che ogni commit sia completamente rivisto, verificato e funzionale allora ovviamente dovrai seguire questa tendenza, i commit parziali non sarebbero un risposta. IMHO non molto agile, ma ancora abbastanza comune in molte organizzazioni.

E dovresti chiedere al tuo manager qual è il metodo per controllare e segnalare i progressi per la tua organizzazione . Questo potrebbe essere in realtà non correlato al numero / tasso di commit (IMHO sarebbe un errore). Ad esempio, tonnellate di banali guadagni cosmetici non sono necessariamente "più progressi" di un singolo commit di miglioramento delle prestazioni dell'infrastruttura (che potrebbe anche essere molto più piccolo).