Il modo migliore per gestire "Quindi, quando sarà fatto?"

Best way to handle “So, when will this be done by?”

"Alla fine dello sprint".

Mi rendo conto che è una risposta snella, ma c'è del vero nascosto lì dentro. Dipende da chi sta facendo la domanda e perché stanno facendo questa domanda.

Il project manager non ha davvero alcun problema a fare domande del genere - dovrebbero chiedere al master di scrum se hanno bisogno di informazioni dettagliate sulle attività in corso, e dovrebbero farlo al di fuori dello stand-up quotidiano.

Se è lo scrum master che sta chiedendo, forse lo stanno chiedendo in modo che possano essere preparati per i prossimi blocchi stradali. Se è così, sii onesto.

In mischia, la squadra non ha l'obbligo di finire alcun compito o storia particolare fino alla fine dello sprint, supponendo che stiano chiedendo una storia relativa allo sprint attuale (rispetto a una hot fix fuori banda). Le scadenze per le attività all'interno di una storia sono di proprietà del team e non dovrebbero sentirsi sotto pressione da un project manager.

Tuttavia , lo sviluppo del software è un processo collaborativo, quindi è ragionevole accogliere tali domande, entro limiti ragionevoli.

La soluzione? Dal tuo punto di vista: rispondi nel modo più onesto possibile, il più brevemente possibile se è durante lo stand-up. Se stai lavorando attivamente all'attività che ti viene posta, puoi sempre dire qualcosa del tipo "si stima che impiegheranno un paio d'ore, quindi potrei essere in grado di terminarlo oggi". Se non ci stai lavorando, un semplice "non lo so, non ho iniziato a lavorarci su. Penso che la stima sia ancora abbastanza accurata".

Dal loro punto di vista: devono accettare la tua risposta.

"So can you commit do having this task done by 4pm today?"

La risposta a questo dovrebbe essere quasi sempre "no". Semplicemente non c'è bisogno di impegnarsi per un deliverable di fine giornata per un'attività nel mezzo di uno sprint. Se il compito è terminato alle 16:00 di oggi o alle 9 di domani, è irrilevante finché la storia nel suo complesso è finita entro la fine dello sprint.

"How many hours do you have left on this subtask?"

Questa è una domanda ragionevole da porre. Rispondi semplicemente onestamente. Mi rendo conto che è molto difficile da fare. Ci sono stato. Penso che gli sviluppatori siano intrinsecamente ottimisti. Guarderemo un compito e penseremo "mi ci vorranno solo un paio d'ore" e prima che tu lo sappia è passato tutto il giorno. Ecco perché agile funziona - ammettiamo i nostri limiti nella stima, e facciamo del nostro meglio per rompere le cose nel più piccolo pezzo possibile.

Chiedi allo Scrum Master di chiarire, lo scopo di uno Sprint e Stand Up Meeting. Quasi tutti quelli che lavorano con Scrum direbbero che lo scopo di uno Sprint è decidere cosa fare durante la durata dello Sprint e non ho mai sentito nulla di ciò che è dovuto durante uno sprint.

Forse hai delle emergenze per cui non hai nulla a che fare con uno sprint. I team / sviluppatori che hanno questi compiti al di fuori dello sprint, devono assicurarsi che non includano il tempo necessario per farlo come parte della pianificazione dello sprint. Forse hai un giorno lavorativo di 8 ore, ma se trascorri 1-2 ore a spegnere gli incendi, non puoi aspettarti di includerlo come parte del preventivo.

Per quanto riguarda le riunioni standup, potresti suggerire qualche altro sistema per tenere traccia di quando certe attività immediate verranno eseguite come una sorta di sistema di ticket di supporto. Questi non dovrebbero nemmeno essere discussi durante lo stand up.

Sembra che il tuo scrum master abbia bisogno di essere riqualificato o ripensare perché stai facendo Scrum in primo luogo. Non è adatto a tutti i gruppi e le situazioni. Qualcuno in cima non ci ha comprato.

