0) E' opportuno _tenere all'oscuro un sviluppatore fino al giorno in cui dovrà iniziare a lavorare su un progetto. Meglio non assillarlo per tempo in task inutili come ad esempio fargli decidere gli strumenti e le tecnologie con un certo anticipo o fargli pianificare eventuali impegni (ferie/permessi/straordinari) quando il progetto dura più di 4 mesi.
1) Evitare di inondare lo sviluppatore di specifiche funzionali visto che o non ci sono del tutto o non gli sarà dato tempo di studiarle. Meglio quindi fargli sapere tutto (a voce) volta per volta o lasciare che capisca in modo autonomo le funzionalità dalle tavole, soprattutto dai livelli nascosti. Del resto è lo sviluppo "Agile", no?;
2) I tempi di sviluppo dovrebbero essere decisi da tutti coloro che sono coinvolti nel progetto, meno lo sviluppatore. A questo va semplicemente chiesto per ultimo - a contratto firmato e tavole approvate - cosa "ne pensa";
3) E' meglio non perdere tempo a mostare in anticipo i mockup allo sviluppatore, potrebbe avanzare oscuri problemi di implementazione o noiosi rilievi sulle tempistiche. Quindi, ad esempio, è meglio tenergli nascosto fino all'ultimo la presenza di form stilati o non mostrargli affatto inutili dettagli come le risposte dei form o messaggi di errore in richieste ajax. Informarlo della presenza di pagine stampabili solo alla fine del progetto;
4) Per ben disporre lo sviluppatore e massimizzare la sua efficienza e la concentrazione è bene presentargli un progetto inziando dalla frase "siamo già in ritardo di x settimane" (l'efficienza aumenterà all'aumentare di x) oppure "il progetto l'ha iniziato <tizio>, se continui con il suo lavoro farai prima";
5) I sistemi di versionamento sono roba per soli sviluppatori. I grafici invece hanno tutto il sacrosanto diritto di sistemare le loro tavole in qualche /(sotto\-)*cartella/, dando ai file nomi generici del tipo "hp_3box_nolog_mixcat_layer2_v4";
6) Se ci sono modifiche successive ad una tavola (soprattutto se sostanziali e dopo l'approvazione del cliente) il PM non dovrebbe ravvisare un cambiamento in corso d'opera ma piuttosto sarà bene avvisare lo sviluppatore, possibilmente dopo che questo ha già completato la tavola in oggetto nella versione precedente;
7) I sistemi di bugtracking sono roba da smanettoni o se sei tipo la mozilla corp. , mentre i file excel via email, quelli sì che sono lo strumento più idoneo per mantenere traccia dei bug in modo consistente e pratico anche tra 10 e più persone;
8) Quando il progetto è completato quasi del tutto è buona norma allocare all'improvviso lo sviluppatore su un altro progetto quasi completo di cui ignora quasi tutto oppure assegnargliene altri due o tre "se ha tempo". Il progetto su cui stava lavorando, invece, sarà seguito a sua volta da un altro sviluppatore che era allocato altrove; ci piace spaziare sulle cose.
9) Se i template preparati dallo sviluppatore devono essere integrati/recepiti da una terza parte è bene che quest'ultima solleciti lo sviluppatore a consegnare un certo template in tempi rapidi (meglio se entro il primo pomeriggio, prima delle 16) e poi chieda assistenza durante la fase di integrazione dello stesso, che avverrà dalle due settimane ai 6 mesi successivi;
10) chi segnala i bug sul progetto è bene che apra più volte la stessa segnalazione (anche se risolta) per verificare che lo sviluppatore sia abbastanza attento. Inoltre la stessa persona dovrebbe evitare di far perdere tempo allo sviluppatore con ticket prolissi e inutili screenshot. Un semplice "non funziona" o un "come da titolo" andrà benissimo;
11) La pianificazione dei rilasci o della messa online non è essenziale, in fondo in un anno tutti i giorni sono all'incirca uguali per cui lo sviluppatore sarà a completa disposizione tanto il 28 gennaio quanto il 15 agosto oppure alle 23 di un qualsiasi giovedì sera.
Rispondi quotando
