Alex Martelli - Sviluppo Software: Esperienze, Consigli e Idee

744 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
744
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Alex Martelli - Sviluppo Software: Esperienze, Consigli e Idee

  1. 1. Sviluppo di Software Esperienze, Consigli ed Idee Alex Martelli http://www.aleax.it/itbes_sseci.pdf ©2009 Google -- aleax@google.com
  2. 2. C'è la Pallottola d'Argento? ...un singolo modo di far fuori tutti i mostri? 2
  3. 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. 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. 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. 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. 7. Chi É un Manager? 7
  8. 8. Il quot;Livelloquot; A Cui Parlo Shu (quot;Imparaquot;) Ha (quot;Distaccaquot;) Ri (quot;Trascendiquot;) 8
  9. 9. Un modo di imparare... ...è con buoni libri -- ce ne sono tanti...! 9
  10. 10. Ars longa, vita brevis... piú ottimi libri, che tempo per leggerli!-) 10
  11. 11. Ovviamente il + importante... ... é quot;Il Principequot;!-) 11
  12. 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. 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. 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. 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. 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. 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. 18. Working Long Hours Productivity ($/hour) Average Hours Worked per Week 18
  19. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28. É un gioco di squadra...! Stellman, Greene, O'Reilly, Berkun, Booch, Doctorow, McConnell, Boehm, Fogel, Martelli, Ambler, Oram... 28
  29. 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. 30. La Fiducia... 30
  31. 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. 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. 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. 34. La fiducia: circolo virtuoso 34
  35. 35. Ancora sulla Fiducia 35
  36. 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. 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. 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. 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. 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. 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. 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. 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. 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. 45. E la pallottola d'argento?! non c'é, ma tanti piccoli spilli tengono lontani i mostri!-) 45
  46. 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. 47. http://www.aleax.it/itbes_sseci.pdf Q? A! 47
  48. 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

×