Newsgroup: it.lavoro.informatica
Titolo: Agile

Ciao a tutti,

Utilizzate un qualche tipo di metodologia Agile? Se si quale? Siete 

approdati in un azienda che abbraccia già questa filosofia o l'avete 

portata voi in ufficio? Quali problemi/resistenze avete incontrato?



Io mi sto da un po' interessando all'argomento, ma non ho mai avuto il 

piacere di sperimentare.



g4b0


 Io mi sto da un po' interessando all'argomento



Qui in UK, le aziende IT lavorano con Agile ormai da molti anni. Non so come sia la situazione in Italia, oggi. Agile non lo impari per conto tuo; trova un'azienda che lo usa.


 Agile non lo impari per conto tuo; trova un'azienda che lo usa.



Non sempre ci si può permettere il lusso di scappare, la mia intenzione è 

proprio l'opposto: migliorare la situazione attuale, invece di cercarne 

una già fatta, che avrà magari altri problemi. Non credo che Bezos nel 

suo scantinato di qualche anno fa fosse strutturato per gestire migliaia 

di dipendenti, ma si è evoluto ed ha creato un impero.



g4b0


 di dipendenti, ma si è evoluto ed ha creato un impero.



Bezos era il capo. Qualunque processo migliorativo deve avere il supporto degli altri, se non ce l'hai la pretesa di migliorare facendo slalom tra mille paletti e' chiaramente fittizia.



  ngw


 Non sempre ci si può permettere il lusso di scappare



Scappare? Ho detto che devi trovare un'azienda che lo usa. Se sei in un'azienda che ha intenzione di usarlo, va bene uguale.


capisci bene che se "i test vengono visti come un costo" abbiamo 



Una volta mi sono sentito dire dall'Head of QA: "forget your fancy unit tests!". E` il momento in cui ho lasciato la stanza ridendo.




 slalom tra mille paletti e' chiaramente fittizia.



Certo, la volontà di migliorare deve venire dall'alto, però in basso deve 

esserci gente pronta a cogliere l'occasione. E non sempre ho visto truppe 

disponibli al cambiamento, il programmatore spesso è abitudinario e poco 

propenso al cambiamento. Poi ci sono i programmatori bravi, ma questo è 

un altro discorso.



g4b0


 un'azienda che ha intenzione di usarlo, va bene uguale.



No, hai detto (il grassetto è mio): "*Agile non lo impari per conto tuo*; 

trova un'azienda che lo usa.". 



g4b0


 la situazione diventa presto difficile da gestire.



Avere un management che ti supporta sarebbe l'ideale. Altrimenti la soluzione e' semplice: non parlare ai manager dei test. Non gliene deve fottere una sega, non so se mi spiego :D



Prima di creare una classe o piazzare un if, andate a chiederlo al manager? Non penso. Vi gestite voi il lavoro tecnico. Scrivere test e' esattamente la stessa cosa.



Se il problema e' che tra sviluppatori non riuscite a mettervi d'accordo e quindi non si riescono ad imporre certe regole interne (scrivere test) allora il manager diventa indispensabile. 



Altrimenti no.


 allora il manager diventa indispensabile.



Questo è un altro problema che ho visto spesso, se gli standard non 

piovono dall'alto difficilmente ci si mette d'accordo tra nerd 

disadattati :)



g4b0


 g4b0



Beh sui test dovrebbero mettersi d'accordo. A meno che tu non stia lavorando in realta' oscene, dove sei circondato da ragionieri programmatori che fanno aggiustatine al codice scritto 10, 20 o 30 anni prima (tanto per far eun esempio)...in quel caso si e' vero non gliene frega niente e non gliene freghera' mai niente. 



E' anche vero che non hai futuro in posto del genere, tu o qualsiasi persona minimamente motivata.


 trova un'azienda che lo usa.". 



Perche` tu hai scritto "Io mi sto da un po' interessando all'argomento, ma non ho mai avuto il piacere di sperimentare.".  Se non hai mai avuto modo di applicare Agile, la cosa piu` semplice, dal momento che, come ho scritto, Agile non lo impari per conto tuo, e` quella di spostarti in un posto in cui la filosofia Agile e` stata gia` abbracciata. Sperimentare, con Agile, non e` possibile, nel senso che e` un semplice esercizio che fai da sviluppatore. Devi coinvolgere l'azienda a vari livelli, dal management, al test, allo sviluppo. Oltretutto, se sei inesperto con Agile, applicarlo male e` un attimo e comprometterebbe tutto. Scrum e` molto difficile da applicare bene. La cosa piu` semplice e sicura, IMO, e` assumere uno ScrumMaster con esperienza. Prima, pero`, l'azienda deve accettare il passaggio e tu devi essere sicuro che non ti troverai a lottare contro i mulini a vento.


>Avere un management che ti supporta sarebbe l'ideale. Altrimenti la soluzione e' semplice: non parlare ai manager dei test. 



Non e` realistico. Il management deve comprendere bene qual e` lo sforzo implementativo di una determinata user story. Deve sapere (almeno come "big picture") che lo sviluppo include gli unit test, gli integration test, gli end-to-end test, gli acceptance tests, i test manuali, ecc. D'altronde tutti questi passaggi fanno parte della "Definition of Done" che il management deve necessariamente accettare. 


 per Agile&co. in situazioni simili.



praticamente stai dicendo che chi gestisce il budget è lo stesso di chi 

lo utilizza. cioè se ad esempio il progetto avesse bisogno di una persona 

in più, lui se la chiede e lui si risponde no :-P

queste sono aziende a gestione che definire artigianale è complimento. 

badabene non è questione di dimensione: anche una piccola startup può, 

anzi deve, avere un controllo di gestione.


 caso se dice no è no, e spesso è così



A parte che uno sviluppatore che, nel 2019, dice no ad Agile per principio e` un peracottaro, non riesco a capire che ambiente di lavoro possa mai essere quello in cui non si riesce a dialogare con questa persona e a fargli/le capire i vantaggi di una metodologia agile.


 Non e` realistico. Il management deve comprendere bene qual e` lo sforzo implementativo di una determinata user story. Deve sapere (almeno come "big picture") che lo sviluppo include gli unit test, gli integration test, gli end-to-end test, gli acceptance tests, i test manuali, ecc. D'altronde tutti questi passaggi fanno parte della "Definition of Done" che il management deve necessariamente accettare.



Implicitamente mi riferivo a unit test e poco sopra, che sono quelli che certamente mancano ad un team che fino ad ora ha rifiutato metodologie agile in toto. Si presume che un minimo di test automatici e manuali (probabilmente alla cazzo) siano cmq in piedi e i manager ne siano a conoscenza.



Ma per quanto riguarda i primi, credo siamo d'accordo che non sia necessario l'avvallo del manager. Cosi' come non e' necessario l'avvallo del manager per impiegare tecniche come TDD.


>Ma per quanto riguarda i primi, credo siamo d'accordo che non sia necessario l'avvallo del manager. Cosi' come non e' necessario l'avvallo del manager per impiegare tecniche come TDD.



No, certo, non ti serve la luce verde dal management per adottare certe tecniche ma mi sembrava che tu suggerissi di tenere all'oscuro il management da certe tecniche utilizzate. Una cosa è che il management non sia interessato o tenuto 

a sapere, una cosa è cosa potrebbe succedere se venisse a sapere che "perdi tempo" con gli unit test. Tutte le aziende IT corrono verso scadenze precise. Si tratta di far capire al management che lo zaino che ti carichi sulle spalle mentre corri, DEVE contenere gli unit test. Alla fine, si tratta sempre di giustificare la "velocity" del team. 



In ogni caso, il ruolo di questo manager/programmatore dovrebbe essere rivisto se si adottasse Scrum. Se vuol essere il product owner si accomodi. Se è un posto talmente piccolo che il product owner partecipa allo sviluppo, bene.


>[...]di norma c'è sempre un cliente/manager che 

chiama e che passa in priorità massima



Un'altra cosa: bisogna capire perche` questo succede e risolvere il problema alla base. Per esempio, se si tratta di priorita` dovute a bug, il problema e` ovviamente la qualita` del codice prodotto. Scrum aiuta anche a risolvere questi problemi perche` incoraggia al fast feedback. Il ciclo sviluppo -> test -> sviluppo e` (o dovrebbe essere) il piu` breve possibile. Da qui il motivo per cui le storie devono essere "ready", a fine grooming, secondo INVEST (
https://en.wikipedia.org/wiki/INVEST_(mnemonic)
) dove la *S* sta appunto per "small". Se una user story e` sufficientemente piccola, lo sviluppo sara` breve, il test sara` breve, qualunque "rework" della storia sara` altrettanto breve. Se a questo poi si aggiungere un rilascio frequente al cliente (e.g. ogni settimana o due) anche il feedback dal cliente diventa veloce.


Ciao a tutti,

Utilizzate un qualche tipo di metodologia Agile? Se si quale? Siete

approdati in un azienda che abbraccia già questa filosofia o l'avete

portata voi in ufficio? Quali problemi/resistenze avete incontrato?





Si.

Non so quale (mi pare scrum, non sono un esperto), ma per fortuna abbiamo 

smesso. Le resistenze che ho trovato, oltre alle mie, sono quelle del team 

quando ha capito che nel nostro caso non funziona.



Trovo che queste metodologie vadano bene in due casi: 1) quando si deve 