Ho sperimentato la micro-gestione come questa e il modo in cui l'ho gestita con successo è molto trasparente e comunicativa. Non ci vuole molto per ottenere la fiducia del manager; costruisci fiducia e loro fanno marcia indietro. A volte ti dà anche più spazio e più latitudine. Il tuo manager può sentirsi insicuro o fuori controllo, quindi questo va ad allentarlo per loro. Ovviamente non è l'ideale, ma sei una squadra e dovresti tutti desiderare lo stesso risultato. In bocca al lupo.

Più la gestione è "micro", più è difficile fare previsioni accurate. Se ho 20 compiti di otto ore, cioè compiti che sono ragionevolmente stimati in otto ore ciascuno, ciò dovrebbe essere fatto in quattro settimane, o forse qualche giorno in più o in meno. Se ho uno di questi compiti, c'è molta più variabilità.

Un tale compito può richiedere 10 minuti se il problema da risolvere risulta molto più facile di quanto pensassi. (È successo a me, ho stimato che avevo bisogno di scrivere un bel po 'di codice, e si è scoperto che qualcun altro aveva già scritto esattamente quello di cui avevo bisogno). O potrebbe volerci una settimana (il mio codice non funziona a causa di un bug in una libreria che deve essere risolto e quindi ha conseguenze del tutto negative). Per venti compiti, queste cose si bilanciano. Non per un compito.

Qualcuno ti sta chiedendo di prevedere il futuro. Non puoi farlo. E ha chiesto di prevedere un singolo evento, le statistiche non ti aiutano. Il tipo di persona che fa queste domande non capisce il significato di "stima" Quindi se ti viene chiesto "lo farai in quattro ore", le risposte possibili sono "molto probabile", "forse, forse no" e "molto" improbabile".

"Sarà fatto quando sarà completato."

Non c'è alcun valore nel tentativo di ottenere stime di completamento dagli sviluppatori. Le stime sono imprecise, specialmente se sono basate sul tempo. Inoltre, le persone in ruoli manageriali hanno la tendenza a interpretare tali stime come impegni, con il risultato degli effetti dannosi che si sentono gli sviluppatori.

Un'opzione sarebbe evitare di rispondere alla domanda in termini di impegni di tempo.

"Questa attività verrà eseguita dopo aver eseguito le operazioni A, B e C".

"Ok. E quanto ci vorrà?"

"Vedremo alla fine della giornata."

Cambiare la conversazione da impegni di tempo a ciò che deve essere fatto può aiutare a prendere il bordo e mostrare che "quanto tempo ci vorrà per essere fatto" è meno importante di "cosa serve per essere fatto."

Non farti intimidire dal maestro di mischia. Parla apertamente e francamente del lavoro che ti aspetta. Poni domande a lui / lui come quello che è l'urgenza. Perché deve essere fatto entro il 4? Se davvero deve essere fatto, altre attività potrebbero dover essere spinte fino a un momento successivo. È la tua opportunità di costruire truss. Le risposte di Frank sono migliori all'inizio piuttosto che scuse più tardi.

Questa è una buona domanda. Risponderò dal punto di vista di una persona con 30 anni di esperienza con un decennio come project manager dedicato in tutte le aree tranne lo sviluppo del software, ma di recente è incappato involontariamente nello sviluppo del software dell'area. Indipendentemente dalla metodologia utilizzata in tutto il vostro team e da ciò che viene chiamato, alla fine della giornata i progetti di sviluppo sono gli stessi di qualsiasi altro nel senso commerciale che gli obiettivi devono essere raggiunti entro vincoli concorrenziali di tempo, budget e qualità - - e mentre i progetti vengono eseguiti, l'azienda continua a muoversi e ad evolversi e ha buone probabilità di apportare modifiche al progetto. Pertanto, è necessario impostare e impegnarsi per obiettivi e tempi e per essere in grado di fornire aggiornamenti su base frequente e quando richiesto. Non consiglio che la risposta alle domande sia una qualche forma di "se fai questa domanda mostra la tua ignoranza e devi essere addestrato".

Detto questo, nella mia esperienza ciò che rende le stime del tempo nello sviluppo del software particolarmente impegnativo è che i progetti di sviluppo comportano molti territori inesplorati. La definizione tecnica di un "progetto", secondo il Project Management Body of Knowledge del Project Management Institute, è che un progetto deve essere unico. Tuttavia, la stragrande maggioranza dei "progetti" in ambito IT sono semplici ri-esecuzioni di progetti precedentemente elaborati e amp; progetta e realizza libri di esecuzione. Nello sviluppo del software, abbiamo framework e vari schemi di progettazione generica che rendono riutilizzabile lo sviluppo, ma il nucleo di ogni progetto è completamente unico.

Inoltre, la maggior parte dei progetti di sviluppo comporta l'integrazione con altri sistemi e quanto velocemente ciò possa essere fatto è una grande ipotesi. Sto lavorando a un progetto in questo momento in cui le mie stime temporali originali erano basate sul presupposto che i 4 sistemi con cui ho bisogno di interagire a livello di programmazione avrebbero le API e non risulta che lo facciano. Inoltre, uno dei sistemi è ospitato su cloud e la mia organizzazione ha politiche che vietano il lavoro svolto. Chi poteva averlo previsto?

Man mano che vengono scoperte scoperte che mettono a repentaglio i tempi, è importante comunicare bene perché è emerso il ritardo, perché non è stato possibile prevederlo, ecc.

Inoltre, mi è stato detto che il lasso di tempo indicato non avrebbe funzionato e reso più rapido il processo. Un'altra variazione viene data a un carico di modifiche alla barca da iniettare nello sviluppo senza che sia stato concesso il tempo aggiuntivo. C'è una legge in fisica che dice che la materia non può essere creata o distrutta, e questo mi viene in mente perché mi sembra che anche il tempo non possa essere creato dal nulla. Accelerare lo sviluppo avrà probabilmente un impatto negativo sulla qualità del rilascio, sulla supportabilità del prodotto e / o sulla futura evoluzione del prodotto.

Le richieste relative alla pianificazione dovrebbero essere risolte in termini commerciali generali. "Sì, siamo sulla buona strada per rispettare i tempi prestabiliti, e non ci sono problemi di produzione che mettano in pericolo". Le richieste di aggiungere uno spazio significativo senza più tempo, o semplicemente accelerare la consegna, dovrebbero essere una forma di "possiamo farlo, ma solo così tutti sono consapevoli che intrinsecamente comporta il rischio di bug perché gran parte del tempo di sviluppo è fatto per essere proattivo da non introdurre bug e anche da testare in modo completo. " Quando rispondono con "così basta testare più velocemente", questo ottiene una risposta che spiega che i test di sviluppo non comportano tempi morti e possono essere accelerati senza introdurre il rischio di difetti mancanti.

In sintesi, sto semplicemente suggerendo che tutti gli sviluppatori - non solo i lead, scrum master o project manager, siano preparati a discutere i loro compiti in un contesto di business e ad avere discussioni sulla modifica dei parametri del progetto rendendoli consapevoli dello scambio -offs che risulterebbe.

As work is performed or completed, the estimated remaining work is updated.

- Guida Scrum , pagina 15

Ogni sviluppatore dovrebbe aggiornare il proprio stato di attività e stimare le ore rimanenti ogni giorno in qualsiasi strumento di produttività utilizzato dal proprio team (ad es. TFS).

Quindi la semplice risposta al tuo manager è di indirizzarlo alla colonna "ore rimanenti" nell'elenco delle attività. Spero che imparerà che può accedere a questi numeri e smettere di fare domande stupide.

Facendo una qualsiasi delle domande di cui sopra. Quello che il mischia sta cercando di decidere è che siamo in linea con questo sprint e se ci sono problemi di blocco per essere in grado di competere con questa attività.

I punti storia non sono correlati con le ore uomo, non sono pensati per farlo, ma chiedendo se puoi fare qualcosa entro una data, ti sta davvero chiedendo cosa ti impedisce di competere con questa attività? Se hai bisogno di qualcosa chiedi, a mio avviso il suo ruolo è quello di assicurarti di essere in grado di competere nello sprint, questo è quello che sta davvero chiedendo ...