Uncovering better ways of developing software
Funambol: introducing SCRUM in software product development
Risposte a questa discussione
-
Permalink Risposto da Andrea Maietta su -
Molto interessante, ancora una volta mi ha permesso di apprezzare la potenza dei tool di monitoraggio offerti da Scrum: un'occhiata al backlog e hai un'idea veramente precisa su quello che sta succedendo, infatti tutte le mie impressioni derivanti dai grafici (a partire dalla dimensione troppo grande delle storie) sono state puntuamente confermate da Edoardo.
-
Permalink Risposto da Edoardo Schepis su -
Grazie Andrea,
vi terro' aggiornati su come procede nelle prossime iterazioni.
La prossima release applicheremo iterazioni di 2 settimane e la cosa spero dia buoni frutti.
Edoardo
-
Permalink Risposto da Edoardo Schepis su
-
Ecco le slides in formato pdf.
Enjoy the show ;-) - Allegati:
-
-
FunambolAgileday2008.pdf, 1.4 MB
-
-
Permalink Risposto da Stefano Leli su -
Vorrei fare i complimenti a tutto il gruppo di Funambol per la testimonianza data. Resoconti di questo genere sono indispensabili per le persone che credono nella pratica delle metodologie agili e che vorrebbero introdurle nel proprio contesto lavorativo nonostante realtà aziendali non troppo sensibili a tali problematiche (non vorrei aprire una discussione su questo argomento molto dibattuto durante l'intero IAD).
Esempi reali di esperienze riuscite, soprattutto nel contesto Italiano, non possono che dare elementi oggettivi con il quale motivare e ponderare gli sforzi di queste persone.
Di nuovo complimenti.
-
Permalink Risposto da Edoardo Schepis su
-
Grazie Stefano,
se qualcuno vuole "seguirci", abbiamo creato un Pragmatic-Agile Blog.
http://pragmatic-agile.net/
Ciao
Edo
-
Permalink Risposto da uberto su -
Purtroppo io non sono potuto venire all'AgileDay.
Riguardo al backlog di Scrum (rispetto a cartine stile XP non rispetto a Waterfall :)) io ho avuto un solo problema:
la tendenza a finirein miniwaterfall / divide et impera antipattern.
Mi spiego:
mettiamo che devo implementare la nuova applicazione ABC, mi serve A, B e C, quindi faccio un backlog con queste 3 cose (ev. spezzettate).
Il fatto e' che poi quando penso di avere finito A si scopre che servono ancora 25 cose, allora va rifatto tutto il piano e il burndown chart sembra piu' un elettrocardiogramma che un dolce discesa.
Usare le storie in modo piu' rigido alla XP mi ha aiutato.
voi avete affrontato questo problema.
-
Permalink Risposto da Edoardo Schepis su
-
Ciao Uberto,
si abbiamo avuto e abbiamo ancora un po' questo problema.
Ha a che fare principalmente con stime sbagliate.
Se hai finito A e scopri che servono ancora 25 cose per finire veramente A allora la stima di A era sbagliata: si dichiara la u.s. A "not done", si ristima l'intera u.s. e se serve si toglie altro che era in piano nella iterazione per far posto al completamento di A.
Se invece hai finito A e scopri che servono ancora 25 cose non legate ad A allora A è done e le 25 cose le metti nel backlog ma per le prossime iterazioni. Quella corrente non si tocca.
Questo e' l'approccio che usiamo noi.... che ne pensi?
Edo
-
Permalink Risposto da uberto su
-
Concordo con la soluzione "tattica" :) ma il problema di base rimane.
Infatti se per motivi di business dovevo uscire per Natale con la nuova versione, dato che non posso spostare il Natale, devo essere in grado di deliverare lo stesso con quello che ho.
Se A non e' "vendibile" nel senso che pur funzionante (altrimenti non siamo Agile) non ha abbastanza nuove funzionalita' "finite lato utente" potrebbe significare un pesante impatto sul business dell'azienda.
Ovviamente non e' una "colpa" di Scrum, ma diciamo che Scrum come viene insegnato ai tanti "scrum master" non insiste molto su questo punto. Almeno per mia esperienza personale e mi sembra anche degli autori dei blog citati prima.
(vedi anche http://community.ative.dk/blogs/ative/archive/2007/03/18/Iterative-...)
In questo senso le storie XP, e la Kanban Lean, avendo definizioni piu' severe aiutano di piu' a definire i task. Nulla vieta poi di mettere le storie in un burndown dopo.
Peraltro la prima (utilissima) esperienza del XPUG-MI ci ha insegnato che e' possibilissimo sbagliare tutto anche usando XP e con le migliori intenzioni.
Piccola considerazione a lato. Spesso parlando con fan di Agile si perde di vista lo scopo ultimo: cioe' il business. Parlando con i manager invece spesso si perde di vista che poi alla fine quelle che contano sono le persone sulle metodologie, agili incluse. :)
Ciao
Uberto
-
Permalink Risposto da Ste su -
Ciao Uberto,
la differenza che fai tra scrum e XP per quanto riguarda le storie e il loro completamento non e' necessariamente realmente segnata. Ossia, nulla ti vieta di usare in scrum storie piu' circoscritte e soprattuto di dare una definizione di done che ti consente a fine iterazione di rilasciare al client. scrum non entra nel dettaglio di queste pratiche.
ste
-
Permalink Risposto da uberto su
-
Appunto Scum non entra in dettaglio, come dicevo prima nulla vieta di farlo ma in pratica il rischio di miniwaterfall c'e'.
Peraltro il BackLog scrum e' diverso dalla lavagna con le storie XP. Almeno nella mia esperienza usare l'uno o l'altro influisce sul risultato.
-
Permalink Risposto da Ste su
-
in che senso influisce? Mi interesserebbe capire meglio. Il backlog e' solo una lista di storie prioritizzate; non esclude nessuna lavagna con storie XP. Le storie possono essere XP. Certo, applicare scrum come processo lascia margine di fare cose diverse e magari non ottimali, ma questo non significa che devi fare cosi. Puoi usare scrum e applicare tutte quelle pratiche aggiuntive che ritieni opportune.
-
Permalink Risposto da uberto su
-
mi spiace non ci stiamo capendo... ci deve essere un problema di comunicazione da parte mia. :)
certo che posso usare Scrum con tutte le pratiche Xp, credo ci sia anche una proposta concreta di Scrum+Xp. Cio' non toglie pero' che Scrum "vanilla" non prevede storie nel senso Xp. Le permette ma non le richiede.
Per quello che ho visto io, e per questo mi piacerebbe scambiare esperienze, usando una lavagna con le storie c'e' meno il rischio di finire in miniwaterfall, cioe' backlog con storie fortemente dipendenti l'una dall'altra.
Ripeto, chiaro che posso usare le storie su cartoncino col processo Xp e poi farci sopra un backlog, ma questo punto tanto vale attaccarle direttamente sulla lavagna, cosi' rimane piu' semplice spostarle di priorita' e gli sviluppatori si godono l'effetto catartico di spostarle su lato Done. :)
- ‹ Precedente
- 1
- 2
- Successivo ›
© 2013 Creato da Marco.