gestire team composti da persone inesperte oppure 2) quando il lavoro e' 

facilmente pianificabile (cosa che in effetti accade nel 90% dei casi).

In altri casi non vedo utilita' e anzi vedo problematiche.



Ora sto in una startup dove si usa(va) questa metodologia, ma dopo un po' 

che si cercava di pianificare con oreuomo e bigliettini colorati una 

attivita' essenzialmente di *ricerca* si e' capito che probabilmente non 

funziona.

"ok, tu scopri come fare a risolvere questo problema che finora nessuno ha 

mai visto. Quanto tempo ci vuole?" e' roba da idioti che guardano troppo 

silicon valley. Per cui abbiamo eliminato molti aspetti - ma mantenuto altri 

che sono utili.



Dove ero prima, settore industriale, gestivo il team di R&D dove 

l'esperienza media delle persone era superiore ai 10 anni. Ti immagini a 

microgestire gente del genere coi bigliettini? Gli si dava - al singolo - il 

progetto in mano completamente, una scadenza, e lui era in grado di 

pianificarsi il lavoro. E funzionava.

Niente standup meeting, gantt, lavagnette varie. A parte qualche consiglio 

in fase progettuale, se necessario, il mio intervento si limitava a 

intervenire quando per qualche motivo ci si bloccava su qualcosa.

Con i nuovi arrivi naturalmente era diverso.

C'e' da dire che la selezione naturale era fortissima, il lavoro era 

difficile e il programmatore quadratico medio da noi durava poco, bisognava 

avere qualcosina in piu'.



In entrambe le realta', per motivi diversi, a mio avviso una metodologia 

come agile non e' inutile, e' dannosa.

Poi sicuramente ci sono millanta situazioni in cui si deve gestire team 

giovani e/o inesperti che fanno cose piu' o meno routinarie e in quei casi 

agile puo' essere utile.




 microgestire gente del genere coi bigliettini?



Il tuo/vostro problema e` che non avete capito ne` Agile, ne` Scrum. Peccato (per voi). Scrum non e` bigliettini colorati e lavagnette. E` una metodologia seria, che si applica bene a qualunque tipo di progetto, di qualunque dimensione, e con persone di qualunque esperienza.


 CUT



Che infinita noia questo modo di banalizzare qualsiasi argomento in base a propri evidentissimi limiti. Che dici, mi metto a "difendere" SCRUM o kanban dall'evidente puttanata dei "bigliettini"? Possibile mai che siano sempre tutti stupidi (tutti, chi fa unit testing, chi fa scrum, chi usa redis, chi e' sul cloud, chi usa python, chi usa linux, basta cercare su ILI e' un atteggiamento che si ripete per praticamente tutto) e il gallo l'abbiamo giusto trovato qui che c'ha l'esperienza? Passo, utile come pulirsi il culo col radiogiornale.

Che barba che noia.



  ngw


  E` una metodologia seria, che si applica bene a qualunque tipo di progetto, di qualunque dimensione, e con persone di qualunque esperienza.



Sì, come no. Nel tuo campo magari. Prova a proporre Agile o Scrum in qualsiasi azienda che sviluppa firmware per microprocessori e vedi se non ti ridono in faccia




 Che infinita noia questo modo di banalizzare qualsiasi argomento in base a propri evidentissimi limiti.



+1


On Thursday, 17 January 2019 10:09:29 UTC, Giuspi  wrote:



[...]

Un link come tanti, tanto per fare un esempio:



https://innolution.com/blog/agile-in-a-hardware-firmware-environment-draw-the-cost-of-change-curve




ma di esempi ce ne sono molti altri.


 Sì, come no. Nel tuo campo magari. Prova a proporre Agile o Scrum in qualsiasi azienda che sviluppa firmware per microprocessori e vedi se non ti ridono in faccia



Se lo fanno con gli stessi (non)argomenti che usano i detrattori di Agile qui dentro, saro` io a ridergli in faccia. Agile/Scrum non dettano regole su quali progetti tu possa realizzare. Sono trasversali. D'altronde, le idee alla base nascono dal mondo della produzione di automobili. Un'azienda che sviluppoa firmware per microprocessori puo` beneficiare di Agile come qualunque altra azienda. Di esempi, in giro, ce ne sono a bizzeffe.




 Ma davvero sentite l'esigenza di avere attorno figure ridicole come gli scrum master, che non si sa bene che cosa facciano e il cui analogo non esiste in nessun'altra categoria professionale? Non sarebbe meglio abolire i loro stipendi e ridistribuire i soldi come premi produzione per gli sviluppatori? Contenti voi...



Cioe' quello comunemente chiamato "project manager"?



  ngw


 Sì, come no. Nel tuo campo magari. Prova a proporre Agile o Scrum in qualsiasi azienda che sviluppa firmware per microprocessori e vedi se non ti ridono in faccia



Se lo fanno con gli stessi (non)argomenti che usi tu, saro` io a ridergli in faccia. Agile/Scrum sono del tutto trasversali al tipo di software che produci. D'altronde, la storia di Agile parte dal mondo della produzione di automobili, del tutto differente dal software. Il fatto che tu non ritenga Agile/Scrum adatto al firmware per microprocessori, mi fa capire che tu non lo abbia mai utilizzato. Sono metodologie che prescindono dal tipo di progetto specifico. Se hai dei task da completare, se hai del software da rilasciare in produzione a scadenze precise, Agile fa per te. Il problema e` che Agile presuppone la voglia di comprendere i meccanismi, a volte sottili, che stanno alla base, ed applicarli. Cosa evidentemente difficile da fare per molti, che preferiscono banalizzare con bigliettini colorati e lavagnette.



"Ken Rubin is a leader in agile software development training, including Scrum training, Scrum Master certification, coaching agile teams, Scrum consulting and teaching Kanban techniques."



Oste, com'è il vino, è buono?


 Oste, com'è il vino, è buono?



LOL :) E chi ti aspetti che guidi una trasformazione Agile in una societa` che non lo ha mai usato, o dove ci sia molta resistenza ad usarlo, se non un esperto in materia che conosca i benefici? 



E` un articolo abbastanza lungo dove viene spiegato qualcosa. Leggilo. 



Per obiettare alla tua idea che Agile non si possa usare dove si sviluppa firmware, basta una semplice ricerca su Google:



https://comtradedigital.com/wp-content/uploads/2016/09/Firmware_Development_using_Agile_Case_Study_WEB.pdf




https://www.semanticscholar.org/paper/Agile-methods-applied-to-embedded-firmware-Greene/7165993d2fc0c456d68decea593e540b4c796798




Anche: 
https://ieeexplore.ieee.org/document/1359797




https://www.embedded.com/design/prototyping-and-development/4215538/Agile-embedded-software-development




etc... 




On Thursday, 17 January 2019 11:01:46 UTC, Giuspi  wrote:


Che inattesa piega degli eventi, mettere in discussione le fonti non in base a quello che sostengono ma in base a quanto sono coinvolte in una determinata pratica. Come sempre. Ora chiedo al barista di Starbucks cosa ne pensa di Kanban.



  ngw


 Che inattesa piega degli eventi, mettere in discussione le fonti non in base a quello che sostengono ma in base a quanto sono coinvolte in una determinata pratica. Come sempre. Ora chiedo al barista di Starbucks cosa ne pensa di Kanban.



Ovviamente non mi aspettavo che leggesse l'articolo :)



Un intero articolo che spiega esattamente come si possa fare cio` che lui dice non si puo` fare, ma lui che fa? Cerca subito un attacco ad hominem per screditarlo :)




Il tuo/vostro problema e` che non avete capito ne` Agile, ne` Scrum.



Mi ricorda quello che si diceva del comunismo: e' un'ottima idea, ma e' 

veramente difficile applicarla bene. Come scrum.

A mio avviso e' un modo per microgestire la gente, in alcuni ambienti 

funziona ed e' anzi necessario, in altri no. 




 Mi ricorda quello che si diceva del comunismo[...]



E con questo direi che si puo` chiudere qui questo ramo del thread. 


 Un intero articolo che spiega esattamente come si possa fare cio` che lui dice non si puo` fare, ma lui che fa? Cerca subito un attacco ad hominem per screditarlo :)





Invece i vostri problemi sono:



- credete che esista una metodologia "one size fits all"; le metodologie sicuramente funzionano nel vostro campo, nessuno lo mette in dubbio; siete dei presuntuosi a pensare che possano funzionare ovunque. Come diceva giustamente infradito, quando sono nell'ambito della ricerca è semplicemente assurdo utilizzare queste metodologie. In altri casi può essere dannoso e controproducente : per esempio potrei implementare velocemente un'interfaccia SPI tramite polling o interrupt invece del lungo e faticoso DMA, e magari all'inizio funziona tutto e non sto a perdere tanto tempo per analizzare l'architettura generale, poi qualche mese dopo scopro di essere nei guai e sono costretto a ripartire da zero



- avete bisogno della baby-sitter che "rimuove gli ostacoli che limitano la capacità del team di raggiungere gli obiettivi"; ma sul serio?





Infatti è per gente che ha bisogno della baby-sitter che gli rimuova ostacoli che limitano la capacità del team di raggiungere l'obiettivo, e che crede di aver scoperto la metodologia "silver bullet" che si applica in tutti i campi dell'informatica


 Infatti è per gente che ha bisogno della baby-sitter [...]



LOL :) Nella Scrum Guide c'e` tutto quello che devi sapere. Buona lettura :)


