Newsgroup: it.lavoro.informatica
Titolo: Kanban - Chi lo usa?

Mi sono imbattuto in un video che ne parla, proveniente da Pycon Sei... E sembra il classico uovo di Colombo!
 
Qualcuno di voi usa questa metodologia? Come si trova?
 
-- 
Ciao!
Luca

 Qualcuno di voi usa questa metodologia? Come si trova?
 
Alle metodologie agile si fa ancora molta resistenza, purtroppo. Noi a 
lavoro aderiamo fedelemnte a Scrum[1] e usiamo Trello[2] per le "kanban 
board". Il metodo di lavoro iterativo e incrementale (sprint di 2 
settimane, interazione continua col product owner e i vari stakeholders, 
sprint review, sprint retrospective ogni secondo venerdi`, e release 
retrospective) si applica benissimo ai prodotti su cui lavoriamo. 
Rispetto al tradizionale waterfall, si hanno vari vantaggi: si ha un 
feedback continuo su come progredisce il prodotto, si consolida la 
conoscenza tecnica del prodotto all'interno del team, si lavora su 
aspetti sempre nuovi del prodotto. Noi usiamo pesantemente, poi, code 
review (tutte le modifiche devono essere revisionate dai colleghi) e 
pair programming (MOLTO efficace per produrre codice di qualita`).
 
 
[1] "Essential Scrum", K.Rubin - 
http://goo.gl/glAUKI
 
[2] 
www.trello.com
 
 
-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)
"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 
http://tinyurl.com/z6y6gpd
 

 [2] 
www.trello.com
 
 
Puoi indicare in che ambito usi le varie "tecniche"?
Intendo "app android", "webapp gestionale", "siti istituzionali",
"sistemi embedded", .... ?
E con quali linguaggi/framework?
Grazie
 

 E con quali linguaggi/framework?
 
Java EE, principalmente, ma anche C, per la parte "number-crunching" e gli algortimi di ottimizzazione, e C++ per un IDE di un linguaggio creato internamente. I framework usati sono uno sfracello, sia per Java che per JavaScript. Sarebbe troppo lungo elencarli. 

Ho alcune curiosità.
 
Prima di tutto: come vi regolate con eventuali fornitori esterni? e che accade alla pianificazione se per caso uno di questi è in ritardo e con questo pregiudica lo svolgimento di uno sprint?
 
Poi: mentre personalmente trovo molto sensato il code reviewing (è efficace anche se lo faccio io, figurati se lo fa qualcun altro) mi ha sempre lasciato molto perplesso il pair programming, sia da un punto di vista operativo che da un punto di vista costi. Però la mia è una visione 'ragionata' e non sul campo. Mi espandi questo aspetto?
 
Ultima curiosità: ho capito male o tu lavori per una società che inizia per S e finisce per y (e non è SyFy)?
 
-- 
Ciao!
Luca

 Puoi indicare in che ambito usi le varie "tecniche"?
 
Limitatamente allo studio che ho fatto di Kanban e di Kaizen in generale, a me sembra di poter vedere due vantaggi: parliamo di cose semplici e olistiche.
 
Le kanban board nascono in Toyota, che fa di tutto ma non software (in realtà probabilmente ne fa, e pure parecchio) per cui fa tu...
 
-- 
Ciao!
Luca

 Sarebbe troppo lungo elencarli.
 
anche perchè non li sai
 
-- 
Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.
(Victor Hugo)

On Thursday, 3 March 2016 09:56:51 UTC, Luca Menegotto  wrote:
 
[...]
Non ci e` mai successo di non riuscire a consegnare, a fine sprint, quel che abbiamo pianificato, pero` il rischio c'e` sempre, si valuta in ogni stand-up giornaliero. Il lunedi` dello sprint kick-off o ogni volta che fai grooming di una user story non riesci a prevedere tutti i possibili ostacoli, ovviamente. Gli aggiustamenti avvengono spesso in corsa, consultandosi con il product owner, che potrebbe ad esempio rimuovere dallo srpint delle user story critiche e/o delegarle ad uno sprint successivo. E` il PO che sa cosa serve veramente al cliente e stabilisce le priorita`. Riguardao al delivery a fine sprint, la regola, in generale, e` "rilassata": si consegna quel che si riesce a consegnare, e cio` che non si consegna passa al backlog per lo sprint successivo. Mai successo finora, comunque. Almeno, non per ragioni interne. L'estimate del lavoro e` sempre basato sulla "velocity" del team, per uci abbastanza affidabile. L'importante e` non mancare le release - e finora siamo sempre stati puntuali - arma a doppio taglio, perche` al minimo slittamento, se mai avverra`, ci fulmineranno :). Tendiamo a ridurre al minimo le dipendenze da "fornitori" esterni. Di solito lavorano con deadline diverse e non puoi fidarti. Al momento, per esempio, dipendiamo da un gruppo di lavoro bielorusso che avrebbe dovuto fornirci un web component due giorni fa, bello e pronto, e sta invece prendendo tempo perche` devono ancora iniziare a svilupparlo. Abbiamo capito che gli faremmo da cavie, non possiamo fidarci che quel che ci daranno (quando???) funzioni, per cui ci stiamo attrezzando con un fall-back, nel caso le cose vadano per le lunghe. Il punto e` che a fine sprint c'e` una demo e qualcosa devi far vedere. Oltretutto, tra un paio di settimane si deve registrare una demo di un prodotto, da mostrare ad una conferenza annuale negli USA, e non si puo` proprio mancare l'obiettivo. 
 
Io trovo il pari programming fondamentale, anche se in alcuni casi puo` risultare poco efficiente, impegnando due risorse su un unico task. In certi casi, pero`, non se ne puo` fare a meno. Dipende anche dal livello di affiatamento che hai coi colleghi. E` l'uovo di Colombo, "4 occhi meglio di 2", ed e` un modo efficacissimo di produrre codice di qualita` - oltre al fatto che si e` in due ad aver competenza sullo stesso codice, avendolo scritto a 4 mani. E` una cosa non da poco. Di solito, ci si si alterna alla tastiera, ma a me non pesa passare lunghe sessioni in cui sono io a digitare e l'altro guarda, o viceversa.