Trattare le stime come programmatore junior

Lavoro da un paio di mesi in un'azienda che stima (per la popolazione generale, non specificamente i giovani) e poi ci viene assegnato il compito, risolverlo, passa attraverso due test e alla fine la stima dovrebbe essere in qualche modo incontrato.

Sono oltre stressato perché alcune delle stime sono semplicemente impossibili da soddisfare per me. Ancora non conosco l'intero sistema (perché è abbastanza sostanziale), quindi a volte metà del tempo viene speso per scoprire cosa devo fare e dove e quando finisco a volte il preventivo è finito e ci sono ancora test da effettuare fatto (e correggendo gli errori se fossero presenti).

La seconda volta che ho a che fare con una funzionalità simile funziona tutto molto più velocemente, ma finora mi sento come se fossi solo un cattivo programmatore.

C'è qualcosa che hai fatto all'inizio e che ti ha aiutato a superare questo livello? Mi sento così stressato quando vedo quanto poco tempo c'è da programmare che a volte non riesco nemmeno a concentrarmi adeguatamente su ciò che sto facendo, il che peggiora ulteriormente.

• Molti sviluppatori con poca esperienza di gestione stimano le attività utilizzando la propria velocità o velocità di uno "miglior" sviluppatore in un team.

• La velocità varia con l'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 evitato raramente quando si intraprende un nuovo lavoro. Di solito, dopo pochi mesi, le cose vanno meglio, supponendo che tu faccia abbastanza lavoro e faccia molte domande pertinenti.

• I tuoi anziani potrebbero non essere consapevoli di come ti senti riguardo alle stime, quindi è importante chiedere loro cosa si aspettano da te.

Dalla mia esperienza:

• Penso che uno sviluppatore senior o un manager dovrebbero essere in grado di stimare una user story (requisiti aziendali) in termini di t-shirt (XL, L, M, S, XS).

• È compito degli sviluppatori suddividere la storia dell'utente in attività più piccole e stimarle. Una grande operazione potrebbe richiedere uno sviluppatore senior un giorno per risolvere, quando potrebbe richiedere un'intera settimana.

• È molto importante registrare il tempo effettivamente impiegato per completare l'attività.

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

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

Presentalo al capo del tuo team, al project manager e / o a chiunque esegua la tua stima; non noi. Le persone comprendono che le cose non richiedono lo stesso sforzo per tutti e possono lavorare per adattare le stime quando viene assegnato il compito o per lo meno dissipare le paure che hai riguardo al periodo di revisione.

Questo è, a mio avviso, il motivo per cui le persone dovrebbero assegnare le stime (con input / collaborazione da parte del lead / colleghi). Ottieni stime più precise su quanto tempo impiegherà effettivamente la gente a fare il lavoro.

Non riesco a immaginare una posizione peggiore in cui inserire uno sviluppatore junior rispetto a stabilire un'aspettativa che non possono mantenere, a meno che ovviamente non lo facciano per sfidarti. Hai avuto ripercussioni reali nel non rispettare le stime?

Direi per primo, è importante che hai imparato a stimare da solo. Quando ti viene assegnato un compito, stimalo immediatamente in base a ciò che pensi che richiederebbe, quindi inizia a trovare il delta tra i due. Posso quasi scommettere che la qualità viene sacrificata nella breve stima iniziale. Se semplicemente si aspettano che tu progetti e sviluppi gli elementi più velocemente che puoi, potresti dover chattare con qualcuno per risolvere il problema.

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

Ad ogni modo, elimina lo stress, non è divertente continuare a sentirti come se fossi sempre dietro la scrittura di un codice errato. Spero che sia di aiuto.

Questo è comune

In generale, è meglio fornire stime più grandi, piuttosto che più piccole (il più delle volte andrai comunque oltre la stima). Ti consiglierei di tagliare l'attività in attività secondarie più piccole possibili e di stimarle con ogni attività non più di 4 ore.

Se un'attività può richiedere più di 4 ore, suddividerla in un'altra serie di attività secondarie. Aggiungi anche un buffer percentuale per le attività che non puoi prevedere ora (la mia preferenza personale è 1 attività imprevista per ogni 2 attività stimate con ogni attività imprevista che richiede 2 - 4 ore a seconda del sistema con cui stai lavorando).

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

Prima di tutto: se si ottiene più velocemente con ogni tentativo di un problema, probabilmente non si è un cattivo programmatore. Quindi tiriamo fuori quel pensiero.

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