Come diceva giustamente infradito, quando sono nell'ambito della ricerca [...]



L'ambito della ricerca non e` quello di cui parlava quel tale. Si riferiva a cio` che viene comunemente chiamato "spike". Investigare tecniche, tecnologie, metodologie con Agile/Scrum e` roba che si fa comunemente e tranquillamente entro le iterazioni di sviluppo. Pero`, come gia` detto, tutto cio` e` gia` ampiamente spiegato dagli Scrum coach che tu reputi figure inutili ;)



E invece perché un esperto di metodologie agili dovrebbe essere in grado di insegnare a uno sviluppatore firmware come fare meglio il suo lavoro, senza averlo mai fatto lui in prima persona? Provate a proporre una figura professionale simile a un team di medici o avvocati. Vi mettono alla porta all'istante








 E invece perché un esperto di metodologie agili dovrebbe essere in grado di insegnare a uno sviluppatore firmware come fare meglio il suo lavoro[...]



Ti si potrebbe rispondere: e perche` no? Se tu avessi letto il link che ho postato, probabilmente te ne renderesti conto.



Un link che troverai sicuramente interessante:

https://www.beckershospitalreview.com/human-capital-and-risk/agile-management-can-benefit-healthcare-process-improvement-projects.html





On Thursday, 17 January 2019 12:32:17 UTC, Giuspi  wrote:



[...]

Altro link che troverai interessante:



https://www.relativity.com/blog/an-agile-law-firm-it-exists-and-its-getting-results/



On Monday, 14 January 2019 13:13:34 UTC, g4b0  wrote:



[...]

Ti consiglio questo video di Eric Brechner (capo sviluppo della Xbox) 
https://www.youtube.com/watch?v=CD0y-aU1sXo




E` un'ottima introduzione a Kanban.






ha scritto nel messaggio 

news:b4e1f68d-4fb0-4ba6...@googlegroups.com...


E meno male che ho detto che nel 90% dei casi probabilmente e' applicabile.

Faccio 99 cosi' sei piu' tranquillo, dai. 





Accozzaglia di luoghi comuni e fallacie logiche, as usual. Sorry, non interessato a proseguire, ciaps.



  ngw


[...]

Mi ricordano Verdone in Troppo Forte. Quel famoso dialogo nell'atrio dell'ospedale: "ma me venisse l'AIDS!"



Non cominciare neanche a parlargli di unit test o addirittura Test-Driven development. Ti distruggono la materia in 3 secondi perché a loro tutto ciò non può applicarsi. Loro sono un caso speciale. Hanno il pisello più lungo di un metro :)


 la capacità del team di raggiungere gli obiettivi"; ma sul serio?



sei spiritoso, quindi cerco di farti un esempio per spiegarti che è una 

battuta inopportuna e sciocca.



supponiamo che tu sia a capo di un team e supponiamo che tu abbia una 

scadenza la prossima settimana. supponiamo anche che un membro del tuo 

team non stia venendo a capo di un problema. ora in questo scenario hai 

due possibilita: 1) ti adoperi in qualche modo per superare il problema e 

uscire dall'empasse 2) che si fotta, è il suo lavoro, se il progetto va 

in sofferenza lo infami e dai la colpa a lui.



tu cosa faresti? considera che con la 1 sceglieresti la "baby sitter".



le metodologie alla fine non è che inventano chissà che, mettono a 

procedura delle questioni di buonsenso. scrum prevede i daily scrum, tu 

magari li chiami sal e non li fai tutti i giorni, però non è che puoi 

dire sia stupido tenere il "polso" del progetto e eliminare gli ostacoli 

prima che si trasformino in scadenze bucate o (peggio) fallimenti. a meno 

che non sia una di quelle persone che pensa di far carriera infamando gli 

altri (in certi ambienti funziona, quindi niente da ridire).


 alla porta all'istante



come se in un team di sviluppo si proponesse una caposala, o un direttore 

di supermercato piuttosto che un allenatore di calcio.



per dirti come ti sei svegliato sagace stamattina.




 procedura delle questioni di buonsenso.



Esatto. E` proprio quello il punto.



D'altronde, Agile ha provato sul campo di essere migliore di Waterfall: 
https://www.infoq.com/articles/standish-chaos-2015




Una riduzione dei progetti falliti dal 29% al 9% (!), una riduzione dal 57% al 49% di quelli over budget, e un incremento di quelli riusciti dal 14% (sigh) al 42%.




 veramente difficile applicarla bene. Come scrum.



scrum è una metodologia, non una ideologia. se proprio vogliamo fare un 

parallelo con una ideologia possiamo farla con il concetto di qualità: è 

un'ottima idea, ma è veramente difficile implementarla. scrum, agile, 

waterfall sono metodologie e tutte puntano alla qualità, il punto è 

chiedersi quale ci riesce meglio. tenendo sempre conto che la complessità 

non è più quella di 20 anni fa e le metodologie tradizionali hanno dei 

limiti evidenti. siamo tutti a deridere scrum ma voglio vedervi all'opera 

con una metodologia waterfall laddove i requirements cambiano più e più 

volte nel corso del progetto, voglio vedere il risultato e la salute 

finale del vostro fegato. 


 finale del vostro fegato.



Il tizio scrive piu` su: "Gli si dava - al singolo - il progetto in mano completamente, una scadenza, e lui era in grado di pianificarsi il lavoro."



Chiaro che pensare di poter ancora lavorare a quel modo, significa non aver capito il fallimento di Waterfall e il successo di Agile. Pensare di assegnare un intero progetto ad un singolo per un tempo piu` o meno lungo e` una follia che comprende anche uno sviluppatore alle prime armi. Ma anche ammettendo che funzioni, non si capisce bene perche` gli stessi parametri non funzionerebbero nel mondo Scrum. Se assegni un "progetto" (user story) ad uno sviluppatore (il singolo) e gli dai una scadenza (fine sprint), e se consenti allo sviluppatore di pianificarsi il lavoro (sprint planning) e se iteri questo processo, cosa cambierebbe in termini di successo? Col vantaggio, pero`, che sei in un team, segui una disciplina inspect&adapt, dai modo a chi commissiona il lavoro di vedere il prodotto crescere iterazione dopo interazione, e gli consenti persino di cambiare priorita` in corso d'opera. Lui pero` ci vede bigliettini colorati e lavagnette. Che ci vuoi fa`.



Non pensavo che sarebbe mai successo, ma in questo caso sono d'accordo 

con te. Il problema più evidente del "one-man project" con scadenze medio/

lunghe si ha quando quella persona migra in un'altra azienda nel bel 

mezzo del progetto, per i motivi più disparati, portandosi via il 99% del 

know-how relativo ed obbligando il suo successore allo studio di sorgenti 

oscuri. Visto con i miei occhi e provato sulla mia pelle. 



In effetti una metodologia Agile che accorcia (spezzetta) i tempi di 

delivery e fa mettere le mani sul progetto a più di un individuo aiuta 

enormemente il processo di rimpiazzo della risorsa.



g4b0



Quello della "torre d'avorio" e` un problema, ma avresti problemi seri anche se quella persona restasse in azienda. Un team sviluppa codice di miglior qualita` e molto piu` velocemente di un singolo. Un approccio come il mob-programming, per esempio, sperimentato sulla mia pelle, e` di gran lunga piu` produttivo dello sviluppo isolato delle storie, pur adottando Scrum. Migliore persino del pair-programming.

Nel mio team, io incoraggio sempre almeno il pair-programming. Si condivide, si hanno 4 occhi sul codice, il tempo di una code review viene praticamente assorbito dallo sviluppo. Questo, insieme al Test-Driven development, e` un approccio vincente. Se si lavora su una storia singolarmente, SI DEVE adottare il processo delle code review (ed io suggerisco sempre di usare un tool, e.g. Crucible). Che il codice sia "reviewed" e` tra l'altro uno degli step della DoD in qualunque team Scrum. Insomma, lo sviluppo di un progetto individualmente, in totale isolamento, e` pura fantasia e chi applica un modus operandi del genere, si sta mettendo un cappio sempre piu` stretto attorno al collo.


 armi. 



prendere un intero progetto, passarlo pari pari ad una persona e 

aspettare che abbia finito non è scrum, ne waterfall, non è niente. è 

l'antitesi del processo. spero almeno intendesse una attività o un task 

di progetto, non il progetto intero. sennò davvero stiamo parlando del 

nulla.


finale del vostro fegato.



Gia', perche' secondo te senza agile nessuno lavora?






>"rootkit"  ha scritto nel messaggio news:q1t51g$qs0$1...@dont-email.me...


Boh non so a che dimensione di progetti sei abituato tu, parlo di progetti 

di al massimo qualche centinaio di migliaia di euro, non enormi ma 

sicuramente non il nulla.

E si, laddove lavoravo io - ma e' piuttosto generale - viene data la 

responsabilita' a una sola persona (*). E' evidente che non hai nessuna 

conoscenza del settore dell'automazione industriale.



(*) giusto per capirci, quella persona in genere prende come tre 

programmatori normali. 




enormemente il processo di rimpiazzo della risorsa.



Questo quando te lo puoi permettere, o quando i progetti sono 

sufficientemente semplici per cui le competenze necessarie sono diffuse.

In molti progetti (tipicamente in industria ma non solo), le competenze sono 

molto verticali e concentrate. Non puoi pensare di avere nel team N esperti 

