Newsgroup: it.lavoro.informatica
Titolo: Coordinare un team di sviluppo senza scrivere una riga di codice

Ciao a tutti,
Per la realizzaizone di un lavoro piuttosto semplice (e neanche tanto 
importante) il "boss" mi ha chiesto di fargli avere in tempi brevissimi 
uno sketch (w la carta e la matita, i migliori strumenti di design del 
mondo!!!) per l'architettura. Ne abbiamo discusso, l'idea gli è piaciuta 
e mi ha fatto questa proposta: definire bene l'architettura (i vari 
moduli, le interfacce, ..etc...) ad un livello piuttosto "alto" di 
astrazione e poi coordinare un team di sviluppatori (4 persone credo) 
assegnando ad ognuno una parte del sistema e facendo - da quello che ho 
capito - delle mini sessioni di pair-programming con ognuno per 
impostare il lavoro.
Qualcuno di voi lo ha mai fatto? E' una strada percorribile? Pro? Contro?
Grazie e ciao a tutti,
Giulio
-- 

 --

 secondo me le cose semplici vanno sempre fatte per prime...
Parole sante! ;-)
Grazie per i preziosi consigli: li terrò a mente!
Ciao,
Giulio
-- 
OnAir: Badi Assad e Toquinho - "Berimbao"

Giulio Petrucci wrote:
: Ciao a tutti,
:
: Per la realizzaizone di un lavoro piuttosto semplice (e neanche tanto
: importante) il "boss" mi ha chiesto di fargli avere in tempi
: brevissimi uno sketch (w la carta e la matita, i migliori strumenti
: di design del mondo!!!) per l'architettura. Ne abbiamo discusso,
: l'idea gli č piaciuta e mi ha fatto questa proposta: definire bene
: l'architettura (i vari moduli, le interfacce, ..etc...) ad un livello
: piuttosto "alto" di astrazione e poi coordinare un team di
: sviluppatori (4 persone credo) assegnando ad ognuno una parte del
: sistema e facendo - da quello che ho capito - delle mini sessioni di
: pair-programming con ognuno per impostare il lavoro.
:
: Qualcuno di voi lo ha mai fatto? E' una strada percorribile? Pro?
: Contro?
E' percorribile se:
1) sei molto ma molto ma molto chiaro nella specifica dell'architettura
2) l'applicazione č semplicissima
3) i programmatori sono cazzuti e sanno il fatto loro in fatto di analisi
Altrimenti lascia perdere.

On 23 Ago, 17:55, Giulio Petrucci <sis...@nonono.boh> wrote:

Beh , visto che l'applicazione da sviluppare e ' semplice e non
fondamentale
direi che per te e' un'ottima occasione per dare i primi passi come
coordinatore.
Penso che l'idea del pair programming sia buona , e se posso mi
permetto di darti qualche
suggerimentoi: oltre al pair programming, prova ad adottare qualche
altro concetto XP, per esempio..
non ti porre come PM con la mega P Maiscula e la Mega M maiscula, ma
piu' come coach. Gia' parti bene per il fatto che facendo pair
programming con loro condividi i loro problemi e  ti guadagni il loro
rispetto.
In piu' potresti renderli partecipi anche sulla fase di design, cn un
bel metting iniziale in cui tu hia gia' pronta sia in testa che su
carta la tua idea , ma sei pronto a discuterla con loro. Sentiranno
come piu' appartenente a loro il progetto e meno come se gli fosse
stato calato sulla testa, impareranno qualcosa e magari ti potranno
sorprendere mostrandoti che anche persone con meno esperienza possono
avere buone idee a volte.  Lascia perdere diagrammi, Gant, formalismi
e stronzate varie, cominciate a scrivere codice prima possibile per
avere un prototipo funzionante come prima cosa, da sviluppare
iterativamente aggiungendo man mano nuove funzionalita'.
un grosso in bocca al lupo!

 e poi coordinare un team di sviluppatori (4 persone credo)
