alex martelli - sviluppo software: esperienze, consigli e idee
DESCRIPTION
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.TRANSCRIPT
©2009 Google -- [email protected]
Sviluppo di Software
Esperienze, Consigli ed IdeeAlex Martelli
http://www.aleax.it/itbes_sseci.pdf
C'è la Pallottola d'Argento?...un singolo modo di far fuori tutti i mostri?
2
NON Parlo Di...(per nulla) gestione strategica/esecutiva
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 "Agilitá":
nè un rigido Waterfall,nè un Caos totale!-)
3
Agile vs Waterfall vs ChaosWaterfall: 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 "metodologie agili" 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
Agilita` Strategica
5
...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 strategic challenge is managing that change.
E Allora di Che Parlo?comunico le mie esperienze (a Google e prima, da sviluppatore, tech lead, manager: non aneddoti ma "il succo")
su UN buon modo di organizzare, fare e gestire lo sviluppo softwarene esistono anche altri, eh!-)
attacco alcune tesi molto popolarie raccomando libri che le difendono!-)
"tips & tricks" (buoni x molti, molti casi...)il tutto arrangiato "dialetticamente"...;-)
6
Chi É un Manager?
7
Il "Livello" A Cui Parlo
8
Shu
Ha
Ri
("Impara")
("Distacca")
("Trascendi")
Un modo di imparare...
9
...è con buoni libri -- ce ne sono tanti...!
Ars longa, vita brevis...
10
piú ottimi libri, che tempo per leggerli!-)
Ovviamente il + importante...
11
... é "Il Principe"!-)
Un'Opinione Diffusa
12
“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)
E un Dissenso da Essa
13
“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 "tech lead" (ingegnere responsabile di UN progetto) da "uber tech lead" e "tech lead/manager" ("highly technical managers" == HTM), ma tutti questi gruppi soddisfano questa definizione.
Un modo di essere un HTM
14
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 "risorsa tecnica 'Jolly'"
non per i compiti + "divertenti", maper 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...
Non Può Andare, Perché...
15
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 "vero" 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 "zona" (o "flow")!7. ...aggiungi le tue obiezioni personali...:-)
1. La Legge di Brooks
16
"Aggiungere programmmatori a un progetto software in ritardo
lo ritarda anche di piú" Si, ma: tutti scordano sempre di citare anche l'inizio della frase: "Sovrasemplificando in modo oltraggioso, asseriamo"...!-)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
2. Come si trova il tempo?
17
NON lavorando sempre piú ore la settimanamira 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 "time management" funziona, se ben fatto
Working Long Hours
18
Average Hours Worked per Week
Prod
uctivit
y ($
/hou
r)
Time Management per ...
19
non é solo per sysadmin:almeno l'80/90% é utile a sviluppatori e HTMspecie 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...
Time Mgmt 101 per HTM
20
programma molti brevi meeting periodicise un meeting finisce presto, no problemsi cancella in caso di emergenzegestire bene il meeting lo mantiene brevela puntualità risparmia tempo per tutti
mai 2 meeting consecutivi!pensa sempre a chi dovrebbe esserci
facile ma errato: "nel dubbio, invitalo"!-)sii sempre pronto a cogliere le opportunità
laptop, libri, Blackberry/PDA, QCFPT
Time Mgmt 102 per HTM
21
considera ogni compito specificamentedeve 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 "disponibile" ogni settimana per cose non ancora urgenti
un generale saggio mantiene una riservacompiti rimandabili in casi di emergenzenon aspettare che diventino urgenti!-)
Estremamente Popolare:
22
decisamente non-specifico (orientato ai manager, ma non hi-tech)ha molti veri e propri entusiasti, un "movimento"http://www.davidco.com/idee chiave: mente come acqua, un singolo "in-basket", flusso strutturato, passi d'azione, "regola dei 2 minuti"
non funziona appieno per me, ma per tanti altri sí!
3. Si trascura il vero lavoroil 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
Gestire Professionistisviluppatori = 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, coordinaNON il tuo compito: il MICROmanagement!-)...e la MOTIVAZIONE...?
24
Cosa Ci Motiva
25
TranscendenzaAutorealizzazioneBisogni EsteticiBisogni CognitiviBisogno di Stima
Bisogno di AppartenenzaBisogno di Sicurezza
Bisogni Fisiologici
Le idee di Maslow sui
bisogni umani sono valide...:
...ma, non vengono necessariamente dal basso verso l'alto!
Motivazioni sul Lavoro
26
so cosa ci si aspetta da mestrumenti, materiali, eccspesso/di solito faccio cio` che so fare meglioho stima, riconoscimentiil manager si cura di me " incoraggia a crescerele mie opinioni contanoapprezzo la missionela qualita` e` importante
Non sono denti d'ingranaggioimpara tutto quel che puoi sulle specifiche, individuali forze e debolezze delle persone
specie i TLs & sotto-mgr, ma non solo lorofa leva sulle loro forzefa scudo alle loro debolezze, ma anche:
aiutali a crescere, rimuovere debolezzecoaching, corsi, libri, pair progr., ...é una maratona, non i 100 metri piani!
fare richieste irragionevoli puo "bruciare" le persone (attento al burnout!!!), ma...
fare solo richieste ragionevoli non offre nessuna sfida (stretch goals)
27
É un gioco di squadra...!
28
Stellman, Greene, O'Reilly, Berkun, Booch, Doctorow, McConnell, Boehm, Fogel, Martelli, Ambler, Oram...
4. ma un mgr deve delegarecerto, 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
La Fiducia...
30
Fiducia: inizia a casa tua...!
31
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, "Il Dio Abbandona Antonio")
Fiducia: la base dell'economia
32
The satisfaction we derive from being connected to others in the workplace grows out of a fundamental human desire for recognition.
La Fiducia...
33
é reciproca, e si costruisce col tempodevi guadagnarti la fiducia degli sviluppatori
capacità tecnica, esercitata regolarmenteinteresse vero in loro come individuidai sempre riconoscimenti e credito
loro devono guadagnarsi la fiducia tuacapacità tecnica, integrità, focusma: inizia sempre "fidandoti di default"!
pre-req: assunzioni MOLTO selettive!-)
La fiducia: circolo virtuoso
34
Ancora sulla Fiducia
35
Fidati, ma verifica
36
→ delega, ma tieni d'occhio"delegare" NON significa "abdicare"→ resti pienamente responsabile se quel che hai delegato salta per aria→ responsabilitá "unita e separata"
strumenti per "tenere d'occhio" al meglio:meeting quotidianiburndown charts & altri "info radiators"email automatica al commit di sorgentibrevi, regolari meeting 1-on-1
Chi decide?in ultima analisi, TU -- ma puoi decidere di accettare la decisione di qualcun altro!
possono essere piú "sul pallone" di teo x una decisione a basso impatto che puó essere cambiate (se occorre) a basso costo -- chance di imparare, di crescerenon occorre che "ti dimostri": sei valutato, alla fin fine, sul successo del progetto, non sul tuo personale contributo al successoquindi, "fatti da parte" piú spesso!☺
37
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!-)"ma questo vale solo in fase di progetto"
ma no, per nulla!"il diavolo sta nei dettagli"e dove c'é un diavolo da combattere, é lí che servono i migliori esorcisti!-)
38
6. Interruzioni e Flussov. Limoncelli sul "gestire le interruzioni"ne restano comunque tante da "servire"...:
tienti fuori dai "percorsi critici" (o garantisci i routing alternativi)impara a capire cosa può aspettare 1 oraimpara a "salvare qualcosa sullo stack", dare immediata attenzione a qualcosa d'altro, pop dello stack e continua liscio
alla fine, é possibile che uno non sia proprio fatto per "multitasking" -- ma qualunque manager deve farne sempre parecchio!-(
39
Consigli vari e assortiti
40
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...
Pianificazione e Schedule
41
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'unoconsidera 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à)
Strumenti appropriaticosa deve essere uniforme nella "squadra"?
stile del codice, nomi, spaziatura, idiomilinguaggi, OS, librerie, framework di test, controllo sorgenti, issue trackingma 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
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 "status""radical colocation"open-space? una-stanza-per-squadra? "caverne e piazza"? "buoni" cubicoli? o che altro?e` un problema aperto... o tre!-)
43
zona di lavoro in stile "Caverne e Piazza"
"Geometria" di squadra
44
"Piazza" (area di lavoro di squadra)
Aree di lavoro private
("Caverne")
E la pallottola d'argento?!non c'é, ma tanti piccoli spilli tengono lontani i mostri!-)
45
Applicare nuove conoscenzeaffrontale sempre in modo criticomettile alla prova dell'esperienza
prova nuove cose e idee un po' alla voltail "Big Bang" 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
http://www.aleax.it/itbes_sseci.pdf
47
Q?A!
48
"Il Principe", N. Machiavelli"Behind Closed Doors", J. Rothman, E. Derby
"Peopleware", T. DeMarco, T. Lister"Agile & Iterative Development", C. Larman
"Ship It!", J. Richardson, W. Gwaltney"Agile Estimating and Planning", M. Cohn
"Object Solutions", G. Booch"Agile Software Development", R. Martin
"The Psychology of Computer Programming", G. Weinberg"The Limits of Software", R. Britcher
"Dreaming in Code", S. Rosenberg"Project Management", S. Berkun"Software Runaways", R. Glass
"Working Effectively with Legacy Code", M. Feathers"Mintzberg on Management", H. Mintzberg
"FIT for Developing Software", R. Mugridge, W. Cunningham"Death March", E. Yourdon
"The Mythical Man-Month", F. Brooks"Time Management for System Administrators", T. Limoncelli
"The Art of War", Sun Zi"How to Lose a Battle", B. Fawcett
"Getting Things Done", D. Allen"Trust", F. Fukuyama
"The Evolution of Cooperation", R. Axelrod"The Speed of Trust", S. Covey
"The Origins of Virtue", M. Ridley"Beautiful Teams", A. Stellman, J. Greene, et al.
"Competing on the Edge", S. Brown, K. Eisenhardt"The Elements of Great Managing", R. Wagner, J. Harter
"Joel on Software", J. Spolsky"Agile Software Development: The Cooperative Game", A. Cockburn