di motion, N esperti di robotica, N esperti di elaborazione 3d, N ingegneri 

dell'automazione, N di questo e N di quello.

Ne hai uno per campo e anzi spesso una persona ricopre piu' figure, in 

questi contesti scrum non serve a un cazzo. 




 Gia', perche' secondo te senza agile nessuno lavora?



non ho detto questo. ho detto voglio vedere ad applicare una metodologia 

a cascata in tutti quei casi, che per quanto mi riguarda sono la quasi 

totalità, in cui non è ragionevolmente possibile blindare i requisiti. 


 programmatori normali.



Di quali RAL stiamo parlando, anche solo indicativamente?



g4b0


>"rootkit"  ha scritto nel messaggio news:q26ckj$jmd$1...@dont-email.me...


Concordo. Ma di metodologia a cascata non ne ho parlato io.

Penso che ci sia comunque un fraintendimento di fondo, probabilmente 

parliamo di progetti di tipo/dimensione diversi. 




 questi contesti scrum non serve a un cazzo.



Si, però se la persona in questione decide di migrare verso altri lidi 

l'azienda si trova un bel problema da gestire. Poi concordo con te sul 

discorso per cui scrum non è la metodologia silver bullet per qualsiasi 

problema, dipende molto dal contesto. Ciò non toglie che avere in azienda 

un guru con del know how difficilmente rimpiazzabile è un problema, ed 

anche bello grosso: se il guru una mattina venendo a lavoro si schianta 

in macchina cosa fa l'azienda?



g4b0


in macchina cosa fa l'azienda?



Si attacca al tram. Ma senza quel guru probabilmente l'azienda farebbe 

gestionali. 




 gestionali.



Be, però potrebbe iniziare affiancandogli un junior da formare, in modo 

da iniziare a pararsi il culo. 


 problema, dipende molto dal contesto.



Io potrei anche concordare con te/voi su questo, se solo voi provaste di aver utilizzato Scrum, magari per qualche anno, e di averne constatato i limiti su un progetto specifico. Affermare "Scrum non e` un silver bullet" da parte di chi non ha mai usato Scrum e` pura retorica. Purtroppo gli unici argomenti contrari che vedo, qui dentro, sono "microgestione", "bigliettini", "lavagnette", e questo mi fa capire bene che non si conosce ne` Agile, ne` Scrum. Non sono stati presentati argomenti validi contro l'uso di Scrum. Un progetto intero assegnato ad una persona sola (a prescindere da quanto sia pagata) e` una stupidaggine in qualunque contesto, non ci sono scuse che tengano. D'altronde Agile/Scrum non presupporrebbero neanche l'esistenza di un team. Si puo` usare Scrum anche se si lavora da soli (
https://www.raywenderlich.com/585-scrum-of-one-how-to-bring-scrum-into-your-one-person-operation
). Affermare Scrum e` utilizzabile sono su "progetti semplici" o con team di inesperti, e` un'altra grande stupidaggine contraddetta dall'esperienza di migliaia di aziende nel mondo, anche di gente che scrive qui dentro. Pensare che esista o la cazzutissima automazione industriale o il mondo dei gestionalini, e` un'altra grandissima stupidaggine. Potrei continuare a menzionare le tante stupidaggini dette qui dentro, ma di controbattere e spiegare perche` sono stupidaggini non ho proprio voglia. E qui su ili, di cazzate del genere, se ne sentono tante, sempre dalle stesse persone.


 limiti su un progetto specifico.



Come ben sai non ho esperienza in Scrum, e la questione del silver bullet 

l'ho letta sui libri con i quali mi sto documentando, e personalmente la 

trovo un concetto di buon senso. 



g4b0


Io potrei anche concordare con te/voi su questo, se solo []



E' che sei un coglione, as usual. 




 programmatori normali.



Il che è francamente irrilevante per l'economia complessiva della questione: le persone in oggetto come lavorano al 100% su un progetto posso lavorare al 50% su due.



Il problema è culturale: la grande maggioranza degli sviluppatori in ambito industriali hanno una bassissima attidudine alla condivisione. Il più delle volte per motivi strettamente egoistici.



Fortunamente è una malattia che si curerà abbastanza facilmente con la riduzione costante dei posti disponibili per chi non saprà adattarsi.



Ciao

  Francesco


 gestionali.



Non è vero: semplicemente alcune aziende lavorano così perchè lo hanno sempre fatto ma questo non significa che potranno continuare a farlo.

Agile o non agile.



Ciao

  Francesco




 conoscenza del settore dell'automazione industriale.



questo è sicuro, ma non è che cambi molto i termini della questione: non 

ha senso parlare di processo se questo consiste nel dare in gestione 

completa l'intero progetto ad una singola persona. questo a prescindere 

dal fatto che sia una prassi più o meno consolidata in quel settore.


dal fatto che sia una prassi più o meno consolidata in quel settore.



Ma infatti, e' quello che dicevo da subito: per la mia esperienza e per 

diversi settori (ad esempio ricerca, oltre che quello industriale), scrum 

non serve a un cazzo.

Poi ci sono altri casi (il 90%, dicevo) dove invece e' utile.

Si fa fatica pero' a leggere piu' di tre righe, c'e' gente che fa grep sul 

testo e se trova due parole chiave gli si tappa la vena e parte con la 

rincorsa; credo sia un modo come un altro per sfogarsi. Guarda:

Aziende serie, ad esempio apple e facebook, col cazzo che usano i 

bigliettini colorati. Perche' sono vecchi e cattivi? No, perche' non serve a 

un cazzo.






inesorabilmente spinte fuori dal mercato.



Premetto che di progetti monopersonali non ho parlato io, ho parlato di 

responsabilita' in capo a una persona, che e' diverso. Ma rimaniamo al caso 

di progetti monopersonali.



Il settore dell'automazione, che probabilmente conosci, in italia e' fatto 

da tante micro e piccole aziende e qualche azienda grande, tipo comau. Per 

piccole intendo aziende con 5-50 dipendenti, compresi commerciali, 

amministrazione, cazzi e lazzi.

E' impensabile di avere ridondanza in particolare nelle posizioni piu' 

tecniche. Non conosco UNA azienda (ho collaborato, per vari progetti, con 

molte di esse) dove ci sono due persone incaricate dello stesso progetto, o 

che lavorano in pair supercazzola, o che sono comunque interscambiabili 

liberamente.

Ci sono, si, persone con compentenze sovrapponibili ma normalmente lavorano 

su progetti distinti e separati. Non e' mai successo che, che so, una 

azienda non prenda un lavoro perche' due suoi softwaristi stanno lavorando 

sulla stessa cosa: uno fa una cosa, uno ne fa un'altra. Per l'azienda avere 

la necessita' di far lavorare due persone al posto di una e' un costo 

insostenibile (e ingiustificabile, anche).



Certo capita che c'e' da fare un lavoro, chi ha fatto il sistema e' occupato 

da qualche parte nel mondo, bisogna farlo subito e allora il capo prende il 

primo programmatore che ha nella lista e lo spedisce a risolvere il 

problema. Beh quello non sa dove mettere le mani perche' il sistema non l'ha 

fatto lui (ed e' anche roba molto complessa e sviluppata col minor costo 

possibile, giusto per anticipare i coglioni che ora iniziano la tiritera sui 

pattern e la documentazione e la rava e la fava) e quindi impiega il triplo 

del tempo/costo. Costava meno farlo meglio dall'inizio? Vero, ma non ho 

incontrato nessun cliente che accetti di sostenere questo costo.



"un rischio che nè l'azienda nè il committente si posso più permettere" e' 

un desiderata. Nel mondo reale il tempo di consegna e' ieri, il costo e' 

sempre troppo alto e l'idea di ridondare risorse e' inapplicabile.



Ognuno poi si attrezza come puo'. Noi nel corso di decenni ci eravamo dotati 

di un framework di lavoro che tutti i tecnici conoscevano e dovevano usare. 

Per cui quantomeno la base era comune, se c'era da correggere un bug o fare 

una modifica piccola era possibile farlo - magari con supporto telefonico 

dell'autore - da chiunque. Entrare nella logica del sistema ovviamente era 

molto piu' complesso.



Poi magari in google ci sono team che applicano l'ultimissima metodologia e 

hanno 25 persone a fare il lavoro di 3. Se lo possono permettere, sono 

liberi di gestire il personale come vogliono, buon per loro. Sono stato 

anche consulente per una azienda di questo tipo. Ma nel resto dei casi, e se 

vuoi durare nel tempo, no. 




 E' impensabile di avere ridondanza 



Il quadro e' chiaro allora: si tratta di un settore dominato da micro realta' totalmente inefficienti e incapaci di organizzare correttamente il lavoro. Un posto di merda, tanto per intenderci.



Possibile che in Italia sia persino pagato di piu' di un software developer Java, perche' sappiamo che l'IT in Italia e' semplicemente disastroso. 

Abbiamo i commessi dei supermercati che prendono quanto un ingegnere. E abbiamo i programmatori PLC che prendono piu' di programmatore Java o Python o quel che vuoi.



E infatti ho controllato i salari su indeed UK, e la situazione si capovolge: prende abbastanza di piu' un software engineer generico di un programmatore PLC.


 vuoi durare nel tempo, no.



Perdonami ma no, non è così: l'obbiettivo è fare lo stesso lavoro, magari con meno persone se si riesce, senza concentrare tutto nella testa di troppo poche persone.



