Is Software Evolution really Effective?

Per me il primo talk di Cirillo da cui ho tratto un valore culturale ben circoscritto ed identificabile. Il confronto fra modelli evolutivi mi ha proprio interessato.
Anche le sue slide sono improvvisamente migliorate rispetto al solito.
Certo, poi come al solito, come dice @PierG, c'è lo "spottone" iniziale (cit.) e manca la sintesi finale, ma secondo me molto meglio che in passato!

Vuoto di qualsiasi significato. Evidente la scorrelazione tra realtà e l'idea che Cirillo ha del mondo, sintomo di una mancanza quasi totale di esperienza sul campo.

Troppo autocelebrativo e purtroppo inconcludente. Ho lasciato la sala con "e quindi?". Inoltre non mi è chiaro l'assunto fatto secondo il quale comunque vada sarà un disastro (code monster)...

Disclaimer: ho seguito il talk in streaming e non dal vivo.
Concordo con Jacopo sul confronto dei modelli evolutivi, una cosa che in ambito universitario è veramente bistrattata e meriterebbe più attenzione. Ho imparato anche diversi tip sul design emergente.
Un punto minore e ortogonale è l'uso del linguaggio: "questo" e "quello" non aiutano a seguire il discorso: chiamare i concetti "evolutivo", "XP", "Agile", "Agile-bistrattato" semplifica la vita all'ascoltatore, per quanto imprecisi o inventati al momento questi termini possano essere.
Steve e Daniel giustamente fanno notare che manca la soluzione: senza una conclusione speranzosa l'Inspect-Adapt rimane solo Inspect e dall'esperienza dello speaker mi sarei aspettato qualche proposta per migliorare.

Per quanto mi riguarda, l'intervento più deludente della giornata. Da uno speaker di simile fama, mi attendevo decisamente di più. Principi pressochè universalmente ovvii e noti (IE il costo del miglioramento non ha andamento lineare) sono stati invece presentati come grandi spauracchi nel ciclo di vita del SW per le "nuove leve" (cui il talk era apparentemente dedicato), ma senza fornire spunti per il miglioramento. Da chi si propone come esperto, un cenno a possibili soluzioni per evitare ROI avversi me lo sarei quantomeno atteso. Per ricondurmi all'ottimo talk di Claudio Perrone, mi è sembrato che qui si sia puntato il dito contro qualcosa, ma senza cercare di fornire neppure uno spunto per il miglioramento. "What's the point in all this?" è stato il mio pensiero a fine presentazione. Mi è mancato il senso dell'intervento, insomma. Forse una sintesi finale, come sopra invocata dal sempre attento J. Romei avrebbe permesso di far emergere l'(eventuale) senso del discorso.

Tra l'altro personalmente reputo che neppure l'interruzione del talk in momenti salienti per il "DRIN" del pomodoro abbia aiutato a mantenere un focus nel discorso.

Una punto "extra" (nota sicuramente positiva dell'intervento) va allo speaker per aver fatto chiarezza sulla differenza nei processi evolutivi; cosa non sempre ovvia. E anzi, spesso confusa.

Bella la prima parte sulla distinzione tra i vari cicli di vita del software, così come l'analisi dei costi di team agili maturi, un risultato certamente controintuitivo.

Personalmente ho notato due mancanze:
1) non è stato chiarito come sono stati reperiti e in che modo sono stati analizzati i dati che hanno portato alle conclusioni. A mio avviso avrebbe dato più solidità alla tesi
2) come dice Steve, va bene dirla franca alle nuove leve, ma uno spunto per migliorare sarebbe stato gradito

Gente, vi do la mia personale interpretazione di questo intervento, senza pretendere di parlare per Francesco. Fatto: se proviamo a leggere un qualsiasi libro in tema Metodi Agili, si dà per assodato che usando i Metodi Agili si diventa più bravi.

