Gestire stime come programmatore junior

• Molti sviluppatori con poca esperienza di gestione stimano le attività utilizzando la propria velocità o velocità di uno sviluppatore "migliore" in una squadra.

• La velocità varia a seconda dell'esperienza. Lo sviluppatore senior può impiegare 3 ore per risolvere qualcosa, quando ci vorranno 2 giorni lavorativi per risolvere lo stesso problema.

• Lo stress può essere raramente evitato quando si intraprende un nuovo lavoro. Dopo pochi mesi normalmente migliora, supponendo che tu abbia fatto abbastanza lavoro e facciano molte domande pertinenti.

• I tuoi senior potrebbero non sapere come ti senti sulle stime, quindi è importante che tu chieda loro cosa si aspettano da te.

Dalla mia esperienza:

• Penso che uno sviluppatore senior o un manager dovrebbe essere in grado di stimare una storia di un utente (requisito aziendale) in termini di t-shirt taglie (XL, L, M, S, XS).

• È compito degli sviluppatori rompere la user story in compiti più piccoli e stimarli. Un compito di grandi dimensioni potrebbe richiedere uno sviluppatore senior al giorno, in cui potrebbe essere necessaria un'intera settimana.

• È molto importante registrare la durata effettiva del completamento dell'attività.

• Un buon project manager o uno sviluppatore senior raccoglierebbe costantemente queste statistiche. Quando la produttività migliora, ne saranno consapevoli e invieranno più lavoro a modo tuo.

Questo non solo renderà la tua vita meno stressante, ma consentirà anche al dipartimento di gestire le proprie risorse in modo efficace.

Fai questo con il tuo capo squadra, il project manager e / o chi fa la tua stima; non noi. Le persone capiscono che le cose non richiedono lo stesso sforzo per tutti e possono lavorare per aggiustare le stime quando l'attività viene assegnata o almeno per alleviare i timori che si hanno sul periodo di revisione.

Questa è, a mio avviso, il motivo per cui le stime dovrebbero essere fatte dalle persone a cui è stato assegnato il compito (con input / collaborazione dal lead / peer). Ottieni stime più accurate per quanto tempo il lavoro richiederà effettivamente alle persone.

Non riesco a immaginare una posizione peggiore in cui mettere uno sviluppatore junior piuttosto che impostare un'aspettativa che non possono mantenere, a meno che, naturalmente, non lo stiano facendo per metterti alla prova. Hai avuto qualche reale ripercussione nel non soddisfare le stime?

Direi innanzitutto, è importante che tu abbia imparato a valutare da solo. Quando ti viene assegnato un compito, stimalo immediatamente in base a ciò che pensi che sarebbe necessario, quindi inizia a trovare il delta tra i due. Posso quasi scommettere che la qualità viene sacrificata nella breve stima iniziale. Se è semplicemente che si aspettano che tu progetta e sviluppi gli articoli più velocemente di te, potrebbe essere necessario avere una chat con qualcuno per risolvere il problema.

In secondo luogo, comprendi che la qualità è una caratteristica che gli stakeholder, il tuo capo, devono decidere di pagare. Potrebbe essere qualcosa che dovrai sacrificare facendo un po 'per soddisfare i requisiti nel tempo che hai.

In ogni caso, elimina lo stress, non è divertente continuare a sentirti come se fossi sempre dietro a scrivere codice cattivo. Spero che questo aiuti.

Questo è comune.

In generale, è meglio dare stime più grandi, che più piccole (la maggior parte delle volte andrai oltre la stima comunque). Ti consiglio di ridurre l'attività in attività secondarie il più possibile ridotte e di stimarle con ogni attività non più di 4 ore.

Se un'attività può richiedere più di 4 ore, scomporla in un altro insieme di attività secondarie. Aggiungete anche un buffer percentuale per le attività che non potete prevedere ora (la mia preferenza personale è 1 attività inaspettata per ogni 2 attività stimate con ciascuna attività inaspettata che richiede 2 - 4 ore a seconda del sistema con cui si sta lavorando).

Dopodiché aggiungi il tempo che vorresti per test, comunicazione, analisi ecc.

Primo: se si ottiene più veloce ad ogni tentativo di un problema, probabilmente non si tratta di un programmatore cattivo. Quindi prendiamo quel pensiero di mezzo.

Suggerirei che questo è il fallimento dei tuoi manager, ma è e sarà sempre il tuo lavoro gestire le aspettative.

Piuttosto che picchiarti per non essere in grado di rispettare le scadenze irrealistiche, misura quanti giorni di lavoro puoi effettivamente fare in una settimana. Quindi spiega al tuo team che sei nuovo nello sviluppo del business e del software e che ci si può aspettare che i n senior project degli sviluppatori diventino una settimana standard. Dovrebbero almeno capirlo, anche se a loro non piace.

Di 'loro che ti aspetti di continuare a migliorare e mostra loro come puoi misurare quel miglioramento. E sei d'accordo con loro sul fatto che non ti aspetti uno stipendio da senior fino a quando non potrai fare 5 giorni di lavoro per sviluppatori senior in una settimana. Ma allo stesso modo non ti aspetti le stesse responsabilità di un anziano quando non sei pagato quasi altrettanto.

