Organizarea și lucrul într-o companie de software

Un programator poate lucra nu numai într-o companie care produce software dar teoretic un programator lucrează într-o companie care produce și livrează pe piață software.

O companie de software este în primul rând o firmă și prin urmare are mai multe departamente deci nu numai departament tehnic.

Printre departamentele adiacente se numără cel de resurse umane cel juritic cel contabil cel de vânzări și așa mai departe.

Departamentul tehnic nu este numai axat pe producerea de software. În general departamentul tehnic se împarte în trei sub departamente. Departamentul care se ocupă de partea hardware departamentul care se ocupă de rețelistică și departamentul care se ocupă de producerea de software.

În cadrul departamentului care produce software există mai multe tipuri de joburi.

Primul dintre ele este cel care face legătura dintre client și dezvoltatori și se numește business analyst sau product owner. Cei care sunt încadrați pe acest job transformă cererea client în cerințe tehnice.

Al doilea tip de job este cel de project manager. Cei care sunt încadrați pe o astfel de poziție se ocupă de planificarea și bunul mers al unui proiect.

Al treilea tip de job este cel de arhitect software. Arhitectul se ocupă să creeze arhitectura unei aplicații software. Se stabilesc limbajele modulele tools framework modalitatea de implementare modul de comunicare între modurile tipul de arhitectură și așa mai departe.

Al patrulea tip de job este cel de dezvoltator. Cei care se ocupă cu acest tip de job dezvoltă aplicații software adică gândesc și scriu cod pentru un modul sau altul.

Al cincilea tip de job este cel de devops. Cei care se ocupă cu acest job creează modalități automate de integrare a surselor creează modalități automate de construcție a executabilelor și de construcție a livrabilelor. Adică compilează construiesc executabilul și fac deploy după ce au luat sursele de pe git sau alte sisteme de management al surselor.

Al șaselea tip de job este cel de quality assurance sau mai pe scurt tester. Cei care se ocupă cu acest job au grijă ca aplicațiile să nu aibă nimic în neregulă și pentru asta le testează.

Al șaptelea tip de job este cel de scrum master. Acesta are grijă ca în fiecare zi proiectul să se dezvolte fiind un fel de maestru de ceremonii agile care ține în fiecare zi ședințe și se interesează de cum merg lucrurile. Ce a făcut fiecare în ziua precedentă ce urmează să facă în ziua curentă și dacă este undeva un blocaj și echipa poate ajuta sau altcineva din afară echipei.

Oamenii sunt împărțiți în echipe mici de maxim 10 persoane numite echipe de scrum în care ca la fotbal există formule de lucru. De exemplu formula 1-1-4-2-2. Adică un BA/PO (business analyst/product owner) 1 arhitect 4 dev (developers) 2 DevOps 2 QA (quality analyst).

Aceste echipe în fiecare zi au cel puțin o întâlnire care se numește daily stand up meeting în care așa cum spuneam mai sus spun care este starea curentă a ceea ce fac.

Fiecare membru al echipei are la un moment dat de lucru la un task. Aceste task-uri sunt cuprinse în așa numitele sprinturi. Un sprint este o perioadă scurtă de timp de regulă de două săptămâni în care se propune ca echipa să realizeze ceva. Pe lângă ședința de daily mai sunt și alte ședințe regulate în care se planifică un sprint sau se face review la un sprint sau se analizează și se discută anumite story din backlog. Așa numitele ședințe de planning review și rafinament. Pe lângă aceste ședințe regulate mai sunt și ședințe ocazionale pentru dezbaterea unor probleme.

Din punctul de vedere al organizării muncii aceste taskuri fac parte din ceva mai mare care se numesc story. Acestei story sunt de fapt transformarea cererii client în cerința software. În timp ce cererea client se numește epic. Un epic poate avea mai multe story iar un story mai multe taskuri. În cazul în care echipa de q&a găsește ceva în neregulă înainte ca produsul să intre în producție atunci se pot pune defecte în timp ce dacă este găsit ceva în neregulă după ce aplicația a intrat în producție se pun bug-uri. Acesta se rezolvă cu prioritate maximă. Fiecare story este măsurat în story points. Care reprezintă nivelul de complexitate al cerinței. Și care ajută compania să își dea seama de capacitatea de lucru a unei echipe sau a unui om.

Din puncte de vedere ierarhic există interni care pe românește sunt cei care fac practică. Apoi există juniori middle și seniori. Dintre programatorii seniori se aleg lead. Lead este considerat omul principal din fiecare echipă (Dev, devops, q&a ,BA) cu care de regulă se consultă arhitectul. A nu se confunda termenii pentru că există lead și team lead. Nu de fiecare dată un programator lead este și team lead. În o echipă team lead este arhitectul dacă acesta există în echipă respectivă iar în cazul în care nu există este programatorul lead.

Pe linie de raportare junior middle și senior raportează către lead iar lead către arhitect. În timp ce arhitect raportează către project manager. Aceste clase sunt atât pe partea de development cât și pe partea de devops cât și pe partea de q&a cât și pe partea de arhitectură și BA/PO.

Nici una dintre echipele mai sus menționate nu este mai importantă decât cealaltă pentru că dezvoltarea unei aplicații software este un ecosistem în care fiecare echipă și fiecare om din echipa este o părticică indispensabilă prin rolul pe care îl joacă.

Este bine să existe o comunicare bună și o relație bună între echipe astfel încât proiectul să se dezvolte în condiții optime.