Qualche lettura consigliata:
http://www.pragmaticprogrammer.com/titles/jrpm/index.html
http://www.pragmaticprogrammer.com/titles/rdbcd/index.html
http://www.pragmaticprogrammer.com/titles/prj/index.html
http://gettingreal.37signals.com
Bye
Jarod

 ha scritto nel messaggio 
news:1187886140.8...@x35g2000prf.googlegroups.com...
On 23 Ago, 17:55, Giulio Petrucci <sis...@nonono.boh> wrote:
SOPRATTUTTO a nessuno
del team deve venir in mente di mettere in discussione il tuo ruolo,
puņ sembrare banale e scontato ma se a qualcuno saltano i grilli per
la resta, meglio allontanarlo dal gruppo.Per il bene del gruppo.
-------------------------------------------------------------
parole SANTE

 un grosso in bocca al lupo!
Grazie per i consigli e crepi il lupo!
Ciao,
Giulio
-- 

 un grosso in bocca al lupo!
dai i programmatori sono "giovani" e in grado
di assorbire velocemente, ergo se l'analisi fuzionale e di progetto
e' ben fatta, ma soprattutto conosco l'atrezzo di sviluppo,
andra' tutto alla grande :)
felice_pago
la mia analisi e' indifferente
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 un grosso in bocca al lupo!
D'accordo con tutto quello che hai detto PERO':
se hai un progetto, l'approccio di iniziarlo partendo il prima
possibile e aggiungendo cose, scusami, se è un progetto per un cliente
(non è questo il caso ma io facevo una trattazione generale), secondo
me non va bene.
Il cliente vuole il punto della situazione: le riunioni di stato
avanzamento lavori non sono fuffa. Se poi per te la legittima pretesa
di sapere come vengono impiegati i soldi spesi per un progetto OSSIA a
che punto è il progetto non conta, beh, i tempi sono cambiati. I
clienti pagano a quarter e non ci mettono meno di un attimo a cambiare
fornitore... quindi un minimo di formalismo e pianificazione (senza
sfociare nell'esposizione della FUFFA, come detto prima...) ci vuole,
sempre e comunque.

 sempre le stesse cose ma per 4 volte ?
[CUT]
quanto volevo dire nel mio precedente post... un classico caso dove
uno sforzo per evitare la FUFFA in realtà ne genera!!!

 uno sforzo per evitare la FUFFA in realtà ne genera!!!
il problema e' che l'informatico medio non lo capisce,
o fa finta di non capirlo, vuoi per inettitudine, vuoi per
ignoranza.


 Qualcuno di voi lo ha mai fatto? E' una strada percorribile? Pro? Contro?
è abbastanza normale che mi debba occupare di due, tre progetti
simultaneamente e in queste circostanze diventa necessario saper far
sviluppare gli altri, che è una cosa diversa dal saper sviluppare ma
non meno impegnativa e stressante.
l'obiettivo tuo si trasforma in qualcosa di diverso ed è quello di
provvedere che il team sia in condizione di essere produttivo, quindi
che ciascuno sappia in ogni momento cosa fare e come farlo. un
classico indice che stai lavorando male è quando ti chiama lo
sviluppatore per dirti "sono fermo, che faccio?" quando il progetto è
affogato nel marasma.
sul metodo dipende tutto da come intendi organizzare il processo di
sviluppo, saprai meglio di me che il ciclo si può realizzare in tanti
modi ciascuno con i suoi pro e contro. ti posso dare dei suggerimenti
generici che personalmente ritengo validi:
- fai in modo che le persone non abbiano il loro orticello da zappare.
l'obiettivo deve rimanere unico e le persone devono avere sufficiente
indipendenza da completare task che fanno avanzare il progetto. il
fatto di rendere tutti partecipi dell'obiettivo primario è anche il
principale oggetto di motivazione del team.
- sempre riguardo al punto precedente: abitua le persone a non
lasciare *mai*, ribadisco, *mai*, altri componenti del team da soli
nelle difficoltà. tu per primo devi avere questa accortezza.
- fai in modo che le persone non debbano prendere decisioni riguardo a
tecnologie, strumenti, tools, librerie, framework, eccetera. di questo
discutine prima e se nasce una nuova esigenza in corso d'opera fai in
modo di essere tu a decidere.
- qualcuno ti ha suggerito di lasciar perdere gantt, diagrammi e altri
"formalismi". io non mi adentro in polemiche, fatto stà che tu uno
straccio di idea sullo stato di avanzamento la dovrai pur avere,
quindi dovrai individuare almeno delle fasi del progetto. io ti dico
più sei dettagliato e più hai sotto controllo la situazione (tempi,
costi), chi ti consiglia di fare a meno degli inutili formalismi
evidentemente sa tenere tutto a memoria ma io non ne sono capace. vedi
un po' te... ;)

 Sembra dare lo zuccherino
vedi punto 1.
[SNIP]
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sempre le stesse cose ma per 4 volte ?
Eh io ho detto di evitare fuffa & stronzate, non che un paio di
orette
( o anche un giornata se e' per questo) per il design e la
coordinazione non sia
necessario. Se leggi bene il mio post vedrai che parlo di discutere il
design con
gli sviluppatori...E ovvio che intendo evitare solo le montagne di
inutile analisi
che fatte a monte non servono assolutamente a nulla. Si fa un design
inizale consi dei sui limiti ,
e poi si migliora anche quello iterativamente.

On Fri, 24 Aug 2007 02:50:43 -0700, rootkit wrote:
cutto
concordo su tutto e mi permetto di aggiungere:
- non sottovalutare mai qualsiasi suggerimento/indicazione proveniente
dagli altri componenti del team, anche quelli pių apparentemente piu'
banali

 non meno impegnativa e stressante.
Qui mi viene il dubbio che o tu non abbia mai sviluppato o
che tu non abbia mai fatto sviluppare gli altri.
"Far sviluppare gli altri" e' indubbiamente molto (ma proprio tanto)
meno impegnativo e stressante che non sviluppare. Almeno per chi come 
me, quando sviluppava lo faceva "per obiettivi", a costo di stare in
piedi tutta la notte.
E quando sono stato in piedi tutta la notte, ne' l'analista funzionale,
ne' il PM erano li' con me.
Ciao,
Marco


 che tu non abbia mai fatto sviluppare gli altri.
che ti devo dire?
hai il dubbio, vorrà dire che te lo tieni.

 hai il dubbio, vorrà dire che te lo tieni.
Va bene.
Mi sarebbe piaciuto conoscere da cosa deriva non tanto
l'impegno quanto lo stress nel fare sviluppare gli altri, pero' mi
terro' il dubbio.
Ciao,
Marco. 


 terro' il dubbio.
Dipende. C'e' il project manager che va via solo per ultimo e quello che
se ne va via per primo e il giorno dopo comincia a lamentarsi perche' il
lavoro non e' stato fatto. Inutile generalizzare ma forse quello che si
puo' dire e' che spesso i proj mgr sono a piu' contatto con i dirigenti
per cui hanno una maggiore visibilita' e sono piu' protetti rispetto ai
tecnici, per cui se volessero fare i grandi paraculi hanno piu'
possibilita' di farlo di un qualsiasi tecnico che se non produce si nota
immediatamente. 
Personalmente, per la mia opinione, e' un mestiere tanto importante quanto
quello del programmatore, dell'architetto, del sistemista, ecc. ecc.
Putroppo nella maggior parte delle aziende la sua importanza viene
sopravvalutata con il fenomeno paradossale che i piu' bravi tecnici
diventano proj mgr per guadagnare di piu' oppure i peggiori tecnici che
scoprono di non essere in grado di fare quel mestiere per la loro generale
inattitudine e l'azienda si ritrova con proj mgr scadenti o inetti e meno
risorse tecnice valide. Sono pochi quelli che lo fanno per attitudine.


 risorse tecnice valide. Sono pochi quelli che lo fanno per attitudine.
direi che sono POCHISSIMI. Tutti quelli che conosco non sono partiti
dall'attitudine, ma ripeto facendo i tecnici.
In dieci anni che lavoro da dopo la laurea i PM "puri", chiamiamoli
così, ne avro conosciuti in un numero che si conta sulle dita di una
sola mano!
Quelli buoni.
Perchè il resto rientra nella categoria che ti dicevo prima dei PM
"improvvisati"...
Ciao!

 Ciao!
E' un altro mestiere. Tanto importante quanto tanti altri. Per me non e'
l'unica possibile evoluzione della carriera individuale. E poi nascono le
barzellette sulla canoa e i timonieri, proprio perche' tutti vogliono
gradualmente muoversi verso incarichi gestionali. Il risultato e' il
prosciugamento del patrimonio intellettuale tecnico e una sovrabbondanza
di gestori che spesso si dovranno limitare a passare le carte in giro
proprio perche' ci sono troppi timonieri e pochi rematori. :-)


 nulla dell'ambito tecnico, fa più danni che altro.
Ho conosciuto PM molto bravi che avevano competenze tecnico-pratiche 
molto limitate.
Però erano persone in gamba e competenti sul piano teorico e per le 
questioni tecniche sapevano delegare a chi aveva le competenze idonee.
Certo poi esiste il rischio che si deleghi a una persona inadeguata, ma 
questo è un rischio che si verifica in altri n casi.
Vero anche che nelle aziende "grosse" (SAP, MicroSoft, IBM, per citare 
dei casi che ho visto di persona) uno non arriva a fare il PM se prima 
non ha fatto una certa "gavetta".
Ciao,
Paolo

 soldo in più è al bivio: o fa il PM, o fa il commerciale.
Leggenda metropolitana italiana condivisa putroppo da buona parte del
management
italiano. Se questo e' vero, cioe' che tutti i programmatori dopo un
tot di anni si danno
al project management o al ramo commerciale, la conseguenza e'
inevitabilmente che
non esistano veri programmatori seri (o guru che dir si voglia).
Questa, insieme all'idea
"cugina" del programmatore-operaio e' uno dei virus che appesta e
manda in malora
l' informatica in italia.

 terro' il dubbio.
mi piacerebbe rispondere, ma purtroppo a causa della tua tormentata 
situazione conflittuale devo chiudere qui la discussione.

 l' informatica in italia.
Quoto.
Ed infatti l' informatica italiana come settore industriale stenta ad 
affermarsi nel mercato globale (anzi guardando i grandi numeri le 
aziende del settore assomigliano tanto ad un colossale fallimento).
Bye
Jarod

 
riccardo...@email.it
 ha scritto:

Jarod,
da questo punto di vista sono d'accordo anche io. Molte volte sono
stato incoraggiato, da altri colleghi più anziani di me, a perseverare
sull'arricchimento delle competenze tecniche.
Di tecnico ora faccio poco, ma nuovi strumenti che prima non c'erano,
penso solo a wmware, alla possibilità di fare retrocomputing (poi
manco tanto retro) su ebay, mi danno la possibilità di tenermi sul
pezzo anche a casa.
Questo, solo pochi anni fa, non era tanto facile...
Riformulo meglio la frase che è in effetti la sintesi di quanto avete
detto: in altri paesi, soprattutto di cultura anglossassone viengono
dati spazio e giusto riconoscimento a quelli che hanno sviluppato
tendenze tecniche con ALTO livello di seniority. In Italia no, e
questo è un peccato. Che poi sia una leggenda metropolitana, è. come
dice Riccardo, e sottoscrivo (non sai quante volte ho dovuto
scontrarmici!!!) purtroppo colpa del management, di una dirigenza
becera che deve mediare gli interessi di un'azienda in nome del dio
Fatturato, se si investisse (come per fortuna fanno alcune piccole
aziende, ma sono appunto piccole e poche!) almeno una piccola
percentuale in ricerca, allora penso che la figura del tecnico possa
venire finalmente riconosciuta. Non capiscono nemmeno che potrebbe
essere un investimento per la loro sopravvivenza....
Non lo so... forse è tutta colpa degli ingegneri come Orsacchio :-)

 Non lo so... forse č tutta colpa degli ingegneri come Orsacchio :-)
