Uncovering better ways of developing software
Esperienza con Scrum
Per la prima volta mi trovo in una posizione in cui il manager ha imposto a tutti una metodologia agile, in questo caso Scrum.
Quindi il nostro piccolo team (5 persone) e' passato da Lean a Scrum.
Al momento sono emersi un paio di problemi:
in sede di definizione dello spring backlog (1 mese) e' difficile fare stime precise (dobbiamo farle in ore assumendo 6 ore = 1 giorno) di task cosi' lontani da venire. Messa in un altro modo, dobbiamo splittare in task troppe storie per riempire un mese di lavoro.
agile artifacts: spesso un task e' messo in hold in attesa di qualche evento esterno (info, spec, review ecc.) e questo non e' facile capirlo dal burndown chart, mentre e' chiarissimo sulla kanban. Inoltre dobbiamo usare dei fogli excel per descrivere i task, ma continuo a trovare le index card molto piu' pratiche. Volendo potremmo usarli entrambi, ma dover ricopiare tutte le cose enne volte non e' particolarmente divertente.
sollevero' questi problemi alla prima retrospective, ma se qualcuno ha qualche dritta...
Quindi il nostro piccolo team (5 persone) e' passato da Lean a Scrum.
Al momento sono emersi un paio di problemi:
in sede di definizione dello spring backlog (1 mese) e' difficile fare stime precise (dobbiamo farle in ore assumendo 6 ore = 1 giorno) di task cosi' lontani da venire. Messa in un altro modo, dobbiamo splittare in task troppe storie per riempire un mese di lavoro.
agile artifacts: spesso un task e' messo in hold in attesa di qualche evento esterno (info, spec, review ecc.) e questo non e' facile capirlo dal burndown chart, mentre e' chiarissimo sulla kanban. Inoltre dobbiamo usare dei fogli excel per descrivere i task, ma continuo a trovare le index card molto piu' pratiche. Volendo potremmo usarli entrambi, ma dover ricopiare tutte le cose enne volte non e' particolarmente divertente.
sollevero' questi problemi alla prima retrospective, ma se qualcuno ha qualche dritta...
Visualizzazioni: 167
Risposte a questa discussione
-
Permalink Risposto da Ste su -
Ciao Uberto,
per ora ho qualche domanda:
1. se lo sprint di 4 settimane vi sembra troppo lungo, perche' non lo fate piu' corto?
2. perche' dici che con uno sprint cosi' lungo dovete splittare troppe storie in task? Come facevate quando facevate lean?
3. fate anche un release planning o solo iteration planning?
4. perche' ti senti forzato ad usare un file excel e non invece un semplice raccoglitore di card?
ste
-
Permalink Risposto da uberto su -
Cos'e' una nuova pratica? rispondere con sole domande? ;)
cmq. 1 e 4 le ha decise il top manager e sono state imposte a tutti i teams.
2 in lean facevamo il punto ogni settimana, aggiungendo le storie che servivano.
3 entrambe.
-
Permalink Risposto da Ste su
-
:)
Si, si chiama understand-first driven answering (detto anche upfront understanding) :)
Noi abbiamo iniziato con 4 settimane, ma poi ci siamo resi conto, per varie ragioni che erano meglio due. Se il management partecipa alle retrospections, non dovrebbe essere difficile fagli vedere i problemi dovuti a un'iterazione troppo lunga e quindi a prendere come action item di accorciarla. Se siete gia' abituati a iterazioni piu' corte non sara' sicuramente un problema.
Per le US invece, forse ancora non ho capito, ma non vedo un grosso problema. L'iterazione va pianificata, di solito il primo giorno, quindi potete tranquillamente considerare US piu' piccole che allocate nelle varie settimane. Ancora una volta, se siete gia' abituati, non sara' sicuramente un problema.
Per il backlog, abbiamo iniziato anche noi con uno spreadsheet. Ve lo sconosiglio caldamente, ma immagino che vi accorgerete presto che non e' gestibile. Noi usiamo un tool apposito. Ci costa un po', ma non vedo alternative valide.
Ste
-
Permalink Risposto da uberto su
-
;)
OK, piu' che altro volevo capire se era un mio problema o no. Il fatto che le 4 settimane e l'excel le insegnano ai corsi di Scrum Master, quindi volevo capire dove sto sbagliando.
Cmq dato che ci sono parecchi team (almeno 5 forse di piu') e' chiaro che occorre arrivare ad una soluzione comune.
In tutti i casi niente di tragico, solo che mi trovavo meglio prima.
Riguardo alle US, il problema e' che mentre le prime sono chiare, quelle dopo dipendono dalle prime sono meno chiare, e in 5 persone in un mese se ne fa di roba, quindi pianificare l'ultima settimana diventa un po' un azzardo.
-
Permalink Risposto da Ste su
-
Beh, pero' dipende da come le US sono definite. Le dipendenze e' sempre meglio limitarle il piu' possibile. In piu', scrum non ti dice come fare il planning. Puoi fare un iteration planning basato sul commitment del team, ma poi lavorate sulle storie come meglio credete. Per assurdo potresti fare un commitment iniziale e poi all'interno dell'iterazione andare avanti a lavorare esattamente come prima. Se poi 4 settimana e' un orizzonte troppo lontano per centrare i commitment, questo saltera' fuori e il correttivo naturale sara' di accorciare l'iterazione.
BTW, scrum non presuppone assolutamente iterazioni di 4 settimane, anzi, tutte le fonti con cui sono venuto a contatto suggeriscono due o meno.
Una domanda che invece interessa a me: come coordinate il lavoro dei 5 team?
Ste
-
Permalink Risposto da uberto su
-
Chiaro che e meglio limitare le dipendenze, ma in pratica non sempre cio' e' possibile. Anzi per la mia esperienza all'inizio di un progetto e' impossibile del tutto.
Non ho capito esattamente come intendi il commitment, per fare un esempio:
se mi impegno di implementare il CRUD per un paio di entity, il sistema di messaggi di errore e il finire il fwk di auth-auth, e' chiaro che ci saranno molti task dipendenti, per esempio non posso finire il crud se non ho il sistema di messaggi d'errore funzionante, ma non posso finire l'auth-auth se non ho il crud degli utenti ecc.
D'altra parte mi servono i messaggi d'errore per iniziare l'auth-auth, ecc. sono tutti task interdipendenti.
Qui non e' tanto questione di Scrum teorico (anche se il libro suggerisce di provare 4 settimane per lo Sprint) ma della implementazione del nuovo PM.
Riguardo alla coordinazione: ci sono frequenti conference call e dei check point di integration a carico del team di QA.
Se funzionera' e' ancora presto per dirlo...
-
Permalink Risposto da Ste su
-
Il team di QA non e' quindi "embedded" negli scrum team? avete lo scrum-di-scrum che tira le fila del tutto?
Per il commitment si, intendo quello che il team si pone come goal dell'iterazione. Generalmente il backlog dell'iterazione viene inizialmente formato dal product ower e poi i team fanno "commitment" delle US che pensano di poter fare.
E' ben vero che molte US possono essere interdipendenti, ma non mi e' chiaro perche' questo dovrebbe essere un problema maggiore in scrum rispetto a quello che facevate prima (tieni conto che non so nulla di lean). Ritengo (mia personalissima opinione basata sulla nostra esperienza) che il problema dello spezzare le US e' cruciale in scrum (in tutti i processi di sviluppo incrementale per la verita'). Se e' vero che ci possono essere dipendenze, devo dire che nell'ultimo planning abbiamo migliorato molto su tale fronte e abbiamo oggi molte meno storie con dipendenze del passato. Sforzatevi di pensare alle US in termini di utente. Facendo riferimento a cio' che hai citato, per esempio, un CRUD di due entita' non e' una US. I task di una US avranno naturalmente molte dipendenze, ma non le US. US e task sono due cose ben distinte in scrum.
Ste
© 2013 Creato da Marco.
