Molti progetti software si scontrano con problemi di management: le tradizionali tecniche di management non sono molto adatte a gestire i migliori sviluppatori. Questo intervento mostra quanto efficace e` avere, come manager, uno sviluppatore di competenze non inferiori al resto della squadra, in grado di usare se stesso come "risorsa tecnica d'emergenza" se occorre.

1. Sviluppo di Software
Esperienze, Consigli ed Idee
Alex Martelli
http://www.aleax.it/itbes_sseci.pdf
©2009 Google -- aleax@google.com

2. C'è la Pallottola d'Argento?
...un singolo modo di far fuori tutti i mostri?
2

3. NON Parlo Di...
gestione strategica/esecutiva
(per nulla)
business plan, finanza, visione strategica...
(poco o nulla) project management
pianificazione, tempistiche, budget, ...
(appena appena) tecnologie/metodi/strumenti
linguaggi, sistemi operativi, framework...
do per scontato un certo livello di quot;Agilitáquot;:
nè un rigido Waterfall,
nè un Caos totale!-)
3

4. Agile vs Waterfall vs Chaos
Waterfall: mira, mira, mira, mira, FUOCO!
Chaos: fuoco!, fuoco!, fuoco!, OOPS, ...
Agile: mira, fuoco!, aggiusta; mira, fuoco!,
aggiusta; ...
i progetti SW di successo devono avere
una qualche misura di questa agilità;
le quot;metodologie agiliquot; cercano di cogliere
sistematicamente gli aspetti che
funzionano, e applicarli con disciplina,
adottando tecniche di codifica, test &c
appropriate ad esigenze reali e concrete
4

5. Agilita` Strategica
...traditional approaches to strategy
often collapse in the face of
rapidly and unpredictably changing
industries ... because they over-
emphasize the degree to which it
is possible to predict ...
... change is the striking feature of
contemporary business ... the key
managing
strategic challenge is
that change.
5

6. E Allora di Che Parlo?
comunico le mie esperienze (a Google e
prima, da sviluppatore, tech lead, manager:
non aneddoti ma quot;il succoquot;)
su UN buon modo di organizzare, fare e
gestire lo sviluppo software
ne esistono anche altri, eh!-)
attacco alcune tesi molto popolari
e raccomando libri che le difendono!-)
quot;tips & tricksquot; (buoni x molti, molti casi...)
il tutto arrangiato quot;dialetticamentequot;...;-)
6

7. Chi É un Manager?
7

8. Il quot;Livelloquot; A Cui Parlo
Shu
(quot;Imparaquot;)
Ha
(quot;Distaccaquot;)
Ri
(quot;Trascendiquot;)
8

9. Un modo di imparare...
...è con buoni libri -- ce ne sono tanti...!
9

10. Ars longa, vita brevis...
piú ottimi libri, che tempo per leggerli!-)
10

11. Ovviamente il + importante...
... é quot;Il Principequot;!-)
11

12. Un'Opinione Diffusa
“Once you have four or more
people in your group, you can’t
perform technical work and still
be a great manager.” (Wk 6)
“Managers are not usually part
of the teams that they
manage ... leadership just doesn’t
have much place here.” (Ch 23)
12

13. E un Dissenso da Essa
“Tech leads split their time
between development tasks
and management tasks, not
working exclusively in either
realm.” (T.15: Let a tech lead)
A Google, distinguiamo quot;tech leadquot; (ingegnere
responsabile di UN progetto) da quot;uber tech
leadquot; e quot;tech lead/managerquot; (quot;highly
technical managersquot; == HTM), ma tutti questi
gruppi soddisfano questa definizione.
13

14. Un modo di essere un HTM
supponiamo che un manager M sia
tecnicamente almeno un pari degli
sviluppatori (progetto, codifica, debugging...)
M può nutrire reciproca fiducia, interazione
e rispetto con gli sviluppatori usando se
stesso come quot;risorsa tecnica 'Jolly'quot;
non per i compiti + quot;divertentiquot;, ma
per quelli urgenti che richiedono un altro
paio di mani emisferi cerebrali subito,
che siano divertenti o (meglio!-) pallosi
a 'sto punto di solito arrivano le obiezioni...
14

