Il team non reagisce

rated by 0 users
This post has 1 Reply | 2 Followers

Top 10 Partecipanti
Post 30
Punteggio 480
raffaeu Posted: 06-01-2013 11.39

Ciao a tutti, per la prima volta mi trovo nella situazione di dover gestire multipli teams e purtroppo sto riscontrando un grave problema di conoscienze tecniche. Mi spiego meglio.

Al momento ricopro la posizione di Architect in una Software House, in collaborazione con 3 scrum masters e un HR manager gestiamo 3 teams di un totale di circa 14 developers e 3 QA. Tutti lavorano da remoto e posso qualificarli come 6 juniors e i restanti medium. Non ho neanche un senior perche' nessuno conosce SOLID, TDD o qualsiasi tecnologia moderna come Azure, WCF o MVC.

Questi teams lavorano su una piattaforma Windows Form con una SDK integrata in Visual Studio stile PRISM/CAB. Gli sviluppatori sono abituati alla classica struttura Client/Server/Database. Al momento loro creano Views, Services e Mappers semplicemente usando l' SDK di VIsual Studio. Autonomamente non saprebbero nemmeno come fare a creare una view senza l' SDK, nonostante abbia speso mesi a creare ViewPoints e Architecture Views che spiegano in dettaglio la struttura di questo SDK.

L'azienda mi ha incaricato di fare un porting di questo framework in version Saas con WCF, DDD e tutto quel che ne concerne. La scelta architetturale e' caduta su CQRS e DDD per ovvi motivi. Ho speso circa 3 mesi in workshops con i developers spiegando tutti i concetti necessari per iniziare il progetto: NHibernate, CQRS, SOLID, TDD, Messaging, TFS e ALM e cosi' via. Tutti erano chiaramente eccitati ed esaltati dall' idea di fare qualcosa di nuovo, moderno e contemporaneo.

Il problema?
Prima di andare in ferie 2 settimane ho assegnato insieme ai due PO alcune User Stories per poter verificare il livello degli sviluppatori e con mio completo sconcerto e disappunto mi sono accorto che i teams non sono pronti. Fanno fatica a capire cosa sia una projection, perche' e' sbagliato passare un root aggregate attraverso tutti i layers e sono fermamente convinti che TDD sia inutile. L' HR e i PO sono dalla mia parte ma io sono terrorizzato dall' idea di iniziare un qualcosa con degli sviluppatori che non hanno ne' esperienza ne' le conoscienze necessarie. Durante un anno di corso IASA ho imparato che questo potrebbe un pericolossisimo prerequisito, nel senso che oltre a dover avere un buon architect e dei validi PO bisogna avere sviluppatori seniors con buone conoscienze dei patterns e dei frameworks impiegati altrimenti il progetto potrebbe essere una failure upfront. Nello stesso tempo non e' mia natura abbandonare un progetto senza aver prima provato tutte le strade possibili ma sono davvero disorientato e deluso dall' outcome di questi due ultimi sprints.
Voi cosa fareste? Ho provato a spiegare che al momento stiamo usando 14 sviluppatori da remoto in Ukraina e sono tutti juniors e questo e' il problema ma gli stakeholders fanno orecchie da mercante, perche' assumere dei seniors avrebbe costi troppo elevati per il progetto. Nello stesso tempo non ho proprio voglia di buttarmi uno/due anni dentro un progetto dove io sarei l'unico ad avere le conoscienze necessarie per portare al termine la cosa. Mi hanno proposto di fare tutto da solo ma io credo nel lavoro in team e non ho nessuna intenzione di imbarcarmi in un "progetto cowboy" se capite cosa intendo.

Scusate per il mio italiano ma giorno dopo giorno lo sto pian piano dimenticando quindi non fate caso ai miei orrori grammaticali e di sintassi.
Confindo in un buon amichevole consiglio perche' al momento sono veramente incerto sul da farsi.
Raf

  • | Punteggio Post: 20
Top 10 Partecipanti
Maschio
Post 253
Punteggio 3.478

Discorso difficile, purtroppo se questi problemi non interessano agli stakeholders, quello che ti rimane è un gruppo di sviluppatori Junior e da li non scappi. Il problema maggiore è il fatto che tutti lavorino "da remoto" perchè è molto difficile fare formazione su programmatori che sono in remoto. Avendoli in casa piano piano si possono introdurre le buone pratiche, e poter fare face-to-face conversation è sicuramente migliore.

Il rischio maggiore che vedo è avere un forte debito tecnico, che verrà difficilmente colmato, perchè non avendo unit test nessuno fara refactoring. In questo scenario bisogna che l'architettura sia a prova di stupido, ovvero lasciare il meno possibile la possibilità agli sviluppatori di "fare quello che vogliono", però non è assolutamente facile.

Anche io eviterei il progetto cowboy, però se anche il team di persone è reticente ad assimilare nuove conoscenze, probabilmente non è un buon progetto da seguire, e fossi in te cercherei magari di trovare un altro progetto, facendo presente agli stakeholder che è molto difficile "portare a casa" un progetto quando si hanno queste condizionoi al contorno. Uno dei valori di progetti di questo tipo a mio avviso è proprio la formazione di un team interno, quindi si fa un po fatica all'inizio però poi il team si skilla. Se il team è in outsourcing in Ukraina.. probabilmente non vale la pena.

gian Maria.

 

  • | Punteggio Post: 5
Pagina 1 di 1 (2 elementi) | RSS
Powered by Community Server (Commercial Edition), by Telligent Systems