Per continuare, è per questo che sono un strong sostenitore dell'uso dei punti della storia invece delle ore per la stima. vale a dire. Ogni lavoro ottiene un numero di punti e il team stima quanti punti possono raggiungere in un determinato periodo di tempo. Il periodo successivo, la stima è la stessa dell'effettivo del periodo precedente, aggiustata per fattori noti come un mese festivo o uno sviluppatore in partenza.

In qualità di manager, quando arriva un nuovo sviluppatore (junior o senior), chiarisco all'azienda che non aumenteremo la stima in prima istanza. Ci si aspetta che lo sviluppatore impieghi tutto il tempo che gli altri sviluppatori risparmiano. Il nuovo sviluppatore probabilmente andrà meglio di così, ma la promessa e l'eccesso di consegna è il mantra.

Lo sviluppatore migliorerà nel tempo, un anziano più veloce di uno junior, e la "velocità" della squadra - la stima mensile sul mese - migliorerà insieme a quella.

Mantieni la calma e vai avanti. Se il problema del tuo mancato rispetto delle stime è mai accennato, dì semplicemente le stesse cose che hai scritto nel tuo post, o se ti senti insicuro, parlane con il tuo mentore / responsabile del team da solo.

Le stime sono solo questo, stime. Possono e si spengono di più, così quando stai imparando le corde. E come junior, è probabile che tu stia imparando le corde come membro di un team su quel particolare progetto, come programmatore che usa qualunque tecnologia tu stia utilizzando e come dipendente nella tua azienda. E se lavori con persone ragionevoli, sono in attesa di essere fuori dalle stime.

Probabilmente stai osservando le attività che stai ricevendo "dal basso verso l'alto". I tuoi compiti sono più importanti per te della grande immagine del progetto su cui stai lavorando - è comprensibile. Vedete le stime come restrizioni imposte a voi e ovviamente state diventando ansiosi quando non le incontrate.

Ma quando guardi il quadro generale, vedrai che le stime, anche più di "target" per gli sviluppatori, sono "segnali" per lead / project manager. Rompere il lavoro in compiti e stimarli è un modo per ridurre la complessità della gestione e della stima dell'intero progetto. Tenere traccia del lavoro effettivo svolto rispetto alle stime è un modo per tenere traccia di come sta andando il progetto, ma è solo una delle metriche che possono essere applicate. Quando le stime non vengono soddisfatte su base regolare, è un segnale per il manager che c'è qualcosa di sbagliato nel progetto. Ma in qualsiasi progetto ragionevole, non sarà il fatto che ci sia uno sviluppatore junior nel team che non soddisfa le stime.

Permettetemi di presentarvi i miei due amici, WAG e SWAG

Vale a dire, "Wild Assed Guess" e "Scientific Wild Assed Guess"

Che ci crediate o no, non li ho inventati. In realtà sono piuttosto comuni negli affari. Dai un'occhiata a questo articolo per vedere cosa intendo.

Idealmente, è meglio fare una stima attendibile, ma se non è possibile, è meglio affermare che la stima è approssimativa a causa di dati incompleti di quanto non lo sia.

La chiave è che il business non è programmazione per computer. Gestire le aspettative è più importante della precisione. È importante valutare il tempo che pensi ci vorrebbe più del 10% come contingenza per compensare eventuali problemi imprevedibili.

Se sopravvaluti, saranno felici quando finirai col tempo di risparmiare. Se sottovaluti, non saranno delusi se rispetterai la scadenza o saranno estremamente delusi se qualcosa va storto.

Il business è un'area grigia che alcune persone acquisiscono nel tempo una sensazione intuitiva. Il fatto che stiano chiedendo a uno sviluppatore junior di prendere questo tipo di decisioni indipendentemente dice una cosa. O non hanno nessuno disponibile che sia più capace di prendere quel tipo di decisioni o i manager non vogliono assumersi la responsabilità dei fallimenti.

Metterei i miei soldi su quest'ultimo se lavorassi per una grande organizzazione. Quando un modello di business gerarchico diventa abbastanza grande, la cima è talmente lontana dal fondo che i superiori possono misurare il progresso solo su ciò che ricevono sulla carta. È un ambiente terribile perché le promozioni vengono generalmente fornite per non commettere errori. Ma le persone che ottengono le promozioni evitano il fallimento spingendo le proprie responsabilità sugli altri (ad esempio, l'incompetenza cieca) e prendendo il merito dei successi delle persone più in basso sulla catena.

Sfortunatamente, i programmatori sono obiettivi facili da lanciare "sotto l'autobus" perché, indipendentemente da quanto sia grande il problema, cercheremo di trovare una soluzione. La chiave è, non passare più tempo a determinare come stimare il problema rispetto all'implementazione della soluzione.

Questo è un posto difficile. Sembra che tu sia bloccato nella fase "Devi solo consegnare" di quella pipeline.

Nel corso degli anni ho notato quanto segue sulla stima: La qualità di un preventivo può essere determinata rispondendo (con un nome proprio) alle seguenti tre domande.

• Chi ha realizzato il design?
• Chi ha effettuato la stima?
• Chi sta facendo l'implementazione?

La qualità della stima è inversamente proporzionale al numero di individui distinti nominati. Ad esempio: la stima migliore è quando la stessa persona ha svolto tutti e tre i compiti sopra elencati, una stima debole è quando una persona ha progettato / stimato e un'altra eseguirà l'implementazione, e la peggiore stima è quella in cui tutte e tre le domande hanno una risposta con un nome univoco.