15. Non Può Andare, Perché...
Se segui criticamente, potresti avere una o
piu` di queste obiezioni:
1. e la Legge di Brooks?
2. ma come trovi il tempo!?
3. si trascura il quot;veroquot; lavoro da manager!
4. ma un manager non deve sempre delegare?
5. si spreca talento tecnico!
6. troppe interruzioni, non si può mai
raggiungere la quot;zonaquot; (o quot;flowquot;)!
7. ...aggiungi le tue obiezioni personali...:-)
15

16. 1. La Legge di Brooks
quot;Aggiungere programmmatori a
un progetto software in ritardo
lo ritarda anche di piúquot;
Si, ma: tutti scordano sempre di
citare anche l'inizio della frase:
quot;Sovrasemplificando in modo
oltraggioso, asseriamoquot;...!-)
poi, basta che non sia in ritardo...!-)
Si basa sul carico ulteriore sugli sviluppatori esistenti per
addestrare i nuovi + costo delle comunicazioni in piú.
Ma: l'HTM e` sempre sostanzialmente al corrente, e
comunica sempre, quindi: no overhead ☛ no Brooks’ Law
16

17. 2. Come si trova il tempo?
NON lavorando sempre piú ore la settimana
mira a 40 
accetta 50 
60 é escluso 
(Nota: dico vero tempo di lavoro, al netto di
blogging, ciacole, spuntini, surfing, pranzi...!-)
non col telecommuting (faccia-a-faccia é la
forma + efficace di comunicazione, e la
comunicazione é fra gli aspetti piú cruciali
del lavoro di qualsiasi manager)
il quot;time managementquot; funziona, se ben fatto
17

18. Working Long Hours
Productivity ($/hour)
Average Hours Worked per Week
18

19. Time Management per ...
non é solo per sysadmin:
almeno l'80/90% é utile a
sviluppatori e HTM
specie se hanno anche
compiti operativi
Limoncelli presenta il nucleo:
http://video.google.com/videoplay?
docid=7278397109952382318
idee chiave: focus &
interruzioni, lista TODO unica e
come gestirla, crearsi buone
abitudini, come prioritizzare
Aggiungo qualche consiglio specifico per HTM...
19

20. Time Mgmt 101 per HTM
programma molti brevi meeting periodici
se un meeting finisce presto, no problem
si cancella in caso di emergenze
gestire bene il meeting lo mantiene breve
la puntualità risparmia tempo per tutti
mai 2 meeting consecutivi!
pensa sempre a chi dovrebbe esserci
facile ma errato: quot;nel dubbio, invitaloquot;!-)
sii sempre pronto a cogliere le opportunità
laptop, libri, Blackberry/PDA, QCFPT
20

21. Time Mgmt 102 per HTM
considera ogni compito specificamente
deve davvero essere fatto?
sono la persona giusta per farlo?
quando sarebbe ottimale farlo?
non lasciare emergere le emergenze!
un rammendo in tempo salva il calzino
riserva ~50% del tuo tempo quot;disponibilequot;
ogni settimana per cose non ancora urgenti
un generale saggio mantiene una riserva
compiti rimandabili in casi di emergenze
non aspettare che diventino urgenti!-)
21

22. Estremamente Popolare:
decisamente non-specifico
(orientato ai manager, ma non
hi-tech)
ha molti veri e propri
entusiasti, un quot;movimentoquot;
http://www.davidco.com/
idee chiave: mente come
acqua, un singolo quot;in-basketquot;,
flusso strutturato, passi
d'azione, quot;regola dei 2 minutiquot;
non funziona appieno per me, ma per tanti altri sí!
22

23. 3. Si trascura il vero lavoro
il vero lavoro del manager consiste in
questo: coltiva la fiducia, interessati alle
persone, aiuta le squadre a formarsi, segui
accuratamente tutti i tuoi progetti, aiuta le
persone a crescere, concentrati sugli scopi
da raggiungere e le loro priorità
scrivere unit-test, discutere un progetto, o
una terribile sessione di debug, aiutano a
svolgere ciascuno di questi compiti!
e poi cosí anche noi ci divertiamo con un
poco di hacking al posto giusto, no?-)
23

24. Gestire Professionisti
sviluppatori = alta professionalitá
se i tuoi non l'hanno, é L'UNICO problema
rilevante x la tua squadra (o squadre)!!!
se lo sono, INVESTICI (SONO la risorsa +
importante, senza eccezioni)
il tuo compito: puntali nella direzione giusta,
coltiva le squadre, aiutali a crescere, tieni
d'occhio progressi, blocchi e rischi, coordina
NON il tuo compito: il MICROmanagement!-)
...e la MOTIVAZIONE...?
24

25. Cosa Ci Motiva
...ma, non vengono
Le idee di
necessariamente dal
Maslow sui
basso verso l'alto!
bisogni umani
Transcendenza
sono valide...:
Autorealizzazione
Bisogni Estetici
Bisogni Cognitivi
Bisogno di Stima
Bisogno di Appartenenza
Bisogno di Sicurezza
Bisogni Fisiologici
25

26. Motivazioni sul Lavoro
so cosa ci si aspetta da me
strumenti, materiali, ecc
spesso/di solito faccio cio`
che so fare meglio
ho stima, riconoscimenti
il manager si cura di me
quot; incoraggia a crescere
le mie opinioni contano
apprezzo la missione
la qualita` e` importante
26

27. Non sono denti d'ingranaggio
impara tutto quel che puoi sulle specifiche,
individuali forze e debolezze delle persone
specie i TLs & sotto-mgr, ma non solo loro
fa leva sulle loro forze
fa scudo alle loro debolezze, ma anche:
aiutali a crescere, rimuovere debolezze
coaching, corsi, libri, pair progr., ...
é una maratona, non i 100 metri piani!
fare richieste irragionevoli puo quot;bruciarequot; le
persone (attento al burnout!!!), ma...
fare solo richieste ragionevoli non offre
nessuna sfida (stretch goals)
27

28. É un gioco di squadra...!
Stellman, Greene, O'Reilly,
Berkun, Booch, Doctorow,
McConnell, Boehm, Fogel,
Martelli, Ambler, Oram...
28

29. 4. ma un mgr deve delegare
certo, ma, delegare cosa?
delegare non toglie responsibilità
resta sempre aggiornato su tutti i
progetti che guidi o coordini!
devi fidarti che gli sviluppatori facciano le
cose giuste -- ma, devi anche far la tua
parte, per permettergli di farle!
una volta che gli sviluppatori vedono che i
tuoi contributi tecnici sono eccellenti,
e si fidano che gli darai il dovuto credito,
ti vorranno coinvolto il + possibile!
29

30. La Fiducia...
30

31. Fiducia: inizia a casa tua...!
per meritarti la fiducia altrui devi anzitutto
meritarti la tua propria...!-)
This above all: to thine own self be true,
And it must follow, as the night the day,
Thou canst not then be false to any man
= non raccontarti storielle consolatorie...!
Non ti illudere, non dire che fu un sogno
che le orecchie ti ingannarono; rifiuta
queste vane speranze!
(C. Kavafis, quot;Il Dio Abbandona Antonioquot;)
31

32. Fiducia: la base dell'economia
The satisfaction we derive from being connected
to others in the workplace grows out of a
fundamental human desire for recognition.
32

33. La Fiducia...
é reciproca, e si costruisce col tempo
devi guadagnarti la fiducia degli sviluppatori
capacità tecnica, esercitata regolarmente
interesse vero in loro come individui
dai sempre riconoscimenti e credito
loro devono guadagnarsi la fiducia tua
capacità tecnica, integrità, focus
ma: inizia sempre quot;fidandoti di defaultquot;!
pre-req: assunzioni MOLTO selettive!-)
33

34. La fiducia: circolo virtuoso
34

35. Ancora sulla Fiducia
35

36. Fidati, ma verifica
→ delega, ma tieni d'occhio
quot;delegarequot; NON significa quot;abdicarequot;
→ resti pienamente responsabile se quel
che hai delegato salta per aria
→ responsabilitá quot;unita e separataquot;
strumenti per quot;tenere d'occhioquot; al meglio:
meeting quotidiani
burndown charts & altri quot;info radiatorsquot;
email automatica al commit di sorgenti
brevi, regolari meeting 1-on-1
36

37. Chi decide?
in ultima analisi, TU -- ma puoi decidere di
accettare la decisione di qualcun altro!
possono essere piú quot;sul pallonequot; di te
o x una decisione a basso impatto che
puó essere cambiate (se occorre) a basso
costo -- chance di imparare, di crescere
non occorre che quot;ti dimostriquot;: sei valutato,
alla fin fine, sul successo del progetto, non
sul tuo personale contributo al successo
quindi, quot;fatti da partequot; piú spesso!☺
37

38. 5. Spreco di talento tecnico?
non é uno spreco, é un leveraging!
in certe aziende il management é per chi
non ha piú nulla da contribuire sul piano
tecnico... ma non in quelle di successo!-)
quot;ma questo vale solo in fase di progettoquot;
ma no, per nulla!
quot;il diavolo sta nei dettagliquot;
e dove c'é un diavolo da combattere, é lí
che servono i migliori esorcisti!-)
38

39. 6. Interruzioni e Flusso
v. Limoncelli sul quot;gestire le interruzioniquot;
ne restano comunque tante da quot;servirequot;...:
tienti fuori dai quot;percorsi criticiquot; (o
garantisci i routing alternativi)
impara a capire cosa può aspettare 1 ora
impara a quot;salvare qualcosa sullo stackquot;,
dare immediata attenzione a qualcosa
d'altro, pop dello stack e continua liscio
alla fine, é possibile che uno non sia proprio
fatto per quot;multitaskingquot; -- ma qualunque
manager deve farne sempre parecchio!-(
39

40. Consigli vari e assortiti
you have to make a schedule... no programmer
wants to... most are only doing it because their
boss made them do it, halfheartedly, and nobody
actually believes the schedule...
40

41. Pianificazione e Schedule
ascolta Joel: la tecnologia appropriata é una
spreadsheet (o whiteboard + post-it, o
cartoncini...), non diagrammi PERT/GANTT
scegli compiti a grana molto fine (per
combattere l'ottimismo degli sviluppatori, e il
tuo personale!-), idealmente 2-3 giorni l'uno
considera nella schedule le vacanze, i
corsi, le malattie (combatti attivamente per
evitare il burnout!)
ascolta Cohn: stima la dimensione, deriva la
durata (e, usa unità arbitrarie * velocità)
41

42. Strumenti appropriati
cosa deve essere uniforme nella quot;squadraquot;?
stile del codice, nomi, spaziatura, idiomi
linguaggi, OS, librerie, framework di test,
controllo sorgenti, issue tracking
ma NON necess. editor, debugger, IDE...
strumento + importante: un buon sistema di
controllo dei sorgenti (e script accessori
per: continuous build, automatic tests, ...)
subito dopo: sistema di issue-tracking ben
integrato col sistema di controllo sorgenti
42

43. Uffici o Open Space?
DeMarco e Lister lottano per uffici
monopersona e con porta chiudibile
(Spolski pure, anche + intensamente)
...e la comunicazione?
Cockburn: osmosi e correnti d'aria
il problema dello quot;statusquot;
quot;radical colocationquot;
open-space? una-stanza-per-
squadra? quot;caverne e piazzaquot;?
quot;buoniquot; cubicoli? o che altro?
e` un problema aperto... o tre!-)
43