La realtà dei fatti, che ho personalmente riscontrato nelle mie esperienze, è che spesso questo /non è vero/. Diversi team agili di mia conoscenza hanno fallito progetti, o comunque hanno conseguito una fama di essere troppo cari. Fama immeritata? Che importa! Se il risultato finale è che il cliente non ti sceglie più hai fallito. E poi è facile che la fama non sia poi così immeritata.

E' vero che molte pratiche agili producono un beneficio immediato; quel problema che facevi fatica a debuggare si risolve brillantemente con gli unit test, la comunicazione con il cliente migliora se andiamo a chiedergli che cosa pensa veramente, ecc. ecc. MA! Ci vuole molta, molta fatica per rendere questi benefici permanenti. E' sulla distanza che si vede la differenza.

Tanti che credono di programmare a oggetti scrivono invece codice procedurale, e la differenza sulla distanza si traduce in codice ingarbugliato. Tanti che hanno capito che non devono fare big design upfront, non hanno capito che devono però fare tanto design in maniera continua. E magari non sarebbero in grado di farlo neanche se volessero, il design upfront, né big né small. E poi ci vuole tanto coraggio per continuare a mantenere il contatto con il cliente nel lungo periodo.

Kent Beck ha detto "What does it mean to be agile? My definition is that you accept input from reality and you respond to it”. Allora facciamola per davvero questa follia di accettare l'input dalla realtà! Misuriamo quanto ci costa sviluppare. E' da qui che si vede se quello che facciamo funziona veramente.

E già che ci siamo, da quanto tempo non andiamo dal cliente a chiedergli "sei contento di come lavoriamo?"

(Solo 4 thumbs up perché sono d'accordo che i grafici presentati da Francesco sarebbero stati più interessanti se corredati da numeri.)

Peccato non accennare a qualche soluzione....

Concordo con l'idea generale che l'intervento sia stato un po' autoreferenziale. Io ho comunque apprezzato molto i grafici presentati (peccato non avere avuto metriche ed una minima analisi), soprattutto l'ultimo: quello in cui si vedeva la "voglia" di lavorare sul progetto man mano che passa il tempo.
Sarebbe stato molto interessante spenderci del tempo lì, capire perchè la voglia è calata: è finito il mojo iniziale? il progetto non aveva più valore per gli sviluppatori? Code monsters da qualche parte?

Francesco è sempre uno step avanti: molti agilisti, qualunque cosa questo voglia dire, dovrebbero, prima di abbracciare il cambiamento, affrontare la realtà. Francesco spesso ci fa sbattere su di essa.
PierG

Il talk mi è piaciuto molto e ha rimesso il focus su aspetti importanti che spesso si perdono di vista. Interessantissimo l'aspetto evolutivo del software.

Quello che non mi è piaciuto è stata l'esposizione, sembrava di stare ad una lezione universitaria, mi sarebbe piaciuto più un tono di confronto.

E.... quale sarebbe il problema delle lezioni universitarie? :-)

La sintesi finale è quella che dice Matteo: 1. misurare i costi e - come detto anche durante il talk - 2. evitare le illusioni

La slide conclusiva diceva: tu compreresti il tuo software?

Si può rispondere solo misurando quanto costa. Raccogli misure di costo? no? inizia a farlo.

E per evitare le illusioni bisogna sapere in quale ciclo di vita veramente ci si trova.

Per ridurre il ROI è importante non illudersi e accettare il ciclo di vita di appartenenza.

Non so cosa intendete per La Soluzione. Non esiste una soluzione buona per tutti. Esiste un problema che attraverso delle metriche sui costi, come ho mostrato, chiunque può far emergere. Ognuno troverà poi la sua strada per risolverlo. L'indicazione principale è non illudersi. Se esistesse una soluzione generale, sarebbe astratta, no?

I processi dipendono dalle persone, non viceversa.

Re: autoreferenziale. Beh si le metriche le abbiamo raccolte con la mia tecnica, nella mia azienda e con la mia campagna. La tecnica è gratuita, l'azienda è chiusa, la campagna è gratuita. Me ne devo fare una colpa? per lo meno ho fatto qualcosa nella vita :-) Sinceramente mi farebbe piacere più metriche reali nei talk.

Re: slide... beh sì come vedi jacopo ascolto il feedback :-)

Re: Lezioni. Sì era una lezione lo avevo detto all'inizio. Una lezione per gli studenti. Mi sembrava carino visto che l'evento si teneva nella loro università.

Ne conosco diversi proprio di quella università che si stanno avvicinando al mercato del lavoro e sono piuttosto confusi. E all'estero possono essere mandati via facilmente se non producono risultati. E se ci si illude troppo non si producono risultati.

Il messaggio più utile e appropriato volevo fosse: no illusioni e no soluzioni "facili". Non servono.

(Almeno avrete apprezzato il coraggio di presentare tesi diverse da quelle usualmente proposte in quelle aule, spero :-) )

Sicuramente un bel piatto di realtà adeguatamente cucinata e servita ;-) Il percorso risolutivo finale od anche la sola indicazione sul dove riporre l'attenzione, penso effettivamente fosse difficile da indicare, anche data la premessa della misurazione; così facendo però, forse si perde l'opportunità di creare stimoli positivi nella platea, o magari non se ne volevano proprio creare. Per quanto ho potuto seguire negli IAD precedenti, sicuramente una presentazione in linea con lo stile di Francesco, e forse ancora più cruda di altre cui ho assistito; mentre indirizzare il talk ad un pubblico in particolare (studenti, che se non ricordo male erano proprio pochini), credo non abbia un buon effetto in generale perché fa supporre agli interessati di subire una lezione ed agli esclusi di aver sbagliato talk, mentre a giudicare dalla folla l'aspettativa era alta. La bagarre finale in QA ha sicuramente dimostrato che il messaggio é arrivato chiaro e che non c'era un'intenzione di confrontare o confutare alcun contenuto esposto.

re: stimoli postivi per la platea...

per me lo stimolo da dare alla platea è far riflettere. Non dare la soluzione. (soprattutto quando la soluzione in sè è illusoria in quanto generica e astratta non potendo essere quella "soluzione" uguale per ognuno dei programmatori in sala)

Certe questioni sono cosi delicate che a volte occorre un percorso logico molto stringente per indurre a far riflettere.

La dedica agli studenti è una dimostrazione di affetto.

Ho molto rispetto per i programmatori. Io sono un programmatore da quando avevo 12 anni. E non suggerirei mai una soluzione di processo: fai cosi. Perché penso che 1. il programmatore abbia la capacità di trovare la Sua soluzione. 2. perchè so che sbaglierei e imporrei la mia soluzione ad un altro.

I processi dipendono dalle persone, no?

Eppure appare che sempre più programmatori agili chiedano ad altri le soluzioni ai propri problemi.

Per tutto questo, per me l'aspetto più importante è far emergere il problema nel modo più oggettivo e riconoscibile possibile. Impiego molto sforzo per far questo - a volte anni di metriche, a volte scelgo di lavorare in team che falliscono continuamente. Tutto per Individuare il problema, presentarlo e fermarmi lì per non generare inutili illusioni.

Talk Assoluamente inutile, autocelebrativo ed inconcludente. Francesco vive fuori dal mondo: pessimo! Lasciata la sala

Lezione non facile sicuramente, le slides aiutano poco e Cirillo ha un esuberanza e un indole alla provocazione che personalmente apprezzo ma capisco possano lasciare un pò basiti.
Rimane comunque utile se la si usa per foraggiare il pensiero critico sul proprio lavoro (processo, approccio, metodo).

Se posso azzardare un consiglio allo speaker cercherei più il dialogo che la battuta ma capisco che il tempo è tiranno ed il pubblico imprevedibile.

E basta con chi si lamenta che l' IAD non è un "soluzionificio", la soluzione la chieda a Fabry Fibra :-), qui si viene per "dar da mangiare al cervello".

Si ma sta storia dello studente è una balla a mio modo di vedere :D.La capacità di osservarsi non è uno studio? La capacità di misurare la propria produttività non è uno studio? Quando cerco di capire perchè davanti a un pezzo di codice scelgo di cambiare questo e non quello non è studiare? Quando cerco di capire perchè ho stimato X e ho realizzato in X + delta (quasi sempre delta > 0 :D), non è studiare? Mi sono accorto di una cosa scorrendo qualche tweets di Kent: ha una capacità enorme di auto-osservarsi quando codifica. Va avanti, esplora. Si ferma. Torna indietro. Non capisci (almeno io) perchè faccia cosi. Ma gli viene naturale. Ha sviluppato una capacità di pensare. E continua a farlo.
Francesco, apprezzo molto che tu abbia replicato :D

interessante ricevere un "vivi fuori dal mondo" da chi si firma Anonymous :-)

1) team agili costano più di quelli non agili e il risultato è misurato dalle esperienze dirette di Francesco.
Credo sia importante fermarsi su questo pensiero per un momento. Io domani chiederò un aumento come il normale corso delle cose. La qualità ha un costo, ma se costa troppo forse non è qualità. In medio stat virtus è un proverbio latino.

2) Dobbiamo sempre capire dove siamo e rimetterci in discussione e perché no analizzare bene quale è il nostro processo di sviluppo, mi ritrovo nelle slide di Francesco, con "parecchio" design upfront. Anche se non ho paura di cambiarlo, nei progetti solitamente piano piano il design diventa un zoccolo duro e ha un costo anche il solo pensarlo "flessibile al 100%".

3) Sicuramente trovo più da riflettere su questo talk che su altri, in particolare mi ritrovo spaesato su alcuni concetti come inseguire i principi solid è sbagliato se fatto a priori che poi il design migliore emergerà e quindi anche i buoni principi. Anche se trovo qualcosa di contorto in questa frase (che ammetto che è una mia personale sintesi), credo sia la definizione di design emergente a far uscire questi concetti. Lo stesso si può dire di refactoring, design pattern e grasp.

Mia conclusione:
C'è un qualcosa di contorto che spesso sento dal movimento agile.
O meglio io credo che noi programmatori dobbiamo lavorare per fare i soldi, e non per fare codice di qualità.

Produrre codice di qualità è il mezzo con cui lavoriamo, perché crediamo che favorisca il nostro lavoro e avere quindi un ROI migliore. Però non è la regola e non deve essere un vincolo del team, perché se il ROI peggiora stiamo sbagliando obiettivo.

Ho apprezzato molto la prima parte del talk (modelli evolutivi), era tutto molto chiaro e puntuale. Inoltre, le slide erano perfettamente in armonia con la lezione.

La seconda parte è stata deludente. Si è voluto utilizzare il risultato di una ricerca (l'andamento dei costi di un team di sviluppo) per rispondere alla domanda cardine sui costi, ma senza specificare come è stata eseguita tale ricerca e nessun riferimento per un eventuale approfondimento.

disclaimer: l'ho visto solo registrato.

bene: tought provoking topics
aggiungerei: chiarire la tesi, dare piu' evidenze a supporto della stessa
toglierei: affermazioni sarcastiche, empiriche

Tonino (@tonyzt)

Non l'ho seguita dal vivo ma in stream. In generale mi e' piaciuta, Francesco e' un oratore ottimo e il messaggio principale, quello che dice Matteo, e' sicuramente interessante.

Le cose che non mi sono piaciute sono fondamentalmente due:
1) I grafici dei team. Capisco che i dati siano privati ma la metodologia usata la raccolta e il trattamento dovrebbero essere pubblici. Quanti team? Come sono stati presi i valori? ecc. Altrimenti parliamo di evidenza aneddotica con tutti i suoi limiti.

