Uncovering better ways of developing software
Agile: B-Plan. Cosa fare se la strada è ostruita
Alberto Brandolini
Visualizzazioni: 17
- Allegati:
Risposte a questa discussione
-
Permalink Risposto da Alberto Brandolini su -
Ho postato un primo commento su uno spunto interessante emerso nella discussione di venerdì, sul mio blog.
http://ziobrando.blogspot.com/2008/11/alibi-of-creativity.html
e stamattina ho ricevuto i primi interessanti commenti. Non era mia intenzione trascinare la discussione "fuori" da qua, e soprattutto costringervi all'inglese... ;-) provo a "tenere i piedi in due staffe" (rispondo da ambo le parti), vediamo cosa succede.
Brando
-
Permalink Risposto da Cristiano Rastelli su -
Riporto anche io per completezza (e per gettare nuovamente il sasso nello stagno) ciò che ho scritto sul blog di Alberto. Il mio intervento è stato più che altro una provocazione (amo la tecnica del Pomodoro, è geniale in certi suo aspetti, anche se mi riesce difficile pensare di applicarla pedissequamente sempre e comunque) volta a sollevare un dubbio in tutti gli "agilisti" presenti: non vi pare che esista un rischio importante che è quello che le metodologie agili possano trasformarsi in veri e propri riti (lo stand-up meeting di fronte alla lavagna - slide #37 - della presentazione su "Retrospective, Standup e Journal" la dice lunga), se applicate indiscriminatamente? La discussione del panel di apertura, che ha portato alla conclusione implicita che "agile" e "dogmatico" stiano dalla stessa parte del segnale stradale, secondo me è un campanello d'allarme importante.
E l'allarme secondo me è che più si "confina" (time-boxing) e organizza e rende prevedibile e quantificabile e misurabile il lavoro delle persone (perchè è di questo che stiamo parlando: persone, non automi) più secondo me aumenta il rischio di lasciare fuori dalla porta qualcosa di importante, se non fondamentale. Ciò che rende appunto le persone diverse dalle macchine. Sto parlando di personalità, di creatività, di colpi di genio, di passione, di possibilità di sbagliare anche. Di persone che magari non vogliono fare lo stand-up meeting, la mattina, o che sono davvero degli "zorro" che lavorano benissimo da soli.
E voglio essere chiaro: non intendo che le metodologie agili non siano compatibili con l'umanità e la genilità che è in ognuno di noi, anzi. Solo che non dobbiamo mai dimenticare che sono metodi di lavoro, e il lavoro lo fanno gli uomini. Di lasciare dei margini (piccoli, va bene, ma devono esserci) perchè questi uomini possano esprimersi (leggasi: "programmare"). Magari in forme non necessariamente prevedibili, magari a volte anche con colpi di genio che costringono a "rompere il pomodoro" e proseguire per altri 10 minuti per seguire il filo del "guizzo", senza per questo sentirsi in colpa.
In estrema sintesi e semplificando all'estremo: occhio a non buttare il bambino (la creatività) con l'acqua sporca (l'imprevedibilità).
-
Permalink Risposto da Marco su -
Ciao,
riporto questo tuo frammento:
"La discussione del panel di apertura, che ha portato alla conclusione implicita che "agile" e "dogmatico" stiano dalla stessa parte del segnale stradale"
nel thread del panel :-)
-
Permalink Risposto da Alberto Brandolini su
-
un "pompiere" :-)
-
Permalink Risposto da Alberto Brandolini su
-
Ci sono gli Zorro, è di oggi la notizia che Batman sarà ucciso da Robin, e la gestione dei talenti fortemente individualisti è uno dei punti critici di molti processi. In RUP erano le stesse persone che non volevano fare la documentazione. In XP dovrebbero essere contenti ;-) ed invece ora odiano lavorare in coppia.
Scrum affronta il problema tra le righe in maniera abbastanza drastica. Il team che si auto-organizza ha anche un potere forte sui comportamenti all'interno del team. Qualcosa di analogo allo spogliatoio di una squadra di calcio, o di basket. Cassano è un fenomeno? bene, la Sampdoria è contenta. Cassano è un problema? Bene, la Roma ha vinto 13 partite di fila dopo averlo venduto al Ream Madrid.
Ogni team fa storia a se. A volte un talento basta ed avanza. A volte ti capita il supergruppo, e ti conviene "piegare" il processo alle esigenze dei singoli. Ma è il gruppo a deciderlo. E sul "come" deciderlo, l'approccio agile è abbastanza chiaro: si vede quale strada porta più risultati, in maniera "sperimentale".
L'altra questione è: d'accordo time-boxing, pomodoro, etc. Ma deve tutto essere pomodoro? No. All'interno di un'iterazione ci sono attività che sono esplorative, non direttamente legate al codice. Design, studio dell'interazione con l'utente, discussioni con il cliente per "capire meglio". E' bene che anche queste siano time-boxed (si svacca facilmente) ma non necessariamente a pomodoro, ma queste vanno affrontate con strumenti diversi. Qui c'è creatività e va gestita con quelle armi. Se il processo di sviluppo è solo stand-up and pomodoro-coding, c'è un problema...
-
Permalink Risposto da Alberto Brandolini su
-
...ovviamente nel frattempo avevo risposto anche con un nuovo post...
http://ziobrando.blogspot.com/2008/11/so-wheres-fun-part.html
perdonatemi :-(
-
Permalink Risposto da Alberto Brandolini su
-
Continuo a "sfruculiare" i punti lasciati in sospeso, o semplicemente accennati durante la discussione, continuando a tenere il piede in due staffe: sul blog
http://ziobrando.blogspot.com/2008/11/dark-side-of-self-organizing-...
in cui si parla dal "caso Cassano" e di come i self-organizing teams non siano necessariamente una cosa buona, nè (ma questo è abbastanza ovvio) facile da ottenere.
-
Permalink Risposto da Alberto Brandolini su
-
Altra questione spinosa emersa durante la discussione: "fare agile costa di più?"...
il mio commento sulla questione è qua:
http://ziobrando.blogspot.com/2008/12/does-agile-add-costs.html
la discussione al riguardo, dove volete :-)
© 2012 Creato da Marco.