44. quot;Geometriaquot; di squadra
zona di lavoro in stile quot;Caverne e Piazzaquot;
quot;Piazzaquot; (area
di lavoro di
squadra)
Aree di lavoro
private
(quot;Cavernequot;)
44

45. E la pallottola d'argento?!
non c'é, ma tanti piccoli spilli tengono
lontani i mostri!-)
45

46. Applicare nuove conoscenze
affrontale sempre in modo critico
mettile alla prova dell'esperienza
prova nuove cose e idee un po' alla volta
il quot;Big Bangquot; non solo é rischioso (!),
ma offusca percezione ed analisi
usa soprattutto la tua esperienza, ma non
solo -- usa anche la mia, la sua, la loro...
NB: vale x tutti quei libri, ecc... ma anche x
questo stesso intervento!-)
46

47. http://www.aleax.it/itbes_sseci.pdf
Q?
A!
47

48. quot;Il Principequot;, N. Machiavelli
quot;Behind Closed Doorsquot;, J. Rothman, E. Derby
quot;Peoplewarequot;, T. DeMarco, T. Lister
quot;Agile & Iterative Developmentquot;, C. Larman
quot;Ship It!quot;, J. Richardson, W. Gwaltney
quot;Agile Estimating and Planningquot;, M. Cohn
quot;Object Solutionsquot;, G. Booch
quot;Agile Software Developmentquot;, R. Martin
quot;The Psychology of Computer Programmingquot;, G. Weinberg
quot;The Limits of Softwarequot;, R. Britcher
quot;Dreaming in Codequot;, S. Rosenberg
quot;Project Managementquot;, S. Berkun
quot;Software Runawaysquot;, R. Glass
quot;Working Effectively with Legacy Codequot;, M. Feathers
quot;Mintzberg on Managementquot;, H. Mintzberg
quot;FIT for Developing Softwarequot;, R. Mugridge, W. Cunningham
quot;Death Marchquot;, E. Yourdon
quot;The Mythical Man-Monthquot;, F. Brooks
quot;Time Management for System Administratorsquot;, T. Limoncelli
quot;The Art of Warquot;, Sun Zi
quot;How to Lose a Battlequot;, B. Fawcett
quot;Getting Things Donequot;, D. Allen
quot;Trustquot;, F. Fukuyama
quot;The Evolution of Cooperationquot;, R. Axelrod
quot;The Speed of Trustquot;, S. Covey
quot;The Origins of Virtuequot;, M. Ridley
quot;Beautiful Teamsquot;, A. Stellman, J. Greene, et al.
quot;Competing on the Edgequot;, S. Brown, K. Eisenhardt
quot;The Elements of Great Managingquot;, R. Wagner, J. Harter
quot;Joel on Softwarequot;, J. Spolsky
quot;Agile Software Development: The Cooperative Gamequot;, A. Cockburn
48