Dopo un periodo abbastanza ricco di impegni, con un rilascio alle spalle e più tempo a disposizione, ritorno a scrivere sul blog (anche se contemporaneamente sto testando la nuova build di NNTPota).

Tra poco, quando l'ennesimo blocco del traffico qua a Padova sarà terminato, mi metterò in strada per andare a Milano in occasione del Visual Studio Team System Day.

Avendo un passato da docente sulle tematiche del Project Management e un presente centrato sulle tematiche legate a .NET e allo sviluppo Web, sono contento di partecipare all'evento di domani, dove entrambe le argomentazioni verranno fuse insieme. Finalmente anche Microsoft comincia a proporre una serie di strumenti associati ad una metodologia ben precisa (o forse è meglio dire: un processo di sviluppo e gestione a cui sono associati una serie di strumenti integrati insieme).

Troppo spesso mi è capitato di dover controbattere a chi in maniera più o meno polemica ha sostenuto in mia presenza discorsi a sfavore dei linguaggi proposti da Microsoft (in primis Visual Basic), degli strumenti di sviluppo, di configuration management (anche se VSS i suoi limiti li ha), di modellazione, ecc. Mi sono sentito dire che lo sviluppo targato Microsoft non è un sviluppo "serio"... Addirittura c'è stato chi mi ha detto che C# non è un linguaggio orientato agli oggetti! A parte quelli che hanno il prosciutto davanti agli occhi, per i quali non vale la pena accanirsi per dare una risposta motivata, a tutti gli altri ho sempre cercato di spiegare i vantaggi, le implicazioni e soprattutto gli ambiti in cui ha senso usare una tecnologia (e gli strumenti correlati) piuttosto che un'altra.

In generale ritengo che sia comunque un errore partire dal presupposto che siano la tecnologia e gli strumenti a risolvere tutti i problemi legati alla progettazione, allo sviluppo e alla gestione di un progetto software. Certo, gli strumenti possono essere una soluzione per una certa classe di problemi, ma in generale non sono "la panacea di tutti i mali". Ecco perchè ancora oggi, anche se talvolta si tende a dimenticare che lo sviluppo di applicazioni è una attività tutt'altro che banale (perchè con 2 click NON si fa alcunchè), io continuo a sostenere l'importanza che ricoprono l'approccio, le metodologie (formali e/o agili che siano) e i processi.

OK, la mia sarà anche una visione non da "sviluppatore puro", dato che nel mio DNA è presente una certa attenzione alle problematiche di progettazione e gestione, però credo che dare il giusto peso al metodo sia un approccio corretto anche per chi fa solo sviluppo.

Esiste una sostanziale differenza tra processi di sviluppo e processi di gestione. Spesso capita che un capo progetto sia anche il team leader con responsabilità tecniche e di progettazione, ma in taluni casi può capitare che ad un team leader venga chiesto di fare il capo progetto (con responsabilità non solo tecniche, ma anche di gestione). Essere un buon team leader e un buon progettista non sempre basta per essere un buon capo progetto. Questo perchè gestire non vuol dire solo progettare, c'è di più e può essere interessante capire cosa.

Per questo motivo ho cominciato a scrivere sul Wiki di UGIdotNET una sezione dedicata interamente al Project Management.

Il Wiki proposto da UGIdotNET è uno strumento collaborativo di confronto e discussione attraverso cui tutti (non solo gli utenti di UGIdotNET) possono far emergere nuove idee e raggiungere un consenso sul modo di risolvere problemi impegnativi riguardanti .NET e i temi trasversali alla tecnologia contestualizzati alla specificità di .NET, i processi di sviluppo e di gestione, le architetture, i pattern, ecc.

powered by IMHO