In SCRUM, un compito lungo e noioso ha grandi dimensioni

5

Vari articoli sulla metodologia SCRUM affermano esplicitamente che il dimensionamento non deve focalizzarsi sul tempo, ma piuttosto sulla "complessità" o "fatica necessaria" più astratta del compito.

Come deve essere dimensionata un'attività se l'attività è banale da eseguire, ma richiede molto tempo per essere completata (ad esempio, metà dello sprint o dell'intero sprint)? Dovrebbe essere ridimensionato 1, 2, 3 o più come 20-40-Inf?

Come esempio di tale attività, posso dare il seguente:

Convert the translated texts from the technical PDF documentation (10 000+ texts) in the correct translations format for Android and iOS.

    
posta Shade 29.01.2015 - 13:37
fonte

3 risposte

7

Prendi qualsiasi compito manuale banale e ripetilo 10.000 volte.

Ciò richiederà uno sforzo, forse molto impegnativo.

La nostra professione si basa sull'automazione, quindi l'ovvio primo approccio dovrebbe essere "posso automatizzare questo?". Se puoi, probabilmente dovresti.

Tuttavia, a volte non puoi automatizzare quanto vuoi: forse non c'è un budget per questo, forse definire le regole per l'automazione è troppo difficile, ecc.

Potrebbe essere più veloce eseguire l'attività manualmente piuttosto che automatizzarla .

Non vedo alcun problema nel dimensionare l'attività in modo che rifletta il lavoro svolto, anche se è un lavoro totalmente irragionevole.

    
risposta data 29.01.2015 - 16:46
fonte
3

explicitly state that sizing should not focus on time,

Hanno esplicitamente dichiarato qualcosa di ambiguo, "non dovrebbero focalizzarsi". Come molti principi agili, ciò non significa mai. Il punto di evitare di concentrarsi sul tempo è perché è difficile. Pensare in tempo può richiedere troppa precisione. Se lo sprint coinvolge molte attività complesse, in genere, dovresti ridurne alcune.

In questo caso, sembra che tu abbia una buona idea di quanto tempo ci vorrà. Questo è comune con compiti semplici. Quante tavole puoi tagliare in un'ora se occorrono 2 minuti per tagliare ciascuna scheda? Puoi convertire il tuo compito in una percentuale del tempo del tuo sprint. Tutto il resto ottiene il resto della percentuale.

    
risposta data 29.01.2015 - 19:06
fonte
1

Di fronte a compiti simili in passato, ciò che ho fatto è stato creare un nuovo compito (i) per affrontare il problema in un modo nuovo. Uno che si adatta meglio alla metodologia e agli intervalli di tempo.

In una situazione simile al tuo esempio, ho un compito che arriva alla fine di ogni ciclo di rilascio per la traduzione di nuove stringhe in 6 lingue diverse. A volte le stringhe sono numerate a migliaia. Ho creato un sistema per estrarre queste stringhe e formattarle in modo appropriato rendendo più semplice la traduzione, quindi ho avuto compiti più piccoli per la creazione di questo strumento. Quindi abbiamo due compiti molto piccoli per garantire che le stringhe vengano esportate (inviate per la traduzione da un servizio) e reimportate usando questo strumento prima del rilascio.

Per molti compiti banali così lunghi vorrei considerare il problema in modo diverso e vedere se può essere automatizzato in parte o intero in modo che sia meno dispendioso in termini di tempo in futuro. Ho spesso riscontrato che molte volte si tratta solo di riflettere sul problema in una luce diversa, riformulare il problema e risolverlo.

    
risposta data 29.01.2015 - 13:57
fonte

Leggi altre domande sui tag