In ogni caso è un dibattito meramente filosofico: come quasi sempre accade in questi casi il mercato sta facendo piazza pulita di chi non ha un sistema di lavoro ottimale.



Ciao

  Francesco




 PLC.



A parte che oggi automazione non è da tempo più solo PLC ma ben altro la cosa è dovuta anche al diverso peso del settore nelle due economia: in Italia esportiamo molte più macchine automatiche che l'UK.



Ciao

  Francesco


 serve a un cazzo.



sì però vedo che un po' tutti si faccia fatica a leggere più di tre 

righe, visto che non ci si schioda da questi benedetti bigliettini 

colorati. certo se ci si fissa su questi aspetti, francamente marginali, 

come se fossero pietre miliari della metodologia, si capisce perché uno 

poi la trova inapplicabile. 


 E infatti ho controllato i salari su indeed UK, e la situazione si capovolge: prende abbastanza di piu' un software engineer generico di un programmatore PLC.



Come contractor, in posti come Londra, arrivi a prendere 500-600 sterline al giorno (a volte anche di piu`), per cui a fine mese ti metti in tasca dalle 8000 alle 9000 sterline nette/mese. Certo, devi pagarti alcuni extra che il dipendente ha garantiti, ma conviene. Lui continui pure a farsi le pippe sui supergeni con cui lavora, che possono lasciarlo a meta` progetto col culo per terra.



Il bello e` che non ha neanche capito che Agile nasce proprio per risolvere i problemi di quelle aziende che hanno bisogno di correre e di consegnare "ieri". Quelle che esistono nel grande mondo informatico su cui non si e` mai neanche affacciato. Si riempie la bocca della solita retorica stupida di chi ha una mentalita` lavorativa antiquata, dei metodi antiquati, e una hubris che gli trasuda dalle orecchie. E straparla di bigliettini, lavagnette, microgestione. Patetico.


 [...]non ci si schioda da questi benedetti bigliettini 



Non e` che lui lo trovi inapplicabile, non ha mai neanche cercato di applicarlo. Straparla a vanvera (come al solito). Uno che blatera, oggi, nel 2019, che Agile sia una pratica di microgestione, che implichi far fatica a leggere piu` di tre righe, quanto potra` averci mai capito di tutta la storia?






 una e' un costo insostenibile (e ingiustificabile, anche).



non conosco il settore, ma in altri a me più congeniali non si parla 

necessariamente di competenze sovrapponibili. per dire un progetto web 

per quanto scacio avrà bisogno di competenze di backend, di frontend e 

probabilmente anche di sistema (containerizzazione, ad esempio). quindi 

almeno tre persone sono coinvolte, magari non a tempo pieno se il 

progetto è piccolo, ma a maggior ragione deve esserci coordinazione. era 

questo che intendevo con "aumento di complessità" in ambito enterprise 

negli ultimi 20 anni. 


lavoro. Un posto di merda, tanto per intenderci.



Vedi come e' facile arrivare a conclusioni del cazzo? 




decennio e sta fortunamente evolvendo rapidamente.



Mah. Ne sono fuori da poco piu' di un anno ma francamente non ho visto 

questa mutazione.

Guarda caso proprio in questa settimana ho fatto un colloquio con una 

(piccola) azienda tedesca in questo settore e il quadro che ne e' emerso e' 

sempre lo stesso, anche in germania. 




Personalmente non amo molto l'Agile



Conosci aziende del settore dove si usa scrum? Tipo, che so, vai con 3-4 

colleghi dal cliente e vi mettete a contrattare le ore uomo? 





scusa?


 scusa?



LOL :) 


 probabilmente anche di sistema (containerizzazione, ad esempio)



Ma certo. Io al momento coordino cinque team, tre di sviluppo (web app front-end, web app backend, customer APIs) uno di production support, uno di DevOps. Pretendere che tutti sappiano fare tutto e` stupido, ma all'interno dello stesso team e` importante avere T-shaped skills. Poi esistono sicuramente figure full-stack, in grado di muoversi fluidamente tra team.



...destinati ad essere usati da tappabuchi, sempre utili, mai indispensabili.


 ...destinati ad essere usati da tappabuchi, sempre utili, mai indispensabili.



Non ci hai capito niente, eh? 


 ...destinati ad essere usati da tappabuchi, sempre utili, mai indispensabili.



Ma quali tappabuchi, di cosa stai parlando? Ma perche` vi esprimete su cose che non conoscete? Avete mai lavorato seriamente in team? 





certo, mi riferisco alla tua affermazione "Poi esistono sicuramente figure full-stack, in grado di muoversi fluidamente tra team."


 certo, mi riferisco alla tua affermazione "Poi esistono sicuramente figure full-stack, in grado di muoversi fluidamente tra team."



Che secondo te implica "tappabuchi, sempre utili, mai indispensabili"? Sai che cos'e` uno sviluppatore Full Stack?





Ho una mia idea, ma ascolto volentieri la tua.

Scusami ma mi dai l'impressione di essere un po' aggressivo, come mai?


 Scusami ma mi dai l'impressione di essere un po' aggressivo, come mai?



Mi dai l'impressione di essere un po' provocatorio, come mai?


 Mi dai l'impressione di essere un po' provocatorio, come mai?



solo un'impressione.


 Non intendevo dire che uno sviluppatore full-stack sia un tappabuchi, ma che purtroppo nelle realtà che ho conosciuto c'è il forte rischio che questo avvenga, e che i colleghi "specializzati" gli passino avanti in carriera



Stiamo parlando di ruoli e modelli lavorativi evidentemente diversi. Io parlo di team che lavorano su un progetto con determinate deadlines, team magari formati da contractors che stanno li` 6-12 mesi e vanno via. Non parlo di chi scalda la sedia dietro una scrivania, aggrappandosi a conoscenze di dominio applicativo per costruirsi una torre d'avorio in cent'anni di permanenza in azienda; gente che ovviamente fa cosette di routine ed e` lontana mille anni luce dagli skill richiesti dal mercato. Molto spesso, almeno qui in UK, i team con sviluppatori Full Stack sono formati solo da sviluppatori Full Stack.



scusami avevo pensato si parlasse della triste realtà italiana, anche perché mi pareva ovvio che in uk la situazione fosse diversa


scusa?



il planning poker, o come si chiama. Non l'hai mai fatto? Fallo, e' 

divertente. Ti danno delle specie di carte con i numeri e in qualche modo si 

gioca a stimare il tempo per fare cose di cui probabilmente non si sa 

niente.

Divertente da fare in ufficio per passare il tempo, probabilmente un po' 

meno da fare in trasferta dal cliente (incazzato) mentre c'e' da risolvere 

il problema che sei appunto andato a risolvere.

Reitero: conosci aziende del settore che fanno queste stronzate qui? 





Mi sai spiegare il motivo per cui dovresti fare planning poker dal cliente (incazzato) mentre c'e' da risolvere il problema che sei appunto andato a risolvere? Chi dovrebbero essere i partecipanti di questa estimate session? Il cliente?

Ma poi, quando avete dimostrato di non sapere di che cazzo parlate, vincete un premio? Come funziona?



  ngw



Anche in Italia e' uguale, non e' che se conosci Javascript diventi un tappabuchi in automatico.



  ngw


Il cliente?



Esatto, e' proprio quello che vorrei capire. Non ho mai visto questa cosa e 

credo infatti sia assurda, sarebbe idiota proporre scrum in un contesto del 

genere, e' esattamente quanto sostengo dall'inizio prima che arrivarre 

un'epidemia di vene tappate.

Ma non solo, anche se fai attivita' di ricerca questi metodi non sono 

applicabili e questa ultima cosa l'ho vista personalmente. 





No scusa ti fermo subito, tu hai portato un esempio di utilizzo del planning poker non presente in nessuna letteratura sull'argomento e francamente anche ad occhio completamente inventato. Come evidente anche traducendo superficialmente il termine, il planning poker si fa quando si fa planning, il cliente non c'entra un cazzo, come la risoluzione di eventuali problemi - e' un'attivita' che costringe gli sviluppatori ad arrivare a estimates collettive e concordate esponendo i problemi di una determinata attivita'.

Il che rende privo di senso l'intero argomento: apparentemente stai prendendo situazioni random e aggiungendo alla fine "non posso proporre SCRUM in quel contesto", ignorando il fatto che SCRUM e' codificato piuttosto precisamente e quello che proponi non sta ne in cielo ne in terra. Il problema quindi in questo caso non e' SCRUM, ma la manciata di cromosomi in piu' che questo coglione che si e' messo a fare planning dal cliente ha. Curioso: 10 minuti fa avevamo tecnici superpagati che prendono interi progetti in mano e se li sfangano da soli e non dei poveri coglionazzi come il sottoscritto, ora un tizio che evidentemente non comprende quello che legge.



Le vene si chiudono quando prendete argomenti che ignorate dall'inizio alla fine e di cui molto probabilmente vi frega men di nulla e avete come al solito la pretesa prima di banalizzare e poi di uscirvene col canonico si stava meglio quando si stava peggio, ovviamente volendo venire presi sul serio. Questo thread e' un buon esempio, partito bene, ora stiamo facendo planning poker coi clienti, che non dovrebbero neppure sapere che e'.



  ngw


 scusami avevo pensato si parlasse della triste realtà italiana, anche perché mi pareva ovvio che in uk la situazione fosse diversa



