Ieri ho speso molto tempo sui mezzi di trasporto (troppo....quando potremo direi anche noi "Beam me up, Scotty" ? ), ma per fortuna sono riuscito a investirlo nella sana lettura del libro "Agile Database Techniques".
Uno dei punti che più mi ha favorevolmente colpito - e stupito direi - è che Scott W. Ambler, l'autore, sostiene che per essere Agili è necessario diventare dei Generalized Specialist. E' una cosa in cui ho sempre creduto, e mi sono praticamente sempre trovato in controcorrente , ed ora che lo leggo scritto sul libro di uno degli autori più autorevoli del movimento agile, beh, non può farmi che piacere!
Ma cosa significa Generalized Specialist? Il concetto è molto semplice e si può riassumere dicendo che è necessario far si che i propri orizzonti siano il più larghi possibile, in modo da poter capire pro e contro di ogni tecnologia con cui veniamo a contatto. In pratica, una volta che si è diventati abbastanza specialist in una tecnologia non bisogna pensare di essere arrivati alla fine del proprio lavoro ma, al contrario, bisogna rimboccarsi le maniche e cominciare ad approfondire un'altra campo magari adiacente al nostro.
In questo modo gli sviluppatori capiranno perchè è necessario normalizzare i database, ed i dba capiranno perchè non poi così male dover trattare xml nei loro database .
Per completezza riporto i tre punti che Ambler cita per poter essere Agili:
- Non è necessario essere Superman
- L'approcio agile è uno stato mentale
- E' necessario diventare un Generalized Specialist
Che ne pensate? Io da parte mia sottoscrivo al 100%....dalla mia esperienza, infatti, vedo che, oggi come oggi, per poter sviluppare al massimo la potenza che l'informatica ci mette a disposizione è necessario conoscere:
- .NET (o un linguaggio OO, ad esempio java per l'altra sponda)
- XML (per la persistenza, la manipolazione e lo scambio dei dati)
- SQL (un qualiasi rdbms, per la memorizzazione, il trattamente e l'analisi delle informazione)
Se uno di questi 3 manca, alla fine ci troviamo a dover fare dei giri mostruosi per ottenere delle soluzioni, che, altrimenti, avremmo ottenuto in molto meno tempo e con molta più efficienza ed efficacia, oppure a non capire perchè i nostri colleghi ci richiedono certe funzionalità che noi non capiamo a fondo.
Che ne pensate? Io noto subito una cosa: in questo il nostro lavoro credo che differisca molto dai lavori classici (meccanico, ingegnere ecc ecc), in quanto ci chiede di essere molto ma molto flessibili e poliedrici (nei limite del possibile ovviamente, non credo che ci possano essere seri dei "tuttologhi")