Team buildingul este o activitate importanta in cadrul echipei, ce are ca rol principal eficientizarea raporturilor intre membrii unei echipe prin imbunatatirea relatiilor dintre acestia. Ideea este ca prin activitati ludice si/sau relaxante care nu sunt direct legate de activitatea pe care membrii echipei o desfasoara acestia sa se cunoasca mai bine, sa devina mai apropiati si sa lucreze mai bine unii cu altii.

Cadrul in care au loc aceste activitati este mult mai putin formal decat atmosfera normala de birou, astfel invitand la deschidere.

Atenție: Pentru a fi vazute pozitiv de catre membrii echipei si nu ca o intruziune in spatiul personal, activitatile de team building trebuiesc realizate in timpul programului de lucru (si platite ca atare).

Activitatile de team building se pot incadra in activitati de scurta durata, si activitati de lunga durata. Cele de scurta durata implica jocuri de birou, mese organizate s.a. recomandate a avea loc cel putin o data pe saptamana, in timp ce cele de lunga durata inseamna in general deplasari la locatii specializate teambuilding (un exemplu la noi in tara ar fi gradina de corzi)

Scopurile urmarite prin jocurile de team building sunt foarte variate: * de cunoastere, pentru grupuri noi formate * de colaborare, pentru a imbunatiti colaborarea unui grup * de competitie intre echipe, pentru a strange legaturile din cadrul grupului * de comunicare

Se impart participantii in echipe de 3-10 persoane (cel putin 2 echipe) Conducatorul de joc spune ce trebuie sa se “lege”, si echipele incearca sa urmeze isntructiunile. Prima echipa care termina, anunta conducatorul care verifica si daca e corect echipa respectiva castiga runda. Legatul inseamna ca atatea membre cate anunta conducatorul de joc sa se atinga. Exemplu: * “6 genunchi si 10 degete.” * “3 degete mari, 4 coate si 5 glezne.” * Se pot folosi si obiecte: “4 genunchi,5 mobile si 3 degete.”

Toti membrii echipei trebuie sa participe.

Toti participantii se afla pe o barca de salvare dar care nu ii poate tine pe toti asa ca 2 -3 dintre ei trebuie aruncati peste bord. Fiecare are voie sa pledeze pentru el(2 minute maxim), dupa aceea pot sa dezbata(10-15 minute) si la sfarsit se voteaza.

Se impart participantii in 2 sau mai multe echipe. Fiecare echipa scrie o lege, utile si corecta din punctul lor de vedere care nu exista inca. Celelalte echipa incearca sa gaseasca “loop-holes” sau sa spuna de ce legea nu e buna.

Exercitiu: Ce urmareste fiecare din cele 3 jocuri?

Multe echipe preferă să-și organizeze timpul in perioade de programare numite sprinturi. Sprinturile pot avea de la o saptamana până la patru săptămâni. La începutul fiecărui sprint teamleadul împreună cu echipa stabilește obiectivele pentru următorul sprint. Obiectivele sunt împărțite în taskuri și pentru fiecare task se estimează timpul necesar rezolvării lui și o prioritate. La sfârșitul sprintului trebuie să se prezinte un prototip îmbunătățit fața de prototipul din sprintul precedent cu facilitățile stabilite la începutul sprintului. Evident, nu totdeauna sunt îndeplinite obiectivele (din experiența mea, niciodată), dar estimarea trebuie să fie aproape de posibilitățile programatorilor. Pentru organizarea sprinturilor se foloseste ceva similar cu spreadsheetul pe care l-ați primit de la Lucian.

Atenție: un task este considerat terminat după documentare, testare și code review. Dacă eu mi-am asumat taskul “Implementarea funcției de sortare a unor șiruri de caractere” atunci trebuie să scriu cum se apeleaza librăria mea și teste care imi oferă o garanție.

ps. Dacă (mai) aud povești de genul “am primit la testat niște surse pline de buguri și fără unitteste (de codereview nici nu mai vorbesc)” vă fac code review la tot proiectul. Adriana știe.

Hackthon-urile sunt sprinturi foarte surte (1-2 zile) și sunt în special utile pentru a dezvolta prototipuri pentru diverse idei (sau, presimt eu, rezolvări de teme la MPS). Atenție hackathonurile se pot transforma ușor în marșuri ale morții. Perioada de codare trebuie menținută sub 8 ore (începând de dimineața). După 9 ore de codat rata greselilor creste cu 60%, iar după 12 mai mult ca sigur că reparați buguri înlocuindu-le cu alte buguri. Pașii unui hackaton sunt aceeiași ca la un sprint normal: planificare, codare, evaluare, reluare. Planificarea e foarte importantă, iar organizatorul (de obicei team-leadul) trebuie să distribuie taskurile ca timpul pierdut în așteptare să fie minim. Evident, socoteală de acasă nu se potrivește totdeauna cu cea din târg, și team-leadul se va orienta pe moment pentru a minimiza timpul de frecat menta. Hackatonurile sunt cel mai bine organizate în maxim 5 persoane (multe persoane creaza prea multe probleme) și fără o constrângere de timp (gen, mâine dimineața avem prezentarea unui demo la care n-am scris încă o linie (acesta e un exemplu de marș al morții)).