Ovvio perche`? E` cosi` anche in Italia. "Full Stack" e` meramente legato agli skill tecnici. Quelle di cui parli tu, invece, sono persone che si specializzano in un campo di dominio applicativo e conservano strette le loro conoscenze. 




 Le vene si chiudono quando prendete argomenti che ignorate dall'inizio[...]



LOL :) Io ormai non gli rispondo neanche piu`. Rido e basta.




On Tuesday, 22 January 2019 15:43:17 UTC, Infradito  wrote:



[...]



Coglione e` quel che sei e lo dimostri ad ogni post che scrivi. Ti stai buttando un'altra bella palata di merda addosso, provando, come al solito, di non capire una mazza di niente. Dai, continua, prendo popcorn e coca cola.




coglionazzi come il sottoscritto



Stappati la vena e vivi tranquillo, nessuno ce l'ha con te. 




"4ndre4"  ha scritto nel messaggio 

news:7e18d355-bab9-47f5...@googlegroups.com...



Inutile che mi ballonzoli intorno, rimani coglione as usual. 




 Stappati la vena e vivi tranquillo, nessuno ce l'ha con te.



Ci mancherebbe, lavori con gente che va a fare planning dai clienti, difficile che i coglionazzi siano da questa parte dello schermo :)



  ngw


sostenuto dall'inizio - non sai di che parli.



Ah che non sia un esperto l'ho detto subito, cosi' come che mi riferisco a 

settori che conosco. Giusto per alleviarti la pressione sanguigna copincollo 

il mio primo intervento:



"Si. Non so quale (mi pare scrum, non sono un esperto), ma per fortuna 

abbiamo

smesso. Le resistenze che ho trovato, oltre alle mie, sono quelle del team

quando ha capito che nel nostro caso non funziona."



Magari riformulo, forse e' piu' comprensibile: "ci sono settori, tra cui 

alcuni che conosco personalmente, dove scrum non serve a un cazzo".









E' piu' che comprensibile, ti offro pero' un paio di spunti cosi', anche per il futuro.

E' molto evidente che dell'argomento sai pochissimo. Intendo dire, se tu ora mi dicessi che hai letto un singolo libro su Agile in generale mi faresti cadere dalla sedia. Il tuo livello di formazione a riguardo e' quindi prossimo al nulla, l'hai largamente dimostrato. Ora, possiamo fare il giochino del dualismo esperto - non esperto e buttarti nel calderone dei "non-esperti" in modo che ogni troiata sia giustificabile con le spallucce, ma credo entrambi qui sappiamo che ci sono numerose sfumature di grigio tra Martin Fowler e fare planning poker dai clienti.

Ora, anche togliendo le solite boutade sulle lavagnette e i cartoncini che infastidiscono ma lasciano molto il tempo che trovano che mica si puo' rispondere ad ogni cagata infantile del mondo, mi dai una singola ragione per cui io, che invece un po' l'argomento ho perso tempo a studiarlo, dovrei mettermi a discutere con te di un argomento che non conosci e che per qualche motivo hai deciso invece di conoscere, al punto da andare da gente che lo porta avanti professionalmente per lavoro a spiegargli che fare planning poker dai clienti non serve ad un cazzo? Non fai prima a comprarti un libro e scoprirlo da solo circa a pagina 13 che fare planning poker da un cliente non serve ad un cazzo?

Il messaggio che hai quotato e' allucinante, nemmeno sai il nome di quel che hai applicato, pensa che esperienza significativa e come e' stata portata avanti seriamente. Tra l'altro evidentemente totalmente prevenuti. Chiedi ai tuoi amici ricercatori che valenza scientifica puo' avere un esperimento su una cosa di cui nemmeno si sa il nome, portato avanti in modo evidentemente totalmente prevenuto, e con una conoscenza bassissima dell'argomento. Apparentemente avete davvero fatto 3 coglionate con cartoncini e lavagnette.

E te l'ho detto dal primo momento che stai solo facendo cagnara eh, e' che evidentemente non hai colto.



  ngw


 Inutile che mi ballonzoli intorno



Ballonzolare attorno a te? Ti guardo semmai dall'alto e rido. A giudicare dai post che scrivi qui dentro, l'etichetta di coglione te la stai meritando tutta. E hai ancora il coraggio di replicare.




poker da un cliente non serve ad un cazzo?



Mi interessasse, probabilmente lo farei. Io rispondevo all'op che chiedeva 

di esperienza fatte con agile e ho riportato la mia e cioe' che ho avuto 

modo di lavorare con scrum e, in alcuni settori che conosco, non serve a un 

emerito cazzo.

Magari puoi intervenire, dire che sto dicendo cacate, e spiegare all'op come 

si deve usare scrum in questi casi.

Altrimenti e' solo divertente incontinenza verbale di gente a cui sembra che 

gli offendi la mamma a parlare male di (quella cazzata di) scrum.




 Reitero: conosci aziende del settore che fanno queste stronzate qui?



decisamente no. non conosco nessuna azienda il planning poker dal cliente, magari

pure incazzato. secondo te consiste nel contrattare l'effort col cliente? 






 gli offendi la mamma a parlare male di (quella cazzata di) scrum.



E per fortuna che ci sei tu, con una solida esperienza basata sul planning poker con i clienti e un solido occhiometro.

Ora vado a chiedere al barista che ne pensa di Erlang, l'ho visto fare due caffe' contemporaneamente :D



  ngw


 ho avuto modo di lavorare con scrum



Falso. Tu non hai mai lavorato con Scrum. Se avessi lavorato con Scrum non scriveresti certe idiozie. Chiariamo: tra il non essere esperti di una certa materia e lo sparare totali puttanate su quella materia ce ne passa. E tu appartieni alla seconda categoria, non alla prima. Ti sei imbarcato in un'impresa piu` grande di te, voler dimostrare l'inutilita` di Scrum, e la cosa ti si e` rivoltata contro: non sai cos'e` Agile, non sai cos'e` Scrum, non ne hai mai compreso le idee e la loro applicazione, ma cio` non ti frena dallo scrivere stupidaggini su bigliettini colorati, lavagnette, giochini con carte da fare col cliente, microgestione, metodologie che sarebbero buone solo ad inesperti, ecc... Pure idiozie, come sempre. Hai la pretesa di sapere se Scrum serva o non serva in un certo settore sulla base di una totale ignoranza di Scrum. Ma veramente tu scrivi certe stronzate senza vergognarti neanche un po'? Scemo totale che non sei altro.


 non sai cos'e` Agile, non sai cos'e` Scrum



Ma possibile che le vostre argomentazioni finiscano sempre in questo modo ridicolo? Siete peggio dei Testimoni di Geova. A questo punto allora anche voi di Waterfall non ci avete mai capito un cazzo e non sapete come applicarlo. Specchio di riflesso



Avete un esempio pratico (che non sia un link ad un articolo Cicero Pro Domo Sua) di Agile applicato con successo ad un progetto embedded? Se c'è bene, abbiamo solo da imparare. Non è che uno abbia piacere a fare cose meno efficienti quando esistono strade migliori: il tempo è denaro.



Io purtroppo ho visto solo aziende che distrutte dall'introduzione di Agile/Scrum/Kanban/cazzi e mazzi (ad esempio Pietro Fiorentini) con sviluppatori che danno le dimissioni uno dopo l'altro. Dire che tutte queste aziende non hanno applicato correttamente le metodologie original certified eccetera eccetera contraddice il principio di falsificazione


Carissimi, voglio smentire pubblicamente questo messaggio che non ha purtroppo informazioni corrette. Sono Paolo Albanese e sono Team Leader nei sistemi informativi di Pietro Fiorentini, sono a capo di 20 persone tra cui gli sviluppatori e dal 2013 ad oggi non abbiamo avuto nemmeno una dimissione!!!! Utilizziamo Scrum da un paio d'anni in alcuni progetti specifici con ottimi risultati e stiamo man mano estendendo le metodologie Agili anche ad altri progetti in azienda!

I risultati dell'applicazione sono straordinari, sia per le persone che lavorano in Team che per i tempi di raggiungimento degli obiettivi di progetto.



 Io purtroppo ho visto solo aziende che distrutte dall'introduzione di Agile/Scrum/Kanban/cazzi e mazzi (ad esempio Pietro Fiorentini) con sviluppatori che danno le dimissioni uno dopo l'altro.



Ma non scrivere puttanate. Perdi meno tempo con le stronzate e vai a studiare, se veramente vuoi conoscere Agile o Scrum.



Che Waterfall sia una metodologia fallimentare rispetto ad Agile non e` questione di pratica personale. Viene dall'esperienza. Ho postato un link in questo thread con le percentuali. Vattele a leggere. Ultimo post da parte mia sul tema perche` la vostra stupidaggine ha veramente rotto il cazzo.


 I risultati dell'applicazione sono straordinari, sia per le persone che lavorano in Team che per i tempi di raggiungimento degli obiettivi di progetto.



Grazie Paolo e scusa se ti ho coinvolto, l'informazione in effetti puzzava di scemenza da molto lontano.

E' una risposta sufficiente? Che avreste scocciato un attimino. Come gia' detto, prima si studia, poi si parla. Dovreste averlo imparato alle elementari, ma magari serviva un ripasso.



  ngw


 progetto.



mi pare di aver sentito uno "sdeng!"



