Come gestire (o rappresentare) il tempo perso nell'attesa di altre cose in un ambiente Agile?

6

Usiamo Scrum. Abbiamo uno sprint di un mese. All'inizio dello sprint stimiamo le attività dal backlog e quindi, a seconda della capacità che abbiamo, aggiungiamo compiti allo sprint corrente.

Tuttavia, la natura del nostro lavoro è tale che (sviluppiamo soluzioni di connettività per il mercato azionario) spesso dobbiamo aspettare per lunghi periodi di tempo (a volte mezza giornata e quasi 2-3 giorni in casi estremi). Ciò accade perché la borsa potrebbe aver rovinato qualcosa dalla loro parte, potrebbe non aver comunicato qualcosa a causa della quale qualcosa si è rotto dalla nostra parte e stiamo cercando di chiarirlo con lo scambio, lo scambio potrebbe essere in ritardo con la consegna di alcune funzionalità che finisce creare ritardi dalla nostra parte.

Il problema è che, diciamo che c'era un'attività X per la quale ho stimato Y ore. Ora ho iniziato a lavorare su X, ma dopo un po 'di tempo, mi viene richiesto di parlare con lo scambio di persone e sono in ritardo alla risposta. Ora il tempo impiegato per completare X non è Y, è Y + Y '.

In che modo (o dove) conto Y? Tecnicamente, mi ci sono voluti ancora un sacco di tempo per completare l'operazione. Il tempo in cui Y 'è stato sostanzialmente speso inattivo. (Generalmente uso Y 'per fare diverse cose come scrivere degli script che migliorano la produttività .. alcune prove per vedere se posso migliorare la latenza del prodotto, ecc.). Il mio manager lo sa e lui è più che felice della situazione. Tuttavia, dal punto di vista Scrum / Agile, ho dei problemi. Come posso risolvere questa situazione?

    
posta Chani 03.03.2016 - 07:53
fonte

3 risposte

10

Anche dal punto di vista Agile / Scrum, non stai affrontando problemi reali.

Innanzitutto, nel mondo Agile è ampiamente accettato che le stime in ore debbano essere prese con un granello di sale e stime relative in punti con un chicco solo marginalmente più piccolo. Le stime sono per definizione imprecise.

Ciò che è più apprezzato in un mondo agile è la trasparenza. Nella tua situazione, questo può essere dato in diversi modi, a seconda delle circostanze. Ad esempio, se avevi un ritardo notevole (più della metà della durata media dell'attività), puoi menzionarlo nella situazione quotidiana e se hai trovato qualche altro lavoro utile da fare mentre aspetti, menzionalo pure.
Inoltre, se stai aspettando una festa esterna per più di mezza giornata, dovresti renderla visibile sulla bacheca delle attività.

Se i ritardi dovuti alla comunicazione / interazione con parti esterne sono frequenti, dovresti tenerne conto al momento di pianificare le tue storie / attività riservando il tempo per i ritardi medi previsti. Se la dimensione di questo "buffer di ritardo" corrisponde approssimativamente al tempo di ritardo totale che la tua squadra incontra in uno sprint, la prevedibilità della quantità di lavoro che puoi gestire aumenterà.

    
risposta data 03.03.2016 - 09:19
fonte
2

Il modo in cui ho visto questo fatto con successo è quello di separare l'effettivo pezzo di integrazione in una storia separata:

1) storia 1: l'app funziona, invia i dati all'interfaccia, i test di test automatici che l'app sta inviando i dati correttamente. (e verifica le risposte / i dati restituiti per assicurarsi che l'app funzioni correttamente con la risposta / i dati restituiti).

2) storia 2: con la storia 1 completa, questa è una storia di test di integrazione per assicurarsi che l'interfaccia funzioni correttamente. Cosa si potrebbe chiedere correttamente? Bene, ci deve essere un contratto di qualche interfaccia (probabilmente una definizione di oggetto json o qualcosa con una descrizione di come funziona), se non c'è, allora questo è il vero problema. Metti tutto il tuo lavoro che ha dipendenze esterne in una storia separata. Valuta ciò che pensi che servirà per testare e inizierai a valutare quanto bene il tuo team sta gestendo le dipendenze esterne. A proposito, ho lavorato anche per le borse e questo funzionerà con loro.

Potresti dire che è cascata, ma in realtà è un buon processo agile: hai separato le cose dalle quali non hai alcun controllo. Dopo aver fatto ciò, hai dimostrato che la tua app funziona in modo completo con l'integrazione basata su come comprendi l'interfaccia: hai soddisfatto gli obiettivi dei proprietari dei tuoi prodotti. Se scopri che non funziona una volta che hai integrato la tua storia non ha avuto informazioni corrette e le conseguenze delle modifiche devono essere elaborate dal punto di vista dell'utente. Ciò potrebbe comportare l'aggiunta di nuove funzionalità nella tua app (o meno). Se questo si verifica più e più volte con lo stesso team esterno, allora ci deve essere un po 'di lavoro sul processo per scoprire i "veri" requisiti di integrazione con quel team.

Inoltre, in questo settore, vedo il team di integrazione esterna come un "utente" (persona) che devi capire molto bene per un'integrazione riuscita e continua. Potrebbe non essere il proprietario di un prodotto che scopre come farlo, ma uno sviluppatore, a prescindere, è lì che vorrei dedicare tempo e concentrazione.

    
risposta data 10.03.2016 - 12:27
fonte
1

Mi sono quasi messo a ridere quando un project manager mi ha detto di riempire le mie ore per colpire "40 ore per la settimana".

Supponiamo che l'attività Y sia stata stimata in 8 ore e che tu trascorri 6 ore nell'arco di due giorni. Cosa dovresti segnalare?

Se si segnala 8, la prossima volta che è necessario stimare un'attività simile, non conosceranno l'ora effettiva. È ancora peggio se si segnala 16 ore. Fatelo troppo spesso e sembrerà che state "ingannando" la compagnia.

Quindi è necessario segnalare in tempo reale l'attività effettiva. Il tuo PM deve essere consapevole di questo tempo "non fatturabile", specialmente se è a causa di un elemento bloccante (la comunicazione). Forse il ritardo è inaccettabile e ha bisogno di spingere. In alcuni casi il turnaround per le risposte è impostato contrattualmente. La tua azienda non è in grado di offrire un prezzo equo per il loro servizio se metà della società non è in grado di svolgere attività fatturabili.

Supponendo che tu abbia uno stipendio, allora dovresti offrirti di completare qualche altra attività che aiuti l'azienda.

Se ciò accade raramente, forse c'è qualche rapporto mensile manuale che potresti automatizzare per te o qualcun altro.

Se succede 'di tanto in tanto', studia su qualche nuovo quadro - offri di insegnare al resto del team la prossima settimana quando saranno tutti seduti.

Se questo accade molto, potresti offrire di studiare per un certificato di qualche tipo. Ciò aiuterà l'azienda e ti aiuterà.

    
risposta data 09.03.2016 - 23:49
fonte

Leggi altre domande sui tag