ps. O altă greșeală frecventă este impresia că codatul ține de foame.

Deși cea mai mare parte din desfășurarea unui proiect este axată pe planificare, modelare, implementare, testare, o componentă foarte importantă o reprezintă întâlnirile între membrii echipei. Întâlnirile pot avea rolul de planificare, de evaluare a stării curente a unui proiect, de prezentare de soluții la probleme sau de generare de idei utile în elaborarea proiectului.

În mod tradițional, întâlnirile au loc într-o locație fizică între diverși membri ai echipei. Cu toate acestea, o dată cu dezvoltarea Internetului au apărut și alte forme de comunicare. Utile pentru persoanele pentru care distanța fizică este o problemă, întâlnirile telefonice (call-uri) sau conferințele video reprezintă o alternativă din ce în ce mai răspândită la formele tradiționale de întâlnire.

Întâlnirile au un rol foarte important în realizarea comunicării eficiente între diverși membri ai echipei. Întâlnirile bine realizate pot conduce la sporirea gradului de organizare în cadrul unei echipe sau firme.

În general, în cadrul unui proiect, există întâlniri periodice de evaluare a stării curente a proiectului. Există de asemenea, întâlniri de stabilire a planului de acțiune pentru perioada următoare sau sesiuni de brainstorming. Întâlnirile pot avea loc între project manager și diverși membri ai echipei (project status oriented) sau între membrii unei echipe sub coordonarea liderului de echipă (technical status/solution oriented).

Pot exista întâlniri face-to-face, întâlniri telefonice sau întâlniri video (video-conferințe).

Indiferent dacă o întâlnire a fost sau nu planificată, există un set de întrebări care trebuie răspunse înainte de organizarea efectivă a unei întâlniri.

# Care este principalul obiectiv? # Care sunt criteriile de apreciere a succesului unei întâlniri? # Care este relația dintre tine și ceilalți în cadrul întâlnirii? # Care este tipul de participare așteptat de la ceilalți? # Este nevoie de o pregătire specială înainte de organizarea întâlnirii?

Răspunzând la întrebările de mai sus înainte de organizarea unei întâlniri neplanificate, se pot clarifica * ce se dorește să se obțină în urma întâlnirii * cine ar trebui să fie implicat * cum se măsoară succesul rezultatelor obținute

Un set de acțiuni care trebuie luate înainte de organizarea unei întâlniri sunt:

# Decizie cine trebuie să participe la întâlniri. # Planificarea intervalului de timp în care va avea loc întâlnirea, împreună cu persoanele care vor participa la întâlnire. Se va preciza clar ce se va discuta la o întâlnire și cât de mult va dura. # Planificarea unei locații care să permită discuții constructivă și să nu permită apariția întreruperilor. # Crearea unei agende temporale pentru adresarea diverselor aspecte mentionate. # Distribuirea agendei cu mult timp înainte de organizarea întâlnirii, cu solicitarea de moficări sau adăugiri # În momentul începerii întâlnirii trebuie să existe o persoană care va coordona întâlnirea și va facilita discuțiile. # Coordonatorul întâlnirii trebuie să stimuleze și să clarifice comunicarea, sumarizând aspectele punctate. # Consensul trebuie încurajat, fără a fi scopul final # Dacă este nevoie de mai multă informație pentru luarea de decizii, se stabilește o altă întâlnire cu “teme pentru acasă”. # La sfârșitul unei întâlnirii clarifică ceea ce s-a întâmplat și care sunt următorii pași. # Distribuie un sumar al deciziilor la care s-a ajuns în urma întâlnirii, inclusiv data și timpul întâlnirilor viitoare.

Unele întâlniri planificate pot avea timpi morți. Există situații în care organizarea unor întâlniri neplanificate să aibă un impact mai mare decât organizarea unor întâlniri planificate. Colectarea aspectelor și informațiilor precizate pe parcursul unei întâlniri și furnizarea acestora tuturor persoanelor avizate, fie că au participat fie că nu au participat, sunt importante pentru a comunica esența întâlnirii.

Nu trebuie să existe presupunerea că toată lumea cunoaște scopul întâlnirii. Obiectivele întâlnrii trebuie precizate și reamintite la începutul acesteia.

Este, în general, o idee bună ca o întâlnire să abordeze cât mai puține aspecte. Cu cât sunt mai puține sarcini descrise pe parcursul unei întâlniri, cu atât întâlnirea va avea rezultate mai bune

