[MontelLUG] Agile_4_Ict Project Idea Methods

[Samuele]

On 26/03/2015 14:12, Diego wrote:
> Ciao, @ICT_EDUCATION 

Ma che è sta moda di mettere la @ ogni tre parole?

> Ho trovato in internet delle slides interessanti sul metodo,
> intitolate agile in 45 minuti che ne da una idea "agile" ;-) gioco di parole.
> http://www.slideshare.net/GiulioRoggero/agile-in-45-minuti-v3

Si tratta di varie metodologie per la gestione del carico di lavoro.
In base a chi scrive i libri sono valide. Nella pratica quotidiana
dipende. Io sono favorevole a tutti quei metodi di organizzazione che ti
permettono di migliorare la produttività e la qualità del lavoro.
Perché si riesca ad applicare queste metodologie bisogna che sia la
direzione che i programmatori conivolti credano nella validità e si
impegnino ad applicarle. Se anche una di queste parti non collabora, non
si va da nessuna parte.
Qualche anno fà, ad una delle cene, uno che lavora per una
multinazionale, diceva che ai neo assunti per un certo periodo facevano
fare pair programming. Secondo te, nelle normali aziende informatiche da
15-20 persone che ci sono nei dintorni, costantemente sotto organico,
una metodologia del genere sarebbe applicabile?
Tu la vedi una riunione quotidiana dove si pianifica il lavoro?
Forse una cosa del genere la puoi gestire in un ambiente dove hai un
gruppo di lavoro isolato dal mondo che non ha contatti con il cliente
esterno.

In un posto dove ho lavorato in precedenza, un capo progetto, si vantava
di aver imparato a programmare leggendo il manuale di programmazione di
una stampante, degli ex colleghi che facevano la gara a chi riusciva a
scrivere più istruzioni di un programma senza mai andare a capo, cicli
fatti con while (1) e poi una sfilza di if con break/continue, mentre la
maggioranza si orienta a programmare con OOP, gente che ragiona ancora
"a primitive" e procedure chilometriche. Come puoi ragionare con persone
del genere? Gente da prendere a mazzate in testa con l'armamentario di
Daneel.
Da un cliente che produceva macchinari, un giorno mentre ero li per
altre storie, sentivo i suoi dipendenti/programmatori PLC che parlavano
con ammirazione di quelli che riuscivano a scrivere le routine più
incasinate.

La matrice di Heisenhower imposta il lavoro in modo da evitare il più
possibile le cose urgenti, pianificando il lavoro per tempo.
In una giornata dovresti avere la possibilità di riservarti del tempo
per lo sviluppo dei progetti a medio/lungo periodo, per le emergenze e
l'assistenza ordinaria. Fintanto però che il cliente ti cambia le carte
in tavola ogni due per tre, che aggiunge richieste di funzionalità
all'ultimo minuto, e tu sei li che dovresti avere chiuso il tutto giorni
prima, si sveglia alle 17.30 con la cosa urgentissima per il giorno dopo
perché tanto c'è il mona di turno che è costretto a seguirlo, da questo
circolo non se ne esce.

Le metodologie agili, prevedono che prima di iniziare a scrivere il
codice si preparino le unit di test, ma anche qui, finché sono
classi/funzioni di libreria, che come input/output hanno
numeri/array/stringhe implementare un ambiente di test è relativamente
semplice, se hai a che fare con procedure che leggono e scrivono su
database devi implementare un ambiente di test con i controcaxxi, che
richiede parecchio tempo, specie per la verifica a posteriori della
correttezza dei risultati.

In definitiva, queste metodologie, offrono spunti interessanti su come
migliorarsi e strutturare meglio il lavoro, però risultano difficilmente
implementabili nella pratica.

Ah, ho tralasciato l'universale piaga vagante dei commerciali.