2) Il discorso economico sul ROI e' impreciso e lascia adito a molte critiche. Per esempio: se avessi una startup io cercherei di aumentare gli introiti di 10 volte con un software che costa il doppio, piuttosto che limare un 20% dai costi.


Infine una piccola nota, mi pare di aver colto diverse "frecciatine" durante la presentazione a personaggi noti nel mondo agile. Personalmente le trovo dispersive perche' dopo continuo a domandarmi "ma avra' voluto riferisti al libro di tizio o all'ultima presentazione di caio?" e mi perdo il filo del discorso. Magari ad altri piacciono pero'.

p.s. l'anonimous "tonino" ero io (ed ho sbagliato a scrivere il twitter id, just in case)

re: Dati. Si tratta di dati sui progetti nostri e di nostri clienti. Quindi in ogni caso se è vero che "I processi dipendono dalle persone, no?" qualunque misurazione non può dimostrare nulla di realmente utile e decisivo per "chiunque" _a meno che_non_eseguiate_voi_quelle_misurazioni_sul_vostro_team_.

Principalmente per questo motivo, l'uso di trend è utile: si tratta di pattern reali riconoscibili a partire da Vostri dati.

I dati in sé sono semplici da raccogliere. Misurate i vostri costi per funzionalità. Noi lo facciamo con la Pomodoro Technique, sui team nostri e dei nostri clienti. Come mostrato ci possono essere tanti tipi diversi di forme, verificate la vostra: cercatene una spiegazione partendo dai vostri dati. Relativamente alla qualità interna: partire con un sondaggio sulla percezione della qualità soggettiva è un ottimo inizio. Lo si può correlare a metriche come McCabe o altre eventualmente più favorite.

In altri termini: provate e analizzate. I vostri dati sono rilevanti per il vostro cambiamento: "I processi dipendono dalle persone, no?"

Re: ROI: Non capisco perché sia impreciso. Relativamente alla mia affermazione sulle startup nel talk ho detto che quella è la Mia indicazione. Si tratta di una strategia imprenditoriale: Crescere senza riorganizzare i costi non sembra sostenibile. Questa la tesi. Per me a Berlino ora si tratta di dar vita a questa tesi. Ma da quello che ho visto operativamente in quelle poche startup dove sono stato il problema citato ostacola pesantemente lo sviluppo già dai primi mesi.

Re: "team agili costano più di quelli non agili e il risultato è misurato dalle esperienze dirette di Francesco."

Non è quello che ho misurato. Team Agili maturi hanno costi superiori relativamente a Team Agili meno maturi. Maturità = tempo lavoro insieme. Maturità non fa riferimento ad esperienza.

Re: frecciatine - Non so a cosa fai riferimento esattamente. In genere non faccio riferimento a italiani. Se mi fanno una domanda, rispondo con sincerità quello che penso.

ciao tonino, piacere di trovarti, ma almeno il viso è il tuo? :-)

Bene ragazzi, ringrazio tutti per i vostri commenti. Spero di aver dato informazioni utili come risposte. Mi ha fatto molto piacere partecipare a questo evento. Mi sono fatto una idea molto chiara della comunità agile italiana, come sta crescendo e seguendo quali dinamiche.

Se avete bisogno di informazioni particolari potete scrivere a [email protected]

A presto,

Francesco

Ho seguito solo i primi minuti dal vivo e rivisto ora il video on-line.

Tutto sommato discreto l'intervento di Francesco anche se l'avevo già seguito gli anni scorsi ed non ho trovato grosse novità a parte l'idea di riguardare meglio e con più attenzione alcuni principi base del metodo con cui lavoro oggi. Concordo in parte con chi ha commentato "e quindi?"
Forse avevo un'aspettativa troppo elevata per nuovi contenuti.

La verve e le capacità oratorie di Francesco sono sempre eccellenti.
Solo nella fase del "di qua"/"di là" l'esposizione è diventata un po' contorta da seguire:)