De asemenea, întâlnirea trebuie să aibă un set de obiective măsurabile. Aceasta oferă un scop de urmat pe parcursul întâlnirii și permite cuantificarea succesului întâlnirii.

În general persoana desemnată coordonator al întâlnirii are rolul de a menține constructivismul discuțiilor. De obicei, coordonatorul trebuie să aibă o implicare limitată în discuție (nu trebuie să dețina rol activ), scopul fiind acela de dirijare a discuției și încadrarea în timpul alocat. În general, un bun coordonator va avea grijă ca: * întâlnirea să respecte scopul stabilit * întâlnirea să urmărească agenda * întâlnirea să se se încadreze în timp * să existe dezbateri constructive * să se asigure că fiecare persoană aduce o participare valorificată

Brainstorming este o tehnică de grup creativă proiectată pentru a genera un număr mare de idei pentru soluția unei probleme. Deși nu s-a dovedit impactul creativ al sesiunilor de brainstorming în cadrul unui proiect, aceste tipuri de acțiuni au ca efect sporirea nivelului de relaxare și divertisment în cadrul grupului și creșterea moralului.

Un set de utilitare precum FreeMind și Mind Manager sunt folosite pentru brainstorming/mind-mapping.

* În cadrul săptămânii următoare se va realiza o întâlnire de ansamblu a echipei și întâlniri pentru fiecare componentă a proiectului vostru. Pentru fiecare întâlnire stabiliți următoarele: Când va avea loc? Cât timp va dura? Unde va avea loc? Cine va participa? Care va fi obiectivul întâlnirii? Ce aspecte vor fi punctate? Care va fi rolul fiecărui participant? Care sunt rezultatele așteptate ale întâlnirii? == Controlul comunicației (Lucian) == Cele mai importante resurse pe care un proiect le are sunt: atenția și concentrarea dezvoltatorilor. Anumite tipuri de oameni au tendința de a distrage și a spulbera atenția celor care ar trebui să continue dezvoltarea proiectului sau să repare bug-uri. Comunitatea din jurul unui proiect trebuie să evite intrarea în impas, divagarea sau pierderea de membri. Pentru a crea o comunitate în care să se poată lucra, comunicația trebuie să fie bazată pe: * politețe - dacă unii dintre membrii proiectului se adresează în mod vulgar, indecent, etc. față de alți membri și nimeni din comunitate nu ia atitudine, membrii atacați pot să părăsească proiectul sau pot porni discuții interminabile (“flame”-uri) poluând mediul de comunicație, ducând la irosirea timpului membrilor comunității. * respect - * încredere - Anumiți membri ai proiectului pot (posibil neintenționat) să: * distragă atenția dezvoltatorilor, * distrugă spiritul echipei, * genereze lupte interne nesfârșite. Perfecționiștii sunt una din categoriile care pot să întârzie (neintenționat sau chiar cu cele mai bune intenții) evoluția proiectului prin discuții interminabile: “The perfect is the enemy of the good”. Nu trebuie să se discute interminabil nici pe teme care se referă la elemente de bază ale proiectului. Un site care descrie problema: http://bikeshed.com/. * Release early, release often. * Premature optimisation is the root of all evil. Trebuie să existe și să se respecte o etichetă a listei de discuții (desigur, regulile trebuie specificate după tipul comunității). * nu reîncepeți discuții vechi (mai ales discuții lungi/flame-uri). Pentru a evita reînceperea unei discuții faceți o referire la mesajele vechi și încheiați firul de discuție nou început. * nu trimiteți răspunsuri la fiecare mesaj dintr-un fir de discuție: s-ar putea să fi-ți în situația în care Documentați istoria proiectului pentru a nu fi nevoiți să explicați și reexplicați de ce anumite lucruri sunt așa cum sunt: * deciziile de proiectare * bug-fix-urile * greșelile comise * modificările făcute de-a lungul timpului, și la fiecare etapă (ChangeLog). Impuneți anumite practici de colaborare: citiți codul scris / modificările efectuate de ceilalți membri ai echipei. Nu efectuați modifcări care pot produce probleme celorlalți membri ai proiectului în trunk, dar nici nu lucrați offline până când terminați lucrul la o anumită componentă pentru a nu introduce modificări masive dintr-o dată: se pierde istoria acelor modificări; folosiți suportul de branching al sistemului de gestiune a versiunii. Evitați semnarea în fișierele asupra cărora lucrați (de ex. trecerea unui câmp @author la începutul fișierului): veți crea impresia că sunteți stăpânul acelui fișier și trebuiți consultați înainte de a efectua modificări. Evitați astfel și animozități create în situații în care o a n-a persoană face modificări asupra fișierului, și dorește să-și treacă numele în lista autorilor (după ce cantitate/procent de modificări primește acest privilegiu; ce fel de modificări trebuie să fie acestea (whitespace sau coding-style cleaning se pun?)). Sistemul de gestiune a versiunii ar trebui să se ocupe de gestiunea modificărilor. Accesul de commit în sistemul de gestiune a versiunii trebuie să fie granular: un membru trebuie să aibă acces de commit doar pe componentele pe care lucrează. == Rezolvarea conflictelor (Monica) == Invariabil, in implementarea unui proiect se ajunge intr-un stadiu in care grupul trebuie sa ia o decizie. Daca la un moment dat exista mai multe pareri legate de un anumit subiect, este responsabilitatea TeamLeaderului, sau a ProjectManagerului sa incerce sa remedieze problema. === Decizia. Metode personale. === Fiecare persoana are o metoda proprie de luare a deciziei. * creearea unei liste de avantaje si dezavantaje * aleator * primul venit primul servit * apelul la o persoana care sa ia decizia pentru noi * calculul unei “utilitati” a fiecarei optiuni Mai multe gasiti aici. === Decizia in grup. Abordari === Exista mai multe metode prin care un grup poate sa ajunga la o decizie in cazul unui conflict. Majoritatea sunt inspirate din modalitatea de decizia a unei singure persoane. * competitia ideilor - fiecare dintre optiuni este compatuta pana cand toata lumea ajunge la aceeasi parere * compromisul - ideea adoptata pana la urma, este una de mijloc care include cat mai multe din avantajele ideilor in conflict * votul - cand persoanele implicate au pareri puternice, se ajunge la vot si majoritatea castiga * impunerea - persoana care are mai multa autoritate impune decizia care va fi luata === Calea spre decizie. === O zicala japoneza spune “No decision should take longer than the time required to draw seven breaths.”. Desi aplicarea mot-a-mot in project management ar putea sa nu fie cea mai buna idee, putem trage niste concluzii importante: * sa stii cand o decizie trebuie luata * sa delimitezi timpul cat mai bine pnetru luarea deciziei * acceptarea responsabilitatii pentru decizia in cauza Intrebari importante care trebuie sa fie luate in seama in luarea unei decizii: * Cat de importanta este decizia? Care sunt consecintele deciziei? * Au fost cercetate toate optiunile? * Cat de clara este imaginea pe care o avem acum asupra problemei? - foarte des desi o situatie pare familiara, ea poate sa fie cu totul diferita. Nu este bine sa luam o decizie bazandu-ne numai pe deciziile de pana acum * Chiar si deciziile minore pot avea efecte majore! O metoda des intalnita este creearea unei spirale care sa contina Nevoia principala de la care s-a pornit precum si metodele gasite si rezoltatele scontate. Se doreste o abordare cat mai pragmatica si determinista pentru luarea deciziei optime. Se cunatifica rezultatele obtinute functie de timp si chelutieli si se asociaza un factor de utilitate fiecarei optiuni. Apoi cu toata diagrama in fata se poate lua o decizie cat mai informata. === Exercitiu. === Un mic exercitiu de decizie, care nu are legatura cu software management. Fie doua persoane, un barbat si o femeie care incearca sa faca rost de un taxi. Se opreste o masina si amandoi se indreapta catre ea. Sa se decida cine va lua taxiul. Ipoteza * Nu mai exista nici un taxi disponibil! * Amandoua persoanele au nevoie urgenta de taxi! * Nu pot sa ia aceeasi masina! Femeia * 40 ani * divortata, cu 2 copii in intretinere * partenera la o firma de avocatura * trebuie sa ajunga la un proces, unde este aparatoarea unui acuzat de crime in serie; ea stie ca este vinovat, dar procesul pare sa fie in favoarea ei * daca pierde procesul, isi pierde locul in cadrul firmei si implicit salariul care ii permite sa pastreze copiii in fata sotului, care are o situatie financiara mult mai stabila, dar este alcoolic Barbatul * 35 ani * broker * peste 2 saptamani se insoara pentru a doua oara, cu o femeie cu 17 ani mai in varsta, provenind dintr-o familie nobila si fiind mult mai bogata decat el * pentru a-i demonstra ei si rudelor ei ca nu se casatoreste cu ea pentru bani, ci pentru ca o iubeste s-a implicat in niste afaceri nu tocmai legale * a folosit banii clientilor in investitii neprofitabile si a pierdut banii acestora * trebuie sa ajunga la o intalnire cu un personaj care ii poate oferi informatii din interiorul unei companii, ale carei actiuni vrea sa le speculeze la bursa sperand sa castige suficient incat sa poata pune banii la loc * daca nu ajunge la intalnire la timp, pe de o parte, isi pierde postul si poate intra la inchisoare, si pe de alta parte pierde si respectul femeii pe care o iubeste Aveti la dispozitie 10 minute!**