Cum să organizați munca programatorilor cu o eficiență maximă? Una dintre metode este programarea perechilor, o variantă a tehnicii de programare agilă. Această abordare are o serie de avantaje și dezavantaje. Prin urmare, experiența practică este interesantă, pe care dezvoltatorul Phil Horovitz de la Perforce Software la împărtășit cu InformationWeek.
Conform Wikipedia, pereche de programare - o tehnică în care este creat codul sursă în perechi de oameni de programare o singură sarcină, stând la un loc de muncă. Unul dintre ei ( „master“) gestionează calculatorul și, practic, se gândește la codificare în detaliu, iar celălalt ( „Navigator“) este axat pe imaginea de ansamblu și scanează continuu codul produs de primul programator. Din când în când, schimbă rolurile.
Susținătorii acestei abordări cred că ajută să se asigure o calitate mai mare a codului prin creșterea responsabilității de dezvoltatori și codul de testare continuă, crește productivitatea și de a îmbunătăți disciplina, ca și oamenii care lucrează împreună, vor fi mai puțin distrași.
Argumentul principal împotriva este creșterea costurilor. De ce să plătiți doi programatori pentru ceea ce se poate face? Cu toate acestea, aspectul educației este trecut cu vederea. Potrivit lui Horowitz, oportunitatea de a îmbunătăți abilitățile, de a dobândi noi abilități și de a fi principalul avantaj al programării perechilor.
El a folosit această metodă într-un singur proiect, care a necesitat experiență în dezvoltarea software-ului cloud, care a lipsit de la angajații Perforce Software. Consultanții de la Pivotal Labs au oferit programe de pereche. A fost asamblată o echipă cuprinzând patru angajați din fiecare companie, compoziția perechilor schimbându-se în fiecare zi, astfel încât oamenii să poată primi abilități diferite.
Potrivit lui Horowitz, singura problemă recurentă a fost că cineva și-a încetat să-și explice acțiunile și a început să programeze în tăcere, fără a acorda atenție partenerului. Problema a fost rezolvată rapid fără interferențe exterioare. Au existat, desigur, dezacorduri, dar ele erau în general constructive și rezolvate prin discuții.
Cu toate acestea, sa dovedit că obișnuirea cu acest stil de lucru nu este ușoară. De exemplu, a fost nevoie de Horowitz o saptamana, iar cea mai grea a fost prima zi, dupa care el a gasit cu greu puterea de a merge acasa. Apoi a devenit mai ușor, dar toți aceiași participanți la proiect au simțit o oboseală puternică din cauza muncii depline. A fost dificil să ții pasul cu un coleg care se află lângă el, programând și explicând simultan noi concepte legate de limbă, procese și instrumente.
Dar există o veste bună: a doua săptămână de Horowitz complet adaptat și crede că, dacă se întâmplă să se ocupe de programare pereche, în viitor, chiar în prima zi nu va avea astfel de probleme. El a învățat deja să lucreze în perechi și consideră că una dintre competențe utile învățate în acest proiect.
În plus, acest stil a adus și alte bonusuri în plus față de sarcina inițială de formare a dezvoltării software-ului cloud. Deci, perechea de lucru conduce la un studiu aprofundat al codului din diferite părți și puncte de vedere, ceea ce este imposibil în cazul dezvoltării individuale. La urma urmei, calitatea codului crește atunci când trebuie să vă explicați și să vă apărați deciziile sau când aveți ocazia să întrebați un coleg să se oprească și să-și explice acțiunile.
Un alt avantaj este asigurarea împotriva accidentelor. Chiar dacă se întâmplă ceva cu unul dintre membrii echipei, alții o vor înlocui cu ușurință, deoarece sunt familiarizați cu instrumentele, procesele și proiectul în ansamblu. Prin urmare, în ciuda investițiilor suplimentare din punct de vedere al timpului și al resurselor umane, programarea prin pereche oferă companiei un profit.
După finalizarea acestui proiect, colegii lui Horowitz au plăcut acest mod de a lucra atât de mult încât au început să o folosească ori de câte ori era posibil. Dar sa dovedit că nu este întotdeauna suficient de bun și că este folosit acum într-o cantitate limitată.
Horowitz recomandă și CIOs șefi de departamente de dezvoltare nu se aplică pentru a asocia abordarea de „totul sau nimic“ de programare și de a folosi în cazul în care aveți nevoie pentru a extinde setul de competențe și cunoștințe al echipei de programare. În plus, o astfel de abordare poate da programatorilor un impuls pentru a trece de la stilul individual de muncă la o mai deschisă și colectivă. Și cu cât echipa a dezvoltat mai mult cooperarea, cu atât rezultatele au fost mai reușite.
isicad.ru: mai multe link-uri adăugate
Articole similare
Trimiteți-le prietenilor: