ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 126
Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 13
Abonament PDF

Din uneltele artizanului software: Coaching tehnic

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works



DIVERSE

Știm din experiența industriei că tehnicile promovate de mișcarea software craftsmanship au potențialul de a crește productivitatea echipelor de dezvoltare. Test Driven Development ajută la obținerea unor soluții cu design mai bun și mai.. . stabile într-un timp mai scurt.

Pair Programming ajută la eliminarea greșelilor în timp ce codul este produs, la diseminarea rapidă a cunoștințelor într-o echipă și la găsirea unor soluții mai simple. Continuous Integration ajută la rezolvarea rapidă și fără stress a problemelor de integrare între diverse componente. Refactoring-ul continuu ajută la păstrarea flexibilității codului, astfel că atunci când clienții cer funcționalități neprevăzute, echipa să le poată introduce foarte repede.

Există însă și reversul medaliei. Test Driven Development poate duce la teste greu de întreținut și la abandonarea lor în timp. Refactoring-ul este adesea înțeles ca "iterații" sau "perioade" de refactoring, care se pot lungi săptămâni întregi, uneori fără niciun rezultat. Încercarea de a face pair programming poate fi interpretată ca neîncredere în programatori: "vine cineva să mă supravegheze când scriu cod". Continuous integration poate genera multe probleme când este aplicat pe proiecte care au zeci de componente diferite, rezultând într-un return of investment discutabil.

Ce anume face diferența între exemplele de succes și cele de eșec? Ce poate conduce către o adopție de succes?

Răspunsul constă în gestionarea schimbării. Aici intervine partea de coaching; în acest caz, din cauză ca practicile ce se doresc adoptate sunt uber-tehnice, vorbim de coaching tehnic.

Adopția practicilor tehnice într-o organizație

Un coach tehnic se preocupă de câteva aspecte importante ale adopției unei practici:

  • Identificarea scopului: de ce adoptăm practica respectivă? Dintr-un motiv de business (ex. reducerea ciclului de release de la 12 la 3 luni, de la 3 luni la 2 săptămâni, continuous delivery, creșterea satisfacției clienților)? Dintr-unul operațional (ex. reducerea numărului de unbillable hours, reducerea numărului de apeluri la suport)? Motive gen "am auzit de TDD și e cool", "am auzit de practica X și ne va ajuta" nu sunt îndeajuns de bune; un coach poate ajuta la identificarea practicilor tehnice potrivite pentru atingerea obiectivelor organizației.
  • Definirea unui roadmap de adopție. De obicei este definit un proiect pilot în cadrul căruia 2-4 echipe se oferă voluntare pentru adopție. Rezultatele adopției sunt monitorizate și discutate în continuu cu managementul.
  • Identificarea și gestiunea riscurilor. Unele riscuri sunt vizibile de la început (de exemplu lipsa cunoștințelor necesare pentru a scrie teste unitare simple, un release plasat în timpul perioadei de coaching), pe când altele apar pe parcursul adopției.
  • Lucrul direct, hands-on, pe codul de producție cu echipele de programatori.
  • Mini-training-uri ad-hoc, în funcție de necesități.
  • Introducerea unor comunități de exersare (communities of practice), unde orice persoana interesată poate vedea și încerca practicile care se vor adoptate.

Coach-ul tehnic poate fi intern sau extern companiei care încearcă să adopte TDD, refactoring, sau chiar Extreme Programming. Ambele abordări au avantaje și dezavantaje. Coach-ul intern are avantajul că înțelege structura companiei și proiectele, dar are de obicei dezavantajul că face parte din sistem și îi este mai greu să vadă anumite lucruri care trebuie schimbate. Un coach extern are câteva avantaje ce merită luate în seamă:

  • Experiența cu echipe și contexte diverse: un coach tehnic specializat trece prin zeci de echipe și proiecte, prin tehnologii și soluții diverse. Această experiență îi permite să se adapteze rapid la un mediu nou.
  • Relațiile cu alți consultanți, coach-i tehnici sau programatori de elită: parte din job-ul de coach tehnic este învățarea și vorbitul la conferințe. Un coach tehnic bun își creează o rețea de cunoștințe care îi pot răspunde la întrebări tehnice mai specifice, ajutând la rezolvarea mai rapidă a unor probleme spinoase.
  • Leadership și comunicare: un coach tehnic bun trebuie să fie capabil ca împreună cu managerii, să definească o viziune pe care să o urmeze dezvoltatorii și să o comunice convingător.

Este uneori dificil de înțeles cum un coach tehnic extern poate deveni foarte rapid productiv într-o echipă și într-o aplicație complet nouă. Pare magie, nu-i așa? Explicația este de fapt simplă: coach-ul tehnic nu trebuie să înțeleagă business-ul și toate detaliile interne ale aplicației. Produsul coach-ului este echipa; echipa se îngrijește de a înțelege aplicația și business-ul. Coach-ul tehnic se bazează pe cunoștințe solide despre practicile care se vor adoptate și pe pattern-uri de arhitectură, design, cod și interacțiune interumană pentru a duce întreaga echipă la un nivel mai înalt de productivitate. Coach-ul nu poate lucra fără echipă, la fel cum produsul software nu poate fi creat fără echipă. Doar printr-o colaborare strânsă cu echipa, prin discuții și comunicare sinceră și continuă, prin încredere și respect reciproc, poate coach-ul să ajute echipa să adopte o practică nouă.

Adopția practicilor tehnice la nivel individual

Până acum am prevăzut unele aspecte despre adopția unei practici tehnice noi într-o companie. La nivel individual, lucrurile sunt similare dar mult mai simple.

Un programator motivat și care are condițiile necesare poate să învețe singur o practică tehnică nouă. Folosirea tehnicilor individuale de exersare precum coding kata sau proiect personal este recomandată în combinație cu urmărirea resurselor de pe web (ex. http://katacasts.org) și citirea a două-trei cărți recomandate pe subiectul respectiv. Mai departe, totul ține de tenacitate, voință și automotivare. Participarea la coding dojo, code retreat sau conferințe tehnice este utilă pentru menținerea motivării. Pair programming-ul cu persoane selectate este o altă metodă care poate fi aplicată pentru continuarea învățarii.

Nu toți dezvoltatorii au însă voința și automotivarea necesară pentru a dobandi o aptitudine. Pentru ei, un coach tehnic este unul din mijloacele de a-și atinge scopul de a învăța o practica tehnică prin:

  • Identificarea punctelor tari și punctelor care pot fi îmbunătățite. De exemplu, înțelege cod foarte repede dar scrie teste unitare prea complicate;
  • Stabilirea scopului pe următoarele 3-4 luni. De exemplu, simplificarea testelor unitare;
  • Definirea unui plan de învățare format din: citit cărți, scrierea de cod revizuit de către coach, sesiuni de pair programming etc;
  • Urmărirea programului de învățare. Coach-ul se asigură că programatorul se ține de promisiuni, și îl/o ajută să elimine blocajele care apar în învățare.

La nivel individual, activitățile de coaching sunt foarte similare cu cele de mentoring sau relația craftsman - master. Un coach tehnic ajută în plus față de un mentor tradițional la identificarea și reducerea impedimentelor. Impedimentul tipic declarat de către programatori este lipsa de timp de învățare, care poate fi ușor rezolvat prin: sesiuni de învățare scurte (30-45" pe zi), planificare mai bună sau sesiuni mai intense și mai rare (ex. pair programming, coding dojos sau code retreats).

Merită explicat rolul pair programming-ului în procesul de învățare, pentru că este uneori confuz. Pair programming poate fi folosit în producție, pentru învățarea proiectului și pentru prevenirea greșelilor din cod. În contextul adoptării unei practici, pair programming-ul poate fi folosit ca modalitate prin care coach-ul tehnic transmite cunoștințele sale legate de o anumită practică a programatorului. Pentru a aplica pair programming în producție, este nevoie de asemenea de o perioadă de adopție, iar adoptarea pair programming se face prin sesiuni de pairing între doi programatori, sub supervizarea coach-ului tehnic. În timp ce programatorii se concentrează să rezolve problema la care lucrează, coach-ul se va concentra pe interacțiunea dintre cei doi și pe eliminarea problemelor de comunicare și a discuțiilor ineficiente. Așadar, e o diferența majoră între adoptarea pair programming, folosirea tehnicii în producție și învățarea altor tehnici prin intermediul pair programming. Coach-ul tehnic trebuie să stăpânească foarte bine tehnicile de pairing, pentru a reuși să transmită informație chiar acelor programatori care nu au făcut niciodată pairing dar vor să învețe una din tehnicile descrise mai sus.

Concluzie

În concluzie, un coach tehnic gestionează procesul de adopție a uneia sau mai multor practici tehnice la nivel individual, de echipă sau cu 2-4 echipe. Expertiza sa poate face diferența între succes și eșec când o companie sau un programator dorește adopția practicilor gen unit testing, TDD, refactoring incremental, îmbunătățirea design-ului software, diminuarea problemelor legate de cod existent greu de înțeles.

Coach-ul poate fi intern sau extern organizației. Avantajul unui coach intern este familiarizarea cu contextul organizației și al aplicațiilor, dar dezavantajul unei experiențe limitate și a faptului că face parte din sistem. Un coach extern are că avantaj faptul că a participat în zeci de proiecte cu constrângeri și nevoi diferite și ca poate privi organizația cu ochi proaspeți, din afara sistemului. Coach-ul extern trebuie să înțeleagă doar punctual nevoile de business și ale aplicației, și se încrede în echipa cu care lucrează în legătură cu detaliile specifice proiectului. Produsul coach-ului tehnic este echipa; o echipă care învață tehnici noi, pe care le poate aplica direct în producție cu încredere, reușind în același timp să își atingă obiectivele de business. Colaborarea strânsă între coach tehnic și echipă, bazată pe respect reciproc, comunicare și sinceritate este principalul factor de succes al adopției. După perioada inițială de coaching, echipa are instrumentele necesare pentru a continua învățarea, coach-ul având doar un rol de suport ("vocea conștiinței").

Gândiți-vă așadar ce ratați de fiecare dată când spuneți că nu aveți timp de a adopta o anumită practică. Poate pierdeți clienți, oportunități, potențial inovator, un job mai bun. Un coach tehnic vă poate ajuta să decideți care practică este utilă în contextul business-ului și al aplicațiilor curente și vă poate ajuta să adoptați practicile care duc la împlinirea potențialului.

Așteptăm întrebările voastre pe programez.ro !!!

VIDEO: NUMĂRULUI 126

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Colors in projects