jump to navigation

L’errore dietro alle “quote rosa” sabato 23 gennaio 2010

Posted by andy in Miglioramento, pensieri, vita quotidiana.
Tags: , , , ,
add a comment

Tempo fa sono capitato su una notizia (qui su La Repubblica) che mi ha confermato un’idea che ho già da parecchio tempo.

Le cosiddette ‘quote rosa’ (le pari opportunità garantite alle donne riservando un numero definito a priori di posti in una particolare istituzione) sono uno sbaglio ed un’offesa al gentil sesso.

Pur non avendo difficoltà ad apprezzare lo spirito soggiacente all’idea, che cerca di ristabilire un equilibrio in un mondo controllato, per varie ragioni, dal sesso maschile, continuo ad avere delle notevoli perplessità sul modo.

Ma veniamo alla notizia: in Svezia, per equità, sono garantiti alle donne il 50% dei posti disponibili alle donne, ma (e qui sta la vera notizia) l’altro 50% è invece garantito agli uomini.

Ebbene, le donne hanno scoperto che vi sono delle professioni in cui il proprio sesso prevale, per numero e competenza, rispetto a quello maschile, e si sono trovate penalizzate, dovendo lasciare il 50% dei posti disponibili ad uomini anche meno qualificati di loro.

In sostanza, si è scoperto che una legge fatta nell’interesse delle donne in realtà in particolari contesti può divenire per loro penalizzante.

Ma qual’è il vero problema alla base di tutto questo? A parere mio si tratta di una confusione di termini.

Da troppi anni la gente fa una sostanziale confusione tra uguaglianza e parità tra i sessi.

Mentre è doveroso dover riconosce la parità di diritti tra i sessi, è altrettanto importante capire che questi non sonno uguali, e non lo possono essere neppure se lo vuole la legge.

Uomini e donne sono sostanzialmente diversi nella propria natura, sia fisicamente che psicologicamente ed attitudinalmente (ovviamente parlando in senso generale e non assoluto).

È inconfutabile che vi sono discipline, arti e mestieri in cui eccellono principalmente uomini, ed altri in cui eccellono le donne.

Questo fatto non significa che un sesso sia migliore dell’altro: significa soltanto che la Natura ci ha diversificati, rendendoci complementari.

Dal punto di vista normativo, si conferma che garantire un posto per ‘diritto divino‘ (la legge), invece che per merito porta a penalizzare i più meritevoli.

Dal punto di vista pratico, le leggi sulle quote rosa sono, a parer mio, una soluzione temporanea ormai superata al problema; forse iniziano ad essere maturi i tempi e la consapevolezza per rivedere le norme, sostituendo le quote rosa con regole e criteri più onesti per premiare il merito, criteri che devono essere realmente imparziali rispetto al sesso.

Metodologie RUP vs. Agile nello sviluppo del software martedì 12 gennaio 2010

Posted by andy in tecnologia.
Tags: , , , , , ,
add a comment

Lo sviluppo del software vede sempre più il confronto tra metodologie altamente strutturate (RUP) e quelle che vorrebbero essere le più elastiche possibili (Agile).

Il conflitto è, in parte, tra coloro che vogliono assicurare la qualità formale rispetto alla qualità sostanziale.

Il giusto, o il meglio, ovviamente non sta né da una parte né dall’altra, ma più probabilmente nel mezzo.

Ma in che modo?

Non posso che condividere il pensiero che la programmazione sia un fatto artigianale, in quanto frutto di un’invenzione; tutto ciò che non è più artigianale si trasforma in software consolidato, librerie, componenti standard.

Da programmatore riesco perfettamente a capire quanto possa stare ‘stretto’ l’abito di colui che produce righe di codice secondo regole e schemi.

Da responsabile della Qualità, ritengo che la bellezza e le promesse della metodologia RUP siano il Santo Graal per la produzione del software.

Le metodologie di tipo Agile sono soltanto un compromesso, per venire incontro all’ingestibilità innata dei programmatori (quelli bravi, soprattutto), delle specifiche del cliente in eterno divenire, la documentazione (costosissima) che non riesce mai ad essere allineata allo stato dell’arte del progetto, dei budget di progetto per definizione sottodimensionati e dei tempi di consegna spesso irragionevoli.

In medio stat virtus, dicevano i latini, e già Aristotele era giunto a questa conclusione.

Il problema è riuscire a definire (e in qualche modo a formalizzare) quale sia questa via di mezzo.

L’eccessiva formalizzazione porta a spendere più tempo a ‘vestire’ il progetto (specifiche, documentazione, etc.) che a realizzare l’obiettivo finale.

L’eccessiva libertà porta in breve tempo a risultati vicini all’optimum, lasciando tuttavia dei lavorati (o semilavorati) con costi di manutenzione impredicibili.

L’arte sta, probabilmente, nel concentrarsi nel punto di incontro tra sviluppo ed utilizzo del software, tra fornitore e cliente.

È in questo punto che si scopre se il lavoro risponde ai requisiti o meno, ed in cui emergono i requisiti nascosti.

Sostanzialmente è il momento del collaudo che, da istante finale del lavoro, deve diluirsi nel tempo, affinando i punti e gli elementi di controllo.

Ad esempio, invece che lasciare al fornitore le attività di installazione, sarebbe molto più appropriato gestire internamente tale attività, o comunque delegarla ad una società terza: in questo modo qualsiasi mancanza in termini di documentazione dell’architettura e delle procedure di compilazione ed installazione apparirebbe in modo palese dal mancato funzionamento del sistema.

E lo stesso vale per la formazione agli utenti ed al personale incaricato di gestire il sistema: interponendo una figura terza, tutte le carenze documentali verrebbero immediatamente a galla.

Diviene quindi fondamentale che all’inizio non vengano posti requisiti troppo specifici, ma soltanto quelli sostanziali, quelli che discriminano tra l’usabilità o meno del prodotto finale, tra l’eseguibilità o meno, tra l’integrabilità o meno, nonché la sua affidabilità nel tempo.

Metodologia, strumenti, linguaggi, componenti software .. tutti elementi di fatto ininfluenti ai fini del risultato, se il controllo diviene sostanziale e non formale; se il prodotto viene verificato rispetto alle reali esigenze del cliente, e con continuità.

Ovviamente, e con questo concludo, occorre assolutamente sviluppare una nuova cultura (e ribadisco ‘cultura’, rispetto al termine ‘metodologia’) per l’identificazione e la definizione dei requisiti di progetto.