Una nota su piccoli dettagli di terminologia "Efficacia" ed "efficienza": efficacia non è legata allo sforzo.
Cut&Paste; da internet: "Efficacia ed efficienza sono due concetti molto noti nel mondo del lavoro. Classicamente parlando, per efficacia si intende la capacità di raggiungere un determinato obiettivo, mentre per efficienza la capacità di raggiungerlo con la minima allocazione possibile di risorse."

Uno spunto personale che non influisce sul giudizio: mi provoca un po' di mal di pancia quando vendo messa così tanta importanza sul ROI. È solo uno degli indicatori economici di un'azienda: ci sono molti altri indicatori, ci sono aziende con strategie più complesse e ci sono molti software nel mondo no-profit.
Fare software non è solo legato al mercato delle aziende che fanno soldi in maniera *diretta* dal software prodotto. Preferisco quando si usa il termine "valore" invece che "ricavi". Non ho avuto tempo di fermarmi a chiacchierare all'agileday ma magari alla prossima occasione approfondiamo :)

EDIT: Concordo con Uberto sull'evitare frecciatine invece che tentare di essere costruttivi.

Re: ROI. A prescindere dall'obiettivo lucrativo o meno, il ROI (proprio anche per l'aspetto di analisi dei costi) è rilevante per lo sviluppo di ogni attività produttiva/trasformativa. Oltre che l'analisi dei costi in sé, è quindi utile verificare che le proprie aspettative sul ROI siano verificate dalla realtà.

Re: Earnings. Il ROI è facilmente configurabile. Esistono tante variazioni della formula. Spesso dovute ad incapacità nell'assegnare i giusti costi o ricavi. Il ricavo in economia aziendale è valore della produzione. Quindi se non si "fatturasse" o se si preferisce un'altra definizione di valore la si può sostituire.

spero di aver risposto proprio a tutti. Ancora saluti a tutti.

Francesco

Re: Efficacia ed efficienza: quelle usate sono le definizioni usate tradizionalmente nei corsi di economia della produzione. Efficacia è legata allo sforzo ed efficienza al tempo. E' vero anche che esistono tante diverse definizioni legate ai diversi contesti. (come per altro per i termini evoluzione...). E tanti diversi significati dovuti alle varie lingue in cui queste parole vengono usate (lo stesso capita per metodo e metodologia, spesso confondibili cross language). Ad efficacia nella produzione viene anche associato il concetto di leva.

Quando ci sono termini con significati diversi in vari contesti o anche che cambiano nel tempo è opportuno chiarirne la definizione. Dalla slide del titolo ho provveduto a chiarire la definizione di efficacia ed efficienza e nel talk ho provveduto a fare lo stesso per evoluzione.

E' bello avere da Francesco lezioni di Project Management con solo trenta anni di ritardo! La fortuna per gli studenti di Rome Tre è che "Er Tomato" non sia abilitato a tenere lezioni universitarie.

Mi spiace che non esista la possibilità di dare ZERO come feedback a questo inutile talk.

Ai cari amici Anonymous:
perchè anzichè liquidare il talk con due frasi più o meno sulfuree (bah...) non provate a spiegare a Francesco e anche a noi che abbiamo seguito il talk cosa c'era di così inammissibile?
Mi pare che quantomeno sia da apprezzare la voglia di Francesco di esprimere un parere probabilmente abbastanza fuori dal coro. O no?
Per me, non esperto di ROI e affini, è stato un talk sicuramente interessante ed è stato impagabile osservare le facce di Matteo Vaccari durante lo scambio "vivace" di battute su SOLID agile o meno :D

Speaker carismatico e coinvolgente, è un piacere sentirlo parlare.
Però la sua sessione manca di conclusione, infatti qualcuno alla fine ha chiesto "e dunque?". Abbiamo ricevuto ottimi consigli che se applicati avrebbero evidenziato un problema di efficacia. Ma non è stata proposta nessuna soluzione/idea/supposizione su come far fronte a questo problema. Perciò se abbiamo un problema di efficacia... ce lo teniamo.