E' soprattutto colpa di chi dirige le baracche.
Ma finchč quelli fatturano (e guadagnano) abbastanza per comprarsi 
Ferrari e villa a Miami hanno ragione loro.
Peccato non si rendano conto che coltivando la cultura tecnica in 
azienda potrebbero guadagnare molto di piů ;-)
Comunque č colpa anche dei tecnici che li seguono come oracoli scesi 
dall'olimpo.
Soldi, carriera, potere sono una tentazione troppo forte.
Arrivati ai 35 anni tutti a fare il Project Manager o l'Account Manager.
E tutta la competenza ed esperienza accumulate negli anni direttamente 
giů nel cesso.
Sotto a ricominciare da capo (e da zero) coi ventenni.
Per fortuna negli altri comparti industriali (quelli seri) esistono 
quasi ovunque fior di tecnici 50enni che continuano a fare il loro 
lavoro con ottimi risultati (e buoni guadagni).
Senza l'assillo di dover diventare a tutti i costi un PM o un commerciale.
Altrimenti a quest'ora l'industria italiana sarebbe fallita da un pezzo.
Bye
Jarod

 Jarod
Ciao.


Concordo assolutamente.
Aggiungo che in progetti di grandi dimensioni (per esempio che coinvolgono
più sistemi sviluppati da team diversi, con I/F tra i vari sistemi ed
obiettivi comuni, ecc...) una buona analisi iniziale è assolutamente
fondamentale. Poi ovviamente ciò non implica che non vi possano essere
comunque problemi, magari grossi!!!



No, "far sviluppare gli altri" significa non essere diretti
responsabili solo del
proprio lavoro di sviluppo, ma essere responsabile del lavoro di
*tutto*
un gruppo più o meno grande di persone. Come minimo un impegno ben
diverso,
ma a mio parere anche ben più difficile se fatto con serietà.
Sul fatto di stare in piedi la notte, lasciami dire una cosa, del
tutto
in generale sia chiaro.... Paradossalmente in informatica gli incapaci
 che fanno
errori su errori vengono pure premiati con gli straordinari pagati....

 errori su errori vengono pure premiati con gli straordinari pagati....
Preciso meglio il concetto a scanso di equivoci.
Lo sviluppatore deve sempre avere un'idea
abbastanza precisa  dei tempi, da comunicare poi ai suoi responsabili.
Spesso vedo gente che lavora da anni sulle stesse problematiche,
addirittura sugli stessi sorgenti, non è pressata da particolari
richieste dei capi, quindi in sostanza fa lavoro di routine; eppure
è sempre in emergenza, con relativo codazzo di ultra-straordinari!!
Ecco, il capogruppo o PM deve gestire pure questo. E non è facile

 risorse tecnice valide. Sono pochi quelli che lo fanno per attitudine.
Appunto. Il fenomeno non e' che arriva da solo. Sono le aziende che hanno
deciso cosi' (ovvero "il programmatore non conta una mazza ed e' una
risorsa facilmente rimpiazzabile",  "il PM conta molto di piu'" => e'
ovvio che la gente tenda a voler fare il PM)
Ciao,
Marco.


> Qualcuno di voi lo ha mai fatto? E' una strada percorribile? Pro? Contro?
Ti consiglio una lettura:
Ian Sommerville, Software Engineering
Ti aiuterà in molti dei tuoi dubbi.
Ciao, U.

 Ian Sommerville, Software Engineering
E' qui, sullo scaffale dei libri, fatto comprare al capo ad inizio anno.
;-)
Ciao,
Giulio
-- 

 Giulio
ciao, U.


Standing ovation!!!!



Pensa che in qualche azienda che conosco, dall'oggi al domani, hanno
bloccato gli straordinari pagati (alcuni dipendenti non avevano straordinari
pagati).
Ebbene dopo 1 anno non c'è stato alcun contraccolpo!!! Prima c'erano persone
in azienda fino a notte fonda, poi improvvisamente le stesse persone
uscivano alle 17.30 (o alle 18.00 non ricordo i loro orari) e facevano la
stessa mole di lavoro!!!
Strano eh ? ;-)