Capita quando si studia sui cessi degli autogrill piuttosto che sui libri.



  ngw


 certified eccetera eccetera contraddice il principio di falsificazione



guarda, io è un po' di anni che faccio questo mestiere e non ho solo visto

ma anche vissuto i botti fotonici che facevano i progetti ai tempi in cui

c'era "l'analista funzionale" che passava il tomo al programmatore, il

quale nella migliore delle ipotesi traduceva in una "analisi tecnica"

quando non si doveva mettere subito a buttar giù codice, dopodiché passava

l'eseguibile di nuovo a delle figure agnostiche che facevano i test

funzionali e il collaudo della funzionalità. erano i tempi cui ci si

riconosceva al 100% nella famosa vignetta dell'altalena.



non so da dove provenite ma davvero pensate che le metodologie agile siano

nate da qualche mente malata che non aveva niente di meglio da fare che

cambiare ciò che funzionava bene?



Ma va la, son troll. Evidentemente non sanno assolutamente un cazzo dell'argomento, sparan balle a tutto spiano - non solo tirando in mezzo un'azienda a casaccio, e questa volta è andata particolarmente male, ma figurati se qualcuno è andato a fare planning poker da un cliente - non hanno alcun genere di esperienza a riguardo, non hanno letto non dico il capitolo di un libro, ma un post su un blog sull'argomento, niente. E specialmente, non gliene fotte assolutamente nulla.

Vedono 4 pirla che discutono di un argomento di cui non sanno un cazzo pacificamente e gli viene la stupidite, se noti la tiritera è sempre la stessa, haha cosa nuova, caccaaaaaa. Python, Linux, il Cloud, Apple, html5, nosql, tutto.

Vengono a noia alla lunga, anche perchè a discutere con la portinaia di fisica quantistica non è facilissimo.



  ngw


 Ma va la, son troll. 



Magari! Almeno, i troll *fanno* gli stupidi. Loro lo sono per davvero. Quando interviene 'sta gentaglia, gli argomenti, qui dentro, fanno presto ad arrivare al paradossale; come quel tale che spara "Embe` e allora voi? Si vede che non ci avete capito niente di Waterfall!". 



Vedono la parola "Agile" e gli parte la ciavatta. Io gli sottoporrei un questionario senza nessun riferimento ad Agile, ma solo domande del tipo "Vorresti <metti qui un qualunque beneficio di Agile> nel tuo progetto?". Sicuro che risponderebbero di si`.



Chi e` che rinuncerebbe mai ad un progetto altamente flessibile, con release frequenti? A raccogliere un feedback continuo da un cliente? Chi e` che rinuncerebbe ad un QA continuo, integrato nello sviluppo, anziche` aspettare lunghe fasi di test a fine progetto? 



Peraltro, ci sono aziende che sono agili senza saperlo.  Ho lavorato in aziende dove il metodo di sviluppo ufficiale era Waterfall, ma le tecniche agili che si utilizzavano erano parecchie. C'era, per esempio, un Client Manager, che aveva l'abitudine di convocare il cliente in azienda, regolarmente, e mostrargli cosa si stava sviluppando. Ne raccoglieva il feedback e "raddrizzava" lo sviluppo. Era l'equivalente di una Sprint Review, ma nessuno dava un nome alla cosa.



Quando lavoravo con Waterfall, il tempo che spendevo in riunioni in cui si discutevano i requisiti, e il tempo che si impiegava nello scrivere montagne di documentazione tecnica che accompagnasse il progetto, era di gran lunga maggiore del tempo speso oggi nelle "cerimonie" Scrum. Arrivavi la mattina a lavoro e lo sviluppo lo dovevi fare lo stesso; il confronto coi colleghi lo dovevi avere ugualmente; il test di quel che finivi dovevi farlo; al capo dovevi comunque dar conto del progresso. Se qualcuno ha speso energie nel rendere intelligente ed efficace questo processo, perche` non dargli ascolto? 



No: lavagnette, bigliettini colorati, giochi di carte col cliente, baby sitter, etc...


Torna quando hai studiato



E niente, non si riesce a sapere come cazzo si usa sto coso, bisogna tornare 

quando si e' studiato.



L'ho detto prima, mi sembra di sentire quello che si diceva del comunismo: 

bellissimo, e' che nessuno ha capito come va applicato. 




Falso



No, vero. Lo abbiamo usato per un po' fino a quando ci siamo resi conto che 

non serve a un cazzo. 




pure incazzato. secondo te consiste nel contrattare l'effort col cliente?



No certo, intendevo tra i colleghi. Sei in trasferta con la tua squadra, 

emerge una necessita' dal cliente, c'e' da pianificare ed effettuare 

l'intervento: tiri fuori le carte per giocare coi colleghi?

E in alcune realta', non solo nel mondo industriale ma immagino in buona 

parte del mondo della consulenza, e' questo il modo normale di procedere: si 

lavora direttamente dal cliente. 




 bellissimo, e' che nessuno ha capito come va applicato.



Una variazione della reductio ad Hitlerum. Te capisci che nemmeno al bar vero? Dai su, it.*lavoro*.informatica. Salutami "la donna", a volte la vita non va come speri.



  ngw



No. Non sai cos'è o quando si fa il planning poker. O lo scopri, o parli da solo, non faccio baby sitting.

Per curiosità, come arrivi ad una stima? Occhiometro vero? Perchè ho come l'impressione che la tua profondissima obiezione riguardi la presenza delle carte, ma non ci voglio credere.



  ngw


 > 



Carissimo Paolo.

Io ovviamente parlo da ex dipendente. Perché non pubblichi la lista di quelli che se ne sono andati? Come mai siete sempre alla ricerca disperata di firmwaristi a Rosate?



Dai su, torna pure a fare una sessione di kaizen e metti bene in ordine i file sultuo desktop, altrimenti Nardi si mette a piangere




Pensa che destino crudele. Per fare questo lavoro []



Che lavoro, io parlavo di scrum.




carte, ma non ci voglio credere.



Non hai capito, riguarda la non pianificabilita' (di fondo) di determinate 

attivita'. Ma con la vena tappata e' ovvio che fai fatica a capire. 





Guarda, rispondo a te perché mi sembri l'unico con cui si possano avere interazioni proficue.

Sì, ritengo che le metodologie agili siano state utili in molti campi. No, ritengo che non siano utili nel mio, non mi lamenterei se funzionassero, anzi. Penso che sia giusto dire quando le cose non funzionano



Carissimo "Giuspi", facciamo che cominci a dire il tuo nome in modo da avere una discussione alla pari. La rispostaccia piccata che hai appena dato con tanto di gombloddo ad un messaggio più che normale di un dipendente con un profilo Linkedin facilmente riscontrabile (e che sei infatti andato a stalkerare) sarebbe più che sufficiente per intuire chi dice la verità e chi spara cazzate, ma magari ho torto e non sei un troll da 2 lire.

Per ora, complimenti per la figura di merda.



  ngw


 No, vero. Lo abbiamo usato per un po'



Nah. Non lo avete usato. Chi usa Scrum, conosce almeno le basi di Scrum. Il fatto che tu non abbia mai usato Scrum e non lo conosca si evince da quel che scrivi. 




 bellissimo, e' che nessuno ha capito come va applicato.



Veramente a non aver capito come va applicato Scrum siete tu e 4 altri gatti. Il resto del mondo lo ha capito. Chiediti il perche`.




 tiri fuori le carte per giocare coi colleghi?



Il planning poker e` un'attivita` seria, non un gioco. Lo si fa durante le sessioni di grooming/refinement, non dal cliente, in trasferta coi colleghi.

