Manca una cultura dello sviluppo, la stragrande maggioranza delle piccole aziende che facciano software, o che abbiano un dipartimento di sviluppo, di fatto non utilizza nessuna metodologia, approcciando il processo di produzione del software come fossero piccoli artigiani.
DISCLAIMER: non c'è nulla di sbagliato nell'approccio artigianale, il fatto è che gli artigiani bravi sono pochi: i falegnami che sanno costruire uno splendido comò partendo da semplici assi di rovere sono pochi, e quei pochi impiegano tanto tempo, e si fanno pagare molto.
I programmatori assunti dalla piccola impresa italiana non assomigliano a questi pochi eletti artigiani del legno. Generalmente hanno vincoli di tempo ristretti, sono sottopagati e spesso il loro lavoro non viene apprezzato dai responsabili non-tecnici (quando invece quasi tutti sanno giudicare un comodino ben costruito).
L'artigianato del software assomiglia più alla totale deresponsabilizzazione dei project-manager, project-leader e generici project-something: assumi dei neolaureati, pagali un po' meno della media di mercato, dai loro un compito definito fumosamente, dai dei tempi basati sulle tue impressioni e al termine verifica che lo staff non ha capito cosa doveva fare, i tempi si sono decuplicati, i programmatori si odiano tra loro e odiano i project-something.
Bene, se questa è la situazione nella vostra azienda è meglio chiarire subito e brutalmente una cosa: non siete in grado di mettere su neanche una cassetta per la frutta, altro che comodino in rovere.
Dovete ricorrere a delle metodologie.
I project-something a questo punto ripescheranno nella memoria le paroline magiche che illustrano la strada vincente: metodologie agili, che negli cervelli dei diversi attori si traducono in:
[manager capo]: azienda all'avanguardia, siamo forti!
[project-something]: lavoro fatto bene, meno lavoro per me, più lavoro per lo staff.
[programmatore]: nessun vincolo, nessuna metodologia.
| Le metodologie agili funzionano se il team di sviluppo conosce e usa già una metodologia (non agile), altrimenti è molto probabile che un processo agile venga preso come "nessun processo" e si consegni l'intero sviluppo all'anarchia. |
Esiste poi quella categoria di fini artigiani che quando il chief parla in maniera molto nebulosa di un nuovo progetto, loro vedono già il bellissimo comò nella loro testa. Iniziano a pensare ai materiali più pregiati da impiegare ed alle tecniche più raffinate che la loro esperienza gli mette a disposizione. Alla fine di tutto questo si accorgono che la ditta gli permette di poter costruire solo una cassetta della frutta, fatta di compensato e consegnarla per ieri.
RispondiEliminaPurtroppo la situazione delineata da te non è solo nelle piccole ditte, ma anche in grandi realtà dove l’italian style imperversa, dove la conoscenza acquisita è gelosamente custodita da quei pochi che si credono indispensabili solo perché c’è qualcuno di ancora più “piccolo” sopra di loro.
La situazione del professionismo in Italia è in una condizione disastrosa e nessuno è più in grado di riconoscerlo o apprezzarlo. Un esempio musicale? Solo in una società impregnata di estrema ignoranza come quella italiana una persona che ha fatto fino ad ieri la cassiera in un supermercato, oggi si mette a cantare e senza avere la minima capacità o competenza vende centinaia di migliaia di dischi, mentre chi ha dedicato una vita alla musica e ha studiato per anni ed anni in accademia, non riesce neppure a pubblicare un disco. Questo mi fa riflettere e mi rattrista molto…
Luca Ciciriello
Sempre a proposito delle metodologie agili, questo avrei voluto scriverlo come post sul mio blog, ma GLDM qui mi dà l'occasione per parlare di come l'ottusità e la ristrettezza di visione di certi responsabili di progetto possa far naufragare iniziative ed idee che avrebbero potuto accrescere il prestigio della ditta stessa. Venerdì scorso, parlando con un mio collega di determinati sistemi di test, mi è tornato in mente un episodio successo qualche anno fa nell'azienda in cui presto servizio per conto della ditta di consulenza per la quale lavoro. Bene, allora mi era stato affidato il compito di progettare un sistema per testare la validità di alcuni algoritmi matematici implementati in C++. Di questi algoritmi si conosceva l'input, ma non si aveva nessun modo di sapere se l'output prodotto sarebbe stato esatto, inquanto non si disponeva di valori di riferimento con cui confrontare i valori prodotti. Quindi il compito che mi aspettava era decisamente complesso, perche avrei dovuto testare la validità degli algoritmi basandomi solamente sull'analisi matematica degli algoritmi stessi. Ovviamente il la difficoltà del compito affidatomi è stata enormemente sottovalutata sia dal mio responsabile d'ufficio, sia dal sistema di controllo qualità di questa grande azienda in cui presto servizio. Dopo qualche giorno per studiare il problema ho individuato l'unica via che mi avrebbe consentito di attaccare il problema in maniera soddisfacente. La mia idea era quella di seguire una metodologia già in uso da qualche tempo alla NASA. In pratica avrei dovuto prendere i file C++ contenenti gli algoritmi da testare, estrarre questi e trasformarli in enunciati di logica formale. A questo punto avrei passato il tutto ad un dimostratore automatico di teorimi (avevo deciso di utilizzare il famoso nqthm di Boyer-Moore lo stesso utilizzato alla NASA). Se il theorem proover dava un riscontro positivo allora voleva dire che la sequenza logica ed aritmetica degli algoritmi da testare era consistente e coerente con la funzionalità che mi aspettavo da tali algoritmi. C'era solo un unico problema. Il tempo! Avevo stimato che mettere in piedi un sistema di questa portata mi sarebbe servito più di un mese. Quando ho comunicato al mio responsabile d'ufficio questa tempistica, l'ho visto sbiancare. La sua risposta è stata che in ditta esistevano già delle metodologie di test e nessuna aveva mai richiesto più di una settimana per essere messa in piedi. Provai a spiegargli che le metodologie aziendali non servivano per risolvere il mio problema e che la mia era una nuova metodologia che la ditta avrebbe potuto fare sua e trarne enormi benefici anche in futuro. Ovviamente non capì. Comunque ero riuscito a strappargli una ventina di giorni. Iniziai a scrivere il parser dei file C++ per estrarre gli algoritmi che mi interessavano ed il sistema di traduzione della sequenza logica delle operazione aritmetiche degli algoritmi in un sistema logico che fosse comprensibile per nqthm. Passati i venti giorni il sistema era pronto solo al 70 per cento, ma sufficiente maturo per fare delle piccole demo per i responsabili della qualità aziendale. Fu un disastro. La qualità non capì minimamente la portata di quello che stava vedendo, ed il mio responsabile, che capì ancora meno, si arrabbiò tantissimo. Mi fu intimato di non continuare con il mio progetto e di utilizzare una delle già consolidate, ma perfettamente inutili procedure aziendali. Così feci. In due giorni misi su un sistema completamente inutile ai fini di testare gli algoritmi ma tutti così erano contenti, sia il mio responsabile, sia l'ufficio di controllo qualità. Il mio progetto fu abbandonato ad un passo dalla conclusione. Nonostante io abbia nel mio archivio personale a casa tutti i sorgenti del codice che avevo scritto in quei venti giorni, dissi alla ditta che avevo distrutto tutto il materiale prodotto fino ad allora. Ancora oggi, dopo più di due anni, questa grossa azienda è convinta che gli algoritmi scritti per un sistema a criticità molto alta siano stati esaurientemente testati, cosa che ovviamente non è così. Le loro procedure aziendali testavano non la validità degli algoritmi, ma la validità dell'implementazione C++ degli algoritmi. Questa sottile ma fondamentale differenza non è stata ancora capita dopo due anni. Io fui allontanato dal progetto e persi ogni credibilità verso il responsabile d'ufficio che ancora oggi mi considera un incompetente. E questo è tutto. Traete voi le vostre conclusioni...
RispondiEliminaLuca Ciciriello
Ritengo che mantenere il codice di questo progetto (seppure parziale) rinchiuso in un cassetto sia un enorme spreco.
RispondiEliminaBisognerebbe valutare l'opportunità di rendere pubblici questi sorgenti, per esempio facendoli ospitare da sourceforge; è solo necessario valutare se la pubblicazione rientra nei tuoi diritti, ovvero se il codice rifiutato dal tuo cliente è comunque sotto copyright del cliente.
Mi informerei sulla questione, e nel caso fossi il legittimo proprietario, pubblicherei il lavoro come free software, a beneficio di chi possa essere interessato all'argomento.