Intense Minimalism

"the user will never know what they want until after the system is in production"

quanta saggezza....

queste 4 leggi alla fine si possono ridurre nella pratiche di LEAN: release fast, release often. ;)

in quanto ottieni come contrapposizione a quelle 4 leggi:

1. ridotto delta di errore nella comprensione di specifiche altrimenti mastodontiche (e quindi ridotto costo per tornare in carreggiata)
2. l'utente capisce subito cosa farà il sistema, e come lo farà. pezzettino per pezzettino
3. tanti piccoli step sono meno "interattivi" e quindi più facilmente testabili
4. evoluzione controllata (niente mostri con 2 teste ;P )

cmq interessante la presentazione... soprattutto nella seconda parte.. ha alcuni punti di contatto con quella che avevo fatto io al uxcamp sul fatto che agile viene spesso usato come un mini waterfall da agilisti niubbi...

ps http://en.wikipedia.org/wiki/Zipf%27s_law

@fullo
Io come vedi sto per ora raccogliendo spunti intanto che apprendo su Agile e le varie metodologie (XP, Scrum, etc). ;)

Altro che agilisti niubbi e waterfall: ora agile inizia ad essere in hype sulla bocca di tutte le grosse aziende... ma ce ne fosse uno che lo applica davvero. :/

Mi piace come hai sintetizzato la "soluzione" nella singola pratica Lean. Nice. :)

come dici tu ci sono quelli che effettivamente si prendono il bollino da scum master, lord agile, o roba simile perchè fa cool... questo perchè:

"nonostante quello che viene giurato e spergiurato IMHO le pratiche agili non possono essere applicate da tutti ed in tutti i contesti. E quindi chi ne è escluso si prende il bollino"

per dimostrare il "tutti" bisogna pensare che per usare le pratiche agili c'è bisogno di alta competenza (nella programmazione, nella gestione, nei rapporti umani) e di metodo nel lavoro. E non tutti i team/aziende possono(=vogliono?) permetterseli.

Ad esempio:
rapporti umani vs competenze:
il developer-hero (== guitar hero per il codice) difficilmente si integrerà in un team di sviluppo, anche se ha competenze tecniche da paura.

gestione vs competenze:
Inoltre è spesso gente che punta a rifattorizzare il codice alla nausea senza considerare che l'iterazione è finita da una settimana... poi ci sono quelli che puntano a dire in 10gg raggiunto il risultato X. E lo fanno. Ma come? Con software scritto tendenzialmente con i piedi perchè "tanto devo rilasciare e poi rifattorizzero'.. " e poi la rifattorizzazione non avviene mai perchè non c'è tempo. Ergo ci vuole un PM o un responsabile che dica come e quando smettere e che pianti le basi di una architettura abbastanza flessibile perchè poi possa essere usata in un processo lean come quelli XP.. ma è poco "agile" perchè cmq un pochetto di roba va studiata a priori...

rapporti umani vs gestione: in quanto secondo i principi dell'agile vige la democrazia, tutti hanno diritto di parola e di esprimere la propria opinione e non esiste un PM. MA se si "ascoltano" i pareri di tutti (e quindi anche di chi non ha alto skill o competenza nel dominio di applicazione) si rischia di finire a scrivere "bel codice assolutamente inutile" senza contare la perdita di tempo (e soldi).

inoltre non sempre è possibile fare pair, non sempre il TDD o l'XP da valore al tuo lavoro (pensa solo a siti civetta che servono solo per campagne pubblicitarie di 5gg).

E come fai ad ingabbiare in un timebox come il metodo del pomodoro un creativo che deve scrivere una nuova campagna commerciale? se non hai l'ispirazione non la scrivi.. anche se quel coso continua a marcare il tempo rimanente al tuo (futuro) insuccesso...

cmq io parlo da pragmatico, se c'è qualche agilista puro ci vediamo fuori e ne discutiamo meglio.

Mi piacerebbe parlare - o vedere una discussione - di te come pragmatico e di un agilista puro, credo verrebbero fuori molti punti interessanti e criticità.

Io alla teoria ci sono... è all'applicazione pratica che ancora manco. Infatti pensavo di farmi un qualche workshop di XP giusto per capire un po'... e valutare. :)

Per i punti che sollevi sono molto precisi... credo non ci sia nulla da aggiungere. Se non che dal mio punto di vista sarebbe bello capire in casi concreti come quelli che dici come gestiresti le cose. Magari ci sarà occasione :D

Con Fullo sono d'accordo su molte cose, tanto più che sono "solo" (virgolette modestatis) derivazioni di buon senso.

Aggiungo anzi che la figura dello Scrum Manager è prevista nell'applicazione Scrum più ortodossa, poiché descritta nel libro di Schwaber e quindi possiamo tranquillamente stabilire che Fullo potrebbe essere agile quanto cova nei suoi più reconditi desideri senza per questo cadere nell'eresia (...).

Trovo solo un filo contraddittorio l'appello all'approccio 'lean'.
Il Toyota Production System - che si deve conoscere bene prima di poter fare considerazioni sul 'lean management', e sono convinto che Fullo lo conosce sicuramente molto bene - è un compendio molto ricco di principi (non pratiche, ma principi) che va ben oltre il solo release early, release often. Uno dei passaggi tipici verso la produzione lean è la rimozione del personale superfluo e persino dei *movimenti* superflui. Da questo emerge - come effetto derivato - la pratica Toyota di trasferire la competenza di management verso il personale di catena di montaggio e non verso i manager. Come? Facendo fare a tutti gli operai un master in management? No, ma strutturando un processo a) efficace (prima che efficiente) b) autocorrettivo. Con un processo che corrisponda a queste caratteristiche è possibile fare a meno di (tutti quei) manager.

Questo è lean.

Lean software development quindi non è il *divieto* di avere manager da una parte, ma anche la consapevolezza che un team adeguato *sa* fare a meno dei manager con *maggiore* produttività, non *pari* produttività.

Sull'ormai liso dilemma agilista vs. pragmatico... potrei partire col pistolotto sulla multidimensionalià di certi valori (probabilmente agilità e pragmatismo sono ortogonali fra loro e non sono opponibili in un semplice "vs."), ma mi limiterò a commentare in modo assolutamente trascendente: io sono io. Chi mi paga fa più soldi di quanto gli costo? Sì? Allora va bene così.

A questa sola domanda bisogna saper rispondere.

Io sono un po' indietro anche sulla teoria, mi sa... però il workshop XP sarebbe una cosa interessante.
Ormai ho sentito parlare parecchio di agilità, ma credo che non capirò davvero di che si tratta finché non lo proverò direttamente ;)

"Uno dei passaggi tipici verso la produzione lean è la rimozione del personale superfluo e persino dei *movimenti* superflui."

Di fatto, è quindi un processo di "sola" (:P) semplificazione ed efficienza, no?
(si, anche autocorrezione, cosa che mi sfugge ma che è assolutamente fondamentale, devo imparare ad esplicitarla meglio).

La domanda con cui chiudi cmq è *estremamente* pragmatica... ;)

@jacopo come giustamente dici LEAN !== Agile infatti il mio caso:

Ergo ci vuole un PM o un responsabile che dica come e quando smettere e che pianti le basi di una architettura abbastanza flessibile perchè poi possa essere usata in un processo lean come quelli XP.. ma è poco "agile" perchè cmq un pochetto di roba va studiata a priori...

è stato scelto perchè basato sui presupposti dell'esempio "gestione vs competenze" (o dovrebbe.. questo se il mio autismo non ha aiutato).

In sostanza se i tuoi sviluppatori compiono "movimenti superflui o inefficienti" tu (PM) li aiuti a smettere e li reincanali nelle buone pratiche , su cui poi puoi reiterare, migliorare, ridurre, eliminare sprechi e sviluppatori (fisicamente).

@folletto

Mi piacerebbe parlare - o vedere una discussione - di te come pragmatico e di un agilista puro, credo verrebbero fuori molti punti interessanti e criticità.

passa un giorno in ideato durante i battibecchi CEO vs CTO ;)

ps
una buona lettura grazie a google books Lean Software Development

ps 2
in Ideato stiamo valutando di organizzare (con il buon Jacopo) un workshop su XP e PHP entro la fine dell'anno.. ti tengo aggiornato ;)

@folletto No, non di sola semplificazione. I principi lean da http://en.wikipedia.org/wiki/Lean_software_development :
* 2.1 Eliminate waste
* 2.2 Amplify learning
* 2.3 Decide as late as possible
* 2.4 Deliver as fast as possible
* 2.5 Empower the team
* 2.6 Build integrity in
* 2.7 See the whole
Occhio che Lean Software Development -> 100% agile.
Chiudo con una domanda estremamente pragmatica a dimostrarti come agile/pragmatico non sia una dicotomia legittima. ;-P

@fullo La persona che "li aiuti a smettere e li reincanali nelle buone pratiche" si chiama coach. E anche lui è perfettamente agile-compliant. Ne conosci già uno ;)

Una precisazione.

Ogni tanto uso lean nella accezione forzata (ma validissima nel mio cervello) di "insieme delle metodologie leggere". Non chiedetemi il perchè... deformazione mia. :)

Intense Minimalism. Questo blog è dichiaratamente lean. :-)

Riguardo al Lean la 2.3 è la mia preferita tant'è che oltre 2-3 anni fa prima della bolla agile avevo creato ed aderito al PUP. ;P

scherzi a parte Lean !== Agile

Lean is all about eliminated non value added steps in processes. Agile is about processes that adapt quickly to change. The two, IMHO, can be applied together, but are not necessarily one in the same. I can have a lean process that responds poorly to change, and I can have a process that supports change but is wasteful.
via http://pioneerit.blogspot.com/2006/08/lean-vs-agile.html