Ti e` stato gia` detto molte volte. Tu non hai capito cos'e` Scrum e non lo hai mai applicato. Lavorare direttamente dal cliente non significa quello che pensi tu. Se lavori alla cazzo, con cliente incazzati, e` un *tuo* problema. Il modo di normale di procedere, nel mondo Agile, e` pianificare il lavoro con l'aiuto del cliente ed eseguirlo per iterazioni, dando feedback continuo al cliente. E` una metodologia che ha provato, sul campo, di essere migliore di Waterfall.



Carissimo ngw



Nessuno spara cazzate. Sicuramente nessuno del suo team di Arcugnago ha dato le dimissioni e tutti sono contenti e felici e ottengono risultati "straordinari".

Parimenti la suddetta azienda ha problemi nel reparto firmware a Rosate, ed è esattamente questo che contestavo, che si vogliono applicare acriticamente metodologie che funzionano in un campo in un altro.

Sicuramente posso passare le mie referenze all'ex collega qualora interessato, di certo non le passo a un ngw qualsiasi




1) i firmwaristi non stanno assolutamente lavorando con metodologie Agili quindi dire che "gli sviluppatori" se ne vanno perchè applicano queste metodologie è un'assunzione che fai tu sulla base delle tue idee che non corrispondono a nessun fatto reale. Ci sono vari motivi per cui le persone in quell'area hanno un alto turnover, non le conosco nemmeno io, figuriamoci se le puoi conoscere o capire tu!!!

2) molto volentieri continuerò a fare settimane kaizen, 5S (chissà se conosci realmente cosa sono) e tutto quello che riguarda queste metodologie in azienda, ci credo molto e sono certo che fanno la differenza tra le aziende che sopravviveranno e quelle invece soccomberanno, in bocca al lupo per la tua azienda. E' sempre un problema di conoscenza e formazione, c'è chi parla sapendo di cosa parla e chi parla senza saperlo, in questi forum purtroppo troviamo molti di questi casi!

Saluti!



 attivita'. Ma con la vena tappata e' ovvio che fai fatica a capire.



Di nuovo, questo tentativo di portare avanti un attacco ad personam sono seriamente patetici. Non c'è nessuna vena tappata, ti stai rendendo largamente ridicolo, perchè dovrei essere arrabbiato? Qui hai preso un'attività atta ad avere stime più o meno precise e hai tentato di ridicolizzarla, dimostrando di non esserti neppure preso la briga di leggere la pagina wikipedia (
https://en.wikipedia.org/wiki/Planning_poker
), quando ti si è chiesto come porti tu a questo fantomatico cliente, lo stesso che tre secondi prima stava dando di matto per delle carte, delle stime sulle attività te ne sei uscito con "la non pianificabilità (di fondo) di determinate attività".

Dai su, vai a giocare coi soldatini.



  ngw


 Che lavoro, io parlavo di scrum.



Stai dicendo che la gestione e pianificazione del lavoro non rientra nel tuo lavoro? Spiegherebbe molte cose, a partire dal motivo per cui fate le cose a casaccio.



  ngw


Di nuovo, questo tentativo di portare avanti un attacco ad personam



Ma sei ossessionato! Stai serenissimo, manco so chi cazzo sei, figuriamoci 

cosa mi interessa di attaccarti ad persorotfl.

Scrum in alcuni ambiti non e' applicabile e te t'incazzi che qualcuno lo 

dice, beh peggio per te.




Lavorare direttamente dal cliente non significa quello che pensi tu.



Nel mio settore si. Parli a cazzo, as usual. 





il tuo mi sembra rancore di chi se n'è andato, a torto o a ragione, sbattendo la porta.



e qualora anche fosse che ci siano problemi, che la causa di questi problemi sia "che si 

vogliono applicare acriticamente metodologie che funzionano in un campo in un altro" è

chiaramente una tua opinione. non solo, ma dai la sensazione (sicuramente sbagliata,

ma tant'è) che tu fossi uno che remava contro queste metodologie.


 Scrum in alcuni ambiti non e' applicabile



Non lo sai. No lo hai mai applicato. Non lo conosci.


Parli a cazzo, as usual.



Io eh? Rileggi i tuoi post in questo thread ;)




 Carissimo "Giuspi", facciamo che cominci a dire il tuo nome in modo da avere una discussione alla pari.



Giuseppe Raffaele Arecchi. Immagino sia il tale che lavora da RTA. 




 acriticamente metodologie che funzionano in un campo in un altro.



Acriticamente? Chi cazzo ti ha messo in testa una roba del genere? Ti e` stata postata una valanga di link dai quali hai solo da imparare. Hai detto che volevi imparare, no? Vatteli a leggere, caro Giuseppe Raffaele.


[...]tu fossi uno che remava contro queste metodologie.



...d'altronde, uno sbarbatello che reputa gli ScrumMaster delle baby sitter.




 dice, beh peggio per te.



Ma io ti ho dato ragione in verità, evidentemente a forza di tagliare a casaccio te lo devi essere perso.

Nel momento in cui il livello di competenza è talmente basso da applicare una metodologia senza neppure essere in grado di citarne il nome, fare planning poker dal cliente dimostrando di non aver neppure letto l'articolo wikipedia a riguardo, e su ruchiesta non essere neppure in grado di illustrare come si fa planning, certamente nessuna metodologia è applicabile. Il problema però sta nel manico.

L'hai per altro confermato spiegando come lavorate: senza usare nessuna metodologia, a casaccio.

Era molto chiaro, mi spiace che hai frainteso.

Puoi evitare di tagliare tutto quello che ho scritto per aggiungere qualche stronzata da bimbominkia, buona giornata.



  ngw



Spero di no, che magari servirebbe aver gestito 3 persone nella vita per parlare con cotanta sicumera.



  ngw



Caro Andrea Laforgia, già letto il tuo link. Grazie, ritenta



Su questo ti dò ragione, probabile che sia prevenuto per passate negative esperienze


 Il problema però sta nel manico.



Da notare che la ciabatta non ha soltanto detto che Scrum non si applica al suo particolare contesto. Quella e` la piega svicolante che sta prendendo adesso.



Il 21/1 ha affermato che vale per "progetti semplici" e "persone inesperte", il 22/01 che e` per "due cessi che microgestisci coi bigliettini", il 23/1 ha scritto che "ci sono team che applicano l'ultimissima metodologia e hanno 25 persone a fare il lavoro di 3" (si riferiva a Google.. sic!), il 26/1 riassumeva Scrum come "Tipo, che so, vai con 3-4 colleghi dal cliente e vi mettete a contrattare le ore uomo?", il 30/1 ha scritto "bellissimo, e' che nessuno ha capito come va applicato.", ecc... ecc... ecc... 



Di cazzate ne ha scritte tante. Chiariamolo.


 Caro Andrea Laforgia, già letto il tuo link. Grazie, ritenta



Mi fa piacere che tu l'abbia letto. Io il mio nome e il mio link non lo nascondo mica, sai? Il mio nome lo leggi qui e il mio cognome e` nell'email.



Ritenta? Sei l'Arecchi che lavora per RTA si` o no? Hai scritto qui dentro di essere un fisico e quel profilo e` di un fisico; hai menzionato aziende che lavorano nel firmware, e quel profilo e` di uno che lavora nel firmware; hai menzionato la Fiorentini, azienda che offre prodotti e servizi in ambito industriale, e quel profilo e` di uno che lavora nell'automazione industriale. 



Ti vergogni?






 Su questo ti dò ragione, probabile che sia prevenuto per passate negative esperienze



Negative esperienze con cosa? Non hai mai usato Scrum.





Ho letto ho letto, è che ho da lavorare e non ho tempo di giocare a Cottolengo Cottolengo, altrimenti chiederei lumi su cos'è che hanno applicato e come, anche posto che non credo ad una parola di quel che dice.

Tra i due non si sa chi ne esce peggio.



  ngw


No, ritengo che non siano utili nel mio



Come lo sai? Non le hai mai applicate e ti ho postato valanghe di link che dimostrano il contrario.



Secondo te, alla Sogei usano Scrum o direttamente del Rum ?



-- 

The three most dangerous things in the world are a programmer with a 

soldering iron, a hardware type with a program patch and a user with an 

idea.



Direi di si, mi ha appena aggiunto su Linkedin.



  ngw


 Secondo te, alla Sogei usano Scrum o direttamente del Rum ?



Per me questi usano 
https://scummvm.org/




  ngw


 l'intervento: tiri fuori le carte per giocare coi colleghi?



no, ma molto probabilmente non tiro fuori neanche il planner, l'agenda, 

il foglio excel o qualsivoglia arnese alternativo per stimare l'effort. 

per la semplice ragione che non è il momento di farlo.


 Secondo te, alla Sogei usano Scrum o direttamente del Rum ?



Credo che facciano uso pesante di droghe.


il 30/1 ha scritto



E pensare che ti ho risposto forse due volte solo per darti del coglione. 

Con questa tre, coglione. 




Il tuo settore fa evidentemente cagare.



Rotfl, pensi di offendere "un settore"? Sei troppo un coglione. 




casaccio te lo devi essere perso.



A beh, allora di cosa stiamo parlando?




 Con questa tre, coglione.



Perche` sei un coglione (tu, tu sei un coglione) ed e` tutto cio` che sai fare, non avendo assolutamente nessun argomento con cui ribattere alle palesi imbecillita` su Agile che hai scritto qui dentro. Sei stato praticamente asfaltato e ad azionare il bulldozer sei stato tu stesso.




 Rotfl, pensi di offendere "un settore"?



Ma anche 'sti cazzi. Evidentemente lavori in un settore di merda (gia` che nomini clienti incazzati fa capire la qualita` del tuo lavoro) che pretendi di far assurgere alla norma per tutti. Accetta semplicemente il fatto che lavori alla cazzo di cane. Tra l'altro, se fai il tuo lavoro come scrivi qui dentro, non mi meraviglia che tu abbia clienti incazzati.




Perche`



Non era una domanda, coglione. 




casaccio.



Secondo te non applicare scrum significa fare le cose a casaccio? 




ti ho postato valanghe di link che dimostrano il contrario.



Ma tu sei un noto coglione la cui opinione non vale un cazzo. 




 CUT



Che succede? Non ti sarà mica venuto il dubbio di non esserne uscito da splendido come credevi, tra una battutina tardo-adolescenziale e l'altra? Riapri il thread con l'ennesimo CUT sporco e l'ennesimo finto fraintendimento? Hai spiegato come lavori giusto? Quello è lavorare a caso. Mica ti si deve tappare la vena se ti si fa notare l'ovvio.

Dai, stai bene, che al decimo post senza avere un cazzo da dire la cosa viene un po' a noia.



  ngw


 Non era una domanda, coglione.



Non sei proprio stanco di fare la figura dello scemo, eh? :)




 Secondo te non applicare scrum significa fare le cose a casaccio?



LOL :) No, lavorare come lavori tu, significa fare le cose a casaccio. Che poi questa condizione coincida col non usare Scrum, e` solo una coincidenza.




 Ma tu sei un noto coglione la cui opinione non vale un cazzo.



Yawn. Sbadiglio. Essere considerati dei coglioni da gentaglia come te, e` un onore. 




tappare la vena



Eh.