©2009 Google -- aleax@google.com

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