Invece di picchiarti per non essere in grado di rispettare scadenze non realistiche, misura quanti giorni di lavoro puoi effettivamente fare in una settimana. Quindi spiega al capo del tuo team che sei nuovo nello sviluppo del business e del software e ci si può aspettare di far lavorare n giorni senior-developer in una settimana standard. Dovrebbero almeno capirlo, anche se non gli piace.

Dì loro che ti aspetti di continuare a migliorare e mostra loro come puoi misurarlo. E concorda con loro che non ti aspetti il ​​salario di un anziano fino a quando non puoi fare 5 giorni di lavoro con gli 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 andare oltre, questo è il motivo per cui sono un forte sostenitore dell'utilizzo dei punti della storia anziché 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 seguente, la stima è la stessa dell'effettiva del periodo precedente, rettificata per fattori noti come un mese di ferie pesante o una partenza di uno sviluppatore.

Come manager, quando arriva un nuovo sviluppatore (junior o senior), chiarisco al business che non aumenteremo la stima in prima istanza. Si prevede che lo sviluppatore impiegherà tanto tempo da altri sviluppatori a risparmiare. Il nuovo sviluppatore probabilmente farà meglio di così, ma il mantra è sotto promessa e sovra consegna.

Lo sviluppatore migliorerà nel tempo, un senior più veloce di un junior, e la "velocità" del team - il mese stimato al mese - migliorerà insieme ad esso.

Stai calmo e vai avanti. Se il problema del mancato rispetto delle stime è mai stato sollevato, basta dire loro le stesse cose che hai scritto nel tuo post o se ti senti insicuro, parlane con il tuo mentore / team leader da solo.

Le stime sono proprio questo, le stime. Possono e saranno spenti, tanto più quando imparerai le corde. E come junior, è probabile che tu stia imparando le corde come membro del team su quel particolare progetto, come programmatore usando qualunque tecnologia tu stia usando e come dipendente nella tua azienda. E se lavori con persone sensibili, si aspettano che tu sia fuori con le stime.

Probabilmente stai guardando i compiti che stai ricevendo "dal basso verso l'alto". I tuoi compiti sono più importanti per te del quadro generale del progetto a cui stai lavorando: è comprensibile. Vedi le stime come restrizioni poste su di te e ovviamente stanno diventando ansiose quando non le incontri.

Ma quando guardi il quadro generale, vedrai che le stime, anche più dei "target" per gli sviluppatori, sono "segnali" per i 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 mezzo 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.

Lascia che ti presenti i miei due amici, WAG e SWAG

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

Che ci crediate o no, non mi sono inventato. In realtà sono abbastanza comuni negli affari. Dai un'occhiata a questo articolo per capire cosa intendo.

Idealmente, è meglio elaborare una stima ferma, ma se non è possibile, è meglio affermare che la stima è approssimativa a causa di dati incompleti piuttosto che mentire.

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

Se sopravvaluti, saranno felici quando finirai con il tempo libero. Se sottovaluti, non saranno delusi se rispetti la scadenza o estremamente delusi se qualcosa va storto.

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

Metterei i miei soldi su quest'ultimo se lavori per una grande organizzazione. Quando un modello di business gerarchico diventa abbastanza grande, la parte superiore è così lontana dalla parte inferiore che i piani superiori possono misurare i progressi solo in base a ciò che ricevono sulla carta. È un ambiente terribile perché le promozioni vengono generalmente offerte per non commettere errori. Ma le persone che ricevono le promozioni evitano i fallimenti spingendo le loro responsabilità sugli altri (es. Incompetenza cieca) e prendendosi il merito per i successi delle persone più basse nella catena.

Sfortunatamente, i programmatori sono facili obiettivi da lanciare "sotto il bus" perché, indipendentemente dal problema, cercheremo di trovare una soluzione. La chiave è, non dedicare più tempo a determinare come stimare il problema che a implementare la soluzione.

È 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 una stima può essere determinata rispondendo (con un nome proprio) alle seguenti tre domande.

• Chi ha realizzato il design?
• Chi ha fatto il preventivo?
• 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 tutte e tre le attività di cui sopra, una stima debole è quando una persona ha progettato / stimato e un'altra eseguirà l'implementazione, e la stima peggiore è quella in cui si risponde a tutte e tre le domande un nome univoco.