[troll]@jacopo: coach, pm, dev leader. tanti nomi un'unica mansione. ;P[/troll]

@fullo:
Hehehe sarebbe interessante assistere ad un battibecco perché mi sa che il livello sarebbe altino. :D

Si thx, tienimi informato. Credo di avere oltre a me almeno altre 2-5 persone interessate. Non so se verranno, ma io propago. :)

@jacopo:
Credo di essere d'accordo sul fatto che non sia una dicotomia, ma non mi addentro perché non ho sufficiente esperienza. :)

Sui punti Lean li avevo letti, ma la mia tendenza sintetico-minimalista mi porta a sintetizzare in pochi elementi chiave. Questa è invece deformazione mia. :P

Per dire: 2.1, 2.2, 2.3, 2.4, 2.7 sono incidentalmente o direttamente impliciti nel processo di semplificazione, mentre 2.5, 2.6 nel processo di autocorrezione. Ma sì, è chiaro che 1/ esagero e 2/ parlo da uno che ha solo una cognizione teorica dell'argomento (almeno per ora). Però son ragionamenti che tramite la loro validazine o invalidazione mi aiutano ad apprendere. :)

È interessante notare come l'autore del post parta dal titolo del libro scritto da chi ha inventato il Lean Software Development (LSD!) contestando la scelta (dell'autore!) di includere nel titolo la parola agile.

L'autorità è sempre un valore sdrucciolevole.

@folletto so che ti era piaciuto il talk di Cirillo al Better Software 2009. Lui è er più XP di tutti. Il suo talk era stra-Lean. Tanto per abbassarmi al principio di autorità anche io... ;)

Concludo il mio versante di questa serie di interventi con la morale, secondo me.

Tutti i principi del LSD sono inclusi fra i principi del manifesto agile. Questo fatto basti ad essere preso in considerazione da ogni persona interessata all'argomento per trarre conclusioni magari poco definibili, ma non per questo non ovvie.

Tanto alla fine l'obiettivo è solo la produttività. E tutti questi sono meri mezzi.

True, talk molto bello! Ci ho parlato anche un attimo dopo per chiarirmi alcune cose e ho avuto l'impressione che lui stia seguendo - giustamente - la strada dal mezzo al concetto - o idea, in senso più Platonico - non so se era così anche prima, magari è sempre stato così ovviamente (e quindi la mia impressione sarebbe sbagliata, certo).

Io al momento però devo prima passare per i mezzi, perché il mio presupposto è l'idea. Credo che sia dovuto al fatto di essere una persona prima sintetica. E' come dire che io parto dai presupposti del talk e arrivo agli strumenti: ma ora ho bisogno degli strumenti. Ho bisogno di vedere le casistiche reali da gente che le vive, che le ha vissute o viverle io stesso. :)

Non ricordo il nome esatto - e questo inficia già la spiegazione - ma c'era un saggio Cinese, filosofo diciamo, che non spiegava mai la morale e le idee tramite spiegazioni dell'idea. Spiegava prima il caso concreto e poi faceva ragionare la persona su di esso perché essa stessa capisse il vero significato dell'idea. Perché, diceva, se la spiegassi soltanto perderebbe tutte le sfumature e le profonde implicazioni che invece un caso reale possiede. (Note to self: devo andare a recuperare questo passaggio).

Questo per dire che io, ora, ho bisogno di vivere un po' di casi concreti. Infatti sto cercando di applicare un po' di "tecniche" in modo da vedere se funzionano o se falliscono... e imparare su di esse il vero significato dei concetti Lean, Agile, etc. :)

La costruzione bottom-up della conoscenza è la più lenta ma la più solida. Un esempio su tutti: la madrelingua.

La filosofia orientale è tutta bottom-up, il filosofo cui fai riferimento potrebbe concretizzarsi in più nomi. Ne parleremo presto, spero. Anche di pratiche agili. ;)
Ciao!

Recenti

Scritti

Trova

Idee libere

Chi sono?

Le quattro leggi Agile di Scrum

17 comments Add yours below

Luglio7 2009 05 07 at 15:42

fullo 2009 06 08 at 11:40

Folletto Malefico 2009 06 09 at 15:19

fullo 2009 06 11 at 13:23

Folletto Malefico 2009 06 11 at 14:45

Jacopo Romei 2009 06 11 at 15:24

Simbul 2009 06 11 at 16:48

Folletto Malefico 2009 06 11 at 16:49

fullo 2009 06 11 at 18:05

Jacopo Romei 2009 06 11 at 18:20

fullo 2009 06 11 at 18:22

Jacopo Romei 2009 06 11 at 18:22

fullo 2009 06 11 at 18:35

Folletto Malefico 2009 06 11 at 18:50

Jacopo Romei 2009 06 12 at 10:46

Folletto Malefico 2009 06 12 at 11:28

Jacopo Romei 2009 06 14 at 20:00

Leave your Comment

Colophon

Footsteps

Recent Posts