Leggendo il transcript della "Agile chat"...pensieri sulle metodologie agili e l'OOD

Leggendo l'interessante transcript della "Agile Chat" postata da Emanuele mi sono venuti in mente una serie di considerazioni che vorrei condividere con tutti, in modo da poter avere un feedback su queste idee che tra poco andrò a descrivere e che mi sembrano il "clou" della problematica.

Per chi non volesse leggersi tutto il transcript, basta sapere che un dei punti fondamentali affrontati nella chat è stato quello di "come far applicare le metodologie agili ai team e quindi farle capire ed apprezzare anche ai manager/boss/responsabili".

Leggendo il transcript mi è venuto in mente di partire dal presupposto contrario, e chiedermi perchè è tanto difficile introdurre tali metodologie. Se fossi un manager il mio timore sarebbe dovuto al fatto che la metodologia agile non mi da "sufficiente sicurezza" di poter portare a compimento un progetto entro tempi ragionevoli (notate che non sto dicendo entro i tempi prestabiliti, ma semplicemente ragionevoli, assumendo quindi che qualche rallettamento dovuto all'adozione di una nuova metodologia - diversa rispetto a quelle classiche - sia naturale).

Partendo da questo assunto, il problema quindi si sposta sulla necessità di poter "provare" in modo inconfutabile che tale metodologia sia quantomeno in grado di portare a compimento il progetto in suddetti tempi ragionevoli. In pratica dobbiamo dimostrare che funziona ed è applicabile.

Oggi come possiamo fare questo? Semplicemente portando al responsabile che mostra una certa diffidenza una certa quantità di progetti che tramite l'utilizzo di metodologie agili hanno avuto successo. Anche facendo questo però non sempre si riescie...perchè le metodologie agili, con il suo Refactoring, TDD e via dicendo danno una sensazione di "inconcludenza". Non di rado alcune persone mi hanno fatto osservare che secondo loro il refactoring è paragonabile a un continuo fare-e-disfare che non è produttivo. Capisco questo punto di vista: è piuttosto naturale; il fatto di "vedere" i propri sviluppatori continuare a fare "continue correzioni" dà sicuramente meno sicurezza al manager piuttosto che un progetto su carta dettagliato al millesimo. Certo poi magari il primo riescie ad essere portato a termine ed il secondo no, ma non è questo il punto. Noi lo sappiamo, il problema è farlo sapere a chi di dovere.

Posto che secondo me questa "inerzia sociale" dovuta al fatto che i responsabili di progetto attuali (o superiori) sono (mediamente) di qualche generazione più vecchi di noi avrà una sua naturale fine...il problema che se ne delinea, dal mio punto di vista, è che NON ESISTE UNO STRUMENTO FORMALE PER DIMOSTRARE CHE L'UTILIZZO DI OOD + METODOLOGIE AGILI SIA FUNZIONANTE! (Ok magari ho scoperto l'acqua calda...è da un pò che ci penso...oggi ho avuto il coraggio di scriverlo )

L'unico "strumento" che attualmente abbiamo sono le nostre od altrui esperienze, ma non possono purtroppo essere definite "formali", ossia dimostrabili inconfutabilmente, in modo rigoroso e ripetibile. Da qui la mia considerazione: fino a quando qualcuno (magari qualcuno di questo UG ) non riuscirà a creare un metodo formale (e quindi matematico / logico) che ci permetterà di dimostrare che il nostro progetto può funzionare sulla carta (relativamente alla modellazione OO della nostra necessità) e creerà una metodologia formale di applicazione delle regole che l'approcio agile definisce attualmente su quel progetto, non credo potremo mai risolvere il problema del dover convincere un responsabile che l'approcio agile sia quello corretto. A meno di non aspettare il ricambio generazionale completo del personale.

A questo punto chiedo: non sentite anche voi questa "mancanza"?

Print | posted on Wednesday, December 20, 2006 2:33 PM

Feedback

# Re: Leggendo il transcript della "Agile chat"...pensieri sulle metodologie agili e l'OOD

Left by Roberto Messora at 12/20/2006 3:24 PM
Gravatar Davide,
non vorrei sembrare troppo pessimista, ma credo sia una pia illusione.
Mio padre, che da anni fa il manager, da quando parla con me di lavoro (più o meno 15 anni) mi ripete in continuazione: le aziende sono fatte dalle persone che ci lavorano.
Questo semplicemente dice una cosa: un metodo formale/logico, qualunque esso sia non è affatto detto che produca gli stessi risultati applicato a realtà diverse.
Io sono convinto che esistano tranquillamente aziende che non utilizzando metodologie agili riescano cmq ad avere successo, ed esisteranno quasi certamente aziende che abbraciando una metodologia agile cmq avrenno grosse difficoltà a portare a compimento i propri progetti.
una metodologia ed un'azienda, qualcune esse siano, hanno necessità di relazionarsi tramite un "catalizzatore", questo non può altro che essere la qualità "umana" a disposizione. Questa non credo sia logica, tantomeno formale.
credo la sensibilità di un capo/manager, quindi la sua qualità come responsabile di un team, si possa misurare anche nella saggezza e nella disponibilità ad ascoltare i bisogni del proprio team e le esperienze altrui, cosa che dovrebbe portare naturalmente e senza la necessità di fornire per forza un "vangelo" metodologico, alla sperimentazione di un modo di lavorare anche diverso.
di fronte ad un cattivio manager non credo che un tool come quello che suggerisci, avrebbe un esito molto diverso dal nulla di fatto comunque.
saluti

# re: Leggendo il transcript della "Agile chat"...pensieri sulle metodologie agili e l'OOD

Left by Lawrence Oluyede at 12/20/2006 6:42 PM
Gravatar Risposta breve: se esistesse un metodo formale per dimostrare che l'Agile funzioni non sarebbe più Agile.

# re: Leggendo il transcript della "Agile chat"...pensieri sulle metodologie agili e l'OOD

Left by Davide Mauri at 12/20/2006 7:43 PM
Gravatar @Roberto
Hai ragione. Sono le persone che fanno la differenza. Purtroppo però oggi c'è troppa discrepanza tra il "cattivo" manager ed il buon manager (informaticamente parlando). Se fosse possibile almeno partire da una base comune anche il "cattivo" manager non potrebbe cmq fare un lavoro troppo cattivo; il buon manager, invece, potrebbe fare un lavoro anche migliore di quello che sta gia facendo, in quanto aiutato dagli strumenti giusti. Un esempio lo si può apprezzare con qualsiasi progetto di qualsiasi altra disciplina scientifica (anche se mi è BEN CHIARO che l'informatica non è una scienza esatta): per progettare qualsiasi cosa si parte da un insieme di conoscenze e metodo (formali) comuni, ma non per questo le persone non fanno la differenza.

@Lawrence
Non sono daccordo Il fatto che la disciplina Agile sia tale non implica che non possa avere un metodo formale attraverso la quale venga implementata. Il concetto del "Formale" non è equivalente a "monolitico" e "poco propenso al cambiamento"

# re: TDD e lo sviluppo per approssimazioni successive

Left by Blog...(n)ando! at 1/2/2007 4:35 PM
Gravatar

# TDD e lo sviluppo per approssimazioni successive...feedback

Left by Blog...(n)ando! at 1/4/2007 10:10 AM
Gravatar
Comments have been closed on this topic.

Copyright